1153486 - server name indication tls broken for IIS 8.5 hosted sites (at least)

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Henrik Hudson]

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.

Comment 1

[Matthias Versen [:Matti]]

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.

Comment 2

[Loic]

Probably because your server is TLS intolerant (only 1.0 supported).
We need a public URL to test.

Comment 3

[Henrik Hudson]

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

Comment 4

[Loic]

It would be nice to have the test log from https://www.ssllabs.com/ssltest/

Comment 5

[Henrik Hudson]

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.

Comment 6

[Henrik Hudson]

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.

Comment 7

[Henrik Hudson]

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.