[Openvpn-devel,0/4] Allow setting up OpenVPN in TLS mode without CA

  Setting up a CA even with the help of easy-tls and similar tools is
difficult/tiresome. For small setups self-signed certificates are
sufficient enough and restarting the server to add another client is
generally not a big problem (when you need that capability a CA is
better suited).

This patch set allows setting up OpenVPN with verification of peer
certificates and without a CA certificate. Instead of verifying
certificates through a CA, it allows to verify a certificate just by it
fingerprint. This is usually called certificate pinning. (If you wonder if
this secure, it is as secure as normal CA operation as certificate signature
also only sign the finerprinter of a certificate and not the whole cert.)

The commit themselves have examples.

The main difference of this patch set to Jason's V1 version is that it does
not rely on an external script on the server side and instead relys on an a
inlined <peer-fingerprint> section. The downside is that this requires a
server restart on adding a client but the upside is that no script-security
or external scripts are necessary and server/client setup become symmetric.

Arne Schwabe (3):
  Extend verify-hash to allow multiple hashes
  Implement peer-fingerprint to check fingerprint of peer certificate
  Document the simple self-signed certificate setup in examples

Jason A. Donenfeld (1):
  Support fingerprint authentication without CA certificate

 Changes.rst                       |  12 +++
 doc/man-sections/examples.rst     |  46 ++++++----
 doc/man-sections/inline-files.rst |   4 +-
 doc/man-sections/tls-options.rst  |  36 +++++++-
 src/openvpn/init.c                |   3 +
 src/openvpn/options.c             | 145 +++++++++++++++++++++++++-----
 src/openvpn/options.h             |  13 ++-
 src/openvpn/ssl.c                 |   2 +-
 src/openvpn/ssl_common.h          |   4 +-
 src/openvpn/ssl_verify.c          |  30 +++++--
 src/openvpn/ssl_verify_mbedtls.c  |  17 ++++
 src/openvpn/ssl_verify_openssl.c  |   2 +-
 12 files changed, 263 insertions(+), 51 deletions(-)
  

On 9/8/20 5:41 PM, Arne Schwabe wrote:
> The main difference of this patch set to Jason's V1 version is that it does
> not rely on an external script on the server side and instead relys on an a
> inlined <peer-fingerprint> section. The downside is that this requires a
> server restart on adding a client but the upside is that no script-security
> or external scripts are necessary and server/client setup become symmetric.

One of the nice features of Jason's patch was that also for big(ger) 
deployments you could get rid of the CA if you have another channel to 
establish trust between client and server.

I guess it won't be possible to use --tls-verify (on the server) with 
your patch and verify the fingerprint(s) there? For the client it is 
enough to have a (fixed) list of trusted fingerprints. Would it be 
possible to add this (again)?

Regards,
François
  

> One of the nice features of Jason's patch was that also for big(ger)
> deployments you could get rid of the CA if you have another channel to
> establish trust between client and server.

I really wonder which large deployment want to do that instead of a CA.
I really understand the need for small and simple deployments. But for
larger deployments a CA + CRL seems more useful for everything that I
can come up with.

> I guess it won't be possible to use --tls-verify (on the server) with your patch and verify the fingerprint(s) there? 
No. Currently not.

Arne
  

On 9/8/20 6:38 PM, Arne Schwabe wrote:
> I really wonder which large deployment want to do that instead of a CA.
> I really understand the need for small and simple deployments. But for
> larger deployments a CA + CRL seems more useful for everything that I
> can come up with.

It would be more for the situation where you already have a "parallel 
trust", e.g. through an OAuth API where a CA would be redundant. Just 
having an API to register fingerprints (which would act as a CRL at the 
same time by simply removing fingerprints) is easier than having a 
complete CA with CRL.

Of course, all of this can also be done by using a CA, and something can 
be said that if you operate on that scale you can also handle the extra 
"cost" of a CA...

Thanks,
François
  

Am 09.09.20 um 10:04 schrieb François Kooman:
> On 9/8/20 6:38 PM, Arne Schwabe wrote:
>> I really wonder which large deployment want to do that instead of a CA.
>> I really understand the need for small and simple deployments. But for
>> larger deployments a CA + CRL seems more useful for everything that I
>> can come up with.
> 
> It would be more for the situation where you already have a "parallel
> trust", e.g. through an OAuth API where a CA would be redundant. Just
> having an API to register fingerprints (which would act as a CRL at the
> same time by simply removing fingerprints) is easier than having a
> complete CA with CRL.
> 
> Of course, all of this can also be done by using a CA, and something can
> be said that if you operate on that scale you can also handle the extra
> "cost" of a CA...

I am happy to review a patch that adds a allow_no_ca or similar flag to
the tls-verify option that allows this but I don't have a real
motivation to implement it myself.

Just allowing ca not set with tls-verify script being set is a bit too
dangerous for my taste.

Arne
  

On 09/09/2020 11:21, Arne Schwabe wrote:
> Am 09.09.20 um 10:04 schrieb François Kooman:
>> On 9/8/20 6:38 PM, Arne Schwabe wrote:
>>> I really wonder which large deployment want to do that instead of a CA.
>>> I really understand the need for small and simple deployments. But for
>>> larger deployments a CA + CRL seems more useful for everything that I
>>> can come up with.
>>
>> It would be more for the situation where you already have a "parallel
>> trust", e.g. through an OAuth API where a CA would be redundant. Just
>> having an API to register fingerprints (which would act as a CRL at the
>> same time by simply removing fingerprints) is easier than having a
>> complete CA with CRL.
>>
>> Of course, all of this can also be done by using a CA, and something can
>> be said that if you operate on that scale you can also handle the extra
>> "cost" of a CA...
> 
> I am happy to review a patch that adds a allow_no_ca or similar flag to
> the tls-verify option that allows this but I don't have a real
> motivation to implement it myself.
> 
> Just allowing ca not set with tls-verify script being set is a bit too
> dangerous for my taste.
> 

I too would like to see an external list of fingerprints be made available.
https://community.openvpn.net/openvpn/ticket/1323#ticket
  

Am 09.09.20 um 20:23 schrieb tincanteksup:
> 
> 
> On 09/09/2020 11:21, Arne Schwabe wrote:
>> Am 09.09.20 um 10:04 schrieb François Kooman:
>>> On 9/8/20 6:38 PM, Arne Schwabe wrote:
>>>> I really wonder which large deployment want to do that instead of a CA.
>>>> I really understand the need for small and simple deployments. But for
>>>> larger deployments a CA + CRL seems more useful for everything that I
>>>> can come up with.
>>>
>>> It would be more for the situation where you already have a "parallel
>>> trust", e.g. through an OAuth API where a CA would be redundant. Just
>>> having an API to register fingerprints (which would act as a CRL at the
>>> same time by simply removing fingerprints) is easier than having a
>>> complete CA with CRL.
>>>
>>> Of course, all of this can also be done by using a CA, and something can
>>> be said that if you operate on that scale you can also handle the extra
>>> "cost" of a CA...
>>
>> I am happy to review a patch that adds a allow_no_ca or similar flag to
>> the tls-verify option that allows this but I don't have a real
>> motivation to implement it myself.
>>
>> Just allowing ca not set with tls-verify script being set is a bit too
>> dangerous for my taste.
>>
> 
> I too would like to see an external list of fingerprints be made available.
> https://community.openvpn.net/openvpn/ticket/1323#ticket

Yes it would be nicer but this is for small setups and reconnects and
quick and cheap. I don't want this feature to evolve into a second PKI
infrastructure just worse.

Arne