Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>:
Also, why is it not a MUST that Clients send TLS 1.0 Hello messages?
Clients MAY use backwards compatible SSL Client Hello message
formats. However, except for SSL session resumption, Client
Hello messages MUST be suitable for negotiating TLS 1.0 or later
(i.e. the version field of SSL 2.0 compatible Client Hello
messages or the client_version field of SSL 3.0 compatible Client
Hello messages must be at least 3.1).
Servers MUST be able to understand backwards compatible SSL
Client Hello messages, provided that the client indicates that
it supports TLS 1.0 or later.
Note that neither clients nor servers are required to actually
support protocol versions other than TLS 1.0; but the above rules
make sure that clients can operate in a backwards-compatible mode
without risking interoperability with servers following the
current specifications.
This is completely bogus. The reason we have a TLS specification
is so people can get interoperability by implementing it. If they
instead implement some earlier specification that isn't TLS, they're
not meeting the requirements of the standard. SMTP servers that claim
to support STARTTLS and don't accept TLS 1.0 Hello messages are BROKEN,
full stop.
I agree that such servers are broken. But clients may want to
tolerate them anyway, and it is easy for TLS-only servers to tolerate
clients tolerating such broken servers.
Similarly, clients that issue a STARTTLS command and don't
send TLS 1.0 Hello messages are also BROKEN, full stop.
Can you name an existing SMTP client with STARTTLS support that is not
'broken' by your definition? Most clients that I am aware of use
backwards compatible Client Hello messages indicating support for
TLS 1.0. (But everything after this single handshake message is
usually pure TLS 1.0 -- SSL/TLS protocol version negotiation makes
sure they highest common protocol version is used.)
Forbidding backwards compatible Client Hello messages makes it a
little bit easier to implement servers in theory, but this does does
not help anyone in real life because virtually all connection attempts
will fail.
If a server wants to accept older Hello messages, that's its own
business.
This is not about 'older' Client Hello messages, this is about
backwards compatible Client Hello messages -- old format, but new
content.
And servers would do well to parse older Hello messages
and continue with the TLS dialog even if they don't accept the
resulting client authentication as valid and don't treat the
negotiated session as if it were secure - just because it makes
for better error recovery.
A backwards compatible Client Hello message does not mean that the
connection actually uses the older protocol. (And anyway, client
authentication isn't worse in SSL 3.0 than in TLS 1.0; in fact, most
cryptographic defects of SSL 3.0 have been preserved in TLS 1.0.)
But client implementations shouldn't
expect that sending older Hello messages are going to make them
interoperable with servers that advertise STARTTLS.
They cannot expect interoperability if they support only SSL 3.0 or
even SSL 2.0, but that's not what this is about. No-one requires
servers to support SSL 3.0 or SSL 2.0; all that is required is support
for backwards compatible Client Hello handshake messages so that it is
possible for clients to tolerate SSL-only servers if they feel like
it. Backwards compatible Client Hello messages are described in the
TLS RFC.
--
Bodo Möller <moeller(_at_)cdc(_dot_)informatik(_dot_)tu-darmstadt(_dot_)de>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036