Firefox Nginx configuration problem


#1

So. I played with nginx conf for better rating in SSL Server Test
Reached 100/100/90/100 with ECDHE
https://www.ssllabs.com/ssltest/analyze.html?d=eressea.xyz&hideResults=on

But, after some time in Firefox site doesn’t load at all - just blank page (not even green lock)

Nginx conf: https://gist.github.com/anonymous/c1bc7ed16780b59ead1b


#2

You really don’t need to aim for all 100. It really limits compatibility.

The connection shows as “aborted” for me, so it’s likely some issue with the certificate. I’d suggest loosening up a few things and then test one after another. Since the connection is being aborted quickly, I’m guessing it’s going to be more related to the key pinning you’re doing or some other basic-level issue.


#3

Thanks for answer .
I doesn’t aim for full 4x100, (this is reason why i have TLS 1) and i satisfied with compatibility list

Is there any way to check what exactly is going on? firefox dev tools doesn’t say to me much


#4

I just disabled http2 and spdy support in Firefox, and the site loaded. It looks like it’s something involved with that.


#5

Thanks.
Disabled http2 and site loaded. So is this nginx or firefox problem ?
Downgraded config to spdy.


#6

I’m not really sure. I’ve yet to gain a lot of experience with HTTP/2 or SPDY debugging. Given other sites seem to work with no issues, I’m inclined to think it’s related to your configuration but can’t say for sure.


#7

It can be very rare problem, because i use - armhf and libressl in nginx.
Anyway Thanks you.


#8

It is impossible to force 256-bit encryption and HTTP/2 at the same time without breaking compatibility with Firefox. Your site wasn’t loading because of RFC7540 Appendix A violation.

You MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

ssl_ciphers ‘ECDHE+CHACHA20:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE+AES256+SHA384:ECDHE+AES256+SHA’;


#9

The connection shows as “aborted” for me, so it’s likely some issue with the certificate. I’d suggest loosening up a few things and then test one after another. Since the connection is being aborted quickly, I’m guessing it’s going to be more related to the key pinning you’re doing or some other basic-level issue.

Recently I was having my site not loading in Firefox (but I didn’t try anything else), so I recreated my private CA from scratch. Then I realized the problem was with nginx conflicting parameters related to elliptic curves and session resumption.

Whenever your nginx-powered site doesn’t load without a single browser error, inspect TLS configuration first, don’t mess with certificates, unless you want to waste your time.


#10

Thanks.
I changed nginx config to
ssl_ciphers ‘ECDHE+CHACHA20:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE+AES256+SHA384:ECDHE+AES256+SHA’;

But, site not loading in firefox.

Even if i have only:
ssl_ciphers ‘ECDHE-RSA-AES128-GCM-SHA256’;


#11

Works for me:


#12

Works now.
Looks like just clearing cache isn’t enought for firefox.

So. With ECDHE-RSA-AES128-GCM-SHA256 I dowgrade Cipher Strength to 90.
Looks like that there a choose between 256 bit keys and HTTP/2 - strange for new standart


#13

Most of HTTP/2 clients support compliant 256-bit encryption, except Firefox, and soon Googlebot, unless they add more cipher suites when adding HTTP/2.


#14

I think better solution than drop 256bit keys will be drop http/2 for firefox.


#15

Among 128-bit encryption, you only need to support AES_128_GCM, you should be OK with it.

P.S. Привет курганским!


#16

Hope that AES_128_GCM will be ehough. But anyway - it’s odd to downgrade security for http/2 support.

Вот так всегда =D.


#17

So. To finish it - Does current ciphers setup enoght (or redundant) ?


#18

Should be enough unless you need to support Android 2 and Internet Explorer on Windows XP, but their market share is very low.


#19

Look like Android 2 have around 4%

To support Android it required to bring DH, but i want to stay on ECDHE

I think good way will be some redirection for users of non supported browsers.

But problem that TLS established before HTTP - so user will see message about security error first, and only after it will be redirected


#20

Redirection is possible for visitors who don’t specify HTTPS (and those who don’t click on HTTPS links somewhere). How about just leaving such visitors on HTTP? Even Google does this.