SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
- nicolaasjan
- Moon lover
- Posts: 90
- Joined: 2017-07-28, 14:44
- Location: The Netherlands
SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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?
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 20.3 Mate 64bit
Pale Moon latest
Pale Moon latest
- billmcct
- Keeps coming back
- Posts: 959
- Joined: 2012-09-04, 15:19
- Location: Costa Rica & Union City Georgia USA
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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.
If you have changed it to True then disable it by setting it to False.
--------------------------------------------------------------------------------------------------------------
The difference between the Impossible and the Possible lies in a man's Determination.
Tommy Lasorda
The difference between the Impossible and the Possible lies in a man's Determination.
Tommy Lasorda
- nicolaasjan
- Moon lover
- Posts: 90
- Joined: 2017-07-28, 14:44
- Location: The Netherlands
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
Hi,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.
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 20.3 Mate 64bit
Pale Moon latest
Pale Moon latest
- nicolaasjan
- Moon lover
- Posts: 90
- Joined: 2017-07-28, 14:44
- Location: The Netherlands
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
There is a thread about this issue on r/Firefox (sorry...) as well, with comments of the author of the article.
Linux Mint 20.3 Mate 64bit
Pale Moon latest
Pale Moon latest
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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
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
- billmcct
- Keeps coming back
- Posts: 959
- Joined: 2012-09-04, 15:19
- Location: Costa Rica & Union City Georgia USA
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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.
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.
--------------------------------------------------------------------------------------------------------------
The difference between the Impossible and the Possible lies in a man's Determination.
Tommy Lasorda
The difference between the Impossible and the Possible lies in a man's Determination.
Tommy Lasorda
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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.billmcct wrote:Two have to be created: Don't really know if they will even work in PM.
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
- Moon lover
- Posts: 90
- Joined: 2017-07-28, 14:44
- Location: The Netherlands
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
Sorry I was not really clear.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.
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 20.3 Mate 64bit
Pale Moon latest
Pale Moon latest
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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
- Moon lover
- Posts: 90
- Joined: 2017-07-28, 14:44
- Location: The Netherlands
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true...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.
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 20.3 Mate 64bit
Pale Moon latest
Pale Moon latest
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
Yes, it may break cross-domain logins and site functionality.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)
It explains the absence of the setting. Thanks!JustOff wrote: while its implementation in UXP applications (Pale Moon, Basilisk, etc.) is currently even incomplete.
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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.nicolaasjan wrote:That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true...
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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 wrote: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.nicolaasjan wrote:That makes me wonder why the Tor Browser developers decided to set "privacy.firstparty.isolate" to true...
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
... 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.Paleist wrote:but the really important ones are the other three.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
... a canvas fingerprint?
Mod Edit: keep on topic, please.
Mod Edit: keep on topic, please.
Last edited by satrow on 2018-12-16, 10:28, edited 1 time in total.
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
1.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.
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
Re: SuperCooKey – A SuperCookie Built Into TLS 1.2 and 1.3
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.
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.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite