SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

[nicolaasjan]

SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

I just stumbled upon this article, which is way beyond my knowledge, but I wonder if Pale Moon is affected by this as well?
And if so, what is the best way to mitigate this, without breaking websites?

[billmcct]

In about:config the default for "security.tls.enable_0rtt" is false.
If you have changed it to True then disable it by setting it to False.

[nicolaasjan]

In about:config the default for "security.tls.enable_0rtt" is false.
If you have changed it to True then disable it by setting it to False.

Hi,
Thanks for your answer.
My settting for "security.tls.enable_0rtt_data" is default (false).

But what about these 3 other settings:

security.ssl.disable_session_identifiers (hidden feature in Firefox)
security.ssl.enable_false_start (true, but false is recommended by him)
privacy.firstparty.isolate (non existent or hidden in Pale Moon)

[nicolaasjan]

There is a thread about this issue on r/Firefox (sorry...) as well, with comments of the author of the article.

[Isengrim]

Related thread here: viewtopic.php?f=13&t=20702

[billmcct]

Two have to be created: Don't really know if they will even work in PM.
security.ssl.disable_session_identifiers set to True
privacy.firstparty.isolate set to False as the article says it can break websites. If websites break toggle to True

security.ssl.enable_false_start set to False

The article you linked explained all this.

[gepus]

Two have to be created: Don't really know if they will even work in PM.

Assuming that Pale Moon's 28 code base is based on that of Firefox 52 then the hidden pref security.ssl.disable_session_identifiers should apply if created. So far so good.
However it's strange that privacy.firstparty.isolate is missing in Pale Moon 28 whereas it was present (and never hidden) in Firefox 52.

It would be great if someone with expertise would be so kind to enlighten us.

[nicolaasjan]

Two have to be created: Don't really know if they will even work in PM.
security.ssl.disable_session_identifiers set to True
privacy.firstparty.isolate set to False as the article says it can break websites. If websites break toggle to True

security.ssl.enable_false_start set to False

The article you linked explained all this.

Sorry I was not really clear.
But the article is about Firefox and we are using Pale Moon.

If all 4 preferences need to be set according to his recommendation, then the issue cannot be fully mitigated in Pale Moon when one or two "don't work".

As @gepus said, "it would be great if someone with expertise would be so kind to enlighten us".

[Moonchild]

It all depends on what you feel you need to "fully mitigate". All of this touches different parts of security and privacy.

• If you feel that the normal TLS session duration for servers (generally set to 10 minutes) is too long and you are worried that you may get tracked through it, i.e. you will be requesting resources from the same TLS host within that time from different locations on the web and fear that those hosts are actively keeping track of your session that way, then by all means, disable session identifiers and force a renegotiation every time your protocol TTL expires. As stated before this imposes significant overhead and will cause noticeable latency by disabling an essential part of TLS session management.
• If you feel that TLS false starts are a security risk (they aren't really, because it just means you are sending the encrypted HTTP GET before you get the final TLS finished response from the server, i.e. the moment you have enough data on the client side to send an encrypted request) then you can disable that option and go from 1-RTT to 2-RTT for a TLS connection start. Tracking is NOT possible through false starts.
• 0-RTT with TLS 1.3 is trickier and has a replay attack risk. All 0-RTT solutions require sending key material and encrypted data from the client without waiting for any feedback from the server, meaning a bad actor can intercept and replay the connection. This is a significant risk and the reason why it is disabled in Pale Moon.
• First party isolation only comes into play when you feel you need to mitigate tracking of your presence on sites where a 1st party visit can be linked to content (usually 3rd party) on another website. I don't see this as a particular risk since you are already trusting those websites with your more lenient 1st party visit and data storage.

If you want to know more details about how false starts, TCP fast open and 0RTT data work, I suggest you check out Microsoft's article on the matter which explains it in a way any layman can understand (something that's not my forte).

[JustOff]

I also want to add that First Party Isolation is known to lead to incorrect work of sites (and therefore it's still disabled by default even in recent versions of Firefox), while its implementation in UXP applications (Pale Moon, Basilisk, etc.) is currently even incomplete.

[nicolaasjan]

I also want to add that First Party Isolation is known to lead to incorrect work of sites (and therefore it's still disabled by default even in recent versions of Firefox), while its implementation in UXP applications (Pale Moon, Basilisk, etc.) is currently even incomplete.

That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true...

Anyway, I decided to not change anything for now and on the occasions I really don't want to be tracked, like when searching for medical issues for example, I use the Tor Browser anyway.

[gepus]

I also want to add that First Party Isolation is known to lead to incorrect work of sites (and therefore it's still disabled by default even in recent versions of Firefox)

Yes, it may break cross-domain logins and site functionality.

while its implementation in UXP applications (Pale Moon, Basilisk, etc.) is currently even incomplete.

It explains the absence of the setting. Thanks!

[Moonchild]

That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true...

Because they are trying to push the envelope as hard and fast as possible. They don't care if the web breaks as long as their leak paranoia is satisfied.

[Paleist]

That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true...

Because they are trying to push the envelope as hard and fast as possible. They don't care if the web breaks as long as their leak paranoia is satisfied.

Yeah, they tend to do a bit too much. I'd have liked to play with that setting, but the really important ones are the other three.

[Moonchild]

but the really important ones are the other three.

... of which only the 0rtt-data one is actually bearing any risk, and that is disabled by default. The other two are really not an issue. The person writing the article is making some assumptions about how session identifiers are stored and for how long that are quite incorrect.

[Goodydino]

... a canvas fingerprint?

Mod Edit: keep on topic, please.

[suffix]

[*]0-RTT with TLS 1.3 is trickier and has a replay attack risk. All 0-RTT solutions require sending key material and encrypted data from the client without waiting for any feedback from the server, meaning a bad actor can intercept and replay the connection. This is a significant risk and the reason why it is disabled in Pale Moon.

1.

When I implemented 0-RTT on my website, I took this into account in the nginx settings:

"To protect against such attacks at the application layer, the $ssl_early_data variable should be used.

Code: Select all

proxy_set_header Early-Data $ssl_early_data;

"

And I think that most webmasters also follow this advice.

2.

In Firefox 64.0.2 security.tls.enable_0rtt_data by default true

I think the danger is somewhat exaggerated once firefox defaults to true

3.

0-RTT with TLS 1.3 I find it a useful function.

Even in the best verification service, they began to determine its presence:

https://www.htbridge.com/ssl/?id=mr7ExbBc -- Server's TLSv1.3 Early Data (RFC 8446, page 17) is properly implemented

[Moonchild]

Sorry but you misunderstand.
0-rtt by its very nature will always allow replay because no received data is used to perform the TLS handshake and set up the encrypted channel. Replay will allow a transparent MitM attack that can perform passive decryption of your traffic (eavesdropping) on your connection that for all intents and purposes is considered secure on both the client and server side; something impossible with a full handshake.

Firefox enabling this by default IMO is a mistake. Trying to shave off some milliseconds and compromising TLS security as a result is typical behavior for Mozilla though. Just because it's enabled by a mainstream player doesn't mean it's a good thing to do. Just look at the insecure fallback they used for a few years to "connect at all costs" -- also a serious risk but maintained on purpose. We never did that, and have actually done a good amount of evangelism to server operators to get their stuff in order.

Setting the header in NginX just means you're enabling 0-RTT if the browser supports it. Even if included in server tests to see if it's done properly doesn't automatically mean it's a recommended thing to do.