Closed Bug 1153486 Opened 5 years ago Closed 5 years ago
server name indication tls broken for IIS 8
.5 hosted sites (at least)
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20150407225957 Steps to reproduce: I was setting up some internal SSL sites on IIS 8.5 (Server 2012R2) with SNI (Server Name Indication) enabled. I've got 3 URLs sharing a single IP and all our SSL is enabled via a internal CA. Both of the CA certs are added to my trust store in Firefox. Browsing to any of the URLS throws an error about the connection being unencrypted and won't complete. I've verified it works correctly with: Firefox 36 (Windows) curl command line with cacert option (FreeBSD) IE 11 (Windows 7 and Server 2012R2 install) Chromium (FreeBSD) It fails on: Firefox 37.0.1 (Windows) Firefox 37.0.1 (FreeBSD) I'm guessing it's related to reverting the opportunistic encryption change from 37 -> 37.0.1, but I was under the impression that was for HTTP/2 . I'm connecting to stock IIS (default OS level encryption types enabled) on a Server 2012R2 machine with 3 URLs bound to a single IP with the "SNI enabled" checkbox and the URLs added to the host field. I was able to verify it works okay talking to an Apache Server with SNI hosts. Actual results: Browser showed an error about the https:// session being unencrypted. Secure Connection Failed The connection to the server was reset while the page was loading. Something with the SNI host header and TLS isn't stepping up. Expected results: The page should have displayed with SSL enabled.
Do you have a public URL for a test ? You could also try to find a regression range using http://mozilla.github.io/mozregression/ but only Linux/OSX/Windows are supported by that tool.
Component: Untriaged → Security: PSM
Product: Firefox → Core
Probably because your server is TLS intolerant (only 1.0 supported). We need a public URL to test.
Component: Security: PSM → Desktop
Product: Core → Tech Evangelism
Version: 37 Branch → Firefox 37
Working on public IP. Here is the curl -v -v output. It's TLS v1.2. * Rebuilt URL to: https://someserver.url.com/ * Trying 10.x.x.xx... * Connected to someserver.url.com (10.x.x.xx) port 443 (#0) * successfully set certificate verify locations: * CAfile: /data/shares/temp/CA.pem CApath: none * TLSv1.2, TLS handshake, Client hello (1): * TLSv1.2, TLS handshake, Server hello (2): * TLSv1.2, TLS handshake, CERT (11): * TLSv1.2, TLS handshake, Server key exchange (12): * TLSv1.2, TLS handshake, Server finished (14): * TLSv1.2, TLS handshake, Client key exchange (16): * TLSv1.2, TLS change cipher, Client hello (1): * TLSv1.2, TLS handshake, Finished (20): * TLSv1.2, TLS change cipher, Client hello (1): * TLSv1.2, TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384 * Server certificate: * subject: C=US; ST=State; L=City; O='Org'; OU='Division'; CN=url.com * start date: 2015-04-10 22:44:00 GMT * expire date: 2020-04-08 22:44:00 GMT * subjectAltName: someserver.url.com matched * issuer: DC=com; DC=url; CN=Internal SubCA * SSL certificate verify ok. > HEAD / HTTP/1.1 > User-Agent: curl/7.41.0 > Host: someserver.url.com > Accept: */* > < HTTP/1.1 200 OK HTTP/1.1 200 OK < Cache-Control: private Cache-Control: private < Content-Length: 23070 Content-Length: 23070 < Content-Type: text/html; charset=utf-8 Content-Type: text/html; charset=utf-8 < Server: Microsoft-IIS/8.5 Server: Microsoft-IIS/8.5 < Set-Cookie: dnn_IsMobile=False; path=/; HttpOnly Set-Cookie: dnn_IsMobile=False; path=/; HttpOnly < Set-Cookie: .ASPXANONYMOUS=HHvUpyqr0AEkAAAAM2M4NzAyYmEtZWU1MC00YjllLWJlZTAtZTNlODgzMTJlMTMx0; expires=Sa Set-Cookie: .ASPXANONYMOUS=HHvUpyqr0AEkAAAAM2M4NzAyYmEtZWU1MC00YjllLWJlZTAtZTNlODgzMTJlMTMx0; expires=Sat, < X-AspNet-Version: 4.0.30319 X-AspNet-Version: 4.0.30319 < Set-Cookie: dnn_IsMobile=False; path=/; HttpOnly Set-Cookie: dnn_IsMobile=False; path=/; HttpOnly < Set-Cookie: .ASPXANONYMOUS=HHvUpyqr0AEkAAAAM2M4NzAyYmEtZWU1MC00YjllLWJlZTAtZTNlODgzMTJlMTMx0; expires=Sa Set-Cookie: .ASPXANONYMOUS=HHvUpyqr0AEkAAAAM2M4NzAyYmEtZWU1MC00YjllLWJlZTAtZTNlODgzMTJlMTMx0; expires=Sat, < Set-Cookie: language=en-US; path=/; HttpOnly Set-Cookie: language=en-US; path=/; HttpOnly < X-Powered-By: ASP.NET X-Powered-By: ASP.NET < Date: Sat, 11 Apr 2015 20:48:10 GMT Date: Sat, 11 Apr 2015 20:48:10 GMT < * Connection #0 to host someserver.url.com left intact
It would be nice to have the test log from https://www.ssllabs.com/ssltest/
I setup a Azure Server2012R2 instance and it works fine there with a GoDaddy wildcard cert. So, I will poke at our internal servers and see what's up. They shouldn't be doing anything weird, so perhaps it's a problem with the internal CA. It is weird that it works fine with Firefox 36, but not 37, and our internal CA certs work fine when I switch to a single SSL site per IP. Perhaps the port forwarding from Azure is cleaning something up. I don't know. I'll report back.
Adding the sites in questions to this key: security.tls.insecure_fallback_hosts fixes this issue. According to this thread: http://forums.mozillazine.org/viewtopic.php?f=38&t=2927051 So, Firefox is checking to see if something exists and failing, even though the server can support better encryption? TLSv1.2 is available. It looks like Firefox, according to the technical details section of the "Security" tab is using: TLS_ECDHE_RSA_WITH_AES256_CBC_SHA, 256 bit keys, TLS 1.1) to complete the connection once the insecure fallback is implemented. So, it doesn't seem to try to force v1.2 either and seems to default to a lower method vs. the highest available. You can close this. I guess it's more of a caveat emptor for others.
In addition, our CA was configured to use a SHA-512 hash which isn't a legit hash size for TLS1.2 , so it was failing to find a TLSv1.2 cipher it could use. TLS v1.2 only supports SHA-256 or -384.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.