tls-enc - symmetric protection of TLS handshake

[janspambox]

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?

[Gert Döring]

Syzzers, yours to evaluate and comment on :-)

[Steffan Karger]

This is a very good idea. Actually, I already have a plan for it (I call it 'tls-crypt', instead of 'tls-enc') and it is on my '2016' todo-list. Our primary goal was to better protect user identities, because this will also encrypt the client (and server) certificates that usually contain information that can be traced back to a person and/or machine. But post-quantum security indeed is a nice other feat of such a scheme.

[Steffan Karger]

I sent an implementation proposal and experimental implementation to the openvpn-devel list a little while ago:
​https://www.mail-archive.com/search?l=openvpn-devel@lists.sourceforge.net&q=subject:%22\[Openvpn\-devel\]+Feature+proposal\%3A+tls\-crypt%22&f=1

Comments, test results, etc, are very welcome!

[Gert Döring]

I would claim that this is implemented now :-) - @janspambox: can you please test 2.4_rc1?

commit c6e24fa3e16c32f9b427e360fd07102f613aa5c6
Author: Steffan Karger <steffan.karger@…>
Date: Tue Nov 15 14:29:46 2016 +0100

Add control channel encryption (--tls-crypt)

This adds a --tls-crypt option, which uses a pre-shared static key (like
the --tls-auth key) to encrypt control channel packets.

[janspambox]

Thank you for implementing this!

I've tested the following combinations successfully:
Windows client 2.4rc1 against some way-too-old linux server with tls-auth
Windows client 2.4rc1 against linux server 2.4rc1 with tls-auth
Windows client 2.4rc1 against linux server 2.4rc1 with tls-crypt

I also verified that I could see strings from the certificate in a packet capture in the tls-auth case but not in the tls-crypt case, as expected. :)

(I have not performed any other sort of review beyond this test.)

[Steffan Karger]

Yes, this one is in! And thanks for testing.

Closing this ticket now. Any bugs (if any ;) ) can be reported by opening a new ticket.