SPDY connection coalescing and chosen-plaintext attacks

[Brian Smith]

[Adam Barth, Thai Duong, Juliano Rizzo, Patrick McManus, Ben Adida, and EKR are BCC'd because I don't know who wants to share their email address on the list.]

tl;dr: Perhaps we should restrict the SPDY coalescing feature to hosts with the same TLD+1 (e.g. "alice.com" and "*.alice.com" could share a SPDY connection, but "alice.com" and "mallory.com" wouldn't).

Some SPDY implementations (including Chromium and Firefox) are experimenting with a feature ("coalescing") that allows multiple origins to share a single TLS connection if the TLS connection uses a certificate that includes the hostnames of all of the origins (e.g. as subjectAltNames) and if there is an IP address match for any A/AAAA record returned by the DNS resolver for each of those hostnames.

DNS is spoofable so any active MiTM can cause the IP address match to happen. But, even in the absence of any malicious MiTM, we should expect that many attackers will be able to share IP addresses with their targets via CDNs and/or other kinds of "edge" "accelerator" network proxies. Further, in CDN/accelerator situations, it is quite common for the server to have a certificate that contains many unrelated domain names (perhaps in order to work around the lack of SNI support in Internet Explorer on Windows XP). Consequently, with this feature enabled, some attackers will share a TLS connection with some targets.

It seems like all browser that will implement SPDY will have implemented countermeasures against chosen-plaintext attacks in the client->server direction for SSL 3.0 and TLS 1.0. But, we must assume that they are still possible in the server->client direction *at least* if the connection isn't TLS 1.1+. I do not have an exploit handy, but it seems reasonable that, for SSL3/TLS1.0+SPDY+coalescing case, (adaptive) chosen plaintext attacks that work in the opposite direction of the BEAST attack (deciphering server->client traffic instead of client->server traffic) might become practical, whereas they seem to have been impractical before (currently).

Also, in TLS 1.1 and in the chosen-plaintext mitigations for SSL 3.0/TLS 1.0, we assume that resetting the encryption IV at the start of each TLS record is sufficient to prevent all possibly-practical (adaptive) chosen plaintext attacks. There is nothing in the draft SPDY spec that prohibits the mixing of SPDY frames to/from different origins in the same TLS record (and, it might be difficult for some implementations to enforce such a restriction). So, AFAICT, we have to assume that an attacker in such a scenerio can prefix or suffix (or more generally intermingle) their own frames with frames to/from the site(s) that they are attacking, within a single TLS record. That sounds like something else that might be interesting to study.

Would restricting this connection coalescing feature to same-TLD+1 (e.g. "alice.com" and "*.alice.com" could share a SPDY connection, but "alice.com" and "mallory.com" couldn't) be helpful? It seems like a good idea to me, because it would require an attacker controlling subdomain of their victim websites to mount any such attack. However, it wouldn't allow as much sharing as some might like. But, perhaps that is a necessary tradeoff?

Thoughts?

- Brian

[Mike Belshe]

Hi, Brian,

I'm not 100% certain I understand what you're saying, so let me try to repeat.

  a) You're concerned there is a possible attack vector with coalesced connections, but you don't really have one in hand.

  b) You're wanting to make a change to the policy based on (a).

If that is the case, I don't see this as a good idea.  If there is a specific attack in hand, we can discuss it.  But I'm not sure how to react to maybes, because there is an infinite number of them. 

Am I misreading?  Or do you think there is a real attack here that we missed?

Mike

[Brian Smith]

Mike Belshe wrote:
> I'm not 100% certain I understand what you're saying, so let me try to
> repeat.
> a) You're concerned there is a possible attack vector with coalesced
> connections, but you don't really have one in hand.
> b) You're wanting to make a change to the policy based on (a).
>
> If that is the case, I don't see this as a good idea. If there is a
> specific attack in hand, we can discuss it. But I'm not sure how to
> react to maybes, because there is an infinite number of them.
>
> Am I misreading? Or do you think there is a real attack here that we
> missed?

I don't have a specific attack in hand; instead, I am eagerly awaiting Juliano and Thai make another YouTube® video for us. :) Seriously, though, I have a vague idea of how one or more attacks might work, but I haven't implemented (or even documented) them yet. And, these kinds of threats might have already been considered and already rejected as impractical.

First, has anybody done analysis that can be shared, regarding the susceptibility of SPDY to BEAST and BEAST-like attacks (not just in the client->server direction like Thai and Juliano demonstrated, but also in the server->client direction that the browser cannot ensure is protected short of requiring TLS 1.1)?

Also, are you trying to enable "make only one connection to an Amazon® Web Serices® server, regardless of whether the hostnames in the shared connection are related or totally unrelated," or is "make one connection to twitter.com regardless of subdomain, and make one connection for amazon.com regardless of subdomain" good enough? In what situations is the latter not good enough?

