Message ID | 20200908154157.13809-1-arne@rfc2549.org |
---|---|
Headers | show |
Series | Allow setting up OpenVPN in TLS mode without CA | expand |
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