Subject: [TLS] Inter-protocol attacks

From: Watson Ladd <[email-masked]>
Date: Sat, 9 Aug 2014 07:58:45 -0700

Dear all,
By combining fallback to SSLv3 and session ID based resumption, it is
possible to do some major damage. This is due to  Antoine
Delignat-Lavaud according to whois. Slides are at
https://bh.ht.vc/bh_slides.pdf. This depends on subtleties of TLS
configuration and interactions with the same origin policy, and
results in the sort of thing you don't want to see.

Moral of the story: simplify, simplify, simplify!

Sincerely,
Watson Ladd

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 9 Aug 2014 11:48:19 -0400

Falling back to SSL 3.0 can lead to major problems, period.  (SSL 3.0 was
the main motivation for TLS_FALLBACK_SCSV - not this particular attack, but
there are other options.)

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 9 Aug 2014 21:00:04 +0300

> results in the sort of thing you don't want to see.

The prominent themes in that represetation (excluding the THS part)
seem to be:
- Cookies are just plain insecure[1]
- HTTP servers issuing false authoritative responses.

[1] And extractable bearer tokens in general.

-Ilari

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Sun, 10 Aug 2014 14:20:55 +0100

Hi,

Le 8/9/2014 3:58 PM, Watson Ladd a écrit :
> possible to do some major damage.

This is an imprecise description. In the case you are referring to, the 
browser fallback behavior is abused to exploit the fact that some 
Mozilla servers had an improperly isolated server-side session cache 
(but, interestingly, it also had well-isolated session tickets, hence 
the need to prevent the victim from using tickets). This is another 
reason why draft-bmoeller-tls-downgrade-scsv should be adopted and 
implemented, as the ability of the attacker to get rid of the SNI and 
session ticket of the client can have bad, unexpected effects on some 
servers.

>   This is due to Antoine

Indeed, the attacks I presented rely on improper server configuration, 
plus a very nasty legacy behavior of not rejecting HTTP requests that 
contain an unexpected Host header (I don't anticipate this behavior will 
change). However, TLS is not helping in some regards, and extensions 
that have been described as having no security impact whatsoever 
(including, but not limited to, SNI and session tickets) when in fact, 
there should have been a precise security discussion about the 
application behavior when using these extensions.

> Moral of the story: simplify, simplify, simplify!

What I am seeing is an exactly opposite trend. In particular, I would 
like to attract the attention of the TLS WG on the fact that Chrome 
introduced a very significant change to the authentication model of TLS 
that went virtually unnoticed. In SPDY, the TLS client session cache is 
no longer indexed by domain and port, but instead by domain set, IP and 
port: in classic TLS, an established connection or session can only be 
reused for the same domain, whereas in SPDY, it can be reused for any 
domain in the certificate verified when the session was created, 
provided that it points to the same IP as the original connection. The 
DNS condition is obviously meaningless to a network attacker, which 
means that all security guarantees that were previously session-specific 
should now be considered certificate-specific.

I argued against this behavior with Adam Langley, for several reasons. 
First, it means that our miTLS efforts to prove authentication were once 
again thrown out of the window (not a big deal, but still, such a change 
deserved more than 3 lines in section 9.1.1 of 
draft-ietf-httpbis-http2); second, it explains why current webservers 
are happy to resume connections with an SNI that doesn't match the one 
in the initial connection. Furthermore, they are also accepting requests 
whose Host header doesn't match the SNI of the connection (because 
connection reuse not only occurs at the session level, but also at the 
connection level: if a connection is established with a certificate 
valid for *.x.com, the browser is allowed to send a request first to 
www.x.com, then to static.x.com on the same connection). Unsurprisingly, 
this freedom can be abused by the attacker to exploit an 
improperly-isolated server-side session cache. My third complain was 
that this behavior is not well-known and breaks certain things when one 
is unaware of it. For instance, client authentication and Channel ID 
become hazardous with multi-domain certificates. It may even get worse 
if a malicious domain appears in the certificate, a scenario that sounds 
unlikely but is in fact common in practice (e.g. CloudFlare loves to 
pack unrelated customer domains in their certificates).

