Re: [TLS] Renegotiation with SNI after initial connection without SNI (was Questions about TLS Server Name Indication extension)

[Michael D'Errico <mike-list at pobox.com>]

The desire seems to be to have a way to first negotiate a secure channel
to a machine, then to perform the intended handshake over this secure
channel to keep the real handshake private.

This could be done by adding a new NameType to the SNI extension.  This
new NameType would let the server know that it is performing a handshake
merely to create a private channel over a public medium like the Internet.
Immediately following the negotiation of this secure connection, the
client would be required to perform the intended handshake.  Note that
the session ID specified by the client in the 2nd handshake would be
empty.  The "name" associated with this name type would most likely be
empty (two zero bytes indicating zero length) since it means "the host
I'm connected to".

Both handshakes could return non-empty session IDs.  Upon resuming the
first session, the client would be at the point where it needed to
renegotiate the session using a valid SNI and empty session ID.
Resuming the second session would get them all the way to the virtual
host.

There are obvious security issues -- a client would need to make sure
that the host it connected to was friendly so when it performs the real
handshake, the information doesn't end up in the wrong hands.  Or perhaps
the security offered is similar to the use of TLS for SMTP where clients
don't necessarily care who the server is, just that their message is
encrypted when sent over the Internet; they rely on the DNS to make sure
they're connected to a real MX for the recipient.

Mike



> > > Q3) Consider the "renegotiation" case, where a client and server
> > > negotiate an initial SSL handshake ("in the clear") and then negotiate
> > > a second handshake over the encrypted channel established by the first
> > > handshake.
> > I'd say it's not permitted, it's still the same server and (again) all
> > you're going to do is create confusion if you allow new SNI's to be
> > inserted at this point.  This answers all the subquestions in one.
>
> Well, consider that there are people who don't want to do client
> authentication in the initial handshake because they don't want to send the
> client cert over the wire in the clear.  Perhaps they also don't want to
> send the virtual host name in the clear, or receive the cert for the
> intended virtual host in the clear. So, one could imagine that they do
> an initial handshake without any SNI, then a subsequent renegotiation
> with SNI.