I was reading up on the new spec for TLS 1.3 and I caught a snippet of text that stuck out.
“TLS 1.3 also enables forward secrecy by default which means that the compromise of long term secrets used in the protocol does not allow the decryption of data communicated while those long term secrets were in use. As a result, current communications will remain secure even if future communications are compromised.”
Current communications will remain secure? I would sure hope so! What are they talking about? Why would we need to worry about current traffics remaining secure in the future?
I smell something cool about to be learnt here. Put your thinking gloves on and keep your ears to the grindstone cuz’ here we go! (“Ya Suspect!”)
Lets see if we can take this apart as it is eluding to several things:
Forward Secrecy: ( or Perfect Forward Secrecy ) Implementing the use of an ephemeral shared secret for encrypting payloads such that an attacker can not reuse it to attack other transmissions.
Long Term Secrets: I know what they mean when they say this, but I’d like to come up with a precise definition of long term secret… we’ll come back to this one.
Current Communications Remaining Secure: This is the part that really got me. Why would someone have to worry about this? This is absolutely savage. What is going on here? Well.. here is what I can deduce: If future communications are compromised, that implies that someone has gotten a hold of a key to decrypt an intercepted payload and done just that…. but the need to protect encrypted payloads transmitted in the past also implies that THEY HAVE THE TRAFFIC.
Are you kidding me? They are on your network running a rogue service with access to an outbound port. Lets get serious about what this means. Attack surface is everything; if you do not have control of what is running in your network, you have bigger problems than will be addressed by TLS 1.3. This is making me too upset and I need to go calm down. While Im counting to ten, lets have you go back to defining the meaning of Long Term Secrets.
The Slack Developer Blog remarked about the usage of a Long Term Secret when they introduced Request Signing and Mutual TLS Verification for their API integrations:
Both Request Signing and Mutual TLS allow verification without sending a secret along with every request, preventing the exposure of long-term secrets — even in the presence of someone intercepting a request or TLS-terminating infrastructure that should not have access to the secret.
Seeing as how they used to issue a predetermined secret over HTTP, I can see how they made the move for protecting their integrations from spoofed requests, but this still doesn’t give us an understanding of the complete details of this secret and what makes it long term. Lets keep digging…
And… yay! It looks like I found something perfect ( ha ) for describing this kind of secret… Im looking forward ( Okay, i’ll stop ) to seeing where it leads. John Deters scribbled out some prose on the Crypto subdomain of stack overflow which will encapsulate this nicely:
A long-term key is one that is deliberately stored somewhere, either on a computer disk, flash memory, or even printed on paper. The key is intended to be used at multiple points in time, such as “I will use this key to encrypt this secret file today, and use it again to decrypt my secret next week.” A long term key can be used for any purpose, including stored information as well as transient communications.
So, what does this point us to? Certificates! Private Keys! The most protected element of the cryptography process. Now, as my intolerance for ambiguous verbiage has made itself known to all on this soul searching quest to find meaning ( for a word :), the beauty of the analyst’s quest for exacting definitions is on display. Sometimes you just have to go hunt some things down and make the kill… the best part of which is all the other little mysteries and rabbit holes that make themselves known. If we read further down the page we see John continue with ( may I call you John? ) a specific point of interest:
* Note that an attacker can certainly record the session key exchange, and if they can break the key exchange cryptography they can decrypt the session key.
“Do you know what this means?”
“It means that this…damn…thing…doesn’t work at all!”
Key Exchange Cryptography?! What does that mean!!? How exciting… a new snake pit for us to jump in. We will talk about that next time….but for now, the moral of this story has really been the underlying cause for the importance of Forward Secrecy — the fact that you may have someone on your network or on your workstation running a tcpdump of every network request in sight. Sort of parallels the focus on output sanitization for mitigating your XSS issues.
Take care. And remember: Ya suspect!