FYI: TLS1.2 + 1.3 SuperCooKey

[Thorin-Oakenpants]

snip

[tomrittervg]

The crux of it - that TLS features like 0rtt and Session Resumption can be used as persistent identifiers - is true. But FPI isolates them. (And doesn't block requests as the article says!) And Private Browsing Mode also has the expected protections.

False start has nothing to do with persistent identifiers.

[earthlng]

FPI isolating them is great but there are other issues with 0rtt, namely replay attacks and breaking forward-secrecy. Even passive attackers without the ability to inspect https traffic can do replay attacks according to the DEFCON presentation about 0rtt.

I really hope mozilla won't remove that pref any time soon (or really EVER) because "it's been enabled for x releases"

[JohnWooo]

According to this article (see 2.3 and figure 2.c), do I understand correctly that the 1-RTT variant of TLS 1.3 session resumption allows tracking exactly like the session resumption mechanisms anterior to TLS 1.3 that used session IDs or session tickets ?
Is it also correct that contrary to those anterior tracking mechanisms, that could be disabled by setting
security.ssl.disable_session_identifiers = true ,
there is no about:config pref to disable this 1-RTT TLS 1.3 session resumption tracking ? Or does this pref work for TLS 1.3 too ?

[Atavic]

The PDF link here gives an idea of how this feature can be weaponized by holding session tickets for 60 days (as Yahoo and Yandex do).

It's on page 6. A common abuse from cookies to JS to any new API...

[Atavic]

@JohnWooo I assume you meant: see 1.3 and figure 2.c

Session IDs and session tickets are obsolete since TLS 1.3. They’ve been replaced by a more generic PSK mechanism.

See here

The entries on 1st post of this issue make the TLS sessions to respect Forward Secrecy 👍 as user.js 1205 do.

TLS1.3 improves the security of TLS generally, including much better forward-secrecy for all non-0-RTT data.

Bottom here

[JohnWooo]

@Atavic I meant section 2.3 of the article I linked, but yes, the one about TLS version 1.3.
I was talking about tracking by the server using 1-RTT TLS 1.3 session resumption as a supercookie, not about forward secrecy and other cryptographic improvements of TLS 1.3.

[Atavic]

Ok. As noted by Ritter above "supercookie" isn't the best term, BTW I generally agree with respecting Forward Secrecy in TLS handshakes. RTT doesn't do that.

RTT is being promoted for faster connections and lower server loading, but most of that improvements are really negligible.

Old issue: https://github.com/ghacksuserjs/ghacks-user.js/issues/516

[JohnWooo]

As noted by Ritter above "supercookie" isn't the best term

I used this term because TLS session resumption can be used as session cookies even when session cookies are disabled ; maybe some people reserve the word for tracking that persists across sessions ?

BTW I generally agree with respecting Forward Secrecy in TLS handshakes. RTT doesn't do that.

According to the article I referenced, second half of section 2.4, TLS 1.3 0-RTT resumption does never respect forward secrecy, while TLS 1.3 1-RTT resumption can optionally (which may not be enough).

To clarify my question : the article in the OP says that the 1203 pref disables session resumption for TLS<1.3, and 1205 disables 0-RTT resumption for TLS 1.3, but nowhere it talks about how to disable 1-RTT resumption for TLS 1.3, that allows session tracking by the server (and may break forward secrecy). And considering this article contains errors apparently, I don't even trust it when it says that the 1203 pref is limited to TLS<1.3, hence my question.

I asked Mozilla too here:
https://www.reddit.com/r/firefox/comments/9xypc9/question_about_tls_supercookies_blocking/

[ghost]

@tomrittervg wrote,

False start has nothing to do with persistent identifiers.

But what what does false Start have anything to do with? I've searched and couldn't find an explanation of security.ssl.enable_false_start, hardly an old article mentioning that Google had abandoned it at the time because it figured out that too many servers weren't responding correctly... that was years ago. Now, in 2018, what exactly does SSL False Start perform? Why enable it (default), why disable it (if any reasons)?

[Atavic]

This document specifies an optional behavior of TLS implementations, dubbed False Start: It's one of the google pushes included in spdy, precursor of HTTP/2.

[ghost]

Thanks @Atavic , no idea why I missed the link you provide when searching, or maybe had I ignored it too quickly when noticing the document is dated June 2010.

You write,

It's one of the google pushes included in spdy, precursor of HTTP/2.

SPDY replaced by HTTP/2 .... any sense in wondering if disabling the latter leads to an irrelevant SSL False Start?

I'm guessing most of you guys are beyond this quest of definitions. I'm not refueling the debate, only trying to better understand. The IETF document brings some answers. Thanks again.

[tomrittervg]

False Start is a hack-optimization for TLS 1.2 and below which sends application data before the TLS Handshake is completed. It has some compatibility problems, because this behavior goes against spec, but it works in the overwhelming percentage of cases. However I believe Google still disabled it for the vast minority of problems it caused.

The security concern is that an attacker could downgrade the negotiation so you wind up encrypting data with a weak ciphersuite that could lead to decryption. Thus false start is prohibited if a weak cipher is negotiated.

From memory, TLS 1.3 codifies false start into the normal operation of the protocol.

Unless you are facing compatibility problems with a weird network appliance that can't handle false start; there is no reason to disable it.

[Atavic]

dated june 2010

That's the draft, the actual RFC is here

there is generally no way to be sure that communication with the expected peer is indeed taking place during the False Start.

...from page-6 above.

wondering if disabling the latter leads to an irrelevant SSL False Start?

False Start applies to TLS Protocol Version 1.2 and will be deprecated in TLS 1.3 while HTTP2 applies to TCP connections: they are different protocols.

[ghost]

Thanks @tomrittervg ,

Unless you are facing compatibility problems with a weird network appliance that can't handle false start; there is no reason to disable it.

I hadn't encountered any obvious compatibility problem but I'm disabling it nevertheless pref("security.ssl.enable_false_start", false); because your very explanation, as I understand it, confirms what I perceive as a speculative hacking : "it works most of the time, let's keep it" or not, according to Google. You do state yourself that there is a security concern, maybe negligible (speculation) but not false.

Or I may be exaggeratedly technically idealist : nothing being perfect the idea is to allow a good ratio of advantages/risk. I have SSL False Start disabled and perceive no slowdown. In the same way I perceive no slowdown with http2 disabled. My feeling is that connection quality depends at 90%+ of one's OS connection quality (speed, ping ...) plus browser settings and much much less on these hacks which often hit security for the sake of a hypothetical thousands of a second speed gain.

[ghost]

@Atavic ,

False Start applies to TLS Protocol Version 1.2 and will be deprecated in TLS 1.3 while HTTP2 applies to TCP connections: they are different protocols.

Got it, as well as the actual RFC / (TLS) False Start. Thanks.