As the IETF finalizes DNSName support, the browser will need to implement the DNSName string to pass along in the SSL clienthelo message, so that TLS servers can do virtual hosting and use a different security policy/identity .
Severity: normal → enhancement
OS: other → All
Priority: -- → P2
Hardware: Other → All
Assignee: mstoltz → ssaux
Component: Security: General → Client Library
Product: Browser → PSM
QA Contact: bsharma → junruh
Version: other → 2.2
Where is the client hello message generated? In PSM? in NSS? or in the browser.
Target Milestone: --- → Future
Please read the discussion in bug 116168.
Summary: Browser support for DNSName → Browser support for server name indication
Summary: Browser support for server name indication → Browser support for TLS server name indication
Mass reassign ssaux bugs to nobody
Assignee: ssaux → nobody
Mass change "Future" target milestone to "--" on bugs that now are assigned to nobody. Those targets reflected the prioritization of past PSM management. Many of these should be marked invalid or wontfix, I think.
Target Milestone: Future → ---
I've started work on a patch to implement this. I've got NSS sending the domain it's interested in as per RFC3546. I'm now looking at how to figure out what the domain name the browser was expecting so I can send that (instead of the fixed string "example.com").
The application generally tells NSS what host name or URL it wants using the SSL_SetURL call. See http://lxr.mozilla.org/security/ident?i=SSL_SetURL The value set here is used by the default certificate validation routines, so most applications will call it. If it's not set, you just won't be able to send the host name in the extension.
Terry, good to see you post in bugzilla ! Perry, Nelson mentioned the following issue earlier in a n.p.m.crypto message about client-side TLS server name indication implementation : <quote> The big impediment to this is the continued existance of SSL2-only servers. There are still some big-value heavily-used SSL servers out there that speak only SSL2. Here's one: https://webmail.aol.com/ In order to use the "server name indication" TLS extension, the client must send out an SSL3/TLS style "client hello" message as the first message it sends to the server. And today, most browsers do not do that. They send out SSL2 style hellos, which cannot use that extension. Here's why. If the client sends an SSL3/TLS style hello to the server, and the server is an SSL2 (only) server, the server will misinterpret this SSL3/TLS style hello as a very large SSL2 style record, and will wait a long time (maybe as little as 30 seconds, or maybe much longer) for the rest of the message to come in. This appears to a browser user as a "hung" connection, and tends to anger browser users ("damn browser!"), even though it is no fault of the browser's. To avoid that, browser products continue to this day to send out ssl2-style client hello messages, which make SSL2 servers happy, and which SSL3/TLS servers interpret as SSL3/TLS hellos. But there is no way to put the new "server name indication" into an SSL2-style client hello. When all the big-value SSL servers finally all upgrade to newer server software than understands more than just SSL2, I think you'll see this new "server name indication" come into play. </quote>
You could do something like speak SSLv2, if you get a "certificate doesn't match the hostname" error, retry with SSlv3. Bigname sites aren't going to have bad certificates that don't match their hostnames, but people that do need sslv3's ability to negotiate certificates will be able to use the feature (at a cost of speed). When the SSLv2 sites all vanish from the Internet, this can then be moved to default to v3 only. Would this be achievable?
Perry, Re: comment #9, that would be achievable, but would require a combination of both NSS patches and browser networking code change. NSS would need an option to select whether to use V2 or V3 client HELO message. The browser would need to try V2 first, and then upon hostname failure, retry with V3 . I'm not familiar with the networking code in the browser so I'm not sure how hard this is to achieve. If there is still an error though, and it is a different error in the 2nd connection, the browser would need to decide which error to handle and disdplay to the user. Also, SSL2 hosts with mismatched cert hostname may still lead to a V3 HELO being used by the client, and thus a long timeout, if the server software is incompatible with V3 HELO. There is no perfect solution here. My personal view is : 1) NSS should add a socket option to use V3 client HELO 2) the browser should set it at all times, except if SSL2 is enabled 3) the browser should have SSL2 disabled by default 4) if both SSL2 and SSL3/TLS are enabled, the browser should use your proposed 2 connections strategy 5) open bugzilla "hall of shame" evangelism bugs to track all SSLv2-only sites that hang with V3 HELO . And maybe add that as a URL blacklist to the browser, or something
Julien, NSS's libSSL already has an option to disable SSL v2 compatible client hellos. The option is SSL_V2_COMPATIBLE_HELLO, which is on by default. There is already an SSL2 "hall of shame" bug, bug 76162 Perry, PSM already has code to try negotiating TLS (SSL 3.1) first, and if that fails then back off and try negotiating SSL 3.0. Today it tries both of those using SSL2 style client hellos. But it could conceivably try first with an SSL3/TLS style client hello, and then back off first to SSL 3.0 and then lastly try SSL2 with an SSL2 hello. If it tries an SSL3/TLS style client hello with an unknown server, it would need to set a time limit on that socket, since SSL2-only servers will hang a LONG time waiting for that handshake to finish. These are all PSM changes being suggested. No NSS changes needed. I, too, think it's time for us to help those old SSL2-only servers into retirement.
Julien: If we try SSLv3 first on a v2 only site, it's going to hang until one or the other party times out. This can be mitigated by setting the timeout very very low. But if you do that then you run the risk of temporary internet fluctuations or people on weird connections (satellite?) hitting the timeout. Thats why I suggested doing v2 and only doing v3 if the certificate didn't match the hostname. One way or another you're going to get a problem with this connection if it's v2 with a bad certificate either from a timeout (and perhaps falling back to v2 again), or having to deal with a certificate that doesn't match the sites host. Nelson: Is there a small enough list of high profile sslv3 ignorant sites to just blacklist those that cause an issue and ship a standard blacklist? Bug 76162 seems to suggest that the list is small, there are only a few sites added over the space over a few years (however the bug was closed, should it be reopened and have this bug depend on it?). Would just blacklisting the handful of sites listed there be enough to avoid widespread breakage? Either way, this discussion is kinda of irrelevant until mozilla supports Server Name Indication with SSLv3 which is what I'm trying to achieve here. IMHO Selecting when to use SSLv3 or to use SSLv2 is another issue entirely. So, as an aside, does anyone have any servers that support Server Name Indication around that I could test against?
mod_gnutls now supports SNI. I have setup a test server at: https://sni.corelands.com/ (default for the IP) https://one.sni.corelands.com/ https://two.sni.corelands.com/ https://three.sni.corelands.com/ https://four.sni.corelands.com/ This works correctly with Opera 8.0.
One not on retries, by the time you get to the ssl server name mismatch, you already know if the server is SSL2 or not. The resulting server hello will be different for SSL2 servers and SSL3 aware servers (assuming the client has SSL3 and/or TLS turned on). The client can query the socket to see if it's and SSL2 server before attempting to use TLS server name indication... bob
Bob, I don't think testing for SSL2 first is a workable approach to check for SNI support. An SNI-aware server can decide to have completely different SSL policies based on the absence or value of the SNI from the client hello, including selecting a different protocol (SSL2, SSL3, or TLS). So, sending a v2 client hello without the SNI could result in the server selecting SSLv2 because it's configured to do that for the "no SNI" case; but the same server might select TLS with a different server cert if sent a v3 HELO including a particular SNI. I'm not saying it's going to be a common configuration (it's probably not a very useful one in fact), but nevertheless it's one of the cases that SNI allows, and the client can't make any assumption about the "default" policy of the server in the absence of an SNI . Unfortunately, to get any information about the server's policy with SNI, you have to send a v3 client HELO including an SNI, which may hang old SSL2-only servers. But I still think that's the first thing the browser should try. If it's taking a while (but not as long as 30s, maybe 5s), then the browser could try a second connection concurrently with a v2 HELO, and if it's established quicker than the first one, drop the first connection . This should be a browser option that the user should be able to disable.
This (preliminary) patch appears to work with pquerna's test servers. You also need to apply the patch I attached in bug 284450 and disable SSLv2. Argu^WDiscussions about how to automatically determine when to stop using v2CompatibleHello is left as an exercise for the reader.
An TLS v2CompatibleHello could be sent, the server replies saying it supports TLS, the client could then immediately send a new TLS Hello with SNI (TLS allows the client to send a TLS Hello at any point in the connection, so this is valid and already supported by TLS servers). If the server wants to speak SNI it will just have to make sure it supports upgrading to TLS SNI via a TLS hello. AFAIK pquerna's SNI test server is the only SNI server being used in any real way on the Internet today. What browsers require will define how servers are configured. This method seems to avoid lengthy waits on SSLv2 servers for them to timeout and should still be 100% compatible with SSLv2, SSLv3 and TLS servers. When we finally disable SSLv2 by default on our browsers, this ugly hack can go away and we can go straight to TLS hellos. The code needed in mozilla is to detect TLS server-hello replies to v2CompatibleHello's and reissue a v3 hello. The certificate on the server-hello would need to be ignored (and certainly not popup a nasty dialog asking users if they trust the certificate!).
Perry, this bug is for PSM, the browser code related to NSS. Since NSS is a separate product, it needs a separate bug. Bug 116168 is the corresponding bug for NSS. Since your patch is for NSS, please attach it to bug 116168 instead. This bug is intended for any UI or PSM changes needed in order to support the use of these extensions. There have been suggestions about dropping connections as soon as the server is found to support TLS, and starting over with an SSL3/TLS client hello, as IE does. Such a behavioral change is outside the scope of NSS, and involves PSM, and perhaps the higher-level code also. Those changes would be attached to this bug. I think that, rather than hard coding the implementation of this one extension in-line inside the code that generates an SSL3/TLS client hello, we should add support in a general way for the many new TLS extensions. I imagine that there will be one or more new methods (possibly callbacks) for constructing extensions that will be invoked early in the process of generating the client hello. We need to think about that carefully, since once we add a new public function or callback interface to NSS, we have to support it forever. So, we don't want to hastily add an interface that we'll later regret.
Component: Security: UI → Security: PSM
Comment on attachment 182158 [details] [diff] [review] Preliminary patch adding SNI support to the TLS Client Hello. Perry, thanks for your patch. Since it is an NSS patch, and not a PSM patch, I will continue the discussion of that patch in bug 116168 . You should attach your updated patch to that bug .
Attachment #182158 - Flags: review-
IE 7 will by default be disabling SSLv2 in favor of TLSv1. After they take that step, it would be reasonable for Mozilla products to do the same. http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx
Changing product and adding additional players to this bug.
Component: Security: PSM → Build
Product: Core → NSS
Target Milestone: --- → 3.12
Version: psm2.2 → 3.0
Ooops bug 116168 is the NSS portion of this bug. Returning this back to PSM.
Component: Build → Security: PSM
Product: NSS → Core
Target Milestone: 3.12 → mozilla1.9alpha
Version: 3.0 → 1.0 Branch
(In reply to comment #14) Paul Querna wrote: > mod_gnutls now supports SNI. I have setup a test server at: > https://sni.corelands.com/ (default for the IP) > https://one.sni.corelands.com/ > https://two.sni.corelands.com/ > https://three.sni.corelands.com/ > https://four.sni.corelands.com/ I've been playing with it. Some of the certs are now expired. Sometimes it seems to work. Other times it seems to return an alert with description decimal 206. That doesn't seem to be a defined TLS alert description. What's it mean? why do I get it?
Is it still necessary to have a patch in PSM? I hope when the browser wants to open a connection, it will pass the original hostname to PSM, and PSM will pass the hostname to SSL when opening the connection. Is this sufficient?
SNI support was added to FF2 when FF2 was first released.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.