Some potential attack vectors have already been discussed, like the shared compression context for header compression and the shared compression context for TLS-level compression. In the "Compression contexts and privacy considerations" thread, you wrote:
> The concern that came up was that someone could infer previous requests
> based on sizes of requests to crafted URLs. For sites concerned about
> this, don't share our SPDY sessions is a reasonable answer.

If I am understanding you correctly, you were saying "don't create a situation in which you could have your connection shared with an attacker." I.e. don't use a cert that includes an attacker's domain name in it. Although that does sound reasonable, I know that many organizations (including mozilla.org) do this on CDNs, and there are some scenerios where "don't do that" or "stop doing that" won't work:

1. The site administrator doesn't know that his CDN turned on SPDY support on the CDN-hosted domain.

2. The site administrator takes your advice and decides to stop sharing a cert with potential attackers, but that shared cert still exists and might continue to be used on the CDN after that decision is made. And/or the cert could later be compromised (and we should assume not not revoked, not that it would matter much) and used on another server. (For example, there's probably at least one such cert that includes a subjectAltName for mozilla.org that still hasn't expired.)

3. Even if your CDN/edge proxy neighbors seem honest, they might be exploitable and/or purposefully (but not maliciously) enable attackers to attack the shared connection, perhaps even in a way that is practically harmless to the neighbor but very harmful to you.

It seems like one of the servers in this shared-connection situation to to exploit some of the shared/cumulative state in TLS--especially compression state for TLS-level compression--to learn what the other parties are saying, much more easily than they would be able to otherwise using traffic analysis. Adam Langley rightly pointed out in that thread that defeating traffic analysis is not something TLS aims for, and SPDY shouldn't aim for that either. Yet, it doesn't seem like a good idea to make such traffic analysis significantly easier, faster, and/or more reliable. I think this feature does make such traffic analysis easier, at least when TLS-level compression is used. Perhaps the answer could/should be again "don't do that" but again I am not sure that is reasonable when we consider public CDN and CDN-like services.

Besides information disclosure, I don't think it is clear yet that one-connection-per-CDN is better than one-connection-per-(TLD+1) for performance. Or, rather, we still need to do experiments to determine if there is something inherent in this connection coalescing mechanism that would make it possible for cdn.mallory.com to seriously disrupt traffic to cdn.alice.com if they both end up sharing the connection, especially since it seems pretty for cdn.mallory.com to easy to disrupt any TLS-level compression by just returning a large chunk of already-compressed data. In the best case, it might be better to share, but in bad cases it might be horrible for performance to do so (especially considering many/most initial server implementations will be sub-optimal and/or plain buggy).

This all leads me to think that, at a minimum, this is something that servers should have some control over--i.e. there should be a way to securely opt in or opt out of this connection coalescing feature on a per-domain or per-(TLD+1) basis. And, it also leads me to think that it worthwhile to have our implementation limit sharing to hosts with the same TLD+1.

As soon as I have time, I will type up some more coherent notes about this and pass them to your side for review. I would be very happy to hear from others in the interim, if they have any findings that you can share.

Cheers,
Brian

[Mike Belshe]

On Sat, Oct 29, 2011 at 10:16 PM, Brian Smith <bsm...@mozilla.com> wrote:

Mike Belshe wrote:
> I'm not 100% certain I understand what you're saying, so let me try to
> repeat.
> a) You're concerned there is a possible attack vector with coalesced
> connections, but you don't really have one in hand.
> b) You're wanting to make a change to the policy based on (a).
>
> If that is the case, I don't see this as a good idea. If there is a
> specific attack in hand, we can discuss it. But I'm not sure how to
> react to maybes, because there is an infinite number of them.
>
> Am I misreading? Or do you think there is a real attack here that we
> missed?

I don't have a specific attack in hand; instead, I am eagerly awaiting Juliano and Thai make another YouTube® video for us. :) Seriously, though, I have a vague idea of how one or more attacks might work, but I haven't implemented (or even documented) them yet. And, these kinds of threats might have already been considered and already rejected as impractical.

First, has anybody done analysis that can be shared, regarding the susceptibility of SPDY to BEAST and BEAST-like attacks (not just in the client->server direction like Thai and Juliano demonstrated, but also in the server->client direction that the browser cannot ensure is protected short of requiring TLS 1.1)?

I'll let agl reply.

 

Also, are you trying to enable "make only one connection to an Amazon® Web Serices® server, regardless of whether the hostnames in the shared connection are related or totally unrelated," or is "make one connection to twitter.com regardless of subdomain, and make one connection for amazon.com regardless of subdomain" good enough? In what situations is the latter not good enough?

The goal is to reduce connections required.  It's easy to add more connections - HTTP has been doing that for years.  It's harder to use fewer.  And if we don't use fewer, we strip the ability for the transport to do real optimizations (note bufferbloat and consider how it is impacted by HTTP).  On top of that, we do measure real performance wins when we're able to coalesce connections (no need to wait for DNS + connection + ssl handshake latencies before requests hit the network).

 

Some potential attack vectors have already been discussed, like the shared compression context for header compression and the shared compression context for TLS-level compression. In the "Compression contexts and privacy considerations" thread, you wrote:
> The concern that came up was that someone could infer previous requests
> based on sizes of requests to crafted URLs.  For sites concerned about
> this, don't share our SPDY sessions is a reasonable answer.

If I am understanding you correctly, you were saying "don't create a situation in which you could have your connection shared with an attacker." I.e. don't use a cert that includes an attacker's domain name in it. Although that does sound reasonable, I know that many organizations (including mozilla.org) do this on CDNs, and there are some scenerios where "don't do that" or "stop doing that" won't work:

This particular snippet had to do with data inference based on the compressor state, and this problem exists even without any IP pooling.   For example, some virtual hosters could do path-based (rather than domain based) hosting.   If so, you could be sharing a single SPDY connection between those two path-based virtual hosts.  At one point there was a proposal for resetting compressor state which would mitigate this.  (e.g. allow the server to reset compression state at any time).  

 

1. The site administrator doesn't know that his CDN turned on SPDY support on the CDN-hosted domain.

This isn't really possible - to share a SPDY connection, sites must be using a common certificate.  So your neighbors won't be under the same certificate as you.

If the CDN operator is using their own cert for two sites, then the SPDY connection is isolated within the CDN, and there is no server-side leakage of data.  SPDY can't be exposed to the two sites in this configuration, the CDN proxy would need to pass data to the backends separately.

 

2. The site administrator takes your advice and decides to stop sharing a cert with potential attackers, but that shared cert still exists and might continue to be used on the CDN after that decision is made. And/or the cert could later be compromised (and we should assume not not revoked, not that it would matter much) and used on another server. (For example, there's probably at least one such cert that includes a subjectAltName for mozilla.org that still hasn't expired.) 

3. Even if your CDN/edge proxy neighbors seem honest, they might be exploitable and/or purposefully (but not maliciously) enable attackers to attack the shared connection, perhaps even in a way that is practically harmless to the neighbor but very harmful to you.

It seems like one of the servers in this shared-connection situation to to exploit some of the shared/cumulative state in TLS--especially compression state for TLS-level compression--to learn what the other parties are saying, much more easily than they would be able to otherwise using traffic analysis. Adam Langley rightly pointed out in that thread that defeating traffic analysis is not something TLS aims for, and SPDY shouldn't aim for that either. Yet, it doesn't seem like a good idea to make such traffic analysis significantly easier, faster, and/or more reliable. I think this feature does make such traffic analysis easier, at least when TLS-level compression is used. Perhaps the answer could/should be again "don't do that" but again I am not sure that is reasonable when we consider public CDN and CDN-like services.

I'm not sure if you're concerned about server-side attacks or client side attacks here.

For server side attacks, I believe there is no sharing.  This is because you cannot take a single SPDY connection, proxy it as SPDY, and send part of it to backend server A and part to backend server B.  It won't work because the whole SPDY connection is stateful and each server would only be getting part of the state.  The only way to do this is for the proxy to convert from SPDY to HTTP (or to a new SPDY session), and then pass http to server A and http to server B.  So the backend servers can't analyze the shared SPDY connection at all.  In this config, server A and server B have already trusted that their CDN won't be a man-in-the-middle to their SSL.

As for a beast-like attack, where the client-side javascript attempts to detect something based on timing of packets or other data, well, I guess I'd like to see the attack or at least have a concept proposed.

 

Besides information disclosure, I don't think it is clear yet that one-connection-per-CDN is better than one-connection-per-(TLD+1) for performance. Or, rather, we still need to do experiments to determine if there is something inherent in this connection coalescing mechanism that would make it possible for cdn.mallory.com to seriously disrupt traffic to cdn.alice.com if they both end up sharing the connection, especially since it seems pretty for cdn.mallory.com to easy to disrupt any TLS-level compression by just returning a large chunk of already-compressed data. In the best case, it might be better to share, but in bad cases it might be horrible for performance to do so (especially considering many/most initial server implementations will be sub-optimal and/or plain buggy).

This all leads me to think that, at a minimum, this is something that servers should have some control over--i.e. there should be a way to securely opt in or opt out of this connection coalescing feature on a per-domain or per-(TLD+1) basis. And, it also leads me to think that it worthwhile to have our implementation limit sharing to hosts with the same TLD+1.

I disagree - change is risk and we can't be scared of it.   If we can't identify a real attack right now, neutering the protocol doesn't make sense. 

Thanks for taking the time to write this up.

Mike