Hi, On Fri, May 25, 2018 at 9:51 AM, Jan Just Keijser <janj...@nikhef.nl> wrote: > Hi, > > On 25/05/18 03:41, Simon Rozman wrote: >>>> >>>> Private and public key are still used. The patch stil uses >>>> certificates and TLS, it only replaces the check certificate of the >>>> peer's certificate against the CA with a hash check (certificate >>>> pinning if you want). >>>> >>>> So basically instead of saying that you trust all certificates signed >>>> by a CA, you only trust only those certifcates of which have hashes. A >>>> certificate pinning of an unknown CA is exactly the same. Since you >>>> cannot verify that certificate you add a one off certificate in your >>>> list of trusted certificates. >>> >>> Correct me if I'm wrong, but this approach allows for self-signed >> >> certificates >>> >>> too, right? >> >> Exactly! Client and server can use whatever certificate they like or make >> a >> self-signed one. All they need to do is to exchange their fingerprints >> over >> some trustworthy channel. >> >> Simple. Like SSH. >> >> > for the record: this is not entirely the same as SSH. What happens when > establishing an SSH connection to a new server is that you send the *public > key* to the server, not a hash; similarly the server sends its public key to > the client. The client needs to accept this new key, otherwise the > connection is aborted. For public/priv authentication to work, the server > must know the public key of the client (listed in the authorized_keys file) > , otherwise the user is prompted for a password. Thus, for SSH a > 'trustworthy channel' consists of the user typing 'y' when connecting to a > new server and the server accepting a username+password upon first > connection from a client. > > To implement a similar feature in OpenVPN would require a way to send only > the public key upon TLS initialisation, and these public keys would then > need to be stored/listed on the server somewhere. Probably possible, but a > different approach then to what is proposed above. I'd be (slightly) in > favour of sending public keys instead of hashes, BTW, as it them more > closely mimicks what SSH does.
Me too chiming in :) JJK, I think you are misreading this proposal. No hash is being sent as a part of the handshake -- its still client and server certificates that are exchanged and checked during handshake. The hash is exchanged by a separate channel (say snail mail:) in advance, and serves the purpose of establishing trust (ie., the prior knowledge of hash replaces the prior knowledge of a trusted CA). How the hash is exchanged is beyond the scope of openvpn or TLS handshake in this case. Selva ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
