Closed Bug 960844 Opened 9 years ago Closed 8 years ago

https://atakemlak.sahibinden.com does not load in Firefox (ssl_error_unrecognized_name_alert), but does in other browsers

Categories

(Web Compatibility :: Desktop, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: mwobensmith, Unassigned)

Details

https://atakemlak.sahibinden.com produces an SSL error in Firefox - all versions:

"SSL peer has no certificate for the requested DNS name. 
(Error code: ssl_error_unrecognized_name_alert)"

For me, site loads in both Chrome and Safari. 

Not a regression, behavior goes back to at least FF10 (as far back as I can check, NSS version unknown).
(In reply to Matt Wobensmith from comment #0)
> For me, site loads in both Chrome and Safari. 

Chrome on Mac, right? Which version?

https://atakemlak.sahibinden.com/ fails to load in Chrome 32.0.1700.76 m for me with ERR_CONNECTION_RESET.
https://atakemlak.sahibinden.com/ does load in
Target Milestone: --- → 3.15.5
Version: 3.16.5 → trunk
https://atakemlak.sahibinden.com/ does load in MSIE 11 on Windows 8.1 for me.
The server's response to Chrome's TLS 1.x ClientHello is a
TCP reset. Chrome is only willing to fall back to TLS 1.0 on
ECONNRESET. It is not willing to fall back to SSL 3.0 on ECONNRESET.
This is why Chrome fails with ERR_CONNECTION_RESET after
falling back to TLS 1.0.

The server's response to Firefox's TLS 1.0 ClientHello is
a TLS 1.0 unrecognized_name alert.
A fairly peculiar piece of software which is running at 85.111.30.111, it seems. There's actually a wildcard DNS RR for *.sahibinden.com, so it feels a bit strange that it has decided to take the first route from RFC 6066 (section 3):

   If the server understood the ClientHello extension but
   does not recognize the server name, the server SHOULD take one of two
   actions: either abort the handshake by sending a fatal-level
   unrecognized_name(112) alert or continue the handshake.

In contrast to other implementations (based on RFC 4366, which does not include the above snippet), this implementation indeed sends fatal-level alerts. It seems to do so for all names supplied in an SNI extension, however (even for www.sahibinden.com, which is the PTR record for 111.30.111.85.in-addr.arpa), so probably something is misconfigured in any case. (The Server: header says "Sahibinden Web Servers", though it looks like reverse proxying is in play.)
(In reply to Wan-Teh Chang from comment #4)
> The server's response to Chrome's TLS 1.x ClientHello is a
> TCP reset.

On Windows 8.1, in Wireshark, I see Chrome 32 getting unrecognized_name alerts. Is Chrome doing TLS intolerance in response to unrecognized_name alerts? I searched the Chrome source code and didn't see any special handling of SSL_ERROR_UNRECOGNIZED_NAME_ALERT. I suspect that Chrome is processing the RST that happens after the SSL_ERROR_UNRECOGNIZED_NAME_ALERT without processing the SSL_ERROR_UNRECOGNIZED_NAME_ALERT message itself. If it processed the SSL_ERROR_UNRECOGNIZED_NAME_ALERT message first, then I would expect that it would not invoke TLS intolerance fallback. That seems like a bug in Chrome. What do you think, Wan-Teh?

-> Tech Evangelism for three reasons:
(0) This is not a NSS bug
(1) Website has a broken configuration (thanks for investigating this, Kaspar)
(2) Looks like a bug in Chrome and MSIE that Gecko shouldn't try to be compatible with.
Assignee: nobody → english-us
Component: Libraries → English US
Flags: needinfo?(wtc)
Product: NSS → Tech Evangelism
Summary: https://atakemlak.sahibinden.com does not load in Firefox, but does in other browsers → https://atakemlak.sahibinden.com does not load in Firefox (ssl_error_unrecognized_name_alert), but does in other browsers
Target Milestone: 3.15.5 → Feb
Version: trunk → Trunk
The unrecognized_name alert is not always received by the browser.
If you reload the page in the browser, the page will eventually be
loaded successfully. (If unrecognized_name is received, Chrome works.
If unrecognized_name is not received, Firefox works.)

Brian, you're right that Chrome's error code mapping does not single
out SSL_ERROR_UNRECOGNIZED_NAME_ALERT, so the unrecognized_name alert
triggers an SSL/TLS version fallback. I will fix that. Thanks.

The SSL Server Test of Qualsys SSL Labs says this server is intolerant
of TLS extensions.
Flags: needinfo?(wtc)
(In reply to Wan-Teh Chang from comment #7)
> Brian, you're right that Chrome's error code mapping does not single
> out SSL_ERROR_UNRECOGNIZED_NAME_ALERT, so the unrecognized_name alert
> triggers an SSL/TLS version fallback. I will fix that. Thanks.

OK, I think I understand now. Is it the case that Chrome's error mapping maps specific NSS errors to specific Chrome errors, and the ones that don't have a specific mapping get mapped to a generic "SSL Protocol Error" error? And, then TLS intolerance is done for "SSL Protocol Error"? If so, this means that Chrome will be (much?) more liberal about TLS intolerance than Firefox. Perhaps it would be better to switch Chrome to use a whitelist of more spceific error codes like Firefox?:
https://hg.mozilla.org/releases/mozilla-beta/file/3fe1886a46c8/security/manager/ssl/src/nsNSSIOLayer.cpp#l926. Otherwise, Mozilla will feel pressure to make our TLS intolerance logic more liberal to work with the same sites as Chrome and MSIE. But, I think moving in the other direction is better, if it is reasonable to do so.
BTW, SSL_ERROR_RX_RECORD_TOO_LONG is another error code that Chrome has historically treated as TLS intolerance but which Firefox does not, and this has caused us trouble in the past. SSL_ERROR_RX_RECORD_TOO_LONG is almost always the result of the server returning plain-text HTTP response to the ClientHello, instead of talking TLS. I don't think that is a good problem to do TLS intolerance fallback on.
This is working for me Firefox 32.0.3
Assignee: english-us → nobody
Status: NEW → RESOLVED
Closed: 8 years ago
Component: English US → Desktop
Resolution: --- → WORKSFORME
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.