On 07/11/2019 16:08, Thomas Luening wrote: > Hello David & @all > > Thanks for the answers, I think I have now understood a lot better than before > ... especially the purpose of sharing on 2 channels. But it's really hard to > process that all in mind. I will try to describe the basics from a very high > viewpoint, what I have understand, without details. > > The control channel is not DTLS for UDP/IP, but is functionally similar as > DTLS. RSA encrypts traffic on the control channel with an asymmetric key. > --tls-auth improves security with HMAC.
That is basically correct. IIRC, OpenVPN was publicly released early 2000 while the DTLS specification arrived in 2006. So OpenVPN implemented SSL/TLS over UDP this way, and which is why we don't use DTLS (which has also turned out to be good for OpenVPN, due to the amount if issues found in DTLS over the years). You can basically say that the OpenVPN control channel is a pretty much standard TLS connection, but with the multiplexing we do to separate control and data channel we also can use it over UDP. Since it is TLS, asymmetric crypto is used for the TLS handshake, which ends up with a set of ephemeral keys further used for symmetric encryption of the data being passed in the control channel. This symmetric key is negotiated, typically using DH. This symmetric key is the TLS session key. All of this is standard TLS behavior. --tls-auth will also add another layer of HMAC signature on top of the TLS packets. With OpenVPN 2.4, there is also the --tls-crypt alternative which will encrypt the whole control channel (including encrypting the TLS packets). > The data channel is encrypted with a symmetric key, regardless from the > control-channel, ideally with an ephemeral key and e.g. AES. --auth also > improves security with HMAC. That's correct. The data channel key is always an ephemeral key as well, which is derived from the TLS session key. --auth is enabled by default and is implicitly always enabled with AEAD based ciphers (AES-GCM). > The symmetric key always has the correct length and strenght regardless of the > 'depth' of the RSA key. With a 'smaller' RSA depth, only the > symmetric-key-negotiation is weaker. That's correct. > That's how I understood it now. And I hope I can ask one more question about > this process. At the point I still lack the understanding for the key > negotiation with DH. The DH key exchange is basically part of the TLS handshake in the control channel, and is pretty much a standard DH key exchange. > If I understand that correctly, DH does not encrypt additionally during the > negotiation, it use the RSA encrypted control channel. Either a static dh.pem > file or an 'elliptical curve' is used in this negotiation ... but both are > just the base of the public key, which it can be transmitted uncertainly ... > both are just a very large prime number. Is it here the same as in RSA, that a > smaller bit value only leads to a smaller prime, which only leads to a weaker > entropy in the key negotiation ...? ... but there is also no necessarily > negative effect on the strength or the size of the negotiated one symmetrical > key? I'm not too strong in the lower crypto levels, so I'm not an authoritative source here. In regards to the --dh option, it is required for the TLS layer. Where OpenVPN differs from other server products implementing TLS, we require a locally generated DH parameters file. For many other solutions, this is optional and if not provided it will use hard coded DH parameters. This also mostly saved OpenVPN from Logjam attacks <https://weakdh.org/> A weak public key will naturally make the handshake weaker, and the result of the handshake is the symmetric key. When DH is used for the key exchange to derive the TLS session key, the size of the DH parameters is also influencing the strength of the symmetric key. But as you say, the public key is designed by be used in insecure environments, and is required to establish a secure communication between the end points. Elliptical Curves doesn't need the same large size of keys to achieve a comparable security level compared to RSA keys. But if you start considering post-quantum computing, this gets quite a bit more complicated - where it is currently believed RSA keys is harder for a quantum computer to crack compared to elliptical curves. > If what I have described here is interpreted correctly, then in my opinion the > best breaking point in an attack to break the encryption would be a too low > RSA value. But even if RSA-2048 is not recommended for long-term storage for > later than the year 2030, it still means that today's short-lived > OpenVPN-Session based on RSA-2048->Control-Channel can not be breaked today. Yes, this is a reasonable assumption with todays knowledge and the CPU power available today. > And if the Hack of a recorded session is continued to or after 2030, it can > not be breaked retroactively, because it is not possible to reconstruct the > ephemeral symmetric key ... even if the complete packet traffic was recorded > .... that does not work because the peers' secret key is not available and not > recoverable. Is this conclusion correct? Kind of. No encryption is 100 secure against brute force attacks, neither now nor tomorrow. But OpenVPN uses key negotiation every hour, which means if one symmetric data channel key is retrieved, it is only valid for the packets within the time window for that key. But retrieving the data channel key from a saved packet dump is not too easy. I cannot say it is impossible, as it depends on what kind of vulnerabilities are found in the various key derivation methods implemented either in OpenVPN, crypto libraries or even the TLS and cipher specifications. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
