Re: [TLS] Inter-protocol attacks

[Karthikeyan Bhargavan <[e-mail]>]

On 14 Aug 2014, at 21:56, Martin Rex <[e-mail]> wrote:

> But I still fail to see how session resumption would aggravate
> any bogosities performed by applications as long as the servers
> certificates on both handshakes (resumption an full)
> will properly *PASS* the usual server endpoint identification checks,
> which is what has been asserted.

Perhaps an example scenario would be useful.

-----
Suppose a TLS server S uses a certificate C for domain D
and a TLS server S’ uses a certificate C’ for domain D’.
S and S’ share a session ticket encryption key K (or a session cache).
(Real-world example in Antoine’s talk: D=bugzilla.mozilla.org and D’=git.mozilla.org)
——
Connection 1:
C intends to connect to D and completes a full handshake with S.
S sends C a session ticket for encryption (encrypted under K)
——
Connection 2:
C resumes its session over a new connection using the session ticket.
The network attacker redirects the connection to S’.
S’ will accept the ticket (since it uses the same ticket encryption key K)
C and S’ complete the abbreviated handshake.
——
Result: C thinks it is (re-)connected to server S/domain D but it is connected to server S’/domain D’,
even though S and S’ *do not* serve the same certificate.
(A similar trace can be worked out for session caches shared between S and S’)
——

That this result is undesirable should not be in doubt (it leads to medium-level security exploits in deployed websites.)  At what level do we fix it seems more open to debate.

One may argue that:

(a) this is the application’s fault (at S’). It is fine for S and S’ to share ticket encryption keys (or session caches) but the application (e.g. HTTPS) must carefully disambiguate streams meant for S and S’ using some application-level information (e.g. Host header)

(b) using SNI during resumption should prevent this. S’ should refuse to resume a connection that has an SNI=D when it does not have a certificate that covers D.

(c) TLS session tickets/resumption are underspecified. Session tickets should also include the server_identity, that is the server certificate/hash/server name, not just the client_identity (see http://tools.ietf.org/html/rfc5077#section-4). Then, during resumption, the client should indicate the certificate/server name it wishes to connect to (e.g. via SNI) so that S’ can check that the resumed connection is for the same certificate/server name. 

I gather (from Adam’s and Rich's emails) that Google and Akamai do some version of (c). 
One may force HTTP web servers to do (a), but what about SMTP/IMAP/… servers that may not have a convenient “Host” header?
One may also say that servers should use different ticket encryption keys for each certificate/domain they serve, but this would probably vastly increase the number of full handshakes.
One may try to use SNI as in (b), but only after downgrade attacks have been eliminated.










Is the above (a) a failure of TLS session resumption or (b) a failure of the server implementation at S’ or (c) a failure of the HTTP level addressing




> 
> -Martin
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls