search

csosto-pk / tls-suppress-intermediates

Suppress intermediate certificates in TLS
Other
0 stars 0 forks source link

Crisper language regarding the impact connection re-establishment has on fingerprinting and privacy #12

Open csosto-pk opened 2 years ago

csosto-pk commented 2 years ago

From Ryan S.

It seems like the choice to reintroduce "connection re-establishment" logic would have bearing on the security and privacy assumptions here, and is worth making sure it's captured.

We ought to beef up the text.

csosto-pk commented 2 years ago

By Ilari

It seems to me that the dominant failure modes are:

  • Using old ICA list that is missing some newly minted ICA.
  • Using custom TA that is missing ICA data.

Regarding security and privacy, the most severe impact of any attack I can come up with is determining if some arbitrary ICA is on the ICA list or not (for passive attacks, that is restricted to the issuing ICA used by the server). Practical impact of attacker being able to do that depends on how many endpoints share that same ICA list.

Rough outline of the attack (active variant): Fabricate a certificate purporting to be from some ICA, send it to client and observe if the client retries (ICA not on the list) or just fails (ICA is on the list).

csosto-pk commented 2 years ago

By Ryan S.

Regarding security and privacy, the most severe impact of any attack I can come up with is determining if some arbitrary ICA is on the ICA list or not (for passive attacks, that is restricted to the issuing ICA used by the server). Practical impact of attacker being able to do that depends on how many endpoints share that same ICA list.

Rough outline of the attack (active variant): Fabricate a certificate purporting to be from some ICA, send it to client and observe if the client retries (ICA not on the list) or just fails (ICA is on the list).

I'm hopeful that some may be interested to perform a more thorough analysis. We saw enough complexity with respect to previous TLS versions and the fallback logic being possible to induce downgrade attacks that I think we should be very wary about introducing a class of anticipated handshake failures that require connection re-establishment, especially across independent TLS sessions. I realize that sounds a little like FUD, but rather: every time we've tried to do this, it's blown up spectacularly, so we need to make sure we're not setting up another bomb.

I also think the active attack analysis is a bit lacking, especially since the attacker has the ability to mint arbitrary ICAs on demand, without running afoul of any existing client policies. For example, for the Web PKI, by virtue of nameConstraints without pathLen in the basicConstraints, the site can mint arbitrary ICAs and arbitrary EE certificates. Combined with the discovery mechanism discussed, this is effectively the same as other forms of stateful tracking (ala HSTS tracking), and thus likely to be subjected to the same mitigations that would largely render the benefits here ineffective, at best.

csosto-pk commented 2 years ago

From Ilari

I'm hopeful that some may be interested to perform a more thorough analysis. We saw enough complexity with respect to previous TLS versions and the fallback logic being possible to induce downgrade attacks that I think we should be very wary about introducing a class of anticipated handshake failures that require connection re-establishment, especially across independent TLS sessions. I realize that sounds a little like FUD, but rather: every time we've tried to do this, it's blown up spectacularly, so we need to make sure we're not setting up another bomb.

I have hard time seeing how one could construct downgrade attack out of this, as it just requests extra data from server on fallback. For most other retry stuff, downgrade attack risk is obvious as less secure modes are introduced / more secure modes are removed.

I also think the active attack analysis is a bit lacking, especially since the attacker has the ability to mint arbitrary ICAs on demand, without running afoul of any existing client policies. For example, for the Web PKI, by virtue of nameConstraints without pathLen in the basicConstraints, the site can mint arbitrary ICAs and arbitrary EE certificates. Combined with the discovery mechanism discussed, this is effectively the same as other forms of stateful tracking (ala HSTS tracking), and thus likely to be subjected to the same mitigations that would largely render the benefits here ineffective, at best.

Having pathLen >= 1 would do as well, right?

And such ICAs can already be abused for tracking if the browser does transvalidity. Suppress ICAs flag would make it worse, by allowing other sites to read such tracking supercookies.

Defense is not doing transvalidity nor cached AIA chasing (since those caches represent state that could be attacked). This closes the attack for both with and without suppress ICAs.

Another defense to make reading ICA list harder would be to always trigger fallback if certificate validation fails and ICAs were suppressed.

Neither defense would render suppress ICAs ineffective, since in vast majority of cases one can use quasi-static ICA list to build verifiable certificate chain and then use that with no fallback.

csosto-pk commented 2 years ago

From Ryan S.

I have hard time seeing how one could construct downgrade attack out of this, as it just requests extra data from server on fallback. For most other retry stuff, downgrade attack risk is obvious as less secure modes are introduced / more secure modes are removed.

I think I’m raising a question about whether or not implementations will actually do this, and arguably, to explicitly specify this if this is the expectation. In theory, yes, if the only thing changing in a fallback is an optional flag, it “shouldn’t” have concerns. In practice, however, these sorts of fallbacks (e.g. various server bug workarounds) introduce compositions that cause new and unexpected interactions. This is why the ecosystem has tried very hard to avoid fallbacks (c.f. TLS 1.3) and ensuring that both parties are able to commit to the negotiation. We saw this with the renegotiation issues getting confused state from the initial handshake.

Having pathLen >= 1 would do as well, right?

Sure, “without pathLen constraints”

And such ICAs can already be abused for tracking if the browser does transvalidity. Suppress ICAs flag would make it worse, by allowing othersites to read such tracking supercookies.

Transvalidity was never something widely supported outside of a specific product/library (Mozilla NSS). But yes, this is the point: this feature gives a much stronger signal.

Defense is not doing transvalidity nor cached AIA chasing (since those caches represent state that could be attacked). This closes the attack for both with and without suppress ICAs.

I fail to see how it closes it without suppress ICAs, particularly because the current draft very explicitly suggests caching as a possibility. And yes, implementations that wish to mitigate cross-context tracking are working to isolate those caches, and this was my point: doesn’t this isolation defeat the benefits of the caching / the likelihood of intermediate omission succeeding, and functionally mean that there needs to be a reliable, semi-real-time distribution mechanism for intermediates to achieve the benefits?

I’m trying to look at this from a systems perspective, and tease out explicitly: what is this solution assuming exists in order to achieve the desired effect, and with those assumptions, are there simpler/less-risky/alternative technical solutions? Not to bikeshed, but because the design assumptions here are unstated and have practical and meaningful ecosystem effect, and so we at least owe that much.