On 2009-10-27 23:54 PDT, Peter Gutmann wrote:
Nelson B Bolyard <nelson at bolyard.me> writes:
I eagerly await your answers and comments.
OK, I'll bite:
Q1) A client hello's SNI extension is defined such that it may contain
multiple names.
Intuitively I would say option (a) is the right one, if you're expecting
to connect to a.foo.com then it doesn't seem to make much sense to say
you'd also like b.foo.com, c.foo.com, amazon.com, youtube.com, and
phishme.com. I'm sure someone can dream up some bizarre corner case
where you could in theory possibly somehow maybe do this, but in the
interests of implementation sanity I'd say you're only allowed one name.
I've been informed that the SNI implementation in OpenSSL/mod_ssl/Apache
only honors the first host name in the client hello SNI extension, and
will send an unrecognized_name alert if that first name is unrecognized.
I'm quite willing to follow that example and let that become the de facto
standard. I just wish the RFC was clear about it, and wonder why the RFC
even allows multiple names to be sent.
Q2) if multiple non-synonymous names are included, is the server free
to pick any one that it wants?
This one is resolved by the solution for Q1 above.
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.
I'm not advocating that. I'm merely suggesting that forbidding SNI in
renegotiation might be seen as unnecessarily restrictive in some applications.
Q4 and 5 get a bit complicated, I'd need to hear a bit more about the
circumstances where this might occur...
I received some other email that suggests that my use of the word "scope"
rather than "space" may have made the question unclear, so let me try to
reword Q4 here.
In the context of a physical server acting as multiple virtual server,
is the space of session IDs coming from that server a single space that
encompasses all the sessions for all the virtual servers served by that
physical server? Or does each virtual server have its own separate space?
If each virtual server has its own separate session ID space, then when
attempting to "resume" or "restart" a TLS session, the client hello MUST
bear an SNI extension to inform the physical server which virtual server's
session ID space contains the given session ID, and each virtual server
potentially has its own separate session store/cache.
OTOH, if there is a single session ID space for the entire physical server
covering all the virtual servers, then each cached session must record and
identify the virtual server with which it is associated.
I'm just wondering which way is the right way to implement session cache
lookup in an SNI environment.
