-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 23 April 2021 13:22, Antonio Quartulli <a...@unstable.cc> wrote: > Hi, > > On 23/04/2021 14:16, tincantech wrote: > > > Hi, > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, 23 April 2021 08:12, Antonio Quartulli a...@unstable.cc wrote: > > > > > Hi, > > > > > On 22/04/2021 23:02, tincantech via Openvpn-devel wrote: > > > > > > hi, > > > > I am requesting that $daemon_pid be added to the --tls-crypt-v2-verify > > > > environment. > > > > > The environment for --tls-crypt-v2-verify was designed to be extremely > > > minimal. > > > Anything concerning tls-crypt verification was designed to be as minimal > > > as possible. > > > > > Indeed, differently from other scripts, the env for tls-crypt-v2 is > > > created empty and then only a very few variables are added. > > > > > Anything that was deemed not necessary for the metadata verification was > > > not passed. > > > > I understand your reasoning, however, in the case of daemon_pid would you > > not > > consider the process to be "more secure" if openvpn does provide the PID in > > the environment, rather than have the script read the PID from a file? > > Having to configure openvpn to write the PID and then read the PID is two > > steps > > which can introduce user bound misconfiguration errors. > > we can't control what the user does with the script - he could do > anything wrong and ugly, but we can't just implement shortcuts for them, no? No. This is not a shortcut, this is OpenVPN providing a guaranteed working environment. I am not expecting openvpn to "control" what the user does with the script, I am asking that ALL scripts have access to daemon_pid as an obvious and beneficial security precaution. All scripts ought to have access to daemon_pid for the simple reason of ensuring the scripts run for the same server instance. Providing daemon_pid to all scripts is the *most secure* way to do this. There are other reasons to use --writepid, such as for completely external processes. > > > > I can imagine you have a usecase for daemon_pid, but I am sure more > > > people will have other arguments for other variables as well. Hence the > > > idea to design something extremely minimal and leave more complex logics > > > to following (post-auth) steps. > > > > I reviewed all the other variables for inclusion viability and, with the > > exception of "untrusted_ip / untrusted_ip6", I came to the conclusion that > > the only variable which does come with a genuine security bonus is > > daemon_pid. > > (As outlined in my previous comment) > > As for untrusted_ip*, it definitely could be useful to --tls-crypt-v2-verify > > but I'm not asking for that here. Perhaps on reading this other members will > > see how it can be of benefit to the scripts versatility.. > > (The same goes for untrusted_port but that seems less useful over all) I notice how you conveniently skipped this entire section .. > > I would also quote that old, old expression "Security through Obscurity" > > https://en.wikipedia.org/wiki/Security_through_obscurity > > It's not security through obscurity here, but it's about keeping the > code that leads to the tls-crypt-v2-verify call as minimal as possible. .. and went straight to this comment. In my opinion this is security through obscurity. With holding daemon_pid from any script executed by openvpn is a bad decision and in the case of --tls-crypt-v2-verify, with holding ALL other data from the script is clearly S.T.O. I can understand the reason to make the env minimal but this is clearly a case of going too far. Thus .. as above. > > This said, what is deamon-pid useful for in the tls-crypt-v2-verify > script? Maybe a clear usecase with pro and cons could help understanding > where this need is coming from. You are forcing my hand: https://github.com/TinCanTech/easy-tls I can see absolutely no security benefit to with holding daemon_pid from --tls-crypt-v2-verify, for the simple reason of the extra hoops a user is forced to jump through and the security risks they are forced to take in doing so.. As a final comment here, on the one hand openvpn chooses to enforce cipher-negotiation "because it is more secure and helps unwary users to configure their vpn correctly". On the other hand openvpn cannot see the simple LOGIC of providing daemon_pid to ALL scripts launched by openvpn. Thanks R -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBzBAEBCAAGBQJggtEaACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ06IQgAwYd6fAuuT2Z2g1kyeVHF9uPzy73k+bRf2G3EIjSLhG1yb11X 32SPQGaAAXwDTSRN/Onl6pe+h/XWdiBbTo3GTCKJ3f60isMxpezmOsUMSUGo WQQyKteQw/eWllXk1kxSEmdVW+xG3VxvCFX+HvJmTZgfLXfIk8s7WSYiEZKf rG0ZgSX8uVUaSO1K+935yFVDzabZHO97mpy74tMtVFhTZKAz+EqaDkGmwsVD p+M6ZSLxD0+ZD0OlnzHp3hhUvL1NgRcjHrtPyuhAy1Zu+woh1Dbu5YOja3sW H+y5T0BO1UgqaGLylbc6nbujnokzEOXicNXSutVN2EQ6MqiRS5DkTQ== =hZwd -----END PGP SIGNATURE-----
publickey - tincantech@protonmail.com - 0x09BC3D44.asc
Description: application/pgp-keys
publickey - tincantech@protonmail.com - 0x09BC3D44.asc.sig
Description: PGP signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
