>
> 2. instead of storing a certificate on each side, wouldn't it be nice to
> be able to store the public key only of the certificate, or perhaps even
> a hash of the public key of the certificate?
> To me, storing either the certificate itself is not a problem (I recall
> Jason Donenfeld wanting to get rid of X509 certs altogether - something
> I strongly disagree with), but storing its public key should also be
> good - this mimicka SSH pub/priv key, so we could even re-use parts of
> the SSH code for this. One could even imagine getting the public key for
> a particular user out of his/her ~/.ssh/authorized_keys file.
> Then, to make things even shorter, it was proposed to add *hashes* of
> public keys of certificates. To me, the added value of using a 256 bit
> hash instead of a 1024/2048 bit pubkey is limited, and I would like some
> assurance that this indeed foolproof. Other than that, I wouldn't NACK
> this feature, as long as it remains optional.
There seem to be some confusion about what is secure here and what not.
I will give a bite more detailed example here to explain the pubkey vs
hash check.
Simplified a X509 looks like this:
X509Cert {
CN=foo.example.net
PUBKEY=00:aa:bb:cc
usage="TLSServer"
other attributes
}
Signature {
SigningCAHash=00:bb:cc
SHA1Signature=binarysting
}
On a normal CA Check, the client will do a hash over the whole of the
X509Cert (including CN and all other attributes). Then it will fetch the
CA that signed the certificate, gets its public key and checks if the
signature that is appended to the certifcate is valid and signs the hash
it calculated before.
The reason that we hash the whole certificate and sign the hash and also
check the hash against the signature instead of the pubkey is that we
want to have the other attributes to be validated as well. If we only
signed the pubkey, a malicious party could just edit the CN of the
certificate and the certificate would still be valid.
What is proposed here is that instead of taking the signature of the
certificate and checking if the signature sign that hash, we just look
if we can find the hash in our list of trusted hash.
I have not check the proposol in detail but if we implment something
like this (especially with server side support), I would strongly
suggest verify the hash/fingerprint of the certificate instead of using
only the pubkey. Then there are no surprises for people that are not
intimate with X509/SSL that client can fake the CN.
>
> 3. how a person gets the public key or hash of the client or server side
> certificate to the "other side" is pretty much out of scope: it simply
> requires "a secure channel". I am fine with that.
>
> Note that browser certificate pinning is something else entirely: that
> is an *extra* check , on top of the cert chain check, to ensure that a
> server certificate (for, e.g. google.com) was signed by one of the
> "pinned" CA certificates. Browsers tend to trust a large number of CA
> certs, so this extra check makes sense there. As long as OpenVPN is not
> configured to trust 100+ CA's then this check does not make a lot fo
> sense in OpenVPN.
For self signed certificates checking the hash against the well known
exception list (add this certificate as exception) also becomes the only
check.
Arne
------------------------------------------------------------------------------
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
