Subject: [TLS] Limited rollback attacks in False Start and Snap Start

From: "Brian Smith" <[email-masked]>
Date: Thu, 19 Aug 2010 18:06:04 -0500

http://tools.ietf.org/html/draft-agl-tls-snapstart-00
https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

With current TLS, the client and server securely agree on how *all* the
application data is encrypted. With False Start  the server no longer has
any say in which cipher or which TLS version (in particular, TLS 1.0 vs. TLS
1.1 CBC handling) is used to protect the application data that the client
sends, given an active MitM. Similar considerations apply to Snap Start when
considering a servers' cipher suite preferences changing over time (between
connections) and considering that Snap Start doesn't specify how the client
chooses which algorithms to use. Note also that neither proposal provides a
mechanism for the server to securely indicate to the client that such
extensions should not be used, and a server cannot find out that the
extensions are in use until after the client has already sent application
data encrypted with the MitM-influenced TLS version and cipher.

With the current TLS standards, in the event of a break in any symmetric key
cipher, a TLS server would have been able to prevent all exploits of that
break for new TLS connections simply by disabling the cipher suites on the
server side. This is no longer an effective countermeasure given clients
that implement these proposals; instead, all implementations of these
proposals have to be modified and/or reconfigured.

Currently implementations of False Start (Google Chrome and soon Mozilla
Firefox 4) allow any protocol version 3.0+, and any cipher suite the user
has enabled with key size of at least 80 bits. A quick check indicates that
this includes RC2-128 (only in Firefox, disabled by default), RC4-128,
3DES-EDE, AES-128, AES-256, CAMELLIA (only in Firefox), and SEED (only in
Firefox). Note also that there many servers that already don't want RC2-128
and RC4-128 to be used already due to real and perceived weaknesses in those
algorithms.

Both proposals could be strengthened to be similar to standard TLS by only
allowing the client to use them after the client has received a signed
message from the server that (a) lists allowed cipher suites, (b) indicates
which of these optimizations the server allows, and (c) provides a time
limit on the usage of this information. Such a message would be similar to
the SMIMEEncryptionKeyPreference X.509 attribute, but mandatory instead of
optional, and preferably would exist outside of the certificate so that
standard certificates could be used. Also note that such a mechanism is
needed in order for Snap Start to be extended for key exchange methods other
than RSA key exchange anyway, in order to transmit the reusable (ECDH) keys.

Regards,
Brian

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Aug 2010 07:13:27 +0200 (MEST)

Brian Smith wrote:
> sends, given an active MitM.

With False Start, the client is optimistic in checking the Server Cert
and starting to send encrypted Data.  The interesting thing about
False Start is, that the client may can be using this without the
server necessarily being aware of it. (No changes on the server
required, it probably just works if the client puts the app data
into a seperate SSL record as the ClientFinished message.

If the optimistic client is considered a problem, this could be
fixed with a slightly skewed TLS extension or with a new
Server->client Handshake message (enabled by a TLS extension.

Similar to the client signing previous handshake messsages,
when authenticating, the server could sign the client hello and
(most of) the server hello on the first round-trip.

If only a TLS extension is used, then it is a little skewed,
because the Server can only sign the ServerHello part without
the signature value itself, which is a little difficult
given how the hash of the handshake messages is normally created and
incorporated into a digital signature (e.g. CertificateVerify)

And the signature could not be verified while disassembling
ServerHello, the Client would have to read and process the
ServerCertificate handshake message before being able to
verify a digital signature over ClientHello and part of
ServerHello that travels in a TLS extension within ServerHello.

If only signallig (for a new Server-Client CertificateVerify
handshake message following ServerCertificate) would be done
with the TLS extension, then it might be more conventional
in-order processing of handshake messages and the handshake
message hash (and the server signature would then cover
the ServerCertificate handshake message as well).

-Martin