->PSM

Where is the client hello message generated?  In PSM? in NSS? or in the
browser.

Please read the discussion in bug 116168.

Mass reassign ssaux bugs to 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.

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?

bug 76162 is resolved because it does NOT report a bug nor request an 
enhancement in any mozilla product.  By that measure, it is invalid.  
It should stay resolved.  However, you can mark it as blocking this
(or better as blocking 116168).  And you can join the cc list of bug 76162.

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.

Created attachment 182158 [details]
Preliminary patch adding SNI support to the TLS Client Hello.

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.

Comment on attachment 182158 [details]
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
.

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.

Ooops bug 116168 is the NSS portion of this bug. Returning this back to PSM. 

(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.