Hi Selva,
On 25/05/18 16:07, Selva Nair wrote:
On Fri, May 25, 2018 at 9:51 AM, Jan Just Keijser <janj...@nikhef.nl> wrote:
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.
no, I've heard a lot and talked a lot about this proposal before it
ended up on the list. I do know what the purpose is, it's just that I
have serious doubts about replacing
( pub/priv key plus 'trust anchors' such as CA certificates )
by
( we all trust each other because we know each other's SHA2 hashes )
There are downsides to a PKI with certificates but I think we're
throwing out too much of the good stuff by allowing "just a hash" as the
basis for trust. And one of my main concerns is that people keep
comparing it to "that's just like how SSH does it" - *THAT* is simply
not true.
JM2CW,
JJK
------------------------------------------------------------------------------
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
