On 09.04.20 11:46, Gert Doering wrote: >> Preshared *public* keys, correct. In contrast to the PSK setup that >> OpenVPN offers, which is just symmetric keys. That's a world of a >> difference, mind you. > > OpenVPN with pre-shared secret is not the recommended way of operation > since quite an number of years now (because it has no DH or equivalent). > > TLS with public/private crypto is what you should be using.
Yes, for OpenVPN full PKI is the only good option, which is quite difficult for people unfamilar with security to set up. I'm just saying that the way SSH and Wireguard do it, using raw public keys, gives you all the benefits you're pointing out (PFS using ephemeral key agreement) while still having none of the drawbacks a symmetric PSK has (such as the implementation that OpenVPN uses for PSK). I wasn't suggesting to use OpenVPN-PSK, quite frankly I find it's super crappy. But I do think it's worthwhile pointing out that symmetric PSK is NOT at all the same as asymmetric PSK. >>> OpenVPN >>> is a user-space application that does way more than that, all based on >>> TLS. >> >> Is it all based on TLS? As far as I recall, OpenVPN rolled their own >> protocol, loosely based on some TLS parts, but their own thing >> regardless. With different crypto settings for the comms and bulk data >> channel, if I recall correctly. Am I misremembering or has this been >> aligned by now? You're saying OpenVPN uses just plain old DTLS when run >> over UDP? > > There is a control channel, which is mostly "TLS over UDP", though not > DTLS (because when the control channel protocol was defined, there was > no DTLS). On that channel, handshaking is done, and based on key material > from the TLS control channel, a symmetric session key for the data channel > is negotiated. Then my memory served me correct. Historically I can understand that, OpenVPN was there before DTLS was. But today it makes zero sense anymore. > Some of the confusion regarding ciphers and hash algorithms comes from > that - whether or not a given cipher algorithm is supported depends on > "will the TLS library do it for the control channel" and "after a key > has been negotiated, will the openvpn data layer support using it for > data packets". Some of the ciphers need different API calls into the > SSL libraries, so "just add a new data channel cipher" required actual > code changes (like, AEAD, and as far as I understand, CHACHA-POLY as > well). That's just what I was trying to get at: Every advance in a TLS library does /not/ automatically add that capability to OpenVPN (as Jan suggested), but there's extra steps on the OpenVPN side which can (and did!) delay progress significantly. Best regards, Johannes _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
