SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

General discussion and chat (archived)
Locked
User avatar
nicolaasjan
Apollo supporter
Apollo supporter
Posts: 46
Joined: 2017-07-28, 14:44
Location: The Netherlands

SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by nicolaasjan » 2018-11-15, 18:09

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?
Linux Mint 19.3 Mate 64bit
Pale Moon latest

User avatar
billmcct
Keeps coming back
Keeps coming back
Posts: 842
Joined: 2012-09-04, 15:19
Location: Atlanta Georgia USA

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by billmcct » 2018-11-15, 18:56

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.
BACKUP - BACKUP - BACKUP
Three things in life are certain; Birth, Death and Loss of data.
You have no control over the first two, but you DO control the last.

Happy Pale Moon 29.x.x 32bit user on Win 7 x64 and Win 8.1 x64.

But hey y'all, I still ride everywhere with my "Chumpy Bear."

User avatar
nicolaasjan
Apollo supporter
Apollo supporter
Posts: 46
Joined: 2017-07-28, 14:44
Location: The Netherlands

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by nicolaasjan » 2018-11-15, 19:19

billmcct wrote: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)
Linux Mint 19.3 Mate 64bit
Pale Moon latest

User avatar
nicolaasjan
Apollo supporter
Apollo supporter
Posts: 46
Joined: 2017-07-28, 14:44
Location: The Netherlands

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by nicolaasjan » 2018-11-15, 19:39

There is a thread about this issue on r/Firefox (sorry...) as well, with comments of the author of the article.
Linux Mint 19.3 Mate 64bit
Pale Moon latest

User avatar
Isengrim
Board Warrior
Board Warrior
Posts: 1323
Joined: 2015-09-08, 22:54
Location: 127.0.0.1
Contact:

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by Isengrim » 2018-11-15, 20:50

Related thread here: viewtopic.php?f=13&t=20702
a.k.a. Ascrod
Linux Mint 19.3 Cinnamon (64-bit), Debian Bullseye (64-bit), Windows 7 (64-bit)
"As long as there is someone who will appreciate the work involved in the creation, the effort is time well spent." ~ Tetsuzou Kamadani, Cave Story

User avatar
billmcct
Keeps coming back
Keeps coming back
Posts: 842
Joined: 2012-09-04, 15:19
Location: Atlanta Georgia USA

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by billmcct » 2018-11-15, 22:20

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.
BACKUP - BACKUP - BACKUP
Three things in life are certain; Birth, Death and Loss of data.
You have no control over the first two, but you DO control the last.

Happy Pale Moon 29.x.x 32bit user on Win 7 x64 and Win 8.1 x64.

But hey y'all, I still ride everywhere with my "Chumpy Bear."

User avatar
gepus
Astronaut
Astronaut
Posts: 564
Joined: 2017-12-14, 12:59

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by gepus » 2018-11-15, 22:38

billmcct wrote: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.

User avatar
nicolaasjan
Apollo supporter
Apollo supporter
Posts: 46
Joined: 2017-07-28, 14:44
Location: The Netherlands

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by nicolaasjan » 2018-11-16, 10:20

billmcct wrote: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".
Linux Mint 19.3 Mate 64bit
Pale Moon latest

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 29325
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by Moonchild » 2018-11-16, 14:53

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).
"Son, in life you do not fight battles because you expect to win, you fight them merely because they need to be fought." -- Snagglepuss
Image

User avatar
JustOff
Moon Magic practitioner
Moon Magic practitioner
Posts: 2083
Joined: 2015-09-03, 19:47
Location: UA
Contact:

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by JustOff » 2018-11-16, 16:14

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.
Here are the add-ons I made in a spare time. That was fun!

If you have any questions or problems regarding the migration of my extensions to GitHub, feel free to contact me through a PM.

User avatar
nicolaasjan
Apollo supporter
Apollo supporter
Posts: 46
Joined: 2017-07-28, 14:44
Location: The Netherlands

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by nicolaasjan » 2018-11-16, 16:46

JustOff wrote: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... :o

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.
Linux Mint 19.3 Mate 64bit
Pale Moon latest

User avatar
gepus
Astronaut
Astronaut
Posts: 564
Joined: 2017-12-14, 12:59

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by gepus » 2018-11-16, 18:50

JustOff wrote: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.
JustOff wrote: while its implementation in UXP applications (Pale Moon, Basilisk, etc.) is currently even incomplete.
It explains the absence of the setting. Thanks!

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 29325
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by Moonchild » 2018-11-16, 20:00

nicolaasjan wrote:That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true... :o
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.
"Son, in life you do not fight battles because you expect to win, you fight them merely because they need to be fought." -- Snagglepuss
Image

User avatar
Paleist
Hobby Astronomer
Hobby Astronomer
Posts: 21
Joined: 2017-08-23, 09:44

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by Paleist » 2018-11-17, 15:48

Moonchild wrote:
nicolaasjan wrote:That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true... :o
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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 29325
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by Moonchild » 2018-11-20, 08:55

Paleist wrote: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.
"Son, in life you do not fight battles because you expect to win, you fight them merely because they need to be fought." -- Snagglepuss
Image

Goodydino
Astronaut
Astronaut
Posts: 643
Joined: 2017-10-10, 21:20

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by Goodydino » 2018-12-15, 19:21

... a canvas fingerprint?

Mod Edit: keep on topic, please.
Last edited by satrow on 2018-12-16, 10:28, edited 1 time in total.

User avatar
suffix
Hobby Astronomer
Hobby Astronomer
Posts: 18
Joined: 2018-10-26, 08:01
Location: Russia
Contact:

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by suffix » 2019-01-18, 08:16

Moonchild wrote: [*]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

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 29325
Joined: 2011-08-28, 17:27
Location: Tranås, SE
Contact:

Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3

Post by Moonchild » 2019-01-20, 14:24

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.
"Son, in life you do not fight battles because you expect to win, you fight them merely because they need to be fought." -- Snagglepuss
Image

Locked