1511681 - TLS Warning Alerts can keep a connection open indefinitely

Status: RESOLVED WORKSFORME

(Core :: Networking, enhancement, P2)

Description

[Tom Ritter [:tjr] (OOTO until April)]

A component of https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2018/the-9-lives-of-bleichenbachers-cat.pdf includes the following:

"Adrian et al. [4] show a technique that forces Firefox to keep a TLS handshake alive indefinitely, thus allowing us to perform even very long attacks."

That reference (https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf) says

"Web browsers tend to have shorter timeouts, but we can keep their connections alive by sending TLS warning alerts, which are ignored by the browser but reset the handshake timer. For example, this allows us to keep Firefox’s TLS connections alive indefinitely. (Other browsers we tested close the connection after a minute.)"

It seems like our behavior is inconsistent with other browsers and makes TLS-based attacks easier to exploit. Perhaps we should change this behavior?

(I'm filing this in Networking, because I was told we might have discussed adding timeouts in the necko layer for this?)

Comment 1

[Dragana Damjanovic [:dragana]]

We have a tls handshake timeout. It was added for a different reason, but that does not matter.

It was added in bug 1393691. It is control by pref "network.http.tls-handshake-timeout" and default value is 30s.

Comment 2

[Martin Thomson [:mt:]]

Thanks Dragana.  30 seconds seems fine.  I wonder if that number is a little too conservative, do you think that a smaller value might be worth looking into?

Just to put some parameters on this, absent packet loss, the handshake can take 2 round trips (even in TLS 1.3).  Add another round trip for large certificates that overflow the initial window.  If we allow for packet loss, we might say that we can double that on a really bad network.  That means 6 round trips.  If we take the extreme case in RFC 6298 with an initial RTO of 3 seconds, we get 18 seconds, but that document is written as though interactive applications don't exist (it suggests a max RTO of 60 seconds).  I suspect that we'd get someone hitting refresh before we got to 15 seconds.

Comment 3

[Dragana Damjanovic [:dragana]]

(In reply to Martin Thomson [:mt:] from comment #2)
> Thanks Dragana.  30 seconds seems fine.  I wonder if that number is a little
> too conservative, do you think that a smaller value might be worth looking
> into?
> 
> Just to put some parameters on this, absent packet loss, the handshake can
> take 2 round trips (even in TLS 1.3).  Add another round trip for large
> certificates that overflow the initial window.  If we allow for packet loss,
> we might say that we can double that on a really bad network.  That means 6
> round trips.  If we take the extreme case in RFC 6298 with an initial RTO of
> 3 seconds, we get 18 seconds, but that document is written as though
> interactive applications don't exist (it suggests a max RTO of 60 seconds). 
> I suspect that we'd get someone hitting refresh before we got to 15 seconds.

I do not remember why we have 30s, the bug was a different issue so it was not important.

The extreme case is more extreme than 18s, if a packet get lost 2 times rto doubles... Anyway, telemetry for tcp and tls handshake together is:

for pageload:
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-12-10&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F65&measure=HTTP_PAGE_TLS_HANDSHAKE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-10-22&table=1&trim=1&use_submission_date=0

and for subresources:
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-12-10&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=nightly%252F65&measure=HTTP_SUB_TLS_HANDSHAKE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2018-10-22&table=1&trim=1&use_submission_date=0 

there is some very small number of connections that have taken over 30s (the telemetry is tcp+tls and the timeout is just tls so the telemetry can show values above 30s)

We could set it to 20s. There are people that wait that long.

Comment 4

[Dragana Damjanovic [:dragana]]

I looked at the code and I need to correct what I wrote above. Telemetry for tls handshake only. It will capture telemetry for the failed tls handshakes as well.