The Benefits of Perfect Forward Secrecy are Two-Fold:<\/h2>\n
Security:<\/strong> Cryptography using ephemeral (one-time) keys is harder to break, because an attacker has to break each session to fully decrypt a user. With static (unchanging) keys, you are reusing the same keys for every session, which means that if one session is broken through a security vulnerability or bad cryptography, all of the previous sessions are also broken because they were using the same keys.<\/p>\n Privacy:<\/strong> If you\u2019re not signing in to a website, and not outed through other browser settings, an ephemeral session should look like a new visit every time you go to a website, because you\u2019re using a new secure session on each visit.<\/p>\n TLS 1.3 has a heavily touted feature called 0-RTT that has been paraded by CloudFlare<\/a> as a huge speed benefit to users because it allows sessions to be resumed quickly from previous visits. This immediately raised an eyebrow for me because this means that full negotiation is not taking place.<\/p>\n After more research, I\u2019ve discovered that 0-RTT does skip renegotiation steps that involve generating new keys<\/a>.<\/p>\n This means that every time 0-RTT is used, the server knows that you\u2019ve been to the site before, and it knows all associated IPs and sign-in credentials attached to that particular key.<\/p>\n \u201cThat\u2019s just surveillance with extra steps!\u201d<\/p>\n The 0-RTT design focuses on keeping \u201cforward secrecy\u201d by changing the keys between each session in a predictable way (hashing \/ salting \/ raising the key by an exponent \/ etc) to generate a new key. This (sort of) fixes the security problems with 0-RTT, but this has multiple serious privacy problems that are not forward secret.<\/p>\n 1. The client has to store this key for future use, instead of destroying it. This opens up these stored session keys to the attack surface of the entire web browser for the time period that the session information is stored.<\/p>\n 2. The server has to store this key for future use, instead of destroying it. This means that the TLS 1.3 0-RTT process is fundamentally flawed, as it specifically requires the server to delete information with no verifiable method of doing so. This means that a malicious server can easily follow these keys without deleting them, and associate the 0-RTT session with all previous visits from that original first key. A design that requires internet users to \u201ctrust\u201d that no one will do this is a fundamentally broken design.<\/strong><\/p>\n Here is further scholarly research on how damaging these security practices can be: An excerpt from section 7 of the paper:<\/p>\n This means that not only can websites track your sessions across all known IPs, but that large networks that you frequently hit (think Google Analytics, Google AMP, CloudFlare, Facebook, Twitter, JS libraries, Amazon Web Services, Microsoft Azure etc) can follow you all over the internet and link all of your activity across many sessions.<\/p>\n For a real world example that demonstrates this issue, I visited a TLS 1.3 enabled site with a default build of the latest Firefox. I then closed the browser, signed on to a VPN service, and then visited the same website. While everything on the surface looks the same when you do this, and your IP address is functionally different, under the hood we have a problem. Here\u2019s a WireShark of that second visit:<\/p>\n To be clear, this pre_shared_key identity is uniquely linked to you. Using privacy services with this feature enabled is like putting on a disguise to get into a bar you were kicked out of, and then handing the bouncer your photo ID.<\/p>\n 0-RTT is an \u201cimprovement\u201d over a prior implementation of early_data that applies similar principles. 0-RTT is better in that it doesn\u2019t continuously re-use the same static key, and at least changes it from session to session, making it harder for a man in middle to learn the shared secret. However, to gain the performance edge in 0-RTT, session resumption has to be carried out without replay protection.<\/p>\n In essence, the TLS 1.2 version of session resumption is less safe because the standard has no defined mechanism for changing keys like TLS 1.3s 0-RTT, and both the TLS 1.2 and TLS 1.3 versions of session resumption ignore the principal of ephemeral data and allow services to track users with very high accuracy.<\/p>\n This means that even while in private mode, and with privacy extensions installed in Firefox, this problem persists and can out you.<\/p>\n To mitigate this, you need to be able to disable both TLS 1.2 and TLS 1.3 session resumption. There are four settings related to this scenario that we have to change to fully address the problem.<\/p>\n This is the 0-RTT feature itself. Disabling this feature disables the ability for the server and browser to negotiate a 0-RTT connection using related keys and no replay protection.<\/p>\n To disable 0-RTT: Type about:config into your navigation bar in Firefox. In the screen that pops up, enter security.tls.enable_0rtt_data into the search bar, and make sure that the setting is set to FALSE.<\/p>\n Next, we have to disable the TLS 1.2 session resumption mechanisms. This prevents Firefox from being able negotiate session resumption using static session IDs or session tickets.<\/p>\n To disable session identifiers: Type about:config into your navigation bar in Firefox, in the screen that pops up, you must right click on a blank area of the page and select new -> boolean.<\/p>\n In the window that pops up, we have to enter the exact name of the hidden feature: security.ssl.disable_session_identifiers and hit OK.<\/p>\n Then we have to search for the feature that we added and make sure that it is set to TRUE.<\/p>\n The next two features help to isolate the problem, and explicitly prevent 3rd party services from tracking you by using session IDs, session tickets, and related keys.<\/p>\n This feature prevents the browser from making requests to sites outside of the primary domain from the site. This prevents large ubiquitous services from following your keys around the web like a supercookie.<\/p>\n To enable first party isolation: Type about:config into your navigation bar in Firefox. In the screen that pops up, enter privacy.firstparty.isolate into the search bar, and make sure that the setting is set to TRUE. (This setting can break websites that rely heavily on 3rd party libraries and scripts.)<\/p>\n Lastly, we have to disable False Start. This is because it does not allow the client to fully complete its handshake before starting the actual session. There is more info here from the IETF:\u00a0https:\/\/tools.ietf.org\/html\/rfc7918#section-4<\/a> (See section 5. Security Considerations)<\/p>\n To disable TLS false start: Type about:config into your navigation bar in Firefox. In the screen that pops up, enter security.ssl.enable_false_start into the search bar, and make sure that the setting is set to FALSE.<\/p>\nOne of the Flagship Features of TLS 1.3 Abandons the Privacy Benefit:<\/h2>\n
\n
Hand Waving by the Security Community Ignores Serious Privacy Risks:<\/h2>\n
\nhttps:\/\/jhalderm.com\/pub\/papers\/forward-secrecy-imc16.pdf<\/a><\/p>\n\n
The Use-Case That is Threatened by 0-RTT: Privacy Networks<\/h2>\n
What This Looks Like \u2013 Identifying a VPN user using 0-RTT<\/h2>\n
![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2018\/10\/tls-early-data-cloudflare-1024x659.png\")
<\/p>\nThe Problem is Worse in TLS 1.2<\/h2>\n
Session IDs, Session Tickets, and 0-RTT are enabled by default in \u201cPrivate Mode\u201d on Firefox<\/h2>\n
Mitigation in Firefox<\/h2>\n
security.ssl.disable_session_identifiers (hidden feature)\nsecurity.ssl.enable_false_start\nsecurity.tls.enable_0rtt_data\nprivacy.firstparty.isolate<\/pre>\n
security.tls.enable_0rtt_data<\/h3>\n
![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2018\/09\/disable-0rtt.png\")
<\/p>\nsecurity.ssl.disable_session_identifiers (HIDDEN FEATURE)<\/h3>\n
![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2018\/11\/hidden-feature-1024x278.png\")
<\/p>\n![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2018\/11\/hidden-feature-2.png\")
<\/p>\n![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2018\/11\/hidden-feature-3.png\")
<\/p>\nprivacy.firstparty.isolate<\/h3>\n
![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2018\/11\/Firstpartyisolate.png\")
<\/p>\n![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2018\/11\/False-Start.png\")
<\/p>\n