It also turns out that this feature has been buggy in Chrome for the 
past 2 years, allowing an attacker universal server impersonation (I 
didn't talk about it at Black Hat because the fix is not yet deployed). 
I'm fairly sure that if there had been more discussion, such an ugly bug 
could have been averted.

For all these reasons, it may be a good idea to reconsider certain 
aspects of the design of TLS in an HTTP context. For instance, it would 
be useful to provide strong implementation requirements about the 
isolation of the session cache, and try to make an explicit decision 
about session-specific vs. certificate-specific security guarantees.

Best,

Antoine Delignat-Lavaud

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Aug 2014 23:06:43 -0700

On 10 August 2014 06:20, Antoine Delignat-Lavaud
<[email-masked]> wrote:
> Chrome introduced a very significant change to the authentication model of
> TLS that went virtually unnoticed. In SPDY, the TLS client session cache is
> reused for the same domain, whereas in SPDY, it can be reused for any domain
> in the certificate verified when the session was created, provided that it
> points to the same IP as the original connection. The DNS condition is
> obviously meaningless to a network attacker, which means that all security
> guarantees that were previously session-specific should now be considered
> certificate-specific.

The behaviour you describe isn't quite correct, because - I believe -
that it requires that the DNS resolve to the same IP (or that one of a
set of alternative values point there).  But that's not a particularly
important detail, DNS has never been a part of the security story for
https.  It's a big part of http, but we all know what you get there.

Either way, this behaviour has been discussed at some length and was
not found lacking in the SPDY/HTTP2 context.  Yes, HTTP/2 standardizes
this practice.  The poor handling of Host header fields in HTTP/1.1
means that it will probably never be advisable to do something like
this there.

As always, I caution that we have to be careful to distinguish between
attacks on implementations and attacks on standards.  I am aware that
there are bugs in implementations.  I'm also told that they are
somewhat difficult to exploit.

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Wed, 13 Aug 2014 14:00:48 +0100

> https.  It's a big part of http, but we all know what you get there.

Ultimately, we agree that the precise DNS condition doesn't matter. In 
HTTPS, DNS is under attacker control.

> somewhat difficult to exploit.

The argument is not whether such attacks are to blame on implementation 
or specification. The question is whether behavior such as reusing a 
connection established with attacker.com to send data meant for 
google.com /should be considered an attack at all/.

This is the TLS mailing list, and the relevant problem here is the 
complete lack of any restriction in RFC 5246 and 5077 on when a session 
can be resumed. Thus, we end up in a situation where resumption is up to 
implementations to decide; because of the lack of any specification, TLS 
libraries simply hand off the decision to the application; the 
application won't know what to do (this kind of question is typically 
considered out of the scope of application protocol definitions), and 
thus let the user decide. Of course, the user is very unlikely to 
understand the security impact of session cache or name-based 
certificate settings, and this is how we end up with the kind of attacks 
I demonstrated at Black Hat.

SPDY is an interesting case, as it does specify a clear resumption 
policy (even though, I must against stress out again, this policy 
technically allows resumption between any two HTTP origins as long as 
they appear in the same certificate; thus, CVE-2014-3166 does not 
violate any TLS or HTTP specification and cannot be considered an 
implementation bug). This policy should be interpreted as an 
authorization function for TLS authentication. In a full handshake, 
there is a well-specified and widely-adopted authorization function 
defined in RFC 5280. The problem I am pointing out is that the SPDY and 
PKIX authorization functions are incompatible. Thus, TLS features that 
assume PKIX authorization, such as SNI or ChannelID, may not guarantee 
the same security properties under SPDY authorization. Similarly, 
certain PKIX extensions will also fail under SPDY authorization, most 
notably certificate pinning.

 From the TLS viewpoint, it is reasonable to consider authorization 
outside the scope of the protocol. However, for the security of TLS, 
authentication and authorization must critically be preserved by 
resumption, as it is entirely a protocol feature that currently occurs 
without any application involvement. The issue may disappear in TLS 1.3 
if resumption is removed, but in current versions, the use of different 
authorization policies for full handshakes and resumption should be 
considered a weakness, which can be exploited.

Speaking of this, I have to disagree with your claim that attacks in 
this class are difficult to exploit. It may be true if you compare these 
attacks to heartbleed or browser memory bugs. However, compared to 
BEAST, Lucky13 or triple handshake, these attacks are orders of 
magnitude more exploitable.

Best,

Antoine Delignat-Lavaud

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Aug 2014 16:00:28 +0200 (CEST)

Antoine Delignat-Lavaud wrote:
> can be resumed.

This lack is intentional.  The only prerequisite is that both peers
have the session in their cache and are willing to use it for a session
instead of a full handshake.

>
> Thus, we end up in a situation where resumption is up to 
> implementations to decide; because of the lack of any specification,
> TLS libraries simply hand off the decision to the application;

You seem to be seriously misinterpreting the specifications.
The TLS libraries are not "simply handing off the decision to the
application", they are EXPLICITLY REQUIRED to leave any such decision
to the application.

Last sentence of Section 1. Introduction of every TLS spec:

  https://tools.ietf.org/html/rfc2246#page-4

                             the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left up to the judgment of the designers and
   implementors of protocols which run on top of TLS.

In the abstract definition, the TLS client implementation has _absolutely_
_no_idea_ who it is talking to, working purely on a memory buffer interface
to the client application.

What is probably dangerous and unreasonable is when a TLS implementation
lets an application interfere with the PKIX path validation of a peer cert
chain.

