Hi Steffan,
On 17/05/18 20:31, Steffan Karger wrote:
Hi Jason,
[ Dumping my thoughts so this doesn't remain completely unanswered for
even longer. ]
On 17-04-18 18:50, Jason A. Donenfeld wrote:
OpenVPN traditionally works around CAs. However many TLS-based protocols also
allow an alternative simpler mode in which rather than verify certificates
against CAs, the certificate itself is hashed and compared against a
pre-known set of acceptable hashes. This is usually referred to as
"fingerprint verification". It's popular across SMTP servers, IRC servers,
XMPP servers, and even in the context of HTTP with pinning.
So, I'd like to propose an extremely simple and non-invasive way of
supporting this in OpenVPN, by re-using several features that already
basically support it. Namely, what I propose is:
* Allow specifying 'none' to the --ca parameter, to specify that
certificates should not be checked against a CA. Note that 'none'
is already used in other similar options as a special placeholder.
* When '--ca none' is in use, --verify-hash checks all depths instead
of just level 1.
With these very simple changes, fingerprint authentication is easily achieved
via the --tls-verify script on the server and via --verify-hash on the client.
Adding support for fingerprint authentication sounds like a good idea to
me. Even if it was just to simplify config for peer-to-peer and small
(home) setups by getting rid of the need to create and maintain a CA.
So: feature Ack.
However, if we were to add this, I think I'd rather make it a
first-class citizen. For example by adding a peer fingerprint
verification option that works in both client and server configs, and is
mutually exclusive with --ca. I'd expect such an option to accept an
(inline-able) file that contains a list of fingerprints, so one can make
a config like:
<allowed-peers>
AA:BB:CC:DD:..
AA:BB:CC:DE:..
</allowed-peers>
Or maybe base64 fingerprints, because a lot of people have been trained
by SSH to recognize short base64 strings as fingerprints.
Anyone else from the community that has some thoughts on this?
As for implementation: I'm already having problems getting to my review
queue, so am not promising to implement this. I would definitely put a
patch for this on my review queue though :)
I have some strong thoughts on this, mostly related to: can someone
explain to me why this is safe?
I've seen that OpenSSH 7.7 now implements something similar (xmss
hash-based signatures,
https://tools.ietf.org/html/draft-irtf-cfrg-xmss-hash-based-signatures-12,
disabled by default) but that works entirely differently from what is
proposed here; amongst other things, it uses *one time private keys* to
maximize security - do we want to add something like that to our TLS
stuff (my gut answer: no).
How can a hash replace a public key, cryptographically speaking? if you
are not replacing public keys, then who generates, stores, maintains
these public keys? What about accounting in such a setup? with
certificates, you normally hand out a certificate to a person, with the
name of the person/entity in it. If that person misbehaves, you revoke
the certificate and presto. Is it sufficient to remove the hash from the
config? if so, wouldn't it be better to have a directory with
hash-files, so that you can add and remove hashes without having to
update the server config and/or restart the server to pick up new hashes?
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
