Re: [TLS] ESNIKeys over complex

[Ilari Liusvaara <[e-mail]>]

On Sat, Dec 08, 2018 at 11:42:56AM -0700, David Fifield wrote:
> On Sat, Dec 08, 2018 at 06:38:30PM +0200, Ilari Liusvaara wrote:
> > While thinking about the previous, I ran into some issues with the
> > split mode. Firstly, if the fronting server does not encrypt the
> > client_hello when transmitting it to backend server, passive attack
> > can match incoming connections with backend servers. This reduces
> > anonymity set to a single backend server (a lot smaller set).
> > 
> > And secondly, even if server encrypts the client_hello, but does not
> > use a tunnel to backend, if server does not have client hello replay
> > filtering (and such filtering is hard on typical fronting servers),
> > replay attacks and some very simple traffic analysis can discover the
> > backend server (again reducing the anonymity set by a lot).
> > 
> > This means that the fronting server should have an encrypted tunnel
> > with the backend server (and there is likely double encryption).
> 
> I see--you're thinking of an observer who can see "both sides" of a
> connection: the link between the Client and the Client-Facing Server,
> and the link between the Client-Facing Server and the Backend Server.
> I agree: such an observer could, through timing analysis, deanonymize
> client connections (i.e., tell which Backend Server the Client is
> accessing, as if it were accessing directly and not through the
> Client-Facing Server). I suppose to really defend against a global
> observer, you would need some kind of mixnet.

If the client hello is not encrypted to backend server, one does not
need timing analysis if one is on both sides: Things like key share
and client random allow much more robust correlation.

> It looks like a little bug in the draft. I've checked just now and I
> don't see that it says exactly *where* the observer is. I had assumed
> that the observer only sees the Client–Server link (in Shared Mode) or
> the link between Client and Client-Facing Server (in Split Mode).

I think there have actually been real world attacks where link from
client to CDN is encrypted, but link from CDN to backend is not,
and attacker attacked the CDN to backend link.

And those were active attacks, the attacks I am talking about are
passive-only (not as exciting, but more dangerous).

> I don't understand your point about replay and encrypting the Client
> Hello. An observer doesn't need to see the contents of the Client Hello
> to identify a Backend Server--the destination IP address is enough. I
> don't see what specific attack you have in mind using replay, but it
> seems to me that even an encrypted tunnel is insufficient. Unless the
> encrypted tunnel additionally obfuscates packet sizes and timing, an
> observer can correlate e.g. burst sizes and match incoming flows to
> outgoing flows, in the manner of website fingerprinting.

>From the destination IP address, one can only tell that _some_ client
is accessing the backend. One presumably wants to know _which_ client
is doing so (e.g. correlating the IP address of the client). Because
otherwise the client might actually be someone from juristiction that
is not friendly to you.

And yes, even with encrypted tunnel, traffic analysis can get
great amounts of data. It is just that if client hellos are replayable
and there is no tunnel, it is much easier for the attacker to
correlate connections on both sides (since attacker can then observe
new connections versus just some data exchange).



-Ilari