I wrote:
>>> There is no unique IP address required any more.  Modern TLS implementations
>>> like the one in Mozilla products, allow the client and server to negotiate
>>> the host name over the SSL connection, before the server presents its cert,
>>> So that the server can pick the right cert.  It's good old virtual hosting,
>>> done with https.  Works well.

Dave Townsend wrote:
>> Ah interesting, I was under the impression that bug 276813 was required 
>> for that sort of thing. I shall have to take a look over some popular 
>> hosts to see whether they offer this. Out of interests besides Mozilla 
>> do other browsers support this, IE? Safari? Opera?

Nope.  That's something else, an alternative proposal that (IMO) has been
roundly rejected by the SSL and http implementors of the world.

Eddy Nigg (StartCom Ltd.) wrote:
> To all of my knowledge this works only if the various domain names are 
> bundled in one certificate as DSN extensions. I'm not aware that one can 
> host multiple certificates and multiple hosts on one and same IP address 
> and port (443).

Well, then let me introduce you to "Server Name Indication" (SNI).  It's
SSL on port 443 (could be any port, such as the port for IMAP-over-SSL, that
negotiates SSL before starting the application protocol [http, IMAP, etc.]).

The client tells the server, in the SSL/TLS "client hello", the name of
the server that it's trying to contact at that address/port.  The server
then uses that information to switch to the virtual host named in the SNI,
and also to switch to the certificate for that virtual host.  Each Virtual
host has its own certificate.  The server sends to the client the cert
for the virtual host that the client wants to see.  The client sees no
host name mismatch.  Everyone is happy.

This simplifies things for server admins a LOT because there's no need to
have the hosting service try to get one cert with dozens (hundreds?
thousands?) of host names in it.  The hosting admin can let each of
his customers who wants to use SSL by his own separate cert, and he
merely puts all those certs into his server.

NSS supports SNI on the client side.  Mozilla browsers have supported
SNI beginning with FF 2.0.  It's just in there.  No feature to enable.
It's incompatible with SSL2, so SSL2-format client hellos must be
disabled to use it, and they are disabled (by default) in FF2.

Vista supports SNI, too (it's tied to the SSL code in the OS, not to
the browser version, so XP users of IE7 don't get the feature, AFAIK).

For your reference, the b.m.o bug for adding client SNI to NSS was bug
    https://bugzilla.mozilla.org/show_bug.cgi?id=116168
The bug for adding server side SNI to NSS is bug
    https://bugzilla.mozilla.org/show_bug.cgi?id=360421
The RFC that defines SNI is RFC 4366, pages 9-10.
    http://www.rfc-editor.org/rfc/rfc4366.txt

-- 
Nelson B

_______________________________________________
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto

Reply via email to