The application level "interpretation of authentication certificates
exchanged" ought to be independent from whether the TLS stack performs
a full or an abbreviated TLS handshake, and the calling application
ought to retrieve and check/map the peer certificates after completion
of the TLS handshake and independent of whether the handshake was
full or abbreviated (and independent from the PKIX path validation).

>
> the application won't know what to do (this kind of question is typically 
> considered out of the scope of application protocol definitions),

Nope, that can not possibly happen.  Per specification, the application
*KNOWS* what to do.

There might be clueless programmers that don't know what to do, but
that is a different issue.

> notably certificate pinning.

PKIX authorization does not exist within TLS.  Whether it exists in
the function of the application that "decisions how to interpret the
authentication certificates" is purely an application matter an
none of TLS business.

Certificate pinning would be an application decision, not a TLS decision.

But with your description I somehow still fail to see a problem.
If the server certificate of such resumptions will *pass* the
"server endpoint identification", then why would re-doing the
server endpoint identification make a difference?

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 Aug 2014 19:06:53 +0300

> server endpoint identification make a difference?

As far as I understand, the actual issue is HTTP servers issuing
false responses to HTTP reqeusts if sent to wrong server (but
that server may still have valid certificate). And clients
interpretting those false responses as proper ones then leads
to all sorts of unpleasant problems.

Usually those false responses are because of misconfiguration
(usually default virtual host is something unintended, or the
default vhost is issuing redirects to "main site" even when
such redirect must not be sent (the vhost being handled else-
where)).

HTTP/2 even defines error code specifically for responding to
such requests (421). That code would also apply to HTTP/1.1
(in pinch, 400 would do while waiting for 421).

Where session resumption comes in is that it is more vulernable
than full handshake to attacker interference, resulting in it
being easier to make user connect to wrong server.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Fri, 15 Aug 2014 03:56:30 +0200 (CEST)

> to all sorts of unpleasant problems.

I did understand that part.

> being easier to make user connect to wrong server.

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.

-Martin

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Fri, 15 Aug 2014 09:44:57 +0100

> which is what has been asserted.

As I explained before, the reason why it is the case is because TLS 
authorization is not context free: it depends on the application context.

In HTTP, application context boils down to origin, because the same 
origin policy is the only security context that makes sense in a browser.

Any TLS authorization for the Web that uses a context broader than 
origin is going to be a source of attack. This applies to both server 
and client. The problem with resumption is that unlike full handshakes, 
it uses implicit authorization. This can be easily blamed on protocol 
implementations, but TLS could have made resumption authorization more 
explicit.

On the server side, most web servers use a very simple authorization 
policy, which is basically "return true" regardless of the context. This 
is bad, because there are many reasons why a server would want to reject 
certain resumption requests, in particular when the application context 
(domain / SNI) of the resumption is different from the one in the 
initial connection. For instance, if the session being resumed is user 
authenticated, the server may want to use a different CA on the domain 
of the resumption, or an anonymous session. It may also prefer to use 
another certificate (such as an extended validation one) for this domain 
(even though the initial one may also work, say because it has a 
wildcard), or a different cipher, or avoid using the same Channel ID, or 
many other reasons. The new domain of the resumption may not be handled 
by the server (in fact, if the server uses multiple certificates, or a 
shared ticket key, it can even be that the requested domain is not in 
the certificate of the original session), in which case authorizing the 
resumption is guaranteed to break the same origin policy. These are all 
real attacks that can be found against top websites (see https://bh.ht.vc).

On the client side, clients typically use a resumption policy based on 
the domain associated with the session. This works great for HTTPS 
because protocol+domain is almost as good as origin (port being part of 
origin is a mistake). However, SPDY uses a resumption policy that 
assumes that authorization of the initial connection extends to other 
domains in the certificate. This is not the case: the original 
authorization was granted in a different application context, and it is 
in fact necessary to re-authorize the connection in the new context. See 
http://youtu.be/7zNWKTDs99g for a concrete exploit.

Overall, I am well aware that little can be done in the TLS protocol to 
solve the shortcomings of application authorization. Since SNI provides 
a good application context indication even outside HTTPS, the change 
that I was initially proposing to OpenSSL and Nginx several months ago 
was to enforce that the SNI may not change when a session is resumed. 
However, this restriction is not compatible with SPDY, and almost all 
servers continue to accept resumption with a different SNI currently.

Best,

Antoine Delignat-Lavaud

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 15 Aug 2014 08:36:44 -0400

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Aug 2014 09:56:11 -0700

On 15 August 2014 05:36, Karthikeyan Bhargavan
<[email-masked]> wrote:
> (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 think that this is pretty much the right answer.  Since session
tickets are basically the server talking to itself, it's really only
something we can only recommend in a specification.  Deployments that
don't have multiple configurations aren't going to need a binding, but
those that do should be binding the ticket to the configuration.  In
the end, it's probably best to recommend the binding for all cases to
avoid usage issues.

I don't want to make applications responsible for this, at least to
the extent that is possible.