id summary reporter owner description type status priority milestone component version severity resolution keywords cc 633 tls-enc - symmetric protection of TLS handshake janspambox Steffan Karger "Currently, users have to choose between static key encryption or TLS. If you choose static key, you have no forward secrecy - if the key gets compromised, anyone can read your past traffic. Also, just connecting to a server is enough to make it divulge some of your network traffic in encrypted form, no authentication needed. However, if your key does not get compromised, even a quantum attacker will be unable to read your traffic. If you choose TLS, you have forward secrecy against regular adversaries if your key gets leaked, but you also have the guarantee that all your traffic will eventually be readable by anyone who is willing to store the encrypted form until they get a quantum computer. There is tls-auth, which will protect against attacks like Heartbleed by authenticating the TLS packets with HMAC, but it doesn't stop this attack (as the hardening page correctly points out). To protect against this, I would like to propose tls-enc, which would encrypt the TLS traffic with a static key, just like tls-auth authenticates it. I think this idea was shot down as unnecessary in the past, but given the Snowden disclosures, the NSA announcing a soon-to-come push for quantum safe crypto, and the fact that this issue will disclose past traffic, I think this would be a valuable addition now. Like tls-auth, an implementation should not require replay protection, as this would be covered by the TLS layer, but there may be a risk that an attacker could use the server as an oracle to decrypt captured packets if there is a way for an attacker to reorder/replay packets that get fed into the TLS layer and elicit distinct responses depending on the content. I'm not sure if the OpenVPN protocol would allow that though. The overhead should be minimal - since this only affects connection establishment, adding 8-16 bytes for an IV to each packet won't be too expensive, and tls-enc with AES-GCM could replace the HMAC in tls-auth, making it no more expensive than the status quo in terms of CPU. Would this be something that OpenVPN would like to implement, or at least something that OpenVPN would accept a patch for?" Feature Wish closed major release 2.4 Crypto OpenVPN git master branch (Community Ed) Not set (select this one, unless your'e a OpenVPN developer) fixed