[Openvpn-devel] Erratic TCP Throughput
Hi, I have noticed erratic (or at least not real reliable) throughput when using OpenVPN in proto tcp mode (as I have to - UDP is not available to me, having to go through a TCP Proxy server). On my home network I just ran some tests, using iperf to characterize connection bandwidth between the same two PC's ... with and without OpenVPN. Here are the results ... 1) Without OpenVPN - consistent performance, ~ 70 Mbps total throughput (on a 100 Mb LAN). bin/iperf.exe -c server.home -P 8 -i 1 -p 5001 -f m -t 10 Client connecting to server.home, TCP port 5001 TCP window size: 0.01 MByte (default) [1908] local 192.168.2.109 port 1478 connected with 192.168.1.2 port 5001 [1888] local 192.168.2.109 port 1479 connected with 192.168.1.2 port 5001 [1872] local 192.168.2.109 port 1480 connected with 192.168.1.2 port 5001 [1792] local 192.168.2.109 port 1488 connected with 192.168.1.2 port 5001 [1840] local 192.168.2.109 port 1485 connected with 192.168.1.2 port 5001 [1808] local 192.168.2.109 port 1487 connected with 192.168.1.2 port 5001 [1856] local 192.168.2.109 port 1482 connected with 192.168.1.2 port 5001 [1824] local 192.168.2.109 port 1486 connected with 192.168.1.2 port 5001 [ ID] Interval Transfer Bandwidth [1808] 0.0- 1.0 sec 0.91 MBytes 7.60 Mbits/sec [1872] 0.0- 1.0 sec 0.91 MBytes 7.67 Mbits/sec [1888] 0.0- 1.0 sec 0.94 MBytes 7.86 Mbits/sec [1824] 0.0- 1.0 sec 0.91 MBytes 7.67 Mbits/sec [1792] 0.0- 1.0 sec 0.98 MBytes 8.26 Mbits/sec [1840] 0.0- 1.0 sec 0.92 MBytes 7.73 Mbits/sec [1856] 0.0- 1.0 sec 0.91 MBytes 7.67 Mbits/sec [1908] 0.0- 1.0 sec 0.94 MBytes 7.86 Mbits/sec [SUM] 0.0- 1.0 sec 7.43 MBytes 62.3 Mbits/sec [1888] 1.0- 2.0 sec 1.01 MBytes 8.45 Mbits/sec [1872] 1.0- 2.0 sec 1.00 MBytes 8.39 Mbits/sec [1856] 1.0- 2.0 sec 0.99 MBytes 8.32 Mbits/sec [1808] 1.0- 2.0 sec 1.01 MBytes 8.45 Mbits/sec [1908] 1.0- 2.0 sec 0.98 MBytes 8.26 Mbits/sec [1792] 1.0- 2.0 sec 1.01 MBytes 8.45 Mbits/sec [1824] 1.0- 2.0 sec 1.00 MBytes 8.39 Mbits/sec [1840] 1.0- 2.0 sec 0.98 MBytes 8.19 Mbits/sec [SUM] 1.0- 2.0 sec 7.98 MBytes 66.9 Mbits/sec [1792] 2.0- 3.0 sec 0.95 MBytes 7.93 Mbits/sec [1856] 2.0- 3.0 sec 0.97 MBytes 8.13 Mbits/sec [ ID] Interval Transfer Bandwidth [1888] 2.0- 3.0 sec 0.96 MBytes 8.06 Mbits/sec [1872] 2.0- 3.0 sec 0.96 MBytes 8.06 Mbits/sec [1908] 2.0- 3.0 sec 0.94 MBytes 7.86 Mbits/sec [1840] 2.0- 3.0 sec 0.95 MBytes 7.93 Mbits/sec [1808] 2.0- 3.0 sec 0.96 MBytes 8.06 Mbits/sec [1824] 2.0- 3.0 sec 0.95 MBytes 8.00 Mbits/sec [SUM] 2.0- 3.0 sec 7.63 MBytes 64.0 Mbits/sec [1908] 3.0- 4.0 sec 0.97 MBytes 8.13 Mbits/sec [1792] 3.0- 4.0 sec 0.95 MBytes 8.00 Mbits/sec [1824] 3.0- 4.0 sec 0.95 MBytes 7.93 Mbits/sec [1856] 3.0- 4.0 sec 0.95 MBytes 8.00 Mbits/sec [1808] 3.0- 4.0 sec 0.94 MBytes 7.86 Mbits/sec [1840] 3.0- 4.0 sec 0.96 MBytes 8.06 Mbits/sec [1888] 3.0- 4.0 sec 0.94 MBytes 7.86 Mbits/sec [1872] 3.0- 4.0 sec 0.95 MBytes 7.93 Mbits/sec [SUM] 3.0- 4.0 sec 7.60 MBytes 63.8 Mbits/sec [1792] 4.0- 5.0 sec 1.03 MBytes 8.65 Mbits/sec [1808] 4.0- 5.0 sec 1.02 MBytes 8.52 Mbits/sec [1908] 4.0- 5.0 sec 1.05 MBytes 8.78 Mbits/sec [1824] 4.0- 5.0 sec 1.02 MBytes 8.52 Mbits/sec [ ID] Interval Transfer Bandwidth [1856] 4.0- 5.0 sec 1.02 MBytes 8.52 Mbits/sec [1872] 4.0- 5.0 sec 0.99 MBytes 8.32 Mbits/sec [1840] 4.0- 5.0 sec 1.02 MBytes 8.52 Mbits/sec [1888] 4.0- 5.0 sec 1.02 MBytes 8.59 Mbits/sec [SUM] 4.0- 5.0 sec 8.16 MBytes 68.4 Mbits/sec [1824] 5.0- 6.0 sec 1.05 MBytes 8.78 Mbits/sec [1792] 5.0- 6.0 sec 1.05 MBytes 8.78 Mbits/sec [1908] 5.0- 6.0 sec 1.05 MBytes 8.78 Mbits/sec [1840] 5.0- 6.0 sec 1.05 MBytes 8.78 Mbits/sec [1872] 5.0- 6.0 sec 1.06 MBytes 8.91 Mbits/sec [1888] 5.0- 6.0 sec 1.05 MBytes 8.78 Mbits/sec [1808] 5.0- 6.0 sec 1.07 MBytes 8.98 Mbits/sec [1856] 5.0- 6.0 sec 1.05 MBytes 8.85 Mbits/sec [SUM] 5.0- 6.0 sec 8.42 MBytes 70.6 Mbits/sec [1840] 6.0- 7.0 sec 0.97 MBytes 8.13 Mbits/sec [1872] 6.0- 7.0 sec 0.99 MBytes 8.32 Mbits/sec [1888] 6.0- 7.0 sec 1.02 MBytes 8.52 Mbits/sec [1856] 6.0- 7.0 sec 1.00 MBytes 8.39 Mbits/sec [1824] 6.0- 7.0 sec 1.01 MBytes 8.45 Mbits/sec [1908] 6.0- 7.0 sec 0.99 MBytes 8.32 Mbits/sec [ ID] Interval Transfer Bandwidth [1792] 6.0- 7.0 sec 1.00 MBytes 8.39 Mbits/sec [1808] 6.0- 7.0 sec 0.99 MBytes 8.32 Mbits/sec [SUM] 6.0- 7.0 sec 7.97 MBytes 66.8 Mbits/sec [1792] 7.0- 8.0 sec 1.04 MBytes 8.72 Mbits/sec [1908] 7.0- 8.0 sec 1.02 MBytes 8.59 Mbits/sec [1856] 7.0- 8.0 sec 1.04 MBytes 8.72 Mbits/sec [1808] 7.0- 8.0 sec 1.02 MBytes 8.59 Mbits/sec [1872] 7.0- 8.0 sec 1.02 MBytes 8.59 Mbits/sec [1888] 7.0- 8.0 sec 1.04 MBytes 8.72 Mbits/sec [1840] 7.0- 8.0 sec 1.02 MBytes 8.59 Mbits/sec [1824] 7.0- 8.0 sec 1.07 MBytes 8.98 Mbits/sec [SUM] 7.0- 8.0 sec 8.28 MBytes 69.5 Mbits/sec [1792] 8.0- 9.0 sec 1.05 MBytes 8.78 Mbits/sec [1856] 8.0- 9.
Re: [Openvpn-devel] Erratic TCP Throughput
Hi, This is more my bet, because my question wasn't very clear ... I require a proxy server during "normal" operation, but for this data throughput test I had no proxy server, rather a "direct" connection. Thoughts? Thanks! On Wed, Mar 3, 2010 09:31 AM, "Karl O. Pinc" wrote: > On 03/03/2010 02:40:16 AM, Jason Haar wrote: > > On 03/03/2010 04:52 PM, open...@rkmorris.us wrote: > > > > > > 1) Without OpenVPN - consistent performance, ~ 70 Mbps total > > > throughput (on a 100 Mb LAN). > > > > 2) With OpenVPN - very consistent performance, sometimes fine, > > other > > > times very poor. ~ 70 Mbps total throughput (on a 100 Mb LAN), but > > > bounces around a lot. > > > So what you're saying is that on a ~70Mbs network you sometimes see > > ~70Mbs via "openvpn-via-proxy-server" and sometimes you don't? As the > > performance of openvpn varies - and I assume you know the client and > > server aren't the bottleneck - then that leaves? > > > > The proxy! :-) > > Or problems with tunneling tcp inside tcp which you can trace > back via this thread: > > http://article.gmane.org/gmane.network.openvpn.user/29183 > > > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
Hi, I just tried this, and at least for my data throughput test it didn't seem to help ... buy maybe I have this wrong. I did this in the client configuration file ... is this right? I checked the OpenVPN web site, and it may be that I need this on the server side instead. Please clarify and I'll try it again (if I need to). Thanks! On Thu, Mar 4, 2010 03:35 PM, Gert Doering wrote: > Hi, > > On Thu, Mar 04, 2010 at 09:28:48PM +0100, booyakasha wrote: > > magic number 2952 (ping ?l 2952). It wasn?t only the 1472 ping > > packet which worked OK. All packets over 2952 are OK !!! I am > > waiting for your opinions why packets from 1 byte to 2952 bytes > > (without 1472 byes package) are going extremely slowly and others not. > > TCP_NODELAY > > David has already suggested that you should try setting > > "socket-flags TCP_NODELAY" > > - did you? > > gert > -- > USENET is *not* the non-clickable part of WWW! > //http://www.muc.de/~gert/ > Gert Doering - Munich, Germany g...@greenie.muc.de > fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
Hi, OK, I tried this (on both ends!), but no joy unfortunately ... :-( It almost seemed like overall data throughput was lower, but the throughput results bounce around so much that it's hard to really conclude this or not. I'm not sure if attachments make it through to this mailing list or not, but let me try to attach a couple pictures showing this with and without OpenVPN (to try to make this easier to see). Thoughts? Thanks! On Fri, Mar 5, 2010 02:01 AM, Gert Doering wrote: > Hi, > > On Thu, Mar 04, 2010 at 05:21:43PM -0600, open...@rkmorris.us wrote: > > I did this in the client configuration file ... is this right? > > I checked the OpenVPN web site, and it may be that I need this on > > the server side instead. Please clarify and I'll try it again (if > > I need to). > > "socket-flags TCP_NODELAY" > > that would need to go into both(!) config files - it changes the way the > operating system handles write() calls into a socket, that is, whether > the OS waits for "more data" to eventually generate a full sized packet, > or whether it will send the data immediately (generating a small packet). > > (This is a fundamental problem with TCP - the stacks are optimized for > certain patterns, either "bulk data, make full size packets" or > "interactive traffic, send single bytes of keystrokes, where a few ms > delay don't hurt", but not for VPN-like traffic) > > gert > > -- > USENET is *not* the non-clickable part of WWW! > //http://www.muc.de/~gert/ > Gert Doering - Munich, Germany g...@greenie.muc.de > fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de > Direct-NoOpenVPN.png Description: Binary data WithOpenVPN.png Description: Binary data
Re: [Openvpn-devel] Openvpn 2.1.1 bad tcp performance but good pingwhen -l 1472 (with packet size = MTU)
Hi, That's a very good suggestion! I just tried this with OpenVPN-ALS (adito), and while the average performance is slightly lower (java vs. compiled code?), the throughput inconsistency is not there, rather it's only the case with OpenVPN! Attached another throughput plot for you. On Fri, Mar 5, 2010 03:17 PM, Stefan Monnier wrote: > > because i really believe in open source software I've decided to check > > all sorts of configurations to check problems with tcp tunneling. > > This makes it sound like OpenVPN's performance is lower than some > comparable non-Free software. > Have you actually compared OpenVPN's performance to some other > TCP-tunnel solution? That would be instructive since it may point to > ways to improve the TCP support. > > I know in general OpenVPN discourages the use of TCP tunnels and for > good reasons, but the support for TCP tunnels is also one of the > strengths of OpenVPN, making it usable even with the most > uncooperative firewalls. > > > Stefan > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > OpenVPN-ALS.png Description: Binary data
Re: [Openvpn-devel] Erratic TCP Throughput
Hi, No, compression was on - so I also ran it again with it turned off (on both ends). Here are the results ... It seems that compression boosts performance from ~ 30 Mb/s to ~ 50 Mb/s overall, but still very erratic results ... :-(. Thoughts? Thanks! On Fri, Mar 5, 2010 05:20 PM, Jan Just Keijser wrote: > open...@rkmorris.us wrote: > > > > Hi, > > > > > > > > This is more my bet, because my question wasn't very clear ... I > > require a proxy server during "normal" operation, but for this data > > throughput test I had no proxy server, rather a "direct" connection. > > > > > > > without config files it's impossible to tell - is compression disabled > during testing? otherwise iperf numbers don't make a lot of sense... > > cheers, > > JJK > > Compression.png Description: Binary data NoCompression.png Description: Binary data
[Openvpn-devel] Bytecount Reporting
Hi, I am trying to write an application that monitors traffic over an OpenVPN link - by using bytecount information from the management interface. However, after I telnet in, and enter "bytecount 1" (for 1 second updates), I find that the real-time bytecount updates are not really every second. They seem to be initially, but soon slow down (to an update every 5-10 seconds). Is this expected, or a known issue? Thanks!
Re: [Openvpn-devel] Bytecount Reporting
Hi, I'm running OpenVPN (client) on Windows - connecting to a Linux Server. I am wondering if a value isn't reported if there is no traffic - that could be part of this (though it would be better to report information anyways). Make sense? Thanks! ... Russell On Wed, Mar 17, 2010 04:01 PM, David Sommerseth wrote: > On 17/03/10 20:46, open...@rkmorris.us wrote: > > Hi, > > > > I am trying to write an application that monitors traffic over an OpenVPN > > link - by using bytecount information from the management interface. > > However, after I telnet in, and enter "bytecount 1" (for 1 second updates), > > I find that the real-time bytecount updates are not really every second. > > They seem to be initially, but soon slow down (to an update every 5-10 > > seconds). > > > > Is this expected, or a known issue? > > Hi, > > I'd say this is probably unexpected. But I'd like to know a little bit > more about your setup. What kind of OS are you running OpenVPN? > > It sounds like your OpenVPN process get lower priority somehow. But it > could also be that it is dependent on the amount of traffic passing over > the tunnel. I'll dig more into the code to see if there are some > oddities there before concluding. > > > kind regards, > > David Sommerseth >
Re: [Openvpn-devel] Bytecount Reporting
Hi, All very good questions! Some thoughts, below. Thanks for all your help! ... Russell On Wed, Mar 17, 2010 05:01 PM, David Sommerseth wrote: > On 17/03/10 22:40, open...@rkmorris.us wrote: > > Hi, > > > > > > > > I'm running OpenVPN (client) on Windows - connecting to a Linux Server. > > I'm presuming you're connecting to the management interface on the Linux > server. >> Russell: No, on the local client (i.e. on Windows). This avoids having to >> send information over the link (=wasted bandwidth, and lower speed). > > > > I am wondering if a value isn't reported if there is no traffic - that > > could be part of this > > I have a feeling this is the reality. As I don't see any timer alarms > scheduled in the management part of the code. So I need to see this > more in connection with the main part of the event loop code. But I > believe this is the case. >> Russell: Understood - if it is please just let me know. > > > (though it would be better to report information anyways). > > > > Make sense? > > Yeah, I can see your point. But isn't the information going to be > rather useless if it hasn't changed? If there is no change, no need to > dump the same info once again. What do you think? >> Russell: I understand your point, but I'm also wanting to show transfer >> rate, and plot the data (which would be easiest if the data arrives >> uniformly). Not a huge issue, but I would to at least like to understand why >> this is the case. I guess if this is the way it works it should at least be >> captured in the documentation for the Management Interface, right? > > > kind regards, > > David Sommerseth > > > > > On Wed, Mar 17, 2010 04:01 PM, David Sommerseth > > wrote: > > > > > >> > > On 17/03/10 20:46, open...@rkmorris.us wrote: > >>> Hi, > >>> > >>> I am trying to write an application that monitors traffic over an OpenVPN > >>> link - by using bytecount information from the management interface. > >>> However, after I telnet in, and enter "bytecount 1" (for 1 second > >>> updates), I find that the real-time bytecount updates are not really > >>> every second. They seem to be initially, but soon slow down (to an update > >>> every 5-10 seconds). > >>> > >>> Is this expected, or a known issue? > >> > >> Hi, > >> > >> I'd say this is probably unexpected. But I'd like to know a little bit > >> more about your setup. What kind of OS are you running OpenVPN? > >> > >> It sounds like your OpenVPN process get lower priority somehow. But it > >> could also be that it is dependent on the amount of traffic passing over > >> the tunnel. I'll dig more into the code to see if there are some > >> oddities there before concluding. > >> > >> > >> kind regards, > >> > >> David Sommerseth > >> > >
Re: [Openvpn-devel] Bytecount Reporting
Hi Davide, Yes, that makes sense - and I was going to do that originally, but I figured the real-time bytecount would result in less traffic (and text parsing). One question though ... you say "status file". Do you really mean a file? I can execute the status command over the Management Interface, but it's really a telnet type response, not in a file. Thanks, ... Russell On Wed, Mar 17, 2010 05:38 PM, Davide Brini wrote: > On Wednesday 17 March 2010, open...@rkmorris.us wrote: > > > I am trying to write an application that monitors traffic over an OpenVPN > > link - by using bytecount information from the management interface. > > However, after I telnet in, and enter "bytecount 1" (for 1 second > > updates), I find that the real-time bytecount updates are not really every > > second. They seem to be initially, but soon slow down (to an update every > > 5-10 seconds). > > Sorry for avoiding a direct answer to the question (David has already > addressed that quite well), but I just wanted to tell you that you can get > byte counts from OpenVPN's status file, ie the one you specify with "-- > status". I used that in the past to monitor clients and traffic (it was > actually a Munin plugin that read the file and collected the data). > That said, it might not suit your requirements, but I thought I mentioned > that > just in case. > > -- > D. > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
[Openvpn-devel] Auto-Proxy
Hi, I have been using two different config files to connect to my OpenVPN server - as I am sometimes behind a proxy server, and sometimes not. So to fix this I tried using auto-proxy ... but it didn't work (in the proxy case) ... :-(. I am running the client on Windows - so it should work, no? FYI - the proxy server runs an automatic configuration script (.pac) ... could this be part of the problem? Thanks!
Re: [Openvpn-devel] [Openvpn-users] Auto-Proxy
Hi, I can post it, but not sure it helps much - as it doesn't mention, or even seem to try to detect, the proxy ... :-(. If I include the proxy information in the configuration file then it works great, but if I don't do this and rather add "--auto-proxy" to the command line it just continuously tries to connect directly. Does this make sense? Thanks! On Fri, Apr 2, 2010 11:00 AM, Kosztyu András wrote: > Please post your log to see if there is any useful information From: open...@rkmorris.us [mailto:open...@rkmorris.us] > Sent: Friday, April 02, 2010 5:31 PM > To: openvpn-us...@lists.sourceforge.net; openvpn-devel@lists.sourceforge.net > Subject: [Openvpn-users] Auto-Proxy Hi, I have been using two different config files to connect to my OpenVPN server - as I am sometimes behind a proxy server, and sometimes not. So to fix this I tried using auto-proxy ... but it didn't work (in the proxy case) ... :-(. I am running the client on Windows - so it should work, no? FYI - the proxy server runs an automatic configuration script (.pac) ... could this be part of the problem? Thanks! >
Re: [Openvpn-devel] Auto-Proxy
Hi, Is this perhaps a topic that can / should be covered at the meeting this week? Thanks, ... Russell On Tue, Apr 6, 2010 09:49 PM, Jason Haar wrote: > On 04/06/2010 09:39 PM, Jan Just Keijser wrote: > > open...@rkmorris.us wrote: > > > >> Hi, > >> > >> > >> > >> I have been using two different config files to connect to my OpenVPN > >> server - as I am sometimes behind a proxy server, and sometimes not. > >> So to fix this I tried using auto-proxy ... but it didn't work (in the > >> proxy case) ... :-(. > >> > >> > >> > >> I am running the client on Windows - so it should work, no? > >> > >> > >> > >> > > note to the developers: all error codes when using the > > InternetQueryOption API are lost ... also read > > http://support.microsoft.com/kb/226473 > > Openvpn 2.1 uses the "old" IE4 API . > > > > Another note to developers. Can they work on enabling auto-proxy to work > in configs that contain both UDP and TCP-based "" profiles? :-) > > In a similar vein, the following ticket is in the bug tracking system - > there seems to be a general problem with mixing TCP and UDP options (eg > mssfix, nobind, fragment) > > http://sourceforge.net/tracker/index.php?func=detail&aid=2945147&group_id=48978&atid=454720 > > -- > Cheers > > Jason Haar > Information Security Manager, Trimble Navigation Ltd. > Phone: +64 3 9635 377 Fax: +64 3 9635 417 > PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
[Openvpn-devel] Status Message Missing IP Address
* * * Hi, I have found what seems to be an interesting feature (bug) of the management interface – as I have been using it to write a connection monitor application. Up until recently I have been using the server-bridge command on the server, and setting up a bridge (allowing OpenVPN to assign the IP address). When I did this the management interface on the client reported the IP address that it was assigned (both in real-time or manual state commands). However, now I have changed the server configuration file to allow the local DHCP server (router) to assign the client IP address. While this works fine, and the client connection is functional, the management interface no longer reports the client IP address. Is this a known (or for some reason planned) mode of operation? Thanks, … Russell
Re: [Openvpn-devel] Status Message Missing IP Address
Hi, This makes sense to me on the server side, but I'm running the management interface on the client ... why would it not know (or at least report) it's IP address? Thanks, ... Russell -Original Message- From: David Sommerseth [openvpn.l...@topphemmelig.net] Sent: Saturday, April 24, 2010 5:08 AM To: open...@rkmorris.us Cc: openvpn-us...@lists.sourceforge.net; openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] Status Message Missing IP Address -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/04/10 06:54, open...@rkmorris.us wrote: > > Hi, > > I have found what seems to be an interesting feature (bug) of the > management interface – as I have been using it to write a connection > monitor application. > > Up until recently I have been using the server-bridge command on the > server, and setting up a bridge (allowing OpenVPN to assign the IP > address). When I did this the management interface on the client > reported the IP address that it was assigned (both in real-time or > manual state commands). However, now I have changed the server > configuration file to allow the local DHCP server (router) to assign the > client IP address. While this works fine, and the client connection is > functional, the management interface no longer reports the client IP > address. > > Is this a known (or for some reason planned) mode of operation? Without having looked at the code, I would say this sounds reasonable. As OpenVPN would not care about which IP address is being used when it does not provide the IP address itself. The only reason OpenVPN would do that is to avoid giving out the same IP address to several clients. The rest of OpenVPN's task is to pass the traffic coming from the UDP/TCP port on the Internet side, encrypt/decrypt the data and put it into the TAP interface (in your case). Having that said, it can be done some research on how the "learn address" state is implemented and how that state is used when OpenVPN is not assigning the VPN IP addresses. kind regards, David Sommerseth -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvSwx0ACgkQDC186MBRfrqT8QCfWhQGeVhp6Fm2CjF7jJ46Tdk8 wqcAn09kxxP+efeuZOoUTenph02+zwOW =BWfu -END PGP SIGNATURE-
Re: [Openvpn-devel] Status Message Missing IP Address
This makes sense - thanks!!! ... Russell On Sat, Apr 24, 2010 11:45 AM, "Karl O. Pinc" wrote: > On 04/24/2010 09:34:46 AM, open...@rkmorris.us wrote: > > > > > > Hi, > > > > This makes sense to me on the server side, but I'm running the > > management interface on the client ... why would it not know (or at > > least report) it's IP address? > > Because it's not OpenVPN's IP address it's the client OS's > IP address. OpenVPN is acting as a virtual wire. The > client is obtaining it's IP as it usually does, just from > a server on the other end of the wire. At least if I'm > understanding your configuration. > > > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > >
Re: [Openvpn-devel] Any volunteer Windows devs to change OpenVPN proxying code to use "new" InternetQueryOption API?
Hi Samuli, Very interesting timing! Just last night I was poking about about this a bit, and I'm not so sure that the proxy approach noted so far is the best / right way to do this. Rather, to be able to handle dynamic (not just static) proxy configurations the WinHTTP API looks to me to be the way to do this (see http://msdn.microsoft.com/en-us/library/aa384097(v=VS.85).aspx for an example). I hope this helps! ... Russell On Wed, Apr 28, 2010 09:01 AM, Samuli Seppänen wrote: > Hi all, > > A while back a user noticed that OpenVPN still uses old IE4 API to > detect proxy settings (e.g. in proxy.c and ieproxy.c). This apparently > causes problems with IE's proxy detection on some Windows installations. > A "new" InternetQueryOption API was introduced in IE5, so this part of > OpenVPN would benefit from an upgrade anyways. Would somebody be > interested in taking up this task? We seem to have a shortage of Windows > devs, so any help would be most welcome! > > For more information about this issue can be found from here: > > * http://thread.gmane.org/gmane.network.openvpn.devel/3446 > * http://support.microsoft.com/kb/226473 > > If I've misunderstood the problem, please send clarifications - proxy > usage in OpenVPN is still pretty vague to me :) > > -- > Samuli Seppänen > Community Manager > OpenVPN Technologies, Inc > > irc freenode net: mattock > > > ---------- > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
[Openvpn-devel] TCP Window Size - Impact on Data Throughput
Hi, I can't explain the information below, but hopefully someone a whole bunch smarter than me understands it - as it seems to help with TCP throughput in OpenVPN (the holy grail??? ... :-)). I have added some plots and details to an open OpenVPN ticket, located here ... https://community.openvpn.net/openvpn/ticket/2. And, here is the explanation to go with it, Here are some results, between two machines in my network. The results noted as "direct" are exactly that - a link between the two machines, without OpenVPN running. The "OpenVPN" results are then of course with OpenVPN running (between the same two machines, but traffic over OpenVPN). Note the significant impact that the TCP Window size has on OpenVPN performance ... any thoughts? As above, does anyone understand the huge (5-10x or more) impact TCP Window Size has on OpenVPN throughput? And perhaps more relevant - how do we use this to improve TCP throughput in OpenVPN? Thanks! ... Russell
Re: [Openvpn-devel] TCP Window Size - Impact on Data Throughput
Hi, My apologies, as I haven't gotten back on this yet. I have been trying to test, but my results are consistently inconsistent ... :-(. I have tried tuning the settings, as Windows doesn't seem to show any default setting - but it's not showing any consistent deltas in performance. Has anyone else tried this? Thanks, ... Russell On Mon, Sep 13, 2010 02:24 AM, Samuli Seppänen wrote: > > Hi, > > > > On Thu, Sep 09, 2010 at 06:32:14PM -0500, open...@rkmorris.us wrote: > > > >> I can't explain the information below, but hopefully someone a whole > >> bunch smarter than me understands it - as it seems to help with > >> TCP throughput in OpenVPN (the holy grail??? ... :-)). > >> > > > > Did you change TCP window size on the client, or on the OpenVPN process? > > > > If changing the TCP window size on the client helps, this is somewhat > > unsurprising - OpenVPN adds delay, and TCP with a too-small window size > > breaks down miserably if the delay goes up. > > > > What's the "default" TCP window size here? > > > > Given that you can even see an effect in the "direct" case, I suspect that > > your machines' TCP window sizes are *way* too small - and this has not much > > to do with TCP-over-TCP, but you would see the same effect for UDP-based > > OpenVPN as well. > > > > Simple example, to clarify the effect of round trip time (delay) on > > TCP throughput: > > > > TCP uses a sliding window, that is, the sender can send as many packets > > as the "window size" permits before the sender has to wait for an > > acknowledge > > from the receiver. Now, if the link has a noticeable delay AND lots of > > bandwidth, the bandwidth * time product adds up to the minimum window size > > you need to use: > > > > 1000 Mbit/s link > > 1 ms delay (1/1000s) > > > > 1000 Mbit/s * 1ms = 1 Mbit = 100 Kbyte "in flight" - that is, if the sender > > keeps sending packets back to back, with no pause in between, it needs to > > send out 100 kbyte before the first ACK packet comes back. > > > > If the sender only sends 10 kbyte because the TCP window size doesn't permit > > sending more, these 10 kbyte are sent in ~ 0.1 ms, and then it has to > > wait for 0.9 ms for the ACKs to come in - send again for 0.1 ms, wait 0.9 ms > > (roughly). So it's only using 10% of the available sending capacity, and > > the performance sucks. > > > > > > So, in your examples, my guess is that the TCP window size is "barely large > > enough" for the "direct" case (but the link is not fully saturated unless > > you increase the window size) - and since OpenVPN adds some noticeable > > delay, the bandwidth * delay product goes up, and so needs the window size > > to be able to fully saturate the link... > > > I wonder if the iPerf results only apply to iPerf tests... Linux > autotunes TCP parameters, including send and receive windows[1]. > However, increasing the maximum TCP buffer / memory size may be useful > sometimes [2]. Also, an application can choose to use a smaller buffer > than the OS default [2]: apparently iPerf does this. Windows also > autotunes it's TCP parameters[3], although manual editing is an option[4]. > > Russell: perhaps you could try tuning the OS-level TCP buffer size and > then test the results with a few different real-world applications (e.g. > netcat, scp)? > > [1] <http://www.psc.edu/networking/projects/tcptune/#Linux> > [2] <http://www.psc.edu/networking/projects/tcptune/#options> > [3] <http://fasterdata.es.net/TCP-tuning/> > [4] > <http://www.psc.edu/networking/projects/tcptune/OStune/winxp/winxp_stepbystep.html> > > -- > Samuli Seppänen > Community Manager > OpenVPN Technologies, Inc > > irc freenode net: mattock > > > -- > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing > http://p.sf.net/sfu/novell-sfdev2dev > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel >
[Openvpn-devel] openvpn, NTLM and McAfee Web Gateway
dear all,a few days ago I deployed an ovpn solution in a medium sized company. One of the two ends of the vpn network is passing through a proxy with NTLM authentication. ovpn has problems to recognize the authentication because immediately after sending the message type 1, the proxy sends no response, so I had to modify the source code by replacing the current message with a similar but different one.in particular this one:TlRMTVNTUAABAgIAAA==become:TlRMTVNTUAABB4IIogAFASgKDw==A detail of the work is available at:http://www.morzello.com/?p=350 (in Italian).I was wondering if you could have a function that supports this type of proxy (such as McAfee Web Gateway).thank you very much.
Re: [Openvpn-devel] openvpn, NTLM and McAfee Web Gateway
> Hi, > > I read your blog post, interesting stuff. The strings the client sends > seem to be base64 encoded and the first part on both messages look like > this (in nano/vi): > > NTLMSSP > > It's followed by this, which is apparently the message type hex string: > > ^@^A^@^@^@ > > After this they differ noticeably. I'd guess they are just sending > different NTLM flags: > > > > Can somebody more fluent in NTLM protocol decipher these two messages? > > -- > Samuli Sepp?nen > Community Manager > OpenVPN Technologies, Inc > > irc freenode net: mattock > Firefox uses the following flags: #define NTLM_TYPE1_FLAGS \ (NTLM_NegotiateUnicode |\ NTLM_NegotiateOEM |\ NTLM_RequestTarget | \ NTLM_NegotiateNTLMKey |\ NTLM_NegotiateAlwaysSign | \ NTLM_NegotiateNTLM2Key) take a look here for more informations: http://hg.mozilla.org/releases/mozilla-1.9.2/file/d1c0b2c4ac7a/security/manager/ssl/src/nsNTLMAuthModule.cppI hope that's may helps. vittorio
Re: [Openvpn-devel] openvpn, NTLM and McAfee Web Gateway
Da: "Jan Just Keijser" janj...@nikhef.nl A: "openvpn" open...@lucullo.it Cc: openvpn-devel@lists.sourceforge.net Data: Mon, 18 Oct 2010 12:58:35 +0200 Oggetto: Re: [Openvpn-devel] openvpn, NTLM and McAfee Web Gateway > openvpn wrote: > > dear all, > > > > a few days ago I deployed an ovpn solution in a medium sized company. > > One of the two ends of the vpn network is passing through a proxy with > > NTLM authentication. ovpn has problems to recognize the authentication > > because immediately after sending the message type 1, the proxy sends > > no response, so I had to modify the source code by replacing the > > current message with a similar but different one. > > > > in particular this one: > > > > TlRMTVNTUAABAgIAAA== > > > > > > become: > > > > TlRMTVNTUAABB4IIogAFASgKDw== > > > > > > A detail of the work is available at: > > > > http://www.morzello.com/?p=350 (in Italian). > > > > I was wondering if you could have a function that supports this type > > of proxy (such as McAfee Web Gateway). > > > I applied your "patch" and I still cannot get it to work for my > httpd+mod_ntlm (NTLMv1 only) installation. The NTLM handshake that > OpenVPN does is broken. Without the patch Wireshark tells me the first > NTLMSPP message is invalid > http://www.nikhef.nl/~janjust/openvpn/openvpn-ntlm-error1.png > If I change the phase_1 NTLM message to the above I get one step further > but then it breaks at the next packet: > http://www.nikhef.nl/~janjust/openvpn/openvpn-ntlm-error2.png > It seems the Windows domain and username are not stored properly inside > the request. The same httpd+mod_ntlm installation works flawlessly using > Internet Explorer 7: in that case the domain and user name are encoded > just fine. > > What am I doing wrong? > > cheers, > > JJK > Sorry Jan, mine was a dirty job in order to quick solve my problem. I think the correct way to solve the issue is to deeper study the NTLM and NTLMv2 standard. the error 1 is the same i've got before patching the code but i didn't spent much time to analyze the issue. I can try to solve the problem if someone can test the results (with community agreement). have a nice day, vittorio
[Openvpn-devel] [PATCH 2/2] Add table output formatting to t_client.sh
From: Jens Neuhalfen
Test results will be printed in a tabular format, e.g.
| ID | TEST| RESULT |
| -- | --- | |
| 1 | testing tun/udp/ipv4| [SUCCESS]|
| 2 | testing tun/udp/ipv4 with pam | [FAIL: 5 fails] |
| -- | --- | |
Test sets succeded: 1.
Test sets failed: 2.
Signed-off-by: Jens Neuhalfen
---
tests/t_client.sh.in | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tests/t_client.sh.in b/tests/t_client.sh.in
index 9f0c8f6..e026dee 100755
--- a/tests/t_client.sh.in
+++ b/tests/t_client.sh.in
@@ -361,18 +361,26 @@ print_test_results(){
# see here for an explanation on the calling convention:
#
http://stackoverflow.com/questions/1063347/passing-arrays-as-parameters-in-bash
local -a test_ids=("${!1}")
-local -a test_number_of_fails=("${!2}")
+local -a test_names=("${!2}")
+local -a test_number_of_fails=("${!3}")
local summary_ok=""
local summary_fail=""
-for (( i = 0 ; i < ${#test_ids[@]} ; i++ )) do
-if [ ${test_number_of_fails[$i]} == 0 ]; then
+local fmt="| %2s | %-35s | %-20s |\n"
+
+printf "$fmt" "ID" "TEST" "RESULT"
+printf "$fmt" "--" "---"
""
+for (( i = 0 ; i < ${#test_names[@]} ; i++ )) do
+if [ ${test_number_of_fails[$i]} = 0 ]; then
summary_ok="$summary_ok ${test_ids[$i]}"
+printf "$fmt" "${test_ids[$i]}" "${test_names[$i]}" "[OK]"
else
summary_fail="$summary_fail ${test_ids[$i]}"
+printf "$fmt" "${test_ids[$i]}" "${test_names[$i]}" "[FAIL:
${test_number_of_fails[$i]} fails]"
fi
done
+printf "$fmt" "--" "---"
""
if [ -z "$summary_ok" ] ; then summary_ok=" none"; fi
if [ -z "$summary_fail" ] ; then summary_fail=" none"; fi
@@ -389,6 +397,7 @@ run_test_loop() {
local -i any_test_failed=0
local -i number_of_fails_in_test=0
local -a test_ids
+local -a test_names
local -a test_number_of_fails
local -i current_test_index=0
@@ -405,6 +414,7 @@ run_test_loop() {
eval ping6_hosts=\"\$PING6_HOSTS_$SUF\"
test_ids[$current_test_index]="$SUF"
+test_names[$current_test_index]="$test_run_title"
run_test "$test_prep" "$test_cleanup" "$test_run_title"
"$openvpn_conf" "$expect_ifconfig4" "$expect_ifconfig6" "$ping4_hosts"
"$ping6_hosts"
number_of_fails_in_test=$?
@@ -416,7 +426,7 @@ run_test_loop() {
current_test_index=$((current_test_index + 1))
done
-print_test_results test_ids[@] test_results[@]
+print_test_results test_ids[@] test_names[@] test_results[@]
return $any_test_failed
}
--
2.8.2
[Openvpn-devel] [PATCH 1/2] Refactor t_client.sh
" >/dev/null
+then :
+else
+fail "check_ifconfig(): expected IPv$proto address '$expect' not
found in ifconfig output."
+fi
done
}
@@ -186,166 +203,226 @@ run_ping_tests()
if [ -z "$targetlist" ] ; then return ; fi
case $proto in
- 4) cmd=fping ;;
- 6) cmd=fping6 ;;
- *) echo "internal error in run_ping_tests arg 1: '$proto'" >&2
- exit 1 ;;
+4) cmd=fping ;;
+6) cmd=fping6 ;;
+*) echo "internal error in run_ping_tests arg 1: '$proto'" >&2
+ exit 1 ;;
esac
case $want in
- want_ok) sizes_list="64 1440 3000" ;;
- want_fail) sizes_list="64" ;;
+want_ok) sizes_list="64 1440 3000" ;;
+want_fail) sizes_list="64" ;;
esac
for bytes in $sizes_list
do
- echo "run IPv$proto ping tests ($want), $bytes byte packets..."
-
- echo "$cmd -b $bytes -C 20 -p 250 -q $targetlist"
>>$LOGDIR/$SUF:fping.out
- $cmd -b $bytes -C 20 -p 250 -q $targetlist >>$LOGDIR/$SUF:fping.out 2>&1
-
- # while OpenVPN is running, pings must succeed (want='want_ok')
- # before OpenVPN is up, pings must NOT succeed (want='want_fail')
-
- rc=$?
- if [ $rc = 0 ] # all ping OK
- then
- if [ $want = "want_fail" ] # not what we want
- then
- fail "IPv$proto ping test succeeded, but needs to *fail*."
- fi
- else# ping failed
- if [ $want = "want_ok" ]# not what we wanted
- then
- fail "IPv$proto ping test ($bytes bytes) failed, but should
succeed."
- fi
- fi
+echo "run IPv$proto ping tests ($want), $bytes byte packets..."
+
+echo "$cmd -b $bytes -C 20 -p 250 -q $targetlist"
>>$LOGDIR/$SUF:fping.out
+$cmd -b $bytes -C 20 -p 250 -q $targetlist >>$LOGDIR/$SUF:fping.out
2>&1
+
+# while OpenVPN is running, pings must succeed (want='want_ok')
+# before OpenVPN is up, pings must NOT succeed (want='want_fail')
+
+rc=$?
+if [ $rc = 0 ] # all ping OK
+then
+if [ $want = "want_fail" ]# not what we want
+then
+fail "IPv$proto ping test succeeded, but needs to *fail*."
+fi
+else# ping failed
+if [ $want = "want_ok" ]# not what we wanted
+then
+fail "IPv$proto ping test ($bytes bytes) failed, but should
succeed."
+fi
+ fi
done
}
+#
# --
-# main test loop
+# run single test
# --
-SUMMARY_OK=
-SUMMARY_FAIL=
-
-for SUF in $TEST_RUN_LIST
-do
-# get config variables
-eval test_prep=\"\$PREPARE_$SUF\"
-eval test_cleanup=\"\$CLEANUP_$SUF\"
-eval test_run_title=\"\$RUN_TITLE_$SUF\"
-eval openvpn_conf=\"\$OPENVPN_CONF_$SUF\"
-eval expect_ifconfig4=\"\$EXPECT_IFCONFIG4_$SUF\"
-eval expect_ifconfig6=\"\$EXPECT_IFCONFIG6_$SUF\"
- eval ping4_hosts=\"\$PING4_HOSTS_$SUF\"
-eval ping6_hosts=\"\$PING6_HOSTS_$SUF\"
-
-echo -e "\n### test run $SUF: '$test_run_title' ###\n"
-fail_count=0
-
-if [ -n "$test_prep" ]; then
-echo -e "running preparation: '$test_prep'"
-eval $test_prep
-fi
-
-echo "save pre-openvpn ifconfig + route"
-get_ifconfig_route >$LOGDIR/$SUF:ifconfig_route_pre.txt
-
-echo -e "\nrun pre-openvpn ping tests - targets must not be reachable..."
-run_ping_tests 4 want_fail "$ping4_hosts"
-run_ping_tests 6 want_fail "$ping6_hosts"
-if [ "$fail_count" = 0 ] ; then
-echo -e "OK.\n"
-else
- echo -e "FAIL: make sure that ping hosts are ONLY reachable via VPN,
SKIP test $SUF".
- exit_code=31
- continue
-fi
-
-echo " run openvpn $openvpn_conf"
-echo "# src/openvpn/openvpn $openvpn_conf" >$LOGDIR/$SUF:openvpn.log
-$RUN_SUDO "${top_builddir}/src/openvpn/openvpn" $openvpn_conf
>>$LOGDIR/$SUF:openvpn.log &
-opid=$!
-# make sure openvpn client is terminated in case shell exits
-trap "$RUN_SUDO kill $opid" 0
-trap "$RUN_SUDO kill $opid ; trap - 0 ; exit 1" 1 2 3 15
+run_test() {
+ # get config variables
+
[Openvpn-devel] Refactor t_client.sh & improve output formatting
Ratio: * Cleanup code * Prepare for better automated integration tests (future) Move global code into separate functions. Fixup formatting of code. Also add table output formatting to t_client.sh: | ID | TEST| RESULT | | -- | --- | | | 1 | testing tun/udp/ipv4| [SUCCESS]| | 2 | testing tun/udp/ipv4 with pam | [FAIL: 5 fails] | | -- | --- | | Test sets succeded: 1. Test sets failed: 2. For easier review these patches have also been provided via GitHub pull request: https://github.com/OpenVPN/openvpn/pull/49 Due to moving code around and intention changes this patch looks rather large: 1 file changed, 267 insertions(+), 180 deletions(-).
[Openvpn-devel] Add unit testing support
This is a series of two patches that add unit testing support to openvpn. See https://github.com/OpenVPN/openvpn/pull/44 for a discussion. Thanks to syzzer for his nitty-gritty review! Jens
[Openvpn-devel] [PATCH 1/2] Add unit testing support via cmocka
From: Jens Neuhalfen cmocka [1,2] is a testing framework for C. Adding unit test capabilities to the openvpn repository will greatly ease the task of writing correct code. cmocka source code is added as git submodule in ./vendor. A submodule approach has been chosen over a classical library dependency because libcmocka is not available, or only available in very old versions (e.g. on Ubuntu). cmocka is build during 'make check' and installed in vendor/dist/. [1] https://cmocka.org/ [2] https://lwn.net/Articles/558106/ Signed-off-by: Jens Neuhalfen --- .gitmodules | 4 +++ Makefile.am | 2 +- configure.ac | 16 +++ tests/Makefile.am | 3 +- tests/unit_tests/.gitignore | 1 + tests/unit_tests/Makefile.am | 3 ++ tests/unit_tests/README.md| 40 ++ tests/unit_tests/example_test/Makefile.am | 13 + tests/unit_tests/example_test/README.md | 3 ++ tests/unit_tests/example_test/test.c | 47 +++ tests/unit_tests/example_test/test2.c | 22 +++ vendor/.gitignore | 2 ++ vendor/Makefile.am| 24 vendor/README.md | 9 ++ vendor/cmocka | 1 + 15 files changed, 188 insertions(+), 2 deletions(-) create mode 100644 .gitmodules create mode 100644 tests/unit_tests/.gitignore create mode 100644 tests/unit_tests/Makefile.am create mode 100644 tests/unit_tests/README.md create mode 100644 tests/unit_tests/example_test/Makefile.am create mode 100644 tests/unit_tests/example_test/README.md create mode 100644 tests/unit_tests/example_test/test.c create mode 100644 tests/unit_tests/example_test/test2.c create mode 100644 vendor/.gitignore create mode 100644 vendor/Makefile.am create mode 100644 vendor/README.md create mode 16 vendor/cmocka diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 000..e9c6388 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,4 @@ +[submodule "vendor/cmocka"] + path = vendor/cmocka + url = git://git.cryptomilk.org/projects/cmocka.git + branch = master diff --git a/Makefile.am b/Makefile.am index 66d9f23..364785c 100644 --- a/Makefile.am +++ b/Makefile.am @@ -54,7 +54,7 @@ BUILT_SOURCES = \ config-version.h endif -SUBDIRS = build distro include src sample doc tests +SUBDIRS = build distro include src sample doc vendor tests dist_doc_DATA = \ README \ diff --git a/configure.ac b/configure.ac index 97ad856..fb3fa3c 100644 --- a/configure.ac +++ b/configure.ac @@ -1198,6 +1198,19 @@ sampledir="\$(docdir)/sample" AC_SUBST([plugindir]) AC_SUBST([sampledir]) +VENDOR_SRC_ROOT="\$(abs_top_srcdir)/vendor/" +VENDOR_DIST_ROOT="\$(abs_top_builddir)/vendor/dist" +VENDOR_BUILD_ROOT="\$(abs_top_builddir)/vendor/.build" +AC_SUBST([VENDOR_SRC_ROOT]) +AC_SUBST([VENDOR_BUILD_ROOT]) +AC_SUBST([VENDOR_DIST_ROOT]) + +TEST_LDFLAGS="-lcmocka -L\$(abs_top_builddir)/vendor/dist/lib -Wl,-rpath,\$(abs_top_builddir)/vendor/dist/lib" +TEST_CFLAGS="-I\$(top_srcdir)/include -I\$(abs_top_builddir)/vendor/dist/include" + +AC_SUBST([TEST_LDFLAGS]) +AC_SUBST([TEST_CFLAGS]) + AC_CONFIG_FILES([ version.sh Makefile @@ -1216,6 +1229,9 @@ AC_CONFIG_FILES([ src/plugins/auth-pam/Makefile src/plugins/down-root/Makefile tests/Makefile +tests/unit_tests/Makefile +tests/unit_tests/example_test/Makefile +vendor/Makefile sample/Makefile doc/Makefile ]) diff --git a/tests/Makefile.am b/tests/Makefile.am index b7980e0..2cba9e6 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -12,6 +12,8 @@ MAINTAINERCLEANFILES = \ $(srcdir)/Makefile.in +SUBDIRS = unit_tests + test_scripts = t_client.sh t_lpback.sh t_cltsrv.sh TESTS_ENVIRONMENT = top_srcdir="$(top_srcdir)" @@ -20,4 +22,3 @@ TESTS = $(test_scripts) dist_noinst_SCRIPTS = \ $(test_scripts) \ t_cltsrv-down.sh - diff --git a/tests/unit_tests/.gitignore b/tests/unit_tests/.gitignore new file mode 100644 index 000..8655de8 --- /dev/null +++ b/tests/unit_tests/.gitignore @@ -0,0 +1 @@ +*_testdriver diff --git a/tests/unit_tests/Makefile.am b/tests/unit_tests/Makefile.am new file mode 100644 index 000..18267bd --- /dev/null +++ b/tests/unit_tests/Makefile.am @@ -0,0 +1,3 @@ +AUTOMAKE_OPTIONS = foreign + +SUBDIRS = example_test diff --git a/tests/unit_tests/README.md b/tests/unit_tests/README.md new file mode 100644 index 000..ef81b23 --- /dev/null +++ b/tests/unit_tests/README.md @@ -0,0 +1,40 @@ +Unit Tests +=== + +This directory contains unit tests for openvpn. New features/bugfixes should be written in a test friendly way and come wit
[Openvpn-devel] [PATCH 2/2] Add a test for auth-pam searchandreplace
uth-pam/utils.c b/src/plugins/auth-pam/utils.c
new file mode 100644
index 000..4f2bec1
--- /dev/null
+++ b/src/plugins/auth-pam/utils.c
@@ -0,0 +1,113 @@
+/*
+ * OpenVPN -- An application to securely tunnel IP networks
+ * over a single TCP/UDP port, with support for SSL/TLS-based
+ * session authentication and key exchange,
+ * packet encryption, packet authentication, and
+ * packet compression.
+ *
+ * Copyright (C) 2002-2010 OpenVPN Technologies, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program (see the file COPYING included with this
+ * distribution); if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+/*
+ * OpenVPN plugin module to do PAM authentication using a split
+ * privilege model.
+ */
+#ifdef HAVE_CONFIG_H
+#include
+#endif
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "utils.h"
+
+char *
+searchandreplace(const char *tosearch, const char *searchfor, const char
*replacewith)
+{
+ if (!tosearch || !searchfor || !replacewith) return NULL;
+
+ size_t tosearchlen = strlen(tosearch);
+ size_t replacewithlen = strlen(replacewith);
+ size_t templen = tosearchlen * replacewithlen;
+
+ if (tosearchlen == 0 || strlen(searchfor) == 0 || replacewithlen == 0) {
+return NULL;
+ }
+
+ bool is_potential_integer_overflow = (templen == SIZE_MAX) || (templen /
tosearchlen != replacewithlen);
+
+ if (is_potential_integer_overflow) {
+ return NULL;
+ }
+
+ // state: all parameters are valid
+
+ const char *searching=tosearch;
+ char *scratch;
+
+ char temp[templen+1];
+ temp[0]=0;
+
+ scratch = strstr(searching,searchfor);
+ if (!scratch) return strdup(tosearch);
+
+ while (scratch) {
+strncat(temp,searching,scratch-searching);
+strcat(temp,replacewith);
+
+searching=scratch+strlen(searchfor);
+scratch = strstr(searching,searchfor);
+ }
+ return strdup(temp);
+}
+
+const char *
+get_env (const char *name, const char *envp[])
+{
+ if (envp)
+{
+ int i;
+ const int namelen = strlen (name);
+ for (i = 0; envp[i]; ++i)
+ {
+ if (!strncmp (envp[i], name, namelen))
+ {
+ const char *cp = envp[i] + namelen;
+ if (*cp == '=')
+ return cp + 1;
+ }
+ }
+}
+ return NULL;
+}
+
+int
+string_array_len (const char *array[])
+{
+ int i = 0;
+ if (array)
+{
+ while (array[i])
+ ++i;
+}
+ return i;
+}
diff --git a/src/plugins/auth-pam/utils.h b/src/plugins/auth-pam/utils.h
new file mode 100644
index 000..d896f89
--- /dev/null
+++ b/src/plugins/auth-pam/utils.h
@@ -0,0 +1,54 @@
+/*
+ * OpenVPN -- An application to securely tunnel IP networks
+ * over a single TCP/UDP port, with support for SSL/TLS-based
+ * session authentication and key exchange,
+ * packet encryption, packet authentication, and
+ * packet compression.
+ *
+ * Copyright (C) 2002-2010 OpenVPN Technologies, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program (see the file COPYING included with this
+ * distribution); if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef _PLUGIN_AUTH_PAM_UTILS__H
+#define _PLUGIN_AUTH_PAM_UTILS__H
+
+/* Read 'tosearch', replace all occurences of 'searchfor' with 'replacewith'
and return
+ * a pointer to the NEW string. Does not modify the input strings. Will not
enter an
+ * infinite loop with clever 'searchfor' and 'replacewith' strings.
+ * Daniel Johnson - progman2...@usa.net / djohn...@progman.us
+ *
+ * Retuns NULL when
+ * - any parameter is NULL
+ * - the worst-case result is to large ( >= SIZE_MAX)
+ */
+char *
+searchandreplace(const char *tosearch, const char *searchfor, con
[Openvpn-devel] socklen_t type error resulting from uint8_t duplicate typedef on osx. help?
hi, i'm building openvpn-2.1_rc4 on osx 10.4.10. currently, ./configure \ --prefix=/usr/local/openvpn \ --enable-pthread \ --disable-password-save \ --with-ssl-headers=/usr/local/ssl/include/openssl/ \ --with-ssl-lib=/usr/local/ssl/lib/ \ --with-lzo-headers=/usr/local/include/lzo \ --with-lzo-lib=/usr/local/lib \ --with-ifconfig-path=/sbin/ifconfig \ --with-route-path=/sbin/route fails at, ... checking for socklen_t equivalent... configure: error: Cannot find a type to use in place of socklen_t poking around in config.log socklen-related errors 1st appear, ... configure:7574: result: 0 configure:7660: checking for socklen_t configure:7692: gcc -c -g -O2 -I/usr/local/ssl/include/openssl/ -I/usr/local/include/lzo -I. -no-cpp-precomp conftest.c >&5 In file included from /usr/include/sys/_endian.h:88, from /usr/include/ppc/endian.h:107, from /usr/include/machine/endian.h:30, from /usr/include/sys/types.h:75, from conftest.c:69: /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdint.h:34: error: duplicate 'unsigned' /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdint.h:34: error: two or more data types in declaration specifiers /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdint.h:39: error: duplicate 'unsigned' /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdint.h:39: error: both 'short' and 'char' in declaration specifiers /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdint.h:44: error: duplicate 'unsigned' In file included from conftest.c:69: /usr/include/sys/types.h:120: error: two or more data types in declaration specifiers /usr/include/sys/types.h:120: error: two or more data types in declaration specifiers configure:7698: $? = 1 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "OpenVPN" | #define PACKAGE_TARNAME "openvpn" ... which , looking @: /usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include/stdint.h:34 ... #ifndef _UINT8_T #define _UINT8_T 34: typedef unsigned char uint8_t; #endif /*_UINT8_T */ ... doesn't, in fact, look like a prob with socklen_t ... any suggestions here? thanks!
[Openvpn-devel] CE port needed DLLs
Hello. I'm triying to execute a Windows CE 5.0 porting of openvpn client application. I've been successful on compiling it but when i try to execute i receive the message: "openvpn is not a valid WindowsCE application". I am compiling to ARM-Thumb architecture. I suspect there is a problem with needed DLLs. Could anyone tell me wich DLLs are needed and where could i get them? Thank you very much.
Re: [Openvpn-devel] CE port needed DLLs
Hello. First of all, thank you for the quick response. We have other applications running on the Windows CE distribution and the linker option "MACHINE" is set to "THUMB". We are using a custom developed board, and we develop our applications through Visual Studio 2005. We only need to stablish a connection to a VPN server without need of a GUI, all configuration must be transparent to the user. Therefore I think we only need the openvpn executable and TAP_CE driver. If i'm not wrong, the ovpncmgr module is to provide a GUI for the openVPN client. Is that correct? When no dll is provided, and I try to debug the application from Visual Studio connected to the device, i get the message: "An error occurred that usually indicates a corrupt installation (code 0x8007007e). If the problem persists, repair your Visual Studio installation via 'Add or Remove Programs' in control Panel" Some webs refer to that error like some archives are missing. When I put the dlls you have listed below, the error changes to: "openvpn is not a valid WindowsCE application". I suspect that some of the dll may not be correct for my platform. Could it be the source of my problem? I have not been able to find the cellcore.dll for our platform. Does it mean we cannot use the connection manager functionality? I have read in some forums that this functionality is not present on Windows CE... Sorry for my ignorance, I am pretty new on Windows CE. Your help is so much appreciated. Thank you very much. Jonathan. 2009/5/27 dave > That message usually means the binary is hosed, and I believe missing > dlls give a different message. > Are you sure Thumb is correct for your platform? Are you using a consumer > device like a pocket pc phone, etc, or is it a custom board? > > I ask that because the existing code does use some functionality peculiar > to the pocket pc (phone) that is not generally available on other platforms, > yet the SDKs ofen include the headers and import libs, allowing you to > successfully compile, but then you can't run it on the target device. > > When you say 'client application' are you meaning just the gui, or the > whole entire set of programs (i.e., the TAP driver, the openvpn executable, > and the gui). > > You can use DUMPBIN to find the dlls from the exe, and also inspect the > header to see the cpu configuration. Here is a short list, if it helps: > > openvpn: > * coredll.dll > * w2s.dll > * iphlpapi.dll > * wininet.dll > * ole32.dll > * cellcore.dll > > tap-ce: > * ndis.dll > * coredll.dll > > ovpncmgr: > * iphlpapi.dll > * toolhelp.dll > * cellcore.dll > * ole32.dll > * mfcce300.dll > * coredll.dll > * winsock.dll > > Your build may (will) differ depending on your platform, because your > platform builder may have put some of these features in different dlls. > That list was for PocketPC. > > Now, the cellcore.dll, you may not have on other platforms. It is needed > for supporting Windows Connectin Manager, and you can surgically cut out > that functionality if your platform doesn't have it. Most of the rest is > fairly standard. > > Before doing surgery, you may wish to re-check your assumptions. Also, if > you wish to zip up your problem binaries and send them to me directly, I > will do a quick inspection for you. > > -dave > > -Original Message- > *From:* jonathan openvpn [mailto:jonathan.open...@gmail.com] > *Sent:* Wednesday, May 27, 2009 5:36 AM > *To:* openvpn-devel@lists.sourceforge.net > *Subject:* [Openvpn-devel] CE port needed DLLs > > Hello. > > I'm triying to execute a Windows CE 5.0 porting of openvpn client > application. I've been successful on compiling it but when i try to execute > i receive the message: "openvpn is not a valid WindowsCE application". > > I am compiling to ARM-Thumb architecture. I suspect there is a problem with > needed DLLs. > > Could anyone tell me wich DLLs are needed and where could i get them? > > Thank you very much. > >
Re: [Openvpn-devel] CE port needed DLLs
Hi Dave. This morning I've been able to solve the error and began to debug the application. There were two reasons for my problem: - the wininet.dll file i had was compiled for x86 platform. I've found a thumb file version in internet. - I have removed the code related to the connection manager (files openvpn.c and wince_portstuff.c) and the cellcore.lib link reference. Also, in internet i have found that cellcore.dll is available in Windows Mobile and Windows Embedded CE 6.0 but not in Windows CE 5.0 At this point, as you have said, i will need to do networking "in the more conventional way", in spite of i don't know what it means yet, and how to do it... To sum up, my problem was i didn't have the correct platform libraries, plus a big piece of ignorance... Can you give me a link or reference to somewhere I could get information about possibilities to solve my networking needs without the connection manager? Thank you very much for your help. It has been very useful. Probably i'll come back soon with some new questions and doubts. I hope some day i'll be able to solve someone questions too... Best regards, Jonathan. 2009/5/28 dave > Sure, you're welcome. Thumb should not fundamentally be a problem > provided the platform and tools support it, and it sounds like in your case > it does. > > Your assumptions about what you need are correct, I believe (i.e., you > don't need the gui). You may want to inspect the code, however, because > there are routines for installing and loading the TAP driver that may be of > interest. They are in taputil.h,.c > > cellcore.dll is used to provide the Windows Connection Manager stuff, and > in openvpn.exe this in openvpn.c, around line 203, and around line 284. I > should have conditional-compiled that as an option, but I didn't. Similarly > the support routines are in wince_portstuff.c at line 1631 through the end, > and they can go, too (actually if you remove those first and compile, the > compile should fail and you can find if there was anything I missed, but > that should be it). > > Generic CE platforms don't use the Windows Connection Manager and do > networking in the more conventional way, so you can probable do without it, > and remove the cellcore.lib from your link step. > > Assuming your error message really means 'missing dlls' instead of 'invalid > binary' then you should be better off. > > Again, if you want to send me your compiled binary, I can inspect it more > closely if that is useful. > > -Dave > > -Original Message- > *From:* jonathan openvpn [mailto:jonathan.open...@gmail.com] > *Sent:* Thursday, May 28, 2009 1:56 AM > *To:* dave > *Cc:* openvpn-devel@lists.sourceforge.net > *Subject:* Re: [Openvpn-devel] CE port needed DLLs > > Hello. > > First of all, thank you for the quick response. > > We have other applications running on the Windows CE distribution and the > linker option "MACHINE" is set to "THUMB". > We are using a custom developed board, and we develop our applications > through Visual Studio 2005. > > We only need to stablish a connection to a VPN server without need of a > GUI, all configuration must be transparent to the user. Therefore I think we > only need the openvpn executable and TAP_CE driver. If i'm not wrong, the > ovpncmgr module is to provide a GUI for the openVPN client. Is that correct? > > When no dll is provided, and I try to debug the application from Visual > Studio connected to the device, i get the message: "An error occurred that > usually indicates a corrupt installation (code 0x8007007e). If the problem > persists, repair your Visual Studio installation via 'Add or Remove > Programs' in control Panel" > Some webs refer to that error like some archives are missing. When I put > the dlls you have listed below, the error changes to: "openvpn is not a > valid WindowsCE application". I suspect that some of the dll may not be > correct for my platform. Could it be the source of my problem? > > I have not been able to find the cellcore.dll for our platform. Does it > mean we cannot use the connection manager functionality? I have read in some > forums that this functionality is not present on Windows CE... > > Sorry for my ignorance, I am pretty new on Windows CE. > > Your help is so much appreciated. Thank you very much. > > Jonathan. > > > 2009/5/27 dave > >> That message usually means the binary is hosed, and I believe missing >> dlls give a different message. >> Are you sure Thumb is correct for your platform? Are you using a consumer >> device like a pocket pc phone, etc, or is it a custom board? >> >&
[Openvpn-devel] Cannot find TAP adapter
Hello. I'm triying to execute a Windows CE port of OpenVPN in a custom hardware. First of all, let me say that I cannot use the connection manager due to the plattform i am using. I've been succesfull on open the socket and retrieve initial information from the OpenVPN server. I also have added a TAP interface to the Windows CE registry via the "AddTAPAdapterRegistration" function in "taputil.cpp". My problem comes when it's time to open the just registered TUN adapter. When it searches for the adapters on the device by the "GetAdaptersInfo" function, the TUN adapter is not present. Only the physical ethernet interface is present. I've compared the resgistry entries with a pocket PC running an OpenVPN client and they are identical! I've searched in internet looking for someone with a similar problem but i have found nothing. Have you any idea? What are the requirements for an adapter to be found by the "GetAdaptersInfo" function? Here are my registry entries: [HKEY_LOCAL_MACHINE\Comm\TAP Device] "ImagePath"="tap-ce.dll" "Group"="NDIS" "DisplayName"="TAP Virtual Ethernet Device" [HKEY_LOCAL_MACHINE\Comm\TAP Device\Linkage] "Route"=hex(7):\ 54,41,50,20,44,65,76,69,63,65,20,31,00,54,41,50,20,44,65,76,69,63,65,20,32,\ 00,00 [HKEY_LOCAL_MACHINE\Comm\TAP Device 1] "ImagePath"="tap-ce.dll" "Group"="NDIS" "DisplayName"="TAP1: Virtual Ethernet Device" [HKEY_LOCAL_MACHINE\Comm\TAP Device 1\Parms] "StreamIndex"=dword:0001 "StreamName"="TAP" "BusType"=dword: "BusNumber"=dword: Another doubt. In the tun.c file, in function "do_ifconfig", there is no entry for WIN32 or WIN_CE, instead of this it is an "elif 0" entry. Because of this, in WIN_CE systems no ifconfig is done. Isn't it necessary? Thank you very much. Jonathan.
[Openvpn-devel] CBC mode attack
Hey guys... Was wondering if you were familiar with this: http://news.ycombinator.com/item?id=2029640 And, well... it sounded really familiar: http://www.mail-archive.com/cryptography@metzdowd.com/msg07521.html -- Good code works on most inputs; correct code works on all inputs. My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpOi6GZcvStn.pgp Description: PGP signature
[Openvpn-devel] suggested config settings for wifi?
See attach. I'm wondering, with the default settings (used via Ubuntu's network-manager, though that isn't really relevant I think), why I keep getting timeouts. I can ping the box. It seems to work 1 out of every 5 times, so it's not a packet filter blocking me. Is there any setting I can set? TY -- http://www.subspacefield.org/~travis/ | A real man does not think of victory or defeat. He plunges recklessly towards an irrational death. -- Hagakure If you are a spammer, please email j...@subspacefield.org to get blacklisted. --- Begin Message --- I'm getting a lot of "timeout exceeded" responses when trying to do VPN over WiFi... sometimes it takes 4-5 attempts, especially when doing WiFi->4G->wired connections. Any suggested settings to make it more tolerant of timeouts/retransmits? -- http://www.subspacefield.org/~travis/ "Sweeney? It doesn't exactly sound like a super-villain's... y'know, cool name" If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpPztXLjGX2a.pgp Description: PGP signature -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct_______ Openvpn-users mailing list openvpn-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users --- End Message --- pgp9tsjhWJ2FB.pgp Description: PGP signature
[Openvpn-devel] Unsubscribe
Sent from ProtonMail Mobile
On Thu, Jun 15, 2017 at 8:00 PM,
wrote: Send Openvpn-devel mailing list submissions to
openvpn-devel@lists.sourceforge.net To subscribe or unsubscribe via the World
Wide Web, visit https://lists.sourceforge.net/lists/listinfo/openvpn-devel or,
via email, send a message with subject or body 'help' to
openvpn-devel-requ...@lists.sourceforge.net You can reach the person managing
the list at openvpn-devel-ow...@lists.sourceforge.net When replying, please
edit your Subject line so it is more specific than "Re: Contents of
Openvpn-devel digest..." Today's Topics: 1. Re: Bug or Feature? Username in
environment in auth-user-pass-verify (Steven Haigh) 2. Re: Bug or Feature?
Username in environment in auth-user-pass-verify (David Sommerseth) 3. Re: Bug
or Feature? Username in environment in auth-user-pass-verify (Antonio
Quartulli) 4. Re: W10 Client assigns old AND new IPv6 address to TAP with
GUI+Service but not with cmd prompt (debbie10t)
-- Message:
1 Date: Fri, 16 Jun 2017 02:11:48 +1000 From: Steven Haigh To:
openvpn-devel@lists.sourceforge.net Subject: Re: [Openvpn-devel] Bug or
Feature? Username in environment in auth-user-pass-verify Message-ID:
<1649446.b7buzjz...@dhcp-10-1-1-119.lan.crc.id.au> Content-Type: text/plain;
charset="utf-8" On Thursday, 15 June 2017 5:47:39 PM AEST Gert Doering wrote: >
Hi, > > On Thu, Jun 15, 2017 at 12:50:40PM +1000, Steven Haigh wrote: > > I'm
just trying to figure out if its expected behaviour to have the > > 'username'
set in the environment when using the auth-user-pass-verify > > script. > > The
code in question (ssl_verify.c) is older than the involvement of > any of the
currently-active developers... but JJK or Ecrist might know. > > Anyway, what
the code *says* is: > > ssl_verify.c, about line 1095: > >
verify_user_pass_script(...) > { > ... > /* Set environmental variables prior
to calling script */ > if (session->opt->auth_user_pass_verify_script_via_file)
> { > ... (no setenv here) > } > else > { > setenv_str(session->opt->es,
"username", up->username); > setenv_str(session->opt->es, "password",
up->password); > } > > > so, yes, that is what it *does* - "username" is only
ever set together > with "password", and that's only setenv'ed if you do not
use "via-file". > > Now, that is about calling the --verify-auth-user-pass, but
I think the > "es" (environment set) being affected here is the global
per-connection > es (not something local to this function), so that would
affect > --client-connect as well. > > [..] > > > The auth-user-pass-verify
documentation states: > > If method is set to "via-env", OpenVPN will call
script with the > > environmental variables username and password set to the >
> username/password strings provided by the client. Be aware that this > >
method is insecure on some platforms which make the environment of a > >
process publicly visible to other unprivileged processes. > > This "some
platforms" actually something we should eventually verify > and clearly
spell-out - because Linux and all recent BSDs do *not* show > the environment
to other unprivileged users. > > [..] > > > No mention of the username env
variable when using via-file - but this > > gives me the impression that the
username should *not* be set in the > > environment - but it should be in the
file. > > > > So - bug or feature? > > Username and Password are always handled
in tandem when talking about > --auth-user-pass-verify, so "both in
environment" or "none of them". > > Now, if you use a *plugin* (or the
management interface), the code will > always set both in the es, and delete
the password(!) afterwards, leaving > the username intact... > > > Looking from
a given distance, I'd say that this is a bug, and "username" > should propably
be always visible in the es (if present), while password > should not. > > > If
you want to experiment: go to ssl_verify.c, and move the line 1123 > (master)
outside the else {} block: > > old: > > else > { > setenv_str(session->opt->es,
"username", up->username); > setenv_str(session->opt->es, "password",
up->password); > } > > new: > > else > { > setenv_str(session->opt->es,
"password", up->password); > } > setenv_str(session->opt->es, "username",
up->username); > > ... then it should show up in
[Openvpn-devel] Openvpn
Sent from my iPhone ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] obfs4proxy-openvpn: A Bash script for obfuscating OpenVPN traffic using obfs4
Hi, I have developed a bash script to make openvpn work with obfs4. It's hosted on github: https://github.com/HRomie/obfs4proxy-openvpn It might be worth updating the obfuscation article article and include it: https://community.openvpn.net/openvpn/wiki/TrafficObfuscation Regards, Hamy___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs
Hi, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday 22 June 2020 18:58, Selva Nair wrote: > On Mon, Jun 22, 2020 at 7:31 AM David Sommerseth dav...@openvpn.net wrote: > > > This change makes the server use AES-256-GCM instead of BF-CBC as the > > default cipher for the VPN tunnel when starting OpenVPN via systemd > > and the openvpn-server@.service unit file. > > To avoid breaking existing running configurations defaulting to BF-CBC, > > the Negotiable Crypto Parameters (NCP) list contains the BF-CBC in > > addition to AES-CBC. This makes it possible to migrate existing older > > client configurations one-by-one to use at least AES-CBC unless the > > client is updated to v2.4 or newer (which defaults to upgrade to > > AES-GCM automatically) > > This has been tested in Fedora 27 (released November 2017) with no > > reported issues. By making this default for all Linux distributions > > with systemd shipping with the unit files we provide, we gradually > > expand setups using this possibility. As we gather experience from > > this change, we can further move these changes into the defaults of > > the OpenVPN binary itself with time. > > > > Signed-off-by: David Sommerseth dav...@openvpn.net > > > > --- > > > > Changes.rst | 15 +++ > > distro/systemd/openvpn-ser...@.service.in | 2 +- > > 2 files changed, 16 insertions(+), 1 deletion(-) > > diff --git a/Changes.rst b/Changes.rst > > index 00dd6ed8..e76d3c73 100644 > > --- a/Changes.rst > > +++ b/Changes.rst > > @@ -14,6 +14,21 @@ ChaCha20-Poly1305 cipher support > > channel. > > +User-visible Changes > > +---- > > +New default cipher for systemd based Linux distributions > > > > - For Linux distributions with systemd which packages the systemd unit > > files > > - from the OpenVPN project, the default cipher is now changed to > > AES-256-GCM, > > - with BF-CBC as a fallback through the NCP feature. This change has been > > - tested successfully since the Fedora 27 release (released November > > 2017). > > - > > - WARNING This MAY break configurations where the client uses > > - ``--disable-occ`` feature where the ``--cipher`` has > > > > > > - not been explicitly configured on both client and > > > > > > - server side. It is recommended to remove the > > ``--disable-occ`` > > > > > > - option *or* explicitly add ``--cipher AES-256-GCM`` on > > the > > > > > > - client side if ``--disable-occ`` is strictly needed. > > > > > > - > > > > Overview of changes in 2.4 > > > > === > > > > diff --git a/distro/systemd/openvpn-ser...@.service.in > > b/distro/systemd/openvpn-ser...@.service.in > > index d1cc72cb..f3545ff5 100644 > > --- a/distro/systemd/openvpn-ser...@.service.in > > +++ b/distro/systemd/openvpn-ser...@.service.in > > @@ -10,7 +10,7 @@ > > Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO > > Type=notify > > PrivateTmp=true > > WorkingDirectory=/etc/openvpn/server > > -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log > > --status-version 2 --suppress-timestamps --config %i.conf > > +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log > > --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers > > AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC --config %i.conf > > This is why I keep my openvpn servers out of systemd's view -- it > keeps deciding what's good for us. I want to run my configs as is. > > Selva > > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel Sorry for the noise in advance but I agree. No idea how to keep it out of systemd's view :) but I change the line to -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf +ExecStart=@sbindir@/openvpn --config %i.conf and do everything in %i.conf No unexpected configuration behaviour that way like missing timestamps in log. Pippin ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Wiki: PluginOverview
Hi, Regarding radius plugin: https://community.openvpn.net/openvpn/wiki/PluginOverview The source is here: https://www.nongnu.org/radiusplugin/ Edited Wiki page. W.k.r Pippin Sent with ProtonMail Secure Email. ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Regarding deprecation of --route-nopull
Hi, Regarding, https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--route-nopull "Openvpn devs would like to know if you use this option". Many pfSense users use this option to policy route. P.S. Made a feature request at pfSense Redmine to add --pull-filter six months ago. W.k.r. Pippin _______ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] Regarding deprecation of --route-nopull
Hi, > Am 23.07.2020 um 20:14 schrieb André via Openvpn-devel: > > > Hi, > > Regarding, > > https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--route-nopull > > "Openvpn devs would like to know if you use this option". > > Many pfSense users use this option to policy route. > > I would also vote for keeping this option. I did not vote ;) but ok will give my Senf :) > Yes you can emulate the > option by using a number of pull-filter lines but that feels like not a > good user experience. One could also say that, --route-nopull does more then just barring routes. --pull-filter is specific, I would prefer that. > Also route-pull works in both OpenVPN 2.x and 3.x > clients while pull-filter is currently 2.x only. Could change in 3.x too I guess. W.k.r. Pippin ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Document that --push-remove is generally more suitable than --push-reset
Hi, My vote would be to deprecate --push-reset (same for --route-nopull) André Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday 8 September 2020 18:41, Arne Schwabe wrote: > Am 08.09.20 um 18:35 schrieb Gert Doering: > > > Hi, > > On Tue, Sep 08, 2020 at 03:11:40PM +0200, David Sommerseth wrote: > > > > > It would be good if --push-reset would actually not remove certain > > > critical > > > options, but this is anyhow a good heads-up for our users. > > > > Well, that ticket sat there 10 years (!!) waiting for someone to go > > and implement it... 6 years it sat on your lap, 4 years on mine (or so), > > so it looks like this is not going to happen any time soon. > > It also feels like a feature from a different area when pushed options > were few and not as essential to OpenVPN. It would remove/deprecate that > feature instead of trying to figure out how it should now. > > Arne > > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel signature.asc Description: Binary data ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] Fw: Re: [Openvpn-users] Problem with service on windows server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Forwarding to openvpn-devel, as requested. CC'ing -users FTR. --- Original Message --- On Tuesday, June 28th, 2022 at 02:59, Selva Nair wrote: > Hi, > > > > > > the \\config-auto folder is only created if the 'openVPN Service' is > > selected *manually* during installation. > > > We need to install the automatic service without manual intervention. Is this > also the behaviour on a fresh install instead of an update? The logic for > installing the service was complicated from start because we wanted to detect > when automatic service should be set to autostart, migrate configs into > config-auto if required etc. during an update. But, in the process, it seems > we have somehow ended up not installing it by default. > > Actually, always installing and even setting its startup to auto should be > safe now as we have a folder exclusively meant for auto-start ones > (config-auto). This was not the case with older versions. > > Selva > > > > > > > However, the 'Interactive-Service' *is* installed by default. > > > > This feels *needlessly* complicated. > > > > As a long-time Windows user, I am much more accustomed to turning options > > which I do not want OFF than I am turning options which I do want ON. > > > > Also, the installer does not have the customary: > > * FULL (Default) > > * Standard - This could be renamed 'CLIENT ONLY', if that is the intention > > .. > > * Custom - Debugging .. > > * Advertiser sponsored - This is common enough. > > > > which I would normally "hope" to see from a well behaved .msi installer. > > > > my2c > > > > > > > > --- Original Message --- > > On Monday, June 27th, 2022 at 22:49, tincantech > > wrote: > > > > > > > Correction: 2.5.7-I602 not 2.5.5 > > > > > > --- Original Message --- > > > On Monday, June 27th, 2022 at 22:35, tincantech via Openvpn-users > > > openvpn-us...@lists.sourceforge.net wrote: > > > > > > > > > > > > > Hi, > > > > > > > > I must point this out: > > > > > > > > > > > > > > > > > > > > I am setting up an OpenVPN server on a windows server for a > > > > > > > > client, but ran into the problem where the openvpn service in > > > > > > > > services doesn’t pick up the config files I placed into the > > > > > > > > C:\Program Files\Openvpn\config folder. > > > > > > > > > > > > > > > > I can start the server from the command line just fine and also > > > > > > > > from the openvpn-gui client, but when I start the openvpn > > > > > > > > service > > > > > > > > in services, the service starts and stays running, but the > > > > > > > > server > > > > > > > > isn’t listening for incoming connections. > > > > > > > > > > > > > > > > It is not clear if the following point effects the OP, however .. > > > > > > > > The correct folder for auto-start is: > > > > C:\Program Files\Openvpn\config-auto > > > > > > > > However, this directory and the README are not installed using > > > > 2.5.5-I602. > > > > > > > > This could be due to recent changes. > > > > > > > > -- > > > > > > > > > > > -BEGIN PGP SIGNATURE- > > Version: ProtonMail > > > > wsBzBAEBCAAGBQJiujWDACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec > > 9muQuJ2LYAf/Vh4nss7ejL0d+H6gCyxryTURfwoCPL60mfdqXYWuXIBHN19c > > rB5lMr3oa9yzx3MU4ga6zBQzbXlwEw3F7wGVokqNDP1u+BSzjQIIYZsC2QBD > > wdQMa2wdAIOpwwUml3DIyuz68vFmotXYp37DcafHt/tgTyWLNcaXrLSopM7K > > ICwjKFrJ0Wd3Fz9eqMMBMeOimYFCMlqNbYqUWur3Ve9GNMuaou6pURo0X0+e > > Gqmxo7QoGDPVYR59NXL2LQTO8mCAVRkd/9oAUbmpP7d/XuKMBPoPo/gcChx6 > > k1NGhNQR8DqsyK8vA/xFCIiBhg78NfgZMY2qk0Iq4heyGi+z5KZc0A== > > =2LbF > > -----END PGP SIGNATURE- > > ___ > > Openvpn-users mailing list > > openvpn-us...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/openvpn-users -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJiuy/qACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ0E5ggArCAVCZwbhBOt6w+JsZj76USHN7enjWo0OG24qB+BzfOjhZOx r14C1jCZmGydSS7MIjgYy0Toj3Al7N+6ZUwFwzm8h13x23KQIkyAd2lG2kIs zxMRooKIpMmoE/HYF88RCSM5whsJjPVcHJ6VV8tkNnibCnUcTj5h4Mog6TRQ EXv622Hen23tGjWUWU8GV2qXk/PRuDF31VEhs0+nQ7DitVolZe2NMawPdtVl W0Z7KBuW2c7R5TjCqWeOAzjSqSocoF/SOAY19kSTDqN2zhvsyM1DOlUgI7UC 15elTAQj2Y9H/Jp8o2mlf93rCOS5f6uRhyQ8NYYp7wc4JB00gURl/w== =7ZIh -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
[Openvpn-devel] New option --suppress-auth-cache-warning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ref: https://forums.openvpn.net/viewtopic.php?t=34461 Food for thought.. R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJiv25tACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3+uQf8C4svn9uGUDXcjPAohtlnw0/w3WjQI1yY3cHjGTro6KhEJpmB G5og6sOD5jyT3f0wYy3sRaYxEpcA5+DR2XWKLrwtRJNfPPdAhJjs6nX8iI+e /aHvInARZ7ua8QUx07y60JLy+cXThZWWhX4KrAFCV45DQEZaHA/qYAenLL3X VcofwBNl2lXf9tr96wU8dcp3ntH0HOkB9wa1E6GpN8wyI36ZcLcx0niZUFBw 4tKa75Mix4dPEd6Oxnh0mnDD0dVSfaV9mJTL86JwtYwnCUG9dLaj2dps2alt edpjMtYwTSiQPZi5YBxqc1ICoMzNyuZxEQOb4/bGCj3DJCioYy8r1A== =AASZ -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
Re: [Openvpn-devel] Possible bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Magnus, can you report this as an issue on github, please ? https://github.com/OpenVPN/easy-rsa/issues My first guess would be the version of openssl 3.0.1 is at fault. Thanks, Richard Sent with Proton Mail secure email. --- Original Message --- On Thursday, August 18th, 2022 at 02:37, Magnus Larsson via Openvpn-devel wrote: > Hi, > I just moved from Ubuntu 20.04 LTS (where the exact command works fine and > does not prompt for pass phrase) to Red Hat Enterprise Linux 9 and installed > Easy-RSA via EPEL. > > When I run ./easyrsa build-ca nopass as root, it still prompts for PEM pass > phrase: > > > # ./easyrsa build-ca nopass > Using SSL: openssl OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec > 2021) > Enter PEM pass phrase: > Enter PEM pass phrase: > Enter PEM pass phrase: > Enter PEM pass phrase: > 80DB8DBF7D7F:error:0480006D:PEM routines:PEM_def_callback:problems > getting password:crypto/pem/pem_lib.c:62: > 80DB8DBF7D7F:error:07880109:common libcrypto > routines:do_ui_passphrase:interrupted or cancelled:crypto/passphrase.c:175: > 80DB8DBF7D7F:error:1C80009F:Provider routines:p8info_to_encp8:unable to > get passphrase:providers/implementations/encode_decode/encode_key2any.c:116: > > > > > # ./easyrsa --version > EasyRSA Version Information > Version: 3.0.8 > Generated: Wed Sep 9 15:59:45 CDT 2020 > SSL Lib: OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021) > Git Commit: f12e00e53b4f486ce3d119ca429198780fa694ac > Source Repo: https://github.com/OpenVPN/easy-rsa > > > > > # ls -l > total 8 > lrwxrwxrwx 1 root root 29 Aug 17 18:56 easyrsa -> > /usr/share/easy-rsa/3/easyrsa > lrwxrwxrwx 1 root root 41 Aug 17 18:56 openssl-easyrsa.cnf -> > /usr/share/easy-rsa/3/openssl-easyrsa.cnf > drwx-- 9 root root 4096 Aug 17 20:10 pki > -rw-r--r-- 1 root root 332 Aug 17 18:56 vars > lrwxrwxrwx 1 root root 36 Aug 17 18:56 vars.example -> > /usr/share/doc/easy-rsa/vars.example > lrwxrwxrwx 1 root root 32 Aug 17 18:56 x509-types -> > /usr/share/easy-rsa/3/x509-types > > > > > # cat /etc/os-release > NAME="Red Hat Enterprise Linux" > VERSION="9.0 (Plow)" > ID="rhel" > ID_LIKE="fedora" > VERSION_ID="9.0" > PLATFORM_ID="platform:el9" > PRETTY_NAME="Red Hat Enterprise Linux 9.0 (Plow)" > ANSI_COLOR="0;31" > LOGO="fedora-logo-icon" > CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos" > HOME_URL="https://www.redhat.com/"; > DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/9/"; > BUG_REPORT_URL="https://bugzilla.redhat.com/"; > > > REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9" > REDHAT_BUGZILLA_PRODUCT_VERSION=9.0 > REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux" > REDHAT_SUPPORT_PRODUCT_VERSION="9.0" > > > > > # dnf repolist > Updating Subscription Management repositories. > repo id > repo name > codeready-builder-for-rhel-9-x86_64-rpms > Red Hat CodeReady Linux Builder for RHEL 9 x86_64 (RPMs) > epel > Extra Packages for Enterprise Linux 9 - x86_64 > rhel-9-for-x86_64-appstream-rpms > Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs) > rhel-9-for-x86_64-baseos-rpms > Red Hat Enterprise Linux 9 for x86_64 - BaseOS (RPMs) > > > > > # getenforce > Disabled > > > > > # uname -a > Linux test 5.14.0-70.22.1.el9_0.x86_64 #1 SMP PREEMPT Tue Aug 2 10:02:12 EDT > 2022 x86_64 x86_64 x86_64 GNU/Linux > > > > Let me know if you need additional information. > > Thanks, > Magnus > -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJi/gHXACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3FpAf9FRWGhWLwzc8ONkqdMM0yts3GHGMhQ6ZqzILJjLh4Udgn5NlI IV7InwTHZZm7IE6q4IWhzSqGA/KjIc23Xydsz29Vh0BDoDDZemeXkjYdxCQd gRDIMuzMLTqCQIoI9FqeWKKQW9r5cG9qwIpUwiBh2BUmub2D0hb7P0SVEWur +moGPLU1neXIhlL2F6hbTqtl/wNxr2V5qLfODrRJpiEyKQNa1C8GvvqXJR2r BYRA2vyoFIGn+krBMBb2lcExGhioWr4gzecFolqOin9e/i3pCCii1Xl4/XI5 BqHP31VoNmc88CLmOhSn/At3kagcnou9WDsA8DbJabW1/MPeGjKpXQ== =ukTL -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
Re: [Openvpn-devel] [PATCH v5 2/3] Allow setting control channel packet size with max-packet-size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Plus one more typo. Sent with Proton Mail secure email. --- Original Message --- On Thursday, October 20th, 2022 at 11:05, Arne Schwabe wrote: > diff --git a/src/openvpn/common.h b/src/openvpn/common.h > index b94680885..dce6fd01d 100644 > --- a/src/openvpn/common.h > +++ b/src/openvpn/common.h > @@ -68,6 +68,19 @@ typedef unsigned long ptr_type; > / > #define TLS_CHANNEL_BUF_SIZE 2048 > > +/ TLS control buffer minimum size. This size is not actually inherent to > + * the OpenVPN protocol. But with our current sending window being 6 and the > + * receive window being 8 or 12 depending on the OpenVPN version, the biggest > + * payload we can send is 6 * min_size. And we need to support to send > payloads > + * of TLS_CHANNEL_BUF_SIZE. Splitting this into more than > + * 6 packets (with overhead) would complicate our sending logic a lot more. > + * Diving TLS_CHANNEL_BUF_SIZE (2048) by 6 gets us ~342 byte. Allowing for Diving -> Dividing > + * ~100 bytes of overhead (in OpenVPN headers + IP headers) and rounding > + * up to the next "nice" number gives use 512. > + * > + * / -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJjUS1fACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2mxAf/afXklJAMoPqLoelxi8mF7hq97b3Eky6iB+zqiGXhOxBjVOKC F6BpNk2uxCUkNSU9FPaLDTMurKuGe6p5+YSdHQh13EzZkx/vehBce4/+OWZ5 nInvafaUbtAI0LqHZvcNhjB2LQcci2MUyw6duok1V43LRdYFZ0ohk4/o+HZ7 6vrij4xNLO1BHhc91CKS0Gm9ZierXPHS8vmAc6ssrhhhq8eFetVq58S7dhyQ ISx8xg20MnqjynmDjpOVgbxKW00+OBTK5NWGLEXd5effQjgdz4qEv5MBoS4V sNdvCBw4tU/GrZdYlBihcQf2h6tgGJ0DxEu4qiF0Tg1h81rrEHSahw== =8tPU -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
Re: [Openvpn-devel] OpenVPN 2.6.0 released
Hi, So download link in Forum Announcement should be corrected? https://forums.openvpn.net/viewtopic.php?t=35260 Sent with Proton Mail secure email. --- Original Message --- On Friday, January 27th, 2023 at 01:53, David Sommerseth wrote: > On 25/01/2023 20:50, Frank Lichtenheld wrote: > [...snip...] > > > On Red Hat derivatives we recommend using the Fedora Copr repository. > > > > https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release/ > > > > A slight update here. The repo above will be preserved for OpenVPN 2.5 > releases. A new repository for OpenVPN 2.6 has been published: > > https://copr.fedorainfracloud.org/coprs/dsommers/openvpn-release-2.6/ > > > > -- > kind regards, > > David Sommerseth > OpenVPN Inc > > > > > ___ > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] IRC community meeting summary (Feb 14th)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On Wednesday, 14 February 2024 at 15:22, Frank Lichtenheld wrote: > Meeting summary for 14 February 2024: > * New: Easy-rsa in Windows installers > easy-rsa has included pre-built Windows binaries for a long time. But with > Windows 11 they do not seem to work correctly anymore in some cases. Just to clarify: Easy-RSA works perfectly as-is on W10 & W11 but requires Windows Admin access. Without Windows Admin Access, Easy-RSA on W11 does not work with the now 10 year old MKSH:sh.exe This is annoying but it isn't a complete deal-breaker. Regards tct -- -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAnBYJlzPXJCZBPl5z2a5C4nRYhBAm8PURno41yecVVVU+XnPZr kLidAAC+Cwf+P7EBDJirKoBXV/SsOrzfNfFSR2hVOCqSN9jwFs+TIv/kD+UN eOT87L5EW3x/EpF0hRyNy0g83ePdR1ESN4C4mP1Jm9QJZzKgXX44uO4XH5C3 4FXWj/06vQRoaTO5Lk8Y+caLFn9kmpq57JCkorPOI3RjDIwcJcgZ66FweAY2 prSSCj33fzuGoJMWfdXfF4pEu55cV1Iawar2acYJOLlpn0NTFNtyqzVoC8lv k5FDHjzFuTooBvJ4g2hR8KDctaS/3tTjk4c3ZsVr+0F9n2SwsMmHz93YfONX iuvLv/vxGMrWViXv9gbYJMqqfagamWn7SZivlkFp/YxSBg+3vSPo1w== =+izN -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
Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 2 April 2021 19:35, Simon Matter wrote: > > Commit 8fa8a17528c001a introduces "compress migrate" to move old clients > > that have "compress" or "comp-lzo" in their config towards a connection > > without compression. This is done by looking at incoming OCC strings > > to see if the client has compression enabled, and at incoming IV_ > > strings to see whether it can do "compress stub-v2" or needs to be sent > > "comp-lzo no". > > Hi, > > What I'm still wondering is why is compression so dangerous with OpenVPN > but not so with things like SSH or SCP? > Simon, I believe the detail which you have over-looked is this: A lot of people use openvpn as a client to VPN service providers believing things which are not true. They then surf the web with over-confidence. In such a scenario, while pulling off such an attack on a compressed VPN stream may seem remote, when you have such a vast number of victims to potentially abuse, the temptation to do so and potential success rate increase dramatically. But i believe you need to have access to both the compressed VPN data and the uncompressed https packets to exploit such an attack. Still, it was shown to be a genuine attack vector none-the-less. -- Regards R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgZ7oZACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2Qzwf9GFUFmJrJv4ny2uvbLUWKHAGsFKsD12I5YeJLQArsAsP39w7k H4chac7T/XLA2nBYLxIizioc3fiFqPTrlyx2AdwIuTpWhqf4FuU+pXt9JhqJ spI6j907aSN/G1jDjWhzltrWrjhJg/a6VQvtuTzAcBx3h1AA3WwKvRCUVhm6 r0/jqRpb5OhA05Ux6JG0uqlCfG5zTURSaFdjwhEotvHpuzg9IpzEIBx42dnU EgS+aoJPdxYSCldYbdwj9EWus1+MzNHd+JjZsxadqiGarC+I+r5q2fHC9bBA EPdlbWGIdPcASeB0edWSI9uOO18UBpuaOnU4aBN/SXQJE4wApq1wUQ== =LhbH -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
Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, 3 April 2021 01:43, tincantech via Openvpn-devel wrote: > > But i believe you need to have access to both the compressed VPN data > and the uncompressed https packets to exploit such an attack. > Edit: The attacker also needs to control the https website that the victim visits. It's a tall order .. but do you really want to argue with the sort of people that figured out how to do it ? > Still, it was shown to be a genuine attack vector none-the-less. > -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgZ7usACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3yaAgAvefAvhIBj2izSl5JoOH2oPeCYunedXsrFOXjrvteC1GX/Hem gRpLgcjNjdhcWdfW8NCFhihozr1Hrb9cLIxmvNLw5zmAIf6DRtcPPaExsyYJ mDLXMFlKZmSoGc3Jh9hsXxFy5oEH2K2RtQxJevGciAHn6GSkPx0MrHLJlmCH EPhUThW+QpEq+NdqNUo9dPJe9ByUUrZ9c/eySjXG8Eo7hYSLu0AhoYUr/zY1 OqpRNg3lsH6CRFkH7LV5cJEBGLF6qZLeAZ5x7UYGjWWR1pwI02AKknF5E9bW s+4P64TLyIVerUsewJ9EbzU4kI5abf+pammwmqBHFrPaI1foNUS/dA== =s7Ma -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
Re: [Openvpn-devel] [PATCH v2] Remove P2MP mode and check for gettimeofday
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, 3 April 2021 19:46, Arne Schwabe wrote: > Using OpenVPN without P2MP support (pull, TLS) is unrealistic and > building a binary without it is not something we realistically want > to support anyway. Building P2MP support now only depends on > HAVE_GETTIMEOFDAY or win32, which has a compat function for it. > > This also removes the ENABLE_SHAPER and TIME_BACKTRACK_PROTECTION > defines, which also depend only on the HAVE_GETTIMEOFDAY or WIN32. Is this the end of --shaper option ? -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgaMHkACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1nmwf/efDZ8L/Py44AKHZJ90OE3WA8T16qmzbMZpScnCc3iL65QLJF vU/VU/xg636f53OKBav09SXAEhnLvcA3gGdiPb/1e9M/Y/tU6Q9nZknCRcKe 8DwNreop4+YsDY4FI9KeLS6Mnm97DhXS0ErEwgw1Wut0meGHdcKDK6wghOgW DbKsBrXZzEBN7MkmpTbzK9rYBAuGJYjWQL6sG+7ClC9wCN2Jms/SBWq92QpF ZuXecVbUp7tWa3EqxGkAnvg7CMQHwA9XmemzBAX+6EzTMTT90KTJvu88rH9H SeKcJVE1RH2Jf0XaGuqn2ZcrHWGm9R+O6SCsrsRch6Y2stgT9AaTpQ== =zXFm -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
Re: [Openvpn-devel] [PATCH 11/14] Remove P2MP mode and check for gettimeofday
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Before this goes any further, I doubt very much that Openvpn intends to "Remove P2MP mode". Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, 1 April 2021 18:27, Arne Schwabe wrote: > Am 01.04.21 um 15:13 schrieb Arne Schwabe: > > > Using OpenVPN without P2MP support (pull, TLS) is unrealistic and > > building a binary without it is not something we realistically want > > to support anyway. > > > } > > > > > > - /* Check if we have forbidding options in the current mode */ > > - if (dco_enabled( &mi->context.options) > > Ignore this patch for now. Rebasing worked without conflicts but somehow > still pull dco bits into it (rebase is sometimes magic ) > > Arne > > Openvpn-devel mailing list > Openvpn-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openvpn-devel -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgaNsSACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2xqwf9EbssBV+0gW+/y0bIR+3I7DFZouZTRcO+9SCftHO6AcfTBgaD Uro0ZmOa233PaGSB3B5MbJcZQ0gnIWegVeGjN0khVOU75fv332svNc2CLZtn JHwG3XYnHWxMMVaRWkcyPp72UUfxiaooZp1FjPAnhl6D/PUAxw2tU3Cl6dp1 rgHmWhNKza2B8PzhnSZ8K0RiTjdOy3bYLSdj6hKwyQkvG1+wEGpG0qJSEnKF 1Qb2qpPNftG1BfOkTQ3QVuBcpDDusR1ip+qs9LmLo87LKD2UF8DWgZlj5Ev8 pdu8+cp7Fk7G2UrLWbKy7fTPcfncaViiNEHNbm9EMtURCioaLsQwoA== =Cr8U -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
Re: [Openvpn-devel] [PATCH 2/3] Remove --ncp-disable option
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Friday, 9 April 2021 10:53, Arne Schwabe wrote: > > I am not sure how you came to that conclusion. I have written a fairly > comprehensible documentation how NCP in 2.5 works for our manpage: > https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst > > That should also answer your question. > sorry for the noise but I created a quick ref. guide for cipher negotiation: https://community.openvpn.net/openvpn/wiki/CipherNegotiation It may be of some value to others reading this thread. Regards R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgcES+ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2TPAgAuSyk329uuzmDecw9kvFBa/UDQ2C8U4ZVwXZZKXk4AL5NtM9Q Nbsi6qHMPT/WYfgVMOPbJLvWgUx2yi51rPawis5itd4Ghe7nZtBQOdjz1LZY /5VfqgOIMtfvovL+Wlg1SpwPM5Mo/ApILcec4jfrP5XJxe/6Xo8Mx4ZcYLq7 EmjVZ3gFWSX3kmBTdtQmPRKZ6qTe3gezwduZ667eRy58kK39SRFX2tsjvFT+ 2D8mtkLIQvJNDbO1KHNmW4oXxcu7YesQScAshOBpIutyU0vUyg37fp+SoTcs Q4oS2Wp2T2HZlPMkvBopbiddk6Wu1+kaP0+jDiBllSkZRrcrwCRtsQ== =8Qly -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
Re: [Openvpn-devel] make --persist-key always-on and remove "off" code path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Friday, 9 April 2021 17:28, Gert Doering wrote: > I do not use --persist-key, but I still restart my services after fiddling > with configs... > Same. To add weight here, I would estimate 95%+ of all posts on the forum, which include a config file, have --persist-key enabled, regardless. Regards R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgcIRiACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2w0wgAv4Yv3T+4nsxYxocmBdlAGzZAuOOYsg6d9wWyHavY3YXCNWSh CN+8Fi4ruR3iaeEnVa98RlV/SvLkns5cyRRr2XEG/OMOthc4237o33W8BrRX 8zYkxezaYSGWB7Q8KJmyHFnAc3njrVdXRN2INMbZyn9dHUOSIYD8ZUmntxPR +ftK2/idc9ftk1wVqBL5oIngCaFCm1Y/lfG76Ae6GTAha3pEqwh0qj573IC3 Mgyu5JYCCjbYWcojM2nilOWCDPaWPQaasVmLe9Pu31yUCWbTLy4Y/nZuwLpA cSWUV9E+rqQ+C4ZObxx4MJhVPJfVmKWJtZsbN5vF6OELD/w/iQ0Sgw== =qukX -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
[Openvpn-devel] --tls-crypt-v2-verify env $daemon_pid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 hi, I am requesting that $daemon_pid be added to the --tls-crypt-v2-verify environment. FTR: $daemon_pid is currently undocumented in all three manuals. Thanks. R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJggeRlACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3+LQgAxSKGYd1ubfyiSdl4VMNrp+y97t03OLVhBntuUiYHTZUaQlKi 33oQRxNY+ELuZUpK4ueMgeUPvG20kAB5zfpyT6imsYrze3hlbd9G6omflByh f0sAovrDSiegF8adNgdKCsGi8co7z2B3Ec0WWRnGLPPcZHQzIo8MlspYJ50l uf6EdEDZL96VQYHNDJ/RH6egj1+WZww+qk/VJsuiBTyxf/KlRNVbrC24/iM1 gHS/3HqDvwgX675vIIDlB2ZzF0QiHCPZWYlWbPAU2GqEqpzN/qn7EDuPfrFB IY/g8y9+qH+AZmD7byeRSeLSiira84oBWX6OwGJOrmLPsam9ZVTmRg== =+Hpt -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
Re: [Openvpn-devel] --tls-crypt-v2-verify env $daemon_pid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Friday, 23 April 2021 07:13, Gert Doering wrote: > Hi, > > On Thu, Apr 22, 2021 at 09:02:30PM +, tincantech via Openvpn-devel wrote: > > > I am requesting that $daemon_pid be added to the --tls-crypt-v2-verify > > environment. > > What for? Easy-TLS - I'll explain in more detail sometime .. > > > FTR: $daemon_pid is currently undocumented in all three manuals. > > It seems to be an obscure and not very useful feature. > > "Programs that are called from OpenVPN" can find the OpenVPN pid trivially > by calling getppid() (or $PPID in shell). Unfortunately, in Windows $PPID carries the PID of sh.exe being executed. This use case is making Linux sh scripts usable in Windows. Thanks for the PPID tip, R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJggwdgACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ0dVQf+MUWXJy3VToFwmmAsS2ILKvoec8eZH2fjDftQGZoOBDSa68Jp o2vryOtdfxxCVyXDt3O7Wjb4CkkWJM3dlf7hZEYCw47D4++BY0UzhfFRwt2o cTS7RmdqOK9OUPstTzPl6+Nydsn3uNLq/0mNgsshaTq8PoKrBhoya73VNU9d M4vdLF8d89EKaphRFArcTXgWKU363ZvmsrS90onXTNpu1wUY162yFlip5P8j swB4Ziq4+7mRzg+n6QomlForwYP30BnHo+Iaob/snCF+8UJJzWTQCvfsrAjF PCZYEumWvIRQ31a4AuQ2eTAyWzD1xHSBJez5uvmdZI2JKT1G/hcyUw== =dqrf -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
Re: [Openvpn-devel] --tls-crypt-v2-verify env $daemon_pid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Friday, 23 April 2021 13:22, Antonio Quartulli 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+XnPZrkLidFiEE
Re: [Openvpn-devel] --tls-crypt-v2-verify env $daemon_pid
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Friday, 23 April 2021 08:12, Antonio Quartulli 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. > > 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 would also quote that old, old expression "Security through Obscurity" https://en.wikipedia.org/wiki/Security_through_obscurity > > > FTR: $daemon_pid is currently undocumented in all three manuals. > > It'd be nice to have such documentation added :-) I hope that your not suggesting that I provide documentation for something which you then refuse to allow me to use ? ;-) Not only but also, "you give a little, you get a little" :D In conclusion, I request that OpenVPN review their earlier decision to be so *cruelly frugal* to --tls-crypt-v2-verify, on this one occasion. Thanks for your informed and collective consideration, R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJggrqWACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1ZWwgAkgKYkbfa04CCrqu2pVYxYnt4bcRCvMV7qI8RM37PliG8b2Bx 6qDPMUAZ1DwIL59WKYahtKOIVcp5gLXLoAlrfJy+FMRfJodnGT3iPz3no+Ew HWTsiwTXjUozGnD3fIviVfzbcXIb082WRzKP1/IpAtTztnBv6Aq6i5vLb/mJ Ghh/YJIDsaV012dz8qLX9oVbmd8SycfyhKa8E1IwlpkbHsJlqUYo/rxOeXTY 1q4J07aNk1bwPAQU0bWbxf04ItLqeAnoWESnaTc6gWz4fXaRM3XiMuUDFzFl 6FFRQeGkrJAdY2N/ZdAwcNSY3PDkFmu5MPBoaw6lmeBMMoFxG4S/kg== =ZBp4 -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
[Openvpn-devel] [openvpn-devel] Feature request - Include daemon_pid in --tls-crypt-v2-verify env - V2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I am requesting that daemon_pid be added to --tls-crypt-v2-verify env. Version 2 Justification: With the notable exception of --tls-crypt-v2-verify .. daemon_pid provides a verified process ID to All scripts. This ensures that scripts which are intended to pass data along to the following scripts have an index to which they can link that data. Example: An example is presented in Easy-TLS: https://github.com/TinCanTech/easy-tls This script passes hardware address from --tls-crypt-v2 key metadata along to --client-connect, where the pushed client variable IV_HWADDR can be matched against the fixed hardware address encrypted in the TLS Crypt V2 key metadata. Security: There are no known security concerns with regard to including the openvpn process ID (daemon_pid) in the --tls-crypt-v2-verify environment. Complexity: Ongoing support of the required code would be minimal to zero. Code: This patch is included for review purposes only. diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c index 7b5016d3..23d93a6c 100644 --- a/src/openvpn/tls_crypt.c +++ b/src/openvpn/tls_crypt.c @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx *ctx, setenv_str(es, "script_type", "tls-crypt-v2-verify"); setenv_str(es, "metadata_type", metadata_type_str); setenv_str(es, "metadata_file", tmp_file); + setenv_int(es, "daemon_pid", platform_getpid()); struct argv argv = argv_new(); argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); Conclusion: Due to the OS in use and other environmental factors, the *nix built-in variable PPID may not always be available. Without including $daemon_pid in the --tls-crypt-v2-verify environment, openvpn is forcing the user to unnecessarily configure --writepid. The purpose of --writepid is to advertise the openvpn process ID to external processes which do not have access to the internals of openvpn. By including daemon_pid in the --tls-crypt-v2-verify environment all processes launched by openvpn have access to this very useful identifier. Provided there are no genuine reasons to NAK this request, I will send a correctly formatted patch. Addendum: I know this is something which helps me in the short term and I already have a working alternative but I would like you to reconsider your previous decision. In my opinion All scripts launched by openvpn should have immediate access to daemon_pid. Thank you for your time and consideration, R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJggzkmACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ0nVggAkf9tcCo7onTYoZ4WetX/6uePD2QzEYd8rHYbn1q6R8JvOqMi JrDIRIYZw06v/r4pyzq8tYUvS+1VBY9cPIm+v3uudOhZ/WUlyGw180u2tA+w eX+bx/AwA5FC4QGqgJlTEx9G5s0H5Ge2vSd1ChA52VjC5QZeorI/42nZpG2I Gg7vC0JH9rr9LqAzVNH9YfWff7vNKvXAPdmL9/itf3Eq6uFytGsD77KjZaq7 RESDSO2cOnCyoVyktPhw64d77q6bCgFtl08CVQYJOTwg07cY+ZEWa3wRCEAb bcDj6eDNDHy8e9iMzie3yrIgZsRDCbGiXCyaLk2abZtpFsqX7rP6jA== =z4PC -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
Re: [Openvpn-devel] [openvpn-devel] Feature request - Include daemon_pid in --tls-crypt-v2-verify env - V2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, no complaints yet ? Sent with ProtonMail Secure Email. ProtonMail, as crap as googlemail. ‐‐‐ Original Message ‐‐‐ On Friday, 23 April 2021 22:16, tincantech via Openvpn-devel wrote: > Hi, > > I am requesting that daemon_pid be added to --tls-crypt-v2-verify env. > Version 2 > > Justification: > > With the notable exception of --tls-crypt-v2-verify .. > daemon_pid provides a verified process ID to All scripts. This ensures > that scripts which are intended to pass data along to the following scripts > have an index to which they can link that data. > > Example: > > An example is presented in Easy-TLS: > https://github.com/TinCanTech/easy-tls > > This script passes hardware address from --tls-crypt-v2 key metadata along > to --client-connect, where the pushed client variable IV_HWADDR can be > matched against the fixed hardware address encrypted in the TLS Crypt V2 > key metadata. > > Security: > > There are no known security concerns with regard to including the openvpn > process ID (daemon_pid) in the --tls-crypt-v2-verify environment. > > Complexity: > > Ongoing support of the required code would be minimal to zero. > > Code: > > This patch is included for review purposes only. > > > diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c > index 7b5016d3..23d93a6c 100644 > --- a/src/openvpn/tls_crypt.c > +++ b/src/openvpn/tls_crypt.c > @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx > *ctx, > setenv_str(es, "script_type", "tls-crypt-v2-verify"); > setenv_str(es, "metadata_type", metadata_type_str); > setenv_str(es, "metadata_file", tmp_file); > + setenv_int(es, "daemon_pid", platform_getpid()); > > struct argv argv = argv_new(); > argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); > > > > Conclusion: > > Due to the OS in use and other environmental factors, the *nix built-in > variable PPID > may not always be available. Without including $daemon_pid in the > --tls-crypt-v2-verify > environment, openvpn is forcing the user to unnecessarily configure > --writepid. > > The purpose of --writepid is to advertise the openvpn process ID to external > processes > which do not have access to the internals of openvpn. By including daemon_pid > in the --tls-crypt-v2-verify environment all processes launched by openvpn > have access > to this very useful identifier. > > Provided there are no genuine reasons to NAK this request, I will send a > correctly > formatted patch. > > Addendum: > > I know this is something which helps me in the short term and I already have > a working > alternative but I would like you to reconsider your previous decision. In my > opinion All > scripts launched by openvpn should have immediate access to daemon_pid. > > Thank you for your time and consideration, > R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgiMIMACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2yHAf/VwSjdR6F5GQy7rfJLKkP+sbGgL1kgKPsB7bgiiSV47+GTg0J lftyAS6lxyKhJ+7Xt+xm45janjMxnsxXrzIYjJdlfQSPMEfFOn9Uw17ohW0x bO52oTqCqoR5Y/UhqlLQ+lpgUMJJalfWZtJ3uiQ1GfloJk9oKjJ1thmdnmQ+ 048pGsBf2iRnvPJEDqJ/JxoKttvEAHQhVp3wI2aO70JzYujsuq5E6gnQsAT+ roDB8W2HRt5Ycbl+Y9lnzPM4HUk+W67j0+Af6Jf0mrfuK2IC2EFRBTkaVM5C F9QICvlZ/wB9oaH4/OXfp1DXAHBHh2wf0Bw6Rxcsyg3ni8Ro0ARdsw== =TmRk -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
[Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify script environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Openvpn process ID (daemon_pid) provides the most secure way for scripts to verify which process they were called by. This patch adds daemon_poid to --tls-crypt-v2-verify environment. Tested on Linux and Windows. diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c index 7b5016d3..23d93a6c 100644 --- a/src/openvpn/tls_crypt.c +++ b/src/openvpn/tls_crypt.c @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx *ctx, setenv_str(es, "script_type", "tls-crypt-v2-verify"); setenv_str(es, "metadata_type", metadata_type_str); setenv_str(es, "metadata_file", tmp_file); +setenv_int(es, "daemon_pid", platform_getpid()); struct argv argv = argv_new(); argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); -- git version 2.25.1 I hope my MTA has not mangled this patch but I don't currently have access to an SMTP server port. If it is borken then please ignore this and I'll find another way. Feel free to send other feedback. eg: NAK + Reason. Thanks R # -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgiZ8TACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3KTAf+OfRyvNNBqDTulTPHsULxhehPve6mgqsoovqlYomkFnIu20CJ 497Yiqno7Nz49Wy2Ka5nu88sTptp0CdFg6QE2yytol1H8D0vFYwNwyIIS9eq d8pPa/sI0ga8DHSF5QjbvsTJusPolIjR4H7yXPFjrqMXlXYdRgof6IT+P3+G b/ev08nhPSjS0ZlciAPymW1wL5zsttDxSWU8vy/T6NYoq+QTaNfYgqNjlW8M BR48OSAc1aTPBzHeYW8MxOkm3Si9u2qS+hSSMgT0yS8EnvpCZn0vw+tOQ2Ey WR7RmdyoQRsJYANnlY4Pqe+c3h4tuWBK9UCJRnpgz/ytIog8V1VBjg== =iX52 -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify script environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Yeah, I forgot to apply and commit -- sorry. I guess I'll send again if this is an acceptable patch and my MTA didn't screw it up ? Please let me know .. thanks ‐‐‐ Original Message ‐‐‐ On Wednesday, 28 April 2021 18:44, tincantech wrote: > Openvpn process ID (daemon_pid) provides the most secure way for > scripts to verify which process they were called by. > > This patch adds daemon_poid to --tls-crypt-v2-verify environment. > > Tested on Linux and Windows. > > diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c > index 7b5016d3..23d93a6c 100644 > --- a/src/openvpn/tls_crypt.c > +++ b/src/openvpn/tls_crypt.c > @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx > *ctx, > setenv_str(es, "script_type", "tls-crypt-v2-verify"); > setenv_str(es, "metadata_type", metadata_type_str); > setenv_str(es, "metadata_file", tmp_file); > > - setenv_int(es, "daemon_pid", platform_getpid()); > > struct argv argv = argv_new(); > argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); > > > -- > > git version 2.25.1 > > I hope my MTA has not mangled this patch but I don't currently have access > to an SMTP server port. If it is borken then please ignore this and I'll find > another way. Feel free to send other feedback. eg: NAK + Reason. > > Thanks > R > > == -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgiZ/PACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3hPwgAk3GKzcr76rPTac1/6NMQyP3wnWpXgsmbGCvr5zVcQRbAaSbL FwN+qB01aXx8ic7u1t9xoBA83WA5BOy/Nmecg/MmTK2hWapL954b2dEHubFt j9b1wqXX46Mcg55VSvSC2gc35bZB2wXLiKIAOGFgvmH84m18CCDSePaKywrf izC5B+Ew+M6zacf1IZU64DKJdLX8yzyQt9U3zI1egFj9mK7qzm3lY79zier0 jkDQlijZrp6krAeBqlGmm1sMLERyQrCrJrCdbuEbrMbVPxbJOhYFpT8EWolE ta/OTF94IK2T8ErmNZsA3oSdXSuYriZM6gSxKqiMpSXuNjo3wKzrkg== =57ff -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify script environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Looking closer, I can see that it was damaged in transit .. Please let me know if you would be willing to accept my proposed patch and then I will persist to find a way. If you will not accept the addition then please let me know. Thanks R ‐‐‐ Original Message ‐‐‐ On Wednesday, 28 April 2021 18:48, tincantech via Openvpn-devel wrote: > Yeah, I forgot to apply and commit -- sorry. > > I guess I'll send again if this is an acceptable patch and my MTA didn't > screw it up ? > Please let me know .. thanks > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, 28 April 2021 18:44, tincantech tincant...@protonmail.com wrote: > > > Openvpn process ID (daemon_pid) provides the most secure way for > > scripts to verify which process they were called by. > > This patch adds daemon_poid to --tls-crypt-v2-verify environment. > > Tested on Linux and Windows. > > diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c > > index 7b5016d3..23d93a6c 100644 > > --- a/src/openvpn/tls_crypt.c > > +++ b/src/openvpn/tls_crypt.c > > @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx > > *ctx, > > setenv_str(es, "script_type", "tls-crypt-v2-verify"); > > setenv_str(es, "metadata_type", metadata_type_str); > > setenv_str(es, "metadata_file", tmp_file); > > > > - setenv_int(es, "daemon_pid", platform_getpid()); > > struct argv argv = argv_new(); > > argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); > > > > > > -- > > git version 2.25.1 > > I hope my MTA has not mangled this patch but I don't currently have access > > to an SMTP server port. If it is borken then please ignore this and I'll > > find > > another way. Feel free to send other feedback. eg: NAK + Reason. > > Thanks > > R > > == -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgiaNiACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2FZwf/VduCykdRxUIXhDX1+owQ1wKB02tuhj/0ABu0GpK9VvyZCOx4 0BKCaZB6VPWhV4sop4AAfm24LeyT80aST/W+PQ2N5bnfHvC5/Lm6anB+ck38 K/6JkehHkyvuVdR1K2LiKdgtW9gAggdPYSn4WbKSlv+Q2HthmVZlg7/ADrZk RsRE6HYO/mNkTaLsuzkWczyH1z6ncAqg8ivZxcnOBfrjSRNJJMHsAzWzT7J7 eitX50FT387SSbiBgP2PiVUnm5XIO/rT/yJhHTM9p8wISzzOfW/5hUovMnvx wP4er/eYwp1/JbErVDbzlpT0r33MQADbVQAxKJpg4l9m0GIzmlHGIw== =0azE -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify script environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not a single comment ? Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Wednesday, 28 April 2021 19:03, tincantech wrote: > Looking closer, I can see that it was damaged in transit .. > > Please let me know if you would be willing to accept my proposed patch and > then I will persist to find a way. > > If you will not accept the addition then please let me know. > > Thanks > R > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, 28 April 2021 18:48, tincantech via Openvpn-devel > openvpn-devel@lists.sourceforge.net wrote: > > > Yeah, I forgot to apply and commit -- sorry. > > I guess I'll send again if this is an acceptable patch and my MTA didn't > > screw it up ? > > Please let me know .. thanks > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, 28 April 2021 18:44, tincantech tincant...@protonmail.com > > wrote: > > > > > Openvpn process ID (daemon_pid) provides the most secure way for > > > scripts to verify which process they were called by. > > > This patch adds daemon_poid to --tls-crypt-v2-verify environment. > > > Tested on Linux and Windows. > > > diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c > > > index 7b5016d3..23d93a6c 100644 > > > --- a/src/openvpn/tls_crypt.c > > > +++ b/src/openvpn/tls_crypt.c > > > @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct > > > tls_wrap_ctx *ctx, > > > setenv_str(es, "script_type", "tls-crypt-v2-verify"); > > > setenv_str(es, "metadata_type", metadata_type_str); > > > setenv_str(es, "metadata_file", tmp_file); > > > > > > - setenv_int(es, "daemon_pid", platform_getpid()); > > > struct argv argv = argv_new(); > > > argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); > > > > > > > > > -- > > > git version 2.25.1 > > > I hope my MTA has not mangled this patch but I don't currently have access > > > to an SMTP server port. If it is borken then please ignore this and I'll > > > find > > > another way. Feel free to send other feedback. eg: NAK + Reason. > > > Thanks > > > R > > > > > > = -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgipHgACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ064ggAifsuMtavQAW7fBTiMjr/587lEwrO7CMFJOEhIexbeJN2tl1G tbDG5NSIRxM9Vle2rvpybaStga3Fst9Q6Gi7EDIwVFBfSNWjSeogwA30N35f T0KRWCbveSjiKRsyTS7p9zEv1Dvms0iRX0G+NClsbIJr7Fn7gUtSS2ztvj60 KfXeH1dkv1Q7EJPLC0H7zKcoEagFrYb0bNtG3g7uca5Yb7sEyetA3rKX02Z/ JpqeZN3nZe4Fvx19YOnrc+dZPtKpshws7swg7KQOz07GEEXMXe5BBjgWqQlz RTcHefU8fLaMklprpLsuOvMnOgVwQ0fwbV22IBAT4g7d5++CxCvBSQ== =ReR6 -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
[Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Under Windows, programmatically retrieving the parent process ID of the openvpn instance which called a script is practically impossible. The only sensible way, currently available, is to write a PID file. This patch adds a single integer variable, named daemon_pid, to the script environment. The value of which is set to the openvpn process ID that called the script. Providing this variable via the running openvpn process is more secure, faster and far less prone to user-error than using a PID file. Signed-off-by: Richard T Bonhomme tincant...@protonmail.com src/openvpn/tls_crypt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c index 7b5016d3..23d93a6c 100644 --- a/src/openvpn/tls_crypt.c +++ b/src/openvpn/tls_crypt.c @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx *ctx, setenv_str(es, "script_type", "tls-crypt-v2-verify"); setenv_str(es, "metadata_type", metadata_type_str); setenv_str(es, "metadata_file", tmp_file); - setenv_int(es, "daemon_pid", platform_getpid()); struct argv argv = argv_new(); argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); -- 2.25.1 -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgitDzACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3tigf9GP21RvAuybG60NgMaC5t9LIyjlBjaNOcWjLgbCUh7KhFSPMu 6r48YAsdy2PB7vd753GhjoQbQuM8+JhS0+fXBIgtToOxMOSGJoSJLu0RoYL3 ScRLXgx2M0p5wbQdHD9tx3ZsVXKyLPTwRWg3w3V7viIJ2A9tmiAUuX4YflJ+ hyfhp1sT648Hb2PW3eIBvEMZNOGG9Et/jS833/Yk5WRn8Wee/nPASOYYbHGf amX51gbevtmJy67Dti0ibUNomf9uYFd95ojG9qdqJDDQaff76nbda/bRX38g SUu50B2mNpS/sHeirUAKCpuzmMxqpLl9NOxS4m3SFLk+sfeDgSJRSA== =6a1K -END PGP SIGNATURE- From 91baf93e62db2ed063a8c4cfdf5b6ff750ac6103 Mon Sep 17 00:00:00 2001 From: Richard T Bonhomme Date: Thu, 29 Apr 2021 16:17:06 +0100 Subject: [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment Under Windows, programmatically retrieving the parent process ID of the openvpn instance which called a script is practically impossible. The only sensible way, currently available, is to write a PID file. This patch adds a single integer variable, named daemon_pid, to the script environment. The value of which is set to the openvpn process ID that called the script. Providing this variable via the running openvpn process is more secure, faster and far less prone to user-error than using a PID file. Signed-off-by: Richard T Bonhomme --- src/openvpn/tls_crypt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c index 7b5016d3..23d93a6c 100644 --- a/src/openvpn/tls_crypt.c +++ b/src/openvpn/tls_crypt.c @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx *ctx, setenv_str(es, "script_type", "tls-crypt-v2-verify"); setenv_str(es, "metadata_type", metadata_type_str); setenv_str(es, "metadata_file", tmp_file); +setenv_int(es, "daemon_pid", platform_getpid()); struct argv argv = argv_new(); argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); -- 2.25.1 0001-Add-daemon_pid-to-tls-crypt-v2-verify-environment.patch.sig Description: 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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 ‐‐‐ Original Message ‐‐‐ On Thursday, 29 April 2021 18:15, Richard T Bonhomme wrote: > From: string vest stringves...@gmail.com > > Under Windows, programmatically retrieving the parent process ID of > the openvpn instance which called a script is practically impossible. > The only sensible way, currently available, is to write a PID file. > > This patch adds a single integer variable, named daemon_pid, to the > script environment. The value of which is set to the openvpn process > ID that called the script. > > Providing this variable via the running openvpn process is more secure, > faster and far less prone to user-error than using a PID file. > > Signed-off-by: Richard T Bonhomme tincant...@protonmail.com > > src/openvpn/tls_crypt.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c > index 7b5016d3..23d93a6c 100644 > --- a/src/openvpn/tls_crypt.c > +++ b/src/openvpn/tls_crypt.c > @@ -537,6 +537,7 @@ tls_crypt_v2_verify_metadata(const struct tls_wrap_ctx > *ctx, > setenv_str(es, "script_type", "tls-crypt-v2-verify"); > setenv_str(es, "metadata_type", metadata_type_str); > setenv_str(es, "metadata_file", tmp_file); > > - setenv_int(es, "daemon_pid", platform_getpid()); > > struct argv argv = argv_new(); > argv_parse_cmd(&argv, opt->tls_crypt_v2_verify_script); > > > -- > 2.25.1 Bump. -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgkDFOACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1Wywf/bDBG1X2K9a5NfjvSb5X2npD8VOq4d66Dy8uwDnhCkJoT5exm MFRhaLYhQXXK22GVSqX/n7aNDly6HveyMRkuUzoDnKNMhxJ9NUfgwCpgc+Ap 5nJtYfss13mcaHQzwP1CPuQWpjupKQ4nAi+OWT3tPBhc0zkKq8O/VXOjff8g KSE3WMlwCHrrXqZ5XV4Y8FqyeN0mqkVnhKfJy0UxKR1zh+E+a70cCT1mUR0x mlBAXMDoS/p+EoIW6PqJNt+4qgzSQbH8b77XmAkR1eR9LS4GoZG1OHYkwQiW e8SRm6tKLpjTIw9Ob9HTIoIt9kSjFfRVgBVyM37s2KSyeYG0YjPTAg== =DN5K -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
‐‐‐ Original Message ‐‐‐
On Tuesday, 4 May 2021 11:50, Arne Schwabe wrote:
> Am 29.04.21 um 19:15 schrieb Richard T Bonhomme:
>
> > From: string vest stringves...@gmail.com
> > Under Windows, programmatically retrieving the parent process ID of
> > the openvpn instance which called a script is practically impossible.
> > The only sensible way, currently available, is to write a PID file.
> > This patch adds a single integer variable, named daemon_pid, to the
> > script environment. The value of which is set to the openvpn process
> > ID that called the script.
> > Providing this variable via the running openvpn process is more secure,
> > faster and far less prone to user-error than using a PID file.
>
> Could you explain why you need the process ID of the daemon? I am trying
> to figure out why that is needed. I also don't understand the secure in
> this context. What are you protecting yourself against? You are not
> protecting your script being called from a malicious program as that
> could lookup the PID of openvpn and just set the daemon_id variable.
>
The reason I am using the process ID is as follows:
When --tls-crypt-v2-verify is executed, it saves a file named:
$(certificate_serial_number}.${daemon_pid}
with data from the TLS-Crypt-V2 key metadata field, which can then
be read by the following scripts: --tls-verify and --client-connect.
The --tls-verify and --client-connect script have:
$(certificate_serial_number} -> ${tls_serial_hex_0} and ${daemon_pid},
in their environment and can guarantee to pick-up the correct data file.
This is OK for one running server but when there are more than one server
instance running, using a PID file becomes messy and cumbersome.
The "secure" in this sense is that, having openvpn provide the PID is much
more reliable than relying on multiple PID files.
Also, while it is "trivial" for *nix to retrieve the Parent PID, under
Windows, programmatically doing this is not "trivial" at all:
PID:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/finding-the-process-id
PPID:
https://stackoverflow.com/questions/7486717/finding-parent-process-id-on-windows
Therefore, barring any known security reasons for not providing the openvpn PID
to all scripts which it executes, it makes more sense to have openvpn provide
daemon_pid. The only script currently missing this data is
--tls-crypt-v2-verify
(And probably --learn-address but I have not tested that).
Thanks
R
-BEGIN PGP SIGNATURE-
Version: ProtonMail
wsBzBAEBCAAGBQJgkUFuACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ0Zcgf+MpbxgsNS/eKpPsbafA5Qmdotc1HoQuxp+4mlw+Fr7uGxJT1y
cIAf5akt6ox+y/c0tOdFAPvczNirZh0j598TISFXbQtdEFG+budjBXK6peTc
ZKTlxvUSzZNterBcnjmCYYsQBxUdWrsH65cb23nvJ6G9m3dgkAPnt8w8NLe/
Z4/xHAElwU1kOoyGcpG4DMVQM55ikvXSmdDQx6BU8ksUueBHR4m3mMtkjFgq
krvjr+ycEZNcOX5601dOgNZS0AIT8TFvdFPEvMIXrSKJsmXtFLIXhLckM+3v
cUoV65+V3nQpdkJGumWHvCA1HB9nCSh75R8MdlD4mc0efaM2IiElog==
=KHtU
-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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
‐‐‐ Original Message ‐‐‐
On Tuesday, 4 May 2021 13:43, tincantech via Openvpn-devel
wrote:
> Hi,
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, 4 May 2021 11:50, Arne Schwabe a...@rfc2549.org wrote:
>
> > Am 29.04.21 um 19:15 schrieb Richard T Bonhomme:
> >
> > > From: string vest stringves...@gmail.com
> > > Under Windows, programmatically retrieving the parent process ID of
> > > the openvpn instance which called a script is practically impossible.
> > > The only sensible way, currently available, is to write a PID file.
> > > This patch adds a single integer variable, named daemon_pid, to the
> > > script environment. The value of which is set to the openvpn process
> > > ID that called the script.
> > > Providing this variable via the running openvpn process is more secure,
> > > faster and far less prone to user-error than using a PID file.
> >
> > Could you explain why you need the process ID of the daemon? I am trying
> > to figure out why that is needed. I also don't understand the secure in
> > this context. What are you protecting yourself against? You are not
> > protecting your script being called from a malicious program as that
> > could lookup the PID of openvpn and just set the daemon_id variable.
>
> The reason I am using the process ID is as follows:
>
> When --tls-crypt-v2-verify is executed, it saves a file named:
> $(certificate_serial_number}.${daemon_pid}
> with data from the TLS-Crypt-V2 key metadata field, which can then
> be read by the following scripts: --tls-verify and --client-connect.
>
> The --tls-verify and --client-connect script have:
> $(certificate_serial_number} -> ${tls_serial_hex_0} and ${daemon_pid},
> in their environment and can guarantee to pick-up the correct data file.
>
> This is OK for one running server but when there are more than one server
> instance running, using a PID file becomes messy and cumbersome.
>
> The "secure" in this sense is that, having openvpn provide the PID is much
> more reliable than relying on multiple PID files.
>
> Also, while it is "trivial" for *nix to retrieve the Parent PID, under
> Windows, programmatically doing this is not "trivial" at all:
>
> PID:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/finding-the-process-id
> PPID:
> https://stackoverflow.com/questions/7486717/finding-parent-process-id-on-windows
>
> Therefore, barring any known security reasons for not providing the openvpn
> PID
> to all scripts which it executes, it makes more sense to have openvpn provide
> daemon_pid. The only script currently missing this data is
> --tls-crypt-v2-verify
> (And probably --learn-address but I have not tested that).
>
Due to the inordinate resistance this patch has received, consider this my
official
withdrawal. I hereby NACK.
Thanks
R
-BEGIN PGP SIGNATURE-
Version: ProtonMail
wsBzBAEBCAAGBQJgkZoxACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ1HTQf7BSnvVR9LHZTcPyn+1oHv71TOxIMuFqckmxmQk/PZDSU+yq0h
OdjDWjSLLW/ZbQwS3Zcs09h50GEWBtUM5xoghAsBtUpGLCDMtvbU37JI/mMu
IfSI04+afMqi3xSsu1N4NMlAhVJTg2u0wfB6i46/Ltf/gLr9a0w3IAR7z1l4
Ykaxl5pBkNTZjuT6AtSVuVv8VUmr5+xQGWaUAxfPLIHeNeZGfCR7iJWd2L6L
zcnM8j3lLfzz1Tx2Ry3asVU40G6kp826F2LvuBH2mSZQeFENR/74HtAG0yY9
GcZg17oMkgBUmOZJzYupgrRwU1LFRGUIgk9ygS3Ew96M13C4lV90Sw==
=9B+C
-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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Tuesday, 4 May 2021 20:41, Selva Nair wrote: > On Tue, May 4, 2021 at 3:04 PM tincantech via Openvpn-devel > openvpn-devel@lists.sourceforge.net wrote: > > > Due to the inordinate resistance this patch has received, consider this my > > official > > withdrawal. I hereby NACK. > > Resistance is a good thing -- it means people are considering your > patch seriously and are asking questions in earnest. > > I've had patches that languished for years and finally merged, > without batting an eye.. Except for an occasional gentle nudge (say > once a year), and some patience. Selva, thanks for your guidance. On this occasion I have been pushed to find a better way. Thanks to Gert for reminding me about PPID and pushing my code a little further, I now realise that I don't need daemon_pid from openvpn directly. Withdrawing this patch seems the most appropriate way to minimize the time wasted. Sometimes it's difficult to see your own mistakes but realisation is satisfying if and when you do "break on through" ;-) R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgkbBPACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ0MYwgAuFchojIT/cnf0yppB9o/WxJRZHdFaEn9jyRO+PgMYNrAJeet QUqaCbUPZ0N5UdXnwuf5DTMYcStQpDyKnQyeB/dw0r23fmlSV69U1Vdx64+x kjfbxl3h3miJ5yRu62YnmSCtqtiC/ErrJ1bz68RglI/aeGD4g6nPkpoHhZ/O ix1zPxOpV+fnjEZtZfRCzNah+wa1vWyxF/UFpbIUe/pME6Y1pCGf4ZWGPFG8 qVdxSU/GwMMIaQn+Kz+iwoZDzhbkkprHGwS/yvJkEBIXOf8SspnlOOH0gJ6J yFvxCBmaLeFUDoHhOy9JdL5toUN6hCtwu1wKPnUC3xN0IypeGdHtrQ== =a9Jn -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, 4 May 2021 21:36, tincantech via Openvpn-devel wrote: > Hi, > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, 4 May 2021 20:41, Selva Nair selva.n...@gmail.com wrote: > > > On Tue, May 4, 2021 at 3:04 PM tincantech via Openvpn-devel > > openvpn-devel@lists.sourceforge.net wrote: > > > > > > Due to the inordinate resistance this patch has received, consider this > > > my official > > > withdrawal. I hereby NACK. > > > > Resistance is a good thing -- it means people are considering your > > patch seriously and are asking questions in earnest. And this resistance was indeed not futile. I have discovered a flaw in my logic, which is so insidious, that it may bring my entire house of cards down .. I just F000M'^~,.ed myself .. arse! -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgkcFnACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3msAgAsoR4DghKD6z/et3JYXabmsGny+5/hu48E1FMXGUH5cB/cWpM 5P+KL3Kr3D7MkemqbHvvapQQKn0DCA+Kt056fqQI8h9fc8vhJKLYAxFD4M8E b60H8+/K5bSwUxVkH4X6jW8m/HJ16q8fBrTSRDbZeJ4x1u1u0uxTk84WVhW2 gjued3xLGhPlkBlufYayr6LytUXN5wDEJSKLgjeROl04NlvTlDc1VCu+QREw KnqXh1JBg9Lqo5ctmNtV6QZ8R5nx9G3cNqJ0joRQfN329H1Bp30S6iyvkBMV /7pgCyKQ1X38D5rXNcRL/4qP0YfcSkQ43zb2dur9LtQ/wFqepKwr4Q== =IcL9 -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
‐‐‐ Original Message ‐‐‐
On Wednesday, 5 May 2021 08:51, Arne Schwabe wrote:
> > > Could you explain why you need the process ID of the daemon? I am trying
> > > to figure out why that is needed. I also don't understand the secure in
> > > this context. What are you protecting yourself against? You are not
> > > protecting your script being called from a malicious program as that
> > > could lookup the PID of openvpn and just set the daemon_id variable.
> >
> > The reason I am using the process ID is as follows:
> > When --tls-crypt-v2-verify is executed, it saves a file named:
> > $(certificate_serial_number}.${daemon_pid}
> > with data from the TLS-Crypt-V2 key metadata field, which can then
> > be read by the following scripts: --tls-verify and --client-connect.
>
> I can get behind the need of needing something daemon specific when
> running multiple daemon that scripts/plugins need something simple to
> identify a specific daemon. With management and a persistent connection
> that is easier to implicitly assign an ID but for scripts daemon_pid
> seems to be a good fit.
>
> So if we make that a bit clear in the commit message this gets an ACK
> from me.
>
Arne,
thanks for the feedback, I can resubmit with an improved commit message
and corrected email if required.
Thanks
R
-BEGIN PGP SIGNATURE-
Version: ProtonMail
wsBzBAEBCAAGBQJgkxVyACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ0PGggAtMnaL8kv8Z2xGvqMkSr+TO7kHLWl2OoYP+o+S18NpUpQrLn1
1Yr0t2ZHjdho30l24iMsKGYAgtPwXfmNgNI+tjhb2p7URRNgkfaDDDUiTePL
hfnZnjLdmjlCIurKNnCqFsVKj92C2jQbicLcCH+504a0TeTLGmWaCYQ3/QiE
2I5CUJErNmjXrBRTeS5hB7FLSbYzbAs1AC5dU7uGSxjnhPrT1tx7An/GNAc6
HJMMBhF1if98jvPRntG6zXLTC4nIFPEM73m9oyWyrwXPql0lD8hZJ08OnpxI
YyfsH3KEFc3f6st2pmAen8o31zuDxARpYdhusqiLzqWW0WbCj1lt7A==
=ClM7
-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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Monday, 10 May 2021 18:29, Gert Doering wrote: > Hi, > > On Wed, May 05, 2021 at 10:00:37PM +, tincantech via Openvpn-devel wrote: > > > thanks for the feedback, I can resubmit with an improved commit message > > and corrected email if required. > > This is how I understand Arne - he's happy with the code change, just > wants the commit message to explain a bit better why this is relevant. > > So, there is an ACK-and-merge pending :-) > well, personally.. it's complicated.. 1. Antonio's initial reluctance. I do not believe it would be prudent to continue without his opinion. 2. Replacement method. This is no longer required. (Thanks given to Gert for PPID) 3. Work Rewriting the commit message to suit, plus resubmitting as a V2 .. and .. then jumping through googles and gits hoops is not at the top of my list. 4. Having my user account _recently_ locked out of Trac. I expect that I can even ''predict'' what that is with regard to. ... For the time being, I suggest that TLS-Crypt-V2 code be left as-is, because TLS-Crypt-V2 *has* more important issues to consider.. I would list the trac issue but #4 The impasse has been met, R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgmZY5ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1sMggAnsGf77yUfrERZRY67k3zTPqRuXuVegRKSzyAlumJXaMSyY81 JMD1m3s5vQSE2EyH/b+3U0jlZIlnKTRVvLE/YJYKiEEFNm0LuWy1dc7jpdwo vWeGI3O442zngXzk4SRnHRNP1e11jwPtlh3zZevlMHMwgzpKE+xkpT+9ySIP bGNyHO25odJy4lqwpvF54C2IL9Pokh5u3/Ij7vdESE/X+WLkS/I2nPJFMkLj ls4Hdyxfhyh/ekiVPDEkyioAEG00FqVsVYvZrMpsbu2wmwP6eX8Jk1jJVZ1i FRyEaUVJaxzmCr1pqt8Nzu46uL4Pt3xdenxOo6O09SZzCNaPqYcsIQ== =dlZP -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, > 4. Having my user account recently locked out of Trac. > > I expect that I can even ''predict'' what that is with regard to. > > ... > Seems I typed my ludicrously long password incorrectly.. The rest still stands. Sorry for the noise, R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgma0dACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3aSggAs9IxRPp2KmNfmP8o16gHzMA1X7MpncTWmWHRsVsrAv7daAbg LUX310MIqsz1tOb+dG7TqHiXjfhO7VH5L7DJfjm/zRdVIWyHBtYM3CBeleq+ zsHwOYF1k8pyRPMmOIc+mYPpXuk3hb9xvNBvLpdEBsJI7HYE9JTfaLAJNaOi zoIWHUtcG6sc6pP0as0EDoT1kKhN0j0j/BWkxIvNMOENGCTPyHn4MX0aFmdp Hpzva/0zHIbd5MFnDMH3v20thBOp3EhOaBxD0uXn3S4J0NxzNXeOtHaoQSFF W9zefCIUEFxiP7yxae644Cw9FLqjSD+uRyAeJb9YkPwXVxNWJdVzrw== =NgsE -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Monday, 10 May 2021 23:10, Selva Nair wrote: > On Mon, May 10, 2021 at 4:24 PM tincantech via Openvpn-devel > openvpn-devel@lists.sourceforge.net wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > Hi, > > ‐‐‐ Original Message ‐‐‐ > > On Monday, 10 May 2021 18:29, Gert Doering g...@greenie.muc.de wrote: > > > > > Hi, > > > On Wed, May 05, 2021 at 10:00:37PM +, tincantech via Openvpn-devel > > > wrote: > > > > > > > thanks for the feedback, I can resubmit with an improved commit message > > > > and corrected email if required. > > > > > > This is how I understand Arne - he's happy with the code change, just > > > wants the commit message to explain a bit better why this is relevant. > > > So, there is an ACK-and-merge pending :-) > > > > well, personally.. it's complicated.. > > I think it's a good thing to pass daemon_pid to all scripts uniformly. > Can't think of any downside. And, on Windows it's a pain to get the > parent pid from a batch file. Personally, I do not have a use case > though. > > Selva Trac in question: https://community.openvpn.net/openvpn/ticket/1310 -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgmbIfACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2QrQgAoH7L8LCDvs8Tp9mj/VVR/aolKox2hHQJqfEcZXsEfKySmFUC 8oDFY9bnlOiGg1LhEaLIITXkYlW2aTB11Sm1DE/hYy1MK/IxByzwRa1AJyCk 6TJtmoiMl7Inwxz6z/IOCpSDCdOR+/i+BXaXx8pJujn7omr9Vprgkku78I6s 2unDfIycBWwMD78pCULJvqnOPzCM5TkA82x6WdcpJykLaeOOX+do7CrkNmxC s9Hfl7duiqGgSCLAZOZv71CwvyoJYorHpO6yhB+UxikhszFANXRCEU4AXoqR jRL8yH7ouz92mR9vospC39lwAMJGthBQ85l8Sj5ngaiVrvBj3qfh6g== =WQSw -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
Re: [Openvpn-devel] [PATCH] Add daemon_pid to --tls-crypt-v2-verify environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, 11 May 2021 07:02, Gert Doering wrote: > Hi, > > On Mon, May 10, 2021 at 06:10:33PM -0400, Selva Nair wrote: > > > > > So, there is an ACK-and-merge pending :-) > > [..] > > > I think it's a good thing to pass daemon_pid to all scripts uniformly. > > Can't think of any downside. And, on Windows it's a pain to get the > > parent pid from a batch file. Personally, I do not have a use case > > though. > > This was about the thoughts Arne and I had - if we have daemon_pid in > some places, we should have it in all places. And, on Windows it's not > as trivial as on Unix... > > (Out of interest: is there a way at all to get the ppid from a batch file?) > This is what I found for PID/PPID in batch: PID: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/finding-the-process-id PPID: https://stackoverflow.com/questions/7486717/finding-parent-process-id-on-windows Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgmmV+ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ0BCgf9Ffzik7MJhQtRjPBc2L/ZCpcQxLJJTHSB9c//g0YetY2/hEyG ReuEW9G7AnSoZTPep8Xt502rPJZtyxut3kmY79J9Pt/NTD7siV4+f4ZUg24V lPDqWpsVhqD0EeeiPqWa/6OhZWmgT4qXMnYyPznCHdzYlcjYAZARJB4EWeE6 baf6RQFfJ1cjhNY07jaeMJi3SW72J5RjdlLFPfKITfrPgIuzFhFc6rvmyplU Sz41k1Bd1QprZwIGE7JiZDLajOmYkmGUaqXQ6AoLWmTZJACNFDKyQZYXs7lY wwoROF6u14vxLh2TeQ1btfuxnGUs2HhpqZX80TrxAm80EQyBrnJ5bA== =17mP -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I was in the process of reviewing this patch when I found that protonmail had changed most of the git '+' to '-', see below. I have reported a bug to protonmail. Anyway, I can see a few typos and some other odd errors. Hopefully, protonmail will have a solution, or maybe someone here knows what I can do/try ? Finally, I wrote a simple script which generates self-signed certs, keys and inlines the fingerprint for use with Openvpn. https://github.com/TinCanTech/easy-pfp I hope it is of some use in the future. Thanks R ‐‐‐ Original Message ‐‐‐ On Wednesday, 12 May 2021 14:15, Arne Schwabe wrote: > This is meant to give new users a quickstart for a useable OpenVPN > setup. Our own documentation is lacking in this regard and many often > tutorials that can be found online are often questionable in some > aspects. > > Linking the invidiaul RST file on github also give a tutorial > in a nicely formatted way. > > Signed-off-by: Arne Schwabe a...@rfc2549.org > > Changes.rst | 4 + > doc/Makefile.am | 1 + > doc/man-sections/example-fingerprint.rst | 194 +++ > 3 files changed, 199 insertions(+) > create mode 100644 doc/man-sections/example-fingerprint.rst > > diff --git a/Changes.rst b/Changes.rst > index 9185b55f7..f1c739f99 100644 > --- a/Changes.rst > +++ b/Changes.rst > @@ -25,6 +25,10 @@ Certificate pinning/verify peer fingerprint > fingerprint of the peer. The option takes use a number of allowed > SHA256 certificate fingerprints. > > - See the man page section "Small OpenVPN setup with peer-fingerprint" > - for a tutorial how to use this feature. This is also available online > - under > https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst > - > > TLS mode with self-signed certificates > When `--peer-fingerprint` is used, the `--ca` and `--capath` option > become optional. This allows for small OpenVPN setups without setting up > diff --git a/doc/Makefile.am b/doc/Makefile.am > index e411f5f9d..e7022c085 100644 > --- a/doc/Makefile.am > +++ b/doc/Makefile.am > @@ -25,6 +25,7 @@ dist_noinst_DATA = \ > man-sections/connection-profiles.rst \ > man-sections/encryption-options.rst \ > man-sections/examples.rst \ > > - man-sections/examples.rst \ > man-sections/generic-options.rst \ > man-sections/inline-files.rst \ > man-sections/link-options.rst \ > diff --git a/doc/man-sections/example-fingerprint.rst > b/doc/man-sections/example-fingerprint.rst > new file mode 100644 > index 0..7d915aedb > --- /dev/null > +++ b/doc/man-sections/example-fingerprint.rst > @@ -0,0 +1,194 @@ > +Small OpenVPN setup with peer-fingerprint > += > +This section consists of instructions how to build a small OpenVPN setup > with the > +:code:`peer-fingerprint` option. This setup has the advantage to be easy > to setup > +and should for most small lab and home setups without the need to setup > a PKI. > +For bigger scale setup setting up a PKI (e.g. via easy-rsa) is still > recommended. > > - > > +Both server and client configuration can of course be further modified to > individualise the > +setup. > + > +Server setup > + > +1. Install openvpn > + > > - Compile from source-code (see `INSTALL` file) or install via a > distribution (apt/yum/ports) > - or via installer (Windows). > - > > +2. Generate a self-signed certificate for the server: > > - :: > - > - openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout > serverkey.pem -out server.pem -nodes -sha256 -days 3650 -subj '/CN=server' > - > > +3. Generate SHA256 fingerprint of the server certificate > + > > - Use the OpenSSL command line utility to view the fingerprint of just > - created certificate: > - :: > - > - openssl x509 -fingerprint -sha256 -in styx-win.pem -noout server.pem > - > - This output something similar to: > - :: > - > - SHA256 > Fingerprint=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff > > > - > - > > +3. Write a server configuration (`server.conf`): > +:: > + > > - The server certificate we created in step 1 > > > > - cert server.pem > > - key serverkey.pem > > - > - dh none > > - dev tun > > - > - Listen on IPv6+IPv4 simultaneously > > === > > - proto udp6 > > - > - The ip addre
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I used sed to create my own reply .. comments inline. ‐‐‐ Original Message ‐‐‐ On Wednesday, 12 May 2021 14:15, Arne Schwabe wrote: > This is meant to give new users a quickstart for a useable OpenVPN > setup. Our own documentation is lacking in this regard and many often > tutorials that can be found online are often questionable in some > aspects. > > Linking the invidiaul RST file on github also give a tutorial invidiaul -> individual > in a nicely formatted way. > > Signed-off-by: Arne Schwabe > --- > Changes.rst | 4 + > doc/Makefile.am | 1 + > doc/man-sections/example-fingerprint.rst | 194 +++ > 3 files changed, 199 insertions(+) > create mode 100644 doc/man-sections/example-fingerprint.rst > > diff --git a/Changes.rst b/Changes.rst > index 9185b55f7..f1c739f99 100644 > --- a/Changes.rst > +++ b/Changes.rst > @@ -25,6 +25,10 @@ Certificate pinning/verify peer fingerprint > fingerprint of the peer. The option takes use a number of allowed > SHA256 certificate fingerprints. > > +See the man page section "Small OpenVPN setup with peer-fingerprint" > +for a tutorial how to use this feature. This is also available online tutorial how -> tutorial on how (just reads better) > +under > https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst > + > TLS mode with self-signed certificates > When ``--peer-fingerprint`` is used, the ``--ca`` and ``--capath`` option > become optional. This allows for small OpenVPN setups without setting up > diff --git a/doc/Makefile.am b/doc/Makefile.am > index e411f5f9d..e7022c085 100644 > --- a/doc/Makefile.am > +++ b/doc/Makefile.am > @@ -25,6 +25,7 @@ dist_noinst_DATA = \ > man-sections/connection-profiles.rst \ > man-sections/encryption-options.rst \ > man-sections/examples.rst \ > + man-sections/examples.rst \ > man-sections/generic-options.rst \ > man-sections/inline-files.rst \ > man-sections/link-options.rst \ > diff --git a/doc/man-sections/example-fingerprint.rst > b/doc/man-sections/example-fingerprint.rst > new file mode 100644 > index 0..7d915aedb > --- /dev/null > +++ b/doc/man-sections/example-fingerprint.rst > @@ -0,0 +1,194 @@ > +Small OpenVPN setup with peer-fingerprint > += > +This section consists of instructions how to build a small OpenVPN setup > with the > +:code:`peer-fingerprint` option. Reword suggestion: This setup has the advantage to be easy to setup > +and should for most small lab and home setups without the need to setup a > PKI. Using Peer-fingerprint mode has the advantage of being easy to setup without the need for a PKI. It is suitable for most small lab and home setups. > +For bigger scale setup setting up a PKI (e.g. via easy-rsa) is still > recommended. > + > +Both server and client configuration can of course be further modified to > individualise the > +setup. individualise ? - This word is odd .. how about customise ? > + > +Server setup > + > +1. Install openvpn > + > + Compile from source-code (see `INSTALL` file) or install via a > distribution (apt/yum/ports) > + or via installer (Windows). > + > +2. Generate a self-signed certificate for the server: > + :: > + > +openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout > serverkey.pem -out server.pem -nodes -sha256 -days 3650 -subj '/CN=server' Why not using .key and .crt as is the custom when files are created by Easy-RSA ? Also, it is simpler to understand what the file type is .. > + > +3. Generate SHA256 fingerprint of the server certificate > + > + Use the OpenSSL command line utility to view the fingerprint of just > + created certificate: > + :: > + > +openssl x509 -fingerprint -sha256 -in styx-win.pem -noout server.pem Why stix-win .. would it not be more suitable to use consistent names of files ? Also, this command is incorrect, the server.pem causes openssl error: x509: Unknown parameter server.pem > + > + This output something similar to: > + :: > + > + SHA256 > Fingerprint=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff > + > + > +3. Write a server configuration (`server.conf`): > +:: > + > +# The server certificate we created in step 1 > +cert server.pem > +key serverkey.pem > + > +dh none > +dev tun > + > +# Listen on IPv6+IPv4 simultaneously > +proto u
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, missed one.. ‐‐‐ Original Message ‐‐‐ On Thursday, 13 May 2021 22:48, tincantech via Openvpn-devel wrote: > Hi, > > I used sed to create my own reply .. > > comments inline. > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, 12 May 2021 14:15, Arne Schwabe a...@rfc2549.org wrote: > > > This is meant to give new users a quickstart for a useable OpenVPN > > setup. Our own documentation is lacking in this regard and many often > > tutorials that can be found online are often questionable in some > > aspects. many often tutorials -> many tutorials (extra 'often') -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgnaAYACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ0jjwgAygbBIeAgigR5msWnDad8NZboh62d7CDlMMEJGQBm5AU54R28 IYQInLl4LoRx4oFiMQ6aDUzSbkc3dHwnPIDxhEJkh+Js36GOEOBEaOlnPCSq lZQEX0l3scOuBdgSXpqYQkysOySnyqxbiTPR+dVZ1h5PsFTMsSFSD/w93n5y v+pNi4zXy5fae07dJeQCRCermE+FeRwK8jdGVpUS6awE2q87pcZ7rAF6E13s T7WCEkvZt0baK/gInoa5Yv7EcodtJX02uL+A+zfLltg7rgZgrB+Fv7ld3LHo X1dHTBDBhCrGANJP/rRwL/D+zzrqCAdR+onSqaH6esaa/nfAAi2Asw== =LDsm -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
[Openvpn-devel] Feature request - Allow comments inside markers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I think it would useful to allow comment inside the markers. EG: # alice 67:1F:A5:CA:26:98:BA:40:D9:EB:6A:5B:C1:64:8C:8E:66:6E:7A:22:26:73:96:6A:5E:9B:B3:17:8F:F8:C6:9C # bob 55:B6:3F:AD:BC:A0:8C:EF:00:B3:2F:A5:46:46:83:82:6F:34:86:8D:23:2B:AC:79:39:E2:26:0B:FC:1A:86:38 Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgooRFACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2Gxwf+MZsFJKL83UScncpqzPDid2nJnp685JBqS42dmE+XPADUrinU ymZA000r8Q4aqgU/1Ml5TAkFT9yAVUEJK4HJVLenpyL2lP3y2Fel7Wy66caZ K+zUyX82JpBVSyh6O5DwoaEnKG5Er86So4bVrfFvEgYv6xO5eWHaEWfQPwTD 6zw6k5OimLaj+KTPaoL0rDuEt0uTyhAcWFkHmkzskNtNaowNo/u3P5zfT49o ct/9/GpDUx0nY0D6MfM88SIYjcegoaCdVdY0OHIer2sxoRCnDk4r6jgdOj1I 67B/HdKHXSng6sJfRp2teyxFp6+mCsqDdtOjTotZv7rT5+xDA6EGlw== =5Phv -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
Re: [Openvpn-devel] Feature request - Allow comments inside markers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Monday, 17 May 2021 16:31, Gert Doering wrote: > Hi, > > On Mon, May 17, 2021 at 02:57:32PM +, tincantech via Openvpn-devel wrote: > > > I think it would useful to allow comment inside the > > markers. > > I've run across this as well, and share that sentiment. It would be nice. > > That said, I'm not sure how easy it is to implement (the inline-config > parser is used for all inline stuff, not only for peer-fingerprint). > > > As a workaround, you can put "per user" peer-fingerprint lines into the > config: > > the config option - and the inline block - can appear multiple times. > Ah nice, I should have thought of that myself ! I can't think of any other reason to allow comments in other inline sections and your work around is perfectly suitable for small setups, consider this resolved. Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgoo8lACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ36hQf+Iv76yenMrNbvyi32egQsvjGnIEEHekVr1YLjkm935asSF9NW 7Pe0XsGhcbcVgupPPhYo+KsfX0wnAEmVClDSn6r2jZQ9r5/DFoBHP2fst7UA qPZs5EgLXcaNiBLI3gY6yxaxxrqCiAb4LEoHxdaO4sWGoYUnZxly3H/dkLgE NEdxTarhBYPd0Rr5hg0pXIsz+RTGo/Eb/fzqRN7HzZdgk3isVPhtzm0a3tJM YhPpa8KOuRh23u5/gVtLsGtKP3uyIA51RD22tv+NC6QOoV32+bvIbaXS+NfN tX2sfax7F/Tmhv6EhSWoUSe9GktQyczWGjAQF5Ajv9JkT4j1bTrgig== =Ur8w -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Wednesday, 12 May 2021 14:15, Arne Schwabe wrote: > This is meant to give new users a quickstart for a useable OpenVPN > setup. Our own documentation is lacking in this regard and many often > tutorials that can be found online are often questionable in some > aspects. > I believe Openvpn in standard mode (Full PKI) would reject an expired client certificate. Note: There is absolutely nothing in the manual to confirm this ! https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html On that page there are eight uses of the word 'expire' and they all relate to an expired auth-token, this could also probably be improved. However, Openvpn in peer-fingerprint mode allows an expired client certificate to connect. The client log *does* have a 'WARNING: Your certificate has expired!' The server log has nothing about an expired client certificate. And, as we all know, _who reads their log files_ anyway ? The issue here is that the server allows an expired client certificate to connect and there is no mention of this change in behaviour. Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgoqTPACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ18DQgAiFbKtIV3YXi4YG3qiN429AsLyGd8FR+ysy09aNB/FM9p/70E FgobM0x2waAWILLaNOgG/u3B8ocHa6ld0s2h0fJ7ef7FAdo4SRYbosyQFq+Q gcv5Z8AzivkOVbK2d9kP9T9HWd4BVOtduHKg/u/pwwQD7GUB4mM9HrztTzy8 X+oG6197ZZnA9jLUE+wxShttgXf1PP9q39r7gJ798kt1P0zDrtN4gjSTLp5v JwdyxMLHnD5YdwqsW31Zu3AnYP+s12xXfq8dZtAP0JaY/qYt/FqU6t+3hNOB PLtXCdmr53wPdrkyUOHnzLcOoF2S3M9pDLZW1/JSowginVfUpRpUWQ== =kmta -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Monday, 17 May 2021 18:16, tincantech via Openvpn-devel wrote: > Hi, > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, 12 May 2021 14:15, Arne Schwabe a...@rfc2549.org wrote: > > > This is meant to give new users a quickstart for a useable OpenVPN > > setup. Our own documentation is lacking in this regard and many often > > tutorials that can be found online are often questionable in some > > aspects. I think it is also worth noting that, in it's current form, the documentation given does not provide for a --remote-cert-tls solution. I may be able to help with that but prefer to log it here first. Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgor7wACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3g5wf9EXijgq5+j38umqKpdwIeQQ1F78OeEPMi8/LAxyrGZlSJNvr+ 9OIDwj9ZBE1SOY80f2AGR5tXE7Czl1VT0S+CPcrVnaKadR5dfNB3HpVShOWY sFPvmjzY++U0Jmw6/vsV09SCigBv85DU2s+VYmwoBwgq08vc28WvKXPY6DJl PxmePhpVbsV/5uZAw+3MismpvPvw7hzDmEEKtZLeqduLFGx9l0D7Apeq+d1Q 4348BdmeZFaIjk6sKBW45akIjxeLN3wejfp0hUFBYrITVs8ssQUbQUc9uDDu CdUxMwoeu5ZhVT7TN5Rh2iSjkFQjjsewTimGLuNr4dT+dUH3ypJvsQ== =ql9l -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Tuesday, 18 May 2021 13:21, Arne Schwabe wrote: > Am 17.05.21 um 19:16 schrieb tincantech: > > > Hi, > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, 12 May 2021 14:15, Arne Schwabe a...@rfc2549.org wrote: > > > > > This is meant to give new users a quickstart for a useable OpenVPN > > > setup. Our own documentation is lacking in this regard and many often > > > tutorials that can be found online are often questionable in some > > > aspects. > > > > I believe Openvpn in standard mode (Full PKI) would reject an expired > > client certificate. > > Note: There is absolutely nothing in the manual to confirm this ! > > https://build.openvpn.net/man/openvpn-2.5/openvpn.8.html > > On that page there are eight uses of the word 'expire' and they all > > relate to an expired auth-token, this could also probably be improved. > > However, Openvpn in peer-fingerprint mode allows an expired client > > certificate to connect. > > The client log does have a 'WARNING: Your certificate has expired!' > > The server log has nothing about an expired client certificate. > > And, as we all know, who reads their log files anyway ? > > The issue here is that the server allows an expired client certificate > > to connect and there is no mention of this change in behaviour. > > Yes. We just trust the fingerprint of the certificate. The behaviour to > ignore expiry is a side effect of that. It is kinda designed to be this way. > > Arne The change itself is ok, I just thought it worth mentioning is this guide. Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgo76EACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1pAAf+M7BWGoMLjSdhrcfokV0mu9M8eND0XF7AvEI3d+DQEGqJ2S9I l6aVCCXsIKi1m/fJbYSYROhD7zvKj3i1KQebXxUTTonmlhEIMLhXnzHmdAPH Owh3Ixpf284NMTcjZgcQAhGcLdlMeVpykJrIIx4lpR75u0+FV6STUmtIgG2Q gWOi4OduA5gNJanu4BlF/7JCHNXSQvHQ5yrSGBrRdT2kIIGnrHSYfmUz1Jq4 v0AHQP8aTFD6sUaYw2j0nRGKj43rAmV+yyx2oLU1/6jbiBl5wq25fgNi3cCa 22HuxRP1SsbSf5PoWbUyZmXagpnHKRmgj42DkMn3pMTLjGnDD6NmVA== =Fotu -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Monday, 17 May 2021 20:07, tincantech wrote: > Hi, > > ‐‐‐ Original Message ‐‐‐ > On Monday, 17 May 2021 18:16, tincantech via Openvpn-devel > openvpn-devel@lists.sourceforge.net wrote: > > > Hi, > > ‐‐‐ Original Message ‐‐‐ > > On Wednesday, 12 May 2021 14:15, Arne Schwabe a...@rfc2549.org wrote: > > > > > This is meant to give new users a quickstart for a useable OpenVPN > > > setup. Our own documentation is lacking in this regard and many often > > > tutorials that can be found online are often questionable in some > > > aspects. > > I think it is also worth noting that, in it's current form, the > documentation given does not provide for a --remote-cert-tls solution. > > I may be able to help with that but prefer to log it here first. > If/how you choose to document this here, I leave that to you. I have expanded easypfp to create either Server or Client certificates by adding X509v3 Extended Key Usage: TLS Web Client Authentication and TLS Web Server Authentication as optional extras. All tests passed. https://github.com/TinCanTech/easy-pfp Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgpAgIACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2goggAsxXM0nhW/aKCPi5ZiAgn4ZwSXwDuCQRU/G5Ff57RKfdiPjim ZWyWtttrUBlyBNRKUzKVoMbiAdXuf8WIUIgx11SqG0ZrJEbzvyhN6rcsCX33 6c6C2EPFriFwtMDjyiBiS4OtxKVs/L/GpbjfbxU6oPvQfQLVs/licvPOOHGs xAFXMOF8COPvcANstUUFzr9BTq7kc6KUzaI01zrBkDAh7zRapHupo6wiPrjB xRuhWnwV8dGxaeDNoxB7VXAqbWaPQFCsxc+gt9wPlFcG28Y0Ct1ME1MIIKKc +w6+wzEgGq01OTKFIzKJ6CVjIVUTziHZ65nsmHd/JqXOWZ146ZXJ5w== =+xAi -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
Re: [Openvpn-devel] Summary of the community meeting (19th May 2021)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Wednesday, 19 May 2021 14:31, Samuli Seppänen wrote: > Hi, > > Here's the summary of the IRC meeting. > > > > COMMUNITY MEETING > > Place: #openvpn-meeting on irc.freenode.net > Date: Wed 19th May 2021 > Time: 14:00 CET (12:00 UTC) > > Planned meeting topics for this meeting were here: > > https://community.openvpn.net/openvpn/wiki/Topics-2021-05-19 > > Your local meeting time is easy to check from services such as > > http://www.timeanddate.com/worldclock > > SUMMARY > > cron2, dazo, d12fk, lev, mattock, ordex, plaisthos and syzzer > participated in this meeting. > > > > > Talked about removing --no-replay option. Noted that it was to be > removed in 2.5, but we backpedaled on that decision and forgot to change > our documentation. It was also noted that that option changes the wire > format. > > Noted that --cipher none --auth none and --no-replay are quite > intertwined. Getting rid of these options would be good from security > perspective, but it was also noted that plain-text OpenVPN tunnels do > have some advantages over the alternatives like GRE tunnels. > > Summarizing the discussion: > > 1. OpenVPN 2.6: reject configs where --no-replay is used without --auth > none. > > 2. OpenVPN 2.7: remove --no-replay > 3. Add clear warnings to 2.5 and 2.6 about 1) and 2) > > Noted that mattock buildbot setup is shaping up nicely. There are a ton > of workers and code and data are quite well separated. Mattock is now > working on limiting concurrent builds on the docker host, then moving on > to t_client tests. > WRT --no-replay There is also --mute-replay-warnings, which you all seem to have over-looked. Perhaps this message could be changed (crypto.c:338): msg(D_REPLAY_ERRORS, "%s: bad packet ID (may be a replay): %s -- " "see the man page entry for --no-replay and --replay-window for " "more info or silence this warning with --mute-replay-warnings", error_prefix, packet_id_net_print(pin, true, gc)); Remove the reference to --no-replay soon. Just a thought. R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgpTRkACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ30bAgAk6bSZLaE73TDgkhlkhX5dTkLe6Lx4zAal1ADnS3tluqXJIlg IP16FNKbh+ZGahCBh4ICzEJvPwbI12F+hba0QwQpQOUiN0k00yvNxGuPpc8H q1YmasQvst4cFKJGqESR4gVe2hZx/JQT7ZLisWVPO3Je1roACOx/PNtRWG3F 36/zWFTwY7qqpbHrbfOgYV3/6hdvAArn//ki/Mu1DTPVOLu9v6n947nkcA7n /WBGY+IUp4heUQoNmNxkbT/SokVmx6bwgvMwpAF04PKWiLwGFcKxKsRHO6yw /AdxLouR77cRW3Jfu/WjiipXyU+H8LZAfa4UyRA2kQHf+99acRw4/Q== =+xci -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Thursday, 20 May 2021 00:36, Arne Schwabe wrote: > > I just want this to be verified because the manual reads that: > > udp6 will force only udp on IPv6, at least that is how I read it. > > Not on the server side. It is one of the quirks that we need to fix at > some point. See the ipv6only option of --bind for more details I actually checked this and believe it is a reasoanble decision. It works for me and I was not expecting it to do so. > > > > - > > > - The ip address the server will distribute > > > > > > == > > > > > > - server 192.168.234.0 255.255.255.0 > > > - server-ipv6 fd00:6f76:706e::/64 > > > - > > > - A tun-mtu of 1400 avoids problems of too big packets after VPN > > > encapsulation > > > > > > > > > = > > > > > > - tun-mtu 1400 > > > - > > > - The fingerprints of your clients. After adding/remvoing one here > > > restart the > > > > > > > > > = > > > > > > > remvoing -> removing > > > > > - server > > > > > > === > > > > > > - > > > - > > > - > > > - Notify clients when you restart the server to reconnect quickly > > > > > > > > > > > > - explicit-exit-notify 1 > > > - > > > - Ping every 60s, restart if no data received for 5 minutes > > > > > > == > > > > > > - keepalive 60 300 > > > > I presume you are all sure that this is suitable for consumer grade routers. > > I think 60 300 is a good starting point but we might later modify it if > this becomes a problem. OK. It is a big difference from the standard setting so I just wanted to call it here. > > Thanks for spell/grammar checking it! > > Arne No problem. Thanks for everything you've done too. Richard -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgpaUbACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1iEQf9HSb9ReZSAve3LfzgDNo4hb0c1mGNWSNcIQudw8fdaYc8TfjU UD1MLdTM9CM5uuHEz3O29nyBPEjCUJS16bQ45lVtHzAbGcdzUEF9cn/gUsST 7v/3aMeFM76YSDXnI3DrA6PtlqXoWJ7K+NC3tzXb7suF3Zy0Gi8AWgJhKD8q tXvHtXdGD9ohsZTF4yio8PWCW4n0UFPUTImndr/R8D6TRO5umhBDkmQ9fWx0 3gPN6ln9FF2bE/gqG7Sj1s6uu5OLNqJ+aswet2B22DI/7CHlgQzFC38nuy5f CKFJ0eZnrQ8baDDOpOHlmLTarisRLcOP7rxT1qz5S6PWdGTP4+s/rg== =VNul -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, just FYI I was also going to question the --tun-mtu 1400 setting but decided that was above my pay-grade. I think it is probably a good long-term decision that will probably invade some of those less respectable blogs and be a good thing over-all. I know, it is complicated ! Cheers R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgpamaACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3PVQgAju8gPugglio2RQ1Qr/fcXFyq7tAQEy/njizNTIDBEAE3E1tr J0gOsMMe1fQTDjen5DCtJEyq7pwIgMVKWw/kVP7DzOlTzC+oUb4avysoi3Ld pUFDmJdD2eP1Ls+Ylc9O2HDlK1q8n46mUjX5Fuv1+0UN/HFUb1d7z9IgRHTf 0h+6f7dkn4z0QgFjY97esSKDu9x3ZZhhIfUPwPOUF4mLEQv+6PczpzAvm7eS oZRr/GNjSBq1dBzzWNi80v9cv31Uxz7VTuy3ntKp5k0n80W0b93tbG0xVcu7 qi1ZCQh5VgFdh/35+7uwsJkpA9Eoc+ijFqV1+gz1+FekdRAmO1iCpA== =rh5B -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
Re: [Openvpn-devel] [PATCH 9/9] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, missed another one .. ‐‐‐ Original Message ‐‐‐ On Thursday, 20 May 2021 01:13, tincantech wrote: > Hi, > > just FYI > > I was also going to question the --tun-mtu 1400 setting but decided > that was above my pay-grade. I think it is probably a good long-term > decision that will probably invade some of those less respectable blogs > and be a good thing over-all. I know, it is complicated ! > How would that effect the default --mssfix ? Swings and roundabouts R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgpa+8ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1f9Af/ZxK/IusDe82uZsnlZXlRAJElzyamWPA+Splu+nOoUVQhSjah eyc6YqM4+FNNP6dyZxVELT0RKC5p8c7KUEqFzay+2nflnwALDu9m5ak4WVyb EFmXPFctfu1myCdqZ70705DhfORainxI7tLrbzTwLMeZMH1xPJ9IszBE5wqb nUcBO1B3g+E01b/cF9GL6wHF32kW9BH5uc+0A1mb4/3+iO83VP3nUnKBm+sj pZUR4G3VpgLzyc1ymIkxQIxsas1f6M3r8qvBI+ol1F1YkZJXy76Piuh7I5rF 0fYcm0jtxKmf/ETHPIQFL6J3N2zrar8+kazS0GRW9hPLPfqODXqqDQ== =I3MI -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
Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, again, I do not understand why openvpn choose to switch to .pem for this tutorial. PEM -> Private Email, which this is not. You have a certificate and a key and every other openvpn tutorial on openvpn and probably the entire planet uses .crt and .key. This seems to be a poor decision in my opinion. And I presume that --tun-mtu 1400 is not going to break --mssfix 1450 There is also another advantage of using this method which is not documented. Each client can build its own cert/key and send the finger-print to the server in clear text, as can the server FP be sent to the clients. And apologies for the plug but easy-pfp can do all this and more even easier. https://github.com/TinCanTech/easy-pfp Sent with ProtonMail Secure Email. Which does not know how to reply to a git formatted patch and has other stupid quirks too. sed formatted reply. ‐‐‐ Original Message ‐‐‐ On Thursday, 20 May 2021 16:09, Arne Schwabe wrote: > This is meant to give new users a quickstart for a useable OpenVPN > setup. Our own documentation is lacking in this regard and many > tutorials that can be found online are often questionable in some > aspects. > > Linking the individaul RST file on github also give a tutorial > in a nicely formatted way. individaul -> individual (ua) > > Patch V2: Fix grammar/spelling mistakes (thanks ticantech), move > to openvpn-examples(5). > > Signed-off-by: Arne Schwabe > --- > Changes.rst | 4 + > doc/Makefile.am | 1 + > doc/man-sections/example-fingerprint.rst | 196 +++ > doc/openvpn-examples.5.rst | 1 + > 4 files changed, 202 insertions(+) > create mode 100644 doc/man-sections/example-fingerprint.rst > > diff --git a/Changes.rst b/Changes.rst > index 9185b55f7..5ac24307f 100644 > --- a/Changes.rst > +++ b/Changes.rst > @@ -25,6 +25,10 @@ Certificate pinning/verify peer fingerprint > fingerprint of the peer. The option takes use a number of allowed > SHA256 certificate fingerprints. > > +See the man page section "Small OpenVPN setup with peer-fingerprint" > +for a tutorial on how to use this feature. This is also available online > +under > https://github.com/openvpn/openvpn/blob/master/doc/man-sections/example-fingerprint.rst > + > TLS mode with self-signed certificates > When ``--peer-fingerprint`` is used, the ``--ca`` and ``--capath`` option > become optional. This allows for small OpenVPN setups without setting up > diff --git a/doc/Makefile.am b/doc/Makefile.am > index 1dbbddf58..d86560174 100644 > --- a/doc/Makefile.am > +++ b/doc/Makefile.am > @@ -25,6 +25,7 @@ dist_noinst_DATA = \ > man-sections/client-options.rst \ > man-sections/connection-profiles.rst \ > man-sections/encryption-options.rst \ > + man-sections/example-fingerprint.rst \ > man-sections/examples.rst \ > man-sections/generic-options.rst \ > man-sections/inline-files.rst \ > diff --git a/doc/man-sections/example-fingerprint.rst > b/doc/man-sections/example-fingerprint.rst > new file mode 100644 > index 0..c91ca64b9 > --- /dev/null > +++ b/doc/man-sections/example-fingerprint.rst > @@ -0,0 +1,196 @@ > +Small OpenVPN setup with peer-fingerprint > += > +This section consists of instructions how to build a small OpenVPN setup > with the > +:code:`peer-fingerprint` option. This has the advantage of being easy to > setup > +and should be suitable for most small lab and home setups without the need > for a PKI. > +For bigger scale setup setting up a PKI (e.g. via easy-rsa) is still > recommended. > + > +Both server and client configuration can of be further modified to customise > the > +setup. > + > +Server setup > + > +1. Install openvpn > + > + Compile from source-code (see `INSTALL` file) or install via a > distribution (apt/yum/ports) > + or via installer (Windows). > + > +2. Generate a self-signed certificate for the server: > + :: > + > +openssl req -x509 -newkey ec:<(openssl ecparam -name secp384r1) -keyout > serverkey.pem -out server.pem -nodes -sha256 -days 3650 -subj '/CN=server' > + > +3. Generate SHA256 fingerprint of the server certificate > + > + Use the OpenSSL command line utility to view the fingerprint of just > + created certificate: > + :: > + > +openssl x509 -fingerprint -sha256 -in server.pem -noout > + > + This output something similar to: > + :: > + > + SHA256 > Fingerprint=00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22:33:44:55:
Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Thursday, 20 May 2021 19:30, Arne Schwabe wrote: > Am 20.05.2021 um 18:56 schrieb tincantech: > > > Hi, > > again, I do not understand why openvpn choose to switch to .pem > > for this tutorial. PEM -> Private Email, which this is not. > > You have a certificate and a key and every other openvpn tutorial > > on openvpn and probably the entire planet uses .crt and .key. > > This seems to be a poor decision in my opinion. > > pem as extension for keys is pretty common and specifies more the > encoding than the type. E.g. there is also the der encoding. > > Arne I accept the principle but openvpn *only* uses PEM-enc, that I know of. So, why switch to .pem when it has never been used before by openvpn? If you are all happy to let it go that way then so-be-it, Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgpr0yACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3AXgf9H+mL+H1aPZ/Gk0lTukZEP7FVXHkO2LBf49KA/YmoyhbHYAFf sICvASsTlkA0q3wuKYzXs8bspMGiebOeqcoJi7QvJSaAq4sDLvWopz/VmN96 SmB33OnN/jYHQmKpk2qOMeZv6PyhFyjFb/3j1ymQ2zuYXh8osrSiiRHftwSx hXg8CMyXOA0THrK6H9mnxisLuss7uhVsclwTOSKMOnRj0NiEx5tFg1itn7+u YmRL/h2taDC6skHbF5PPfU1x/M6HtG05ZajAtNfh3bc0Zw4S7bRiEUc4+4qb f8GEEufo2WAg4CUwaCVJ9O5pSewk48OAScHGx9RMybvfZ1X6V5xnqA== =EBa6 -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
Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, 20 May 2021 22:05, Jan Just Keijser wrote: > Hi, > > On 20/05/21 21:49, tincantech via Openvpn-devel wrote: > > > > > Hi, > > > > again, I do not understand why openvpn choose to switch to .pem > > > > for this tutorial. PEM -> Private Email, which this is not. > > > > You have a certificate and a key and every other openvpn tutorial > > > > on openvpn and probably the entire planet uses .crt and .key. > > > > This seems to be a poor decision in my opinion. > > > > pem as extension for keys is pretty common and specifies more the > > > > encoding than the type. E.g. there is also the der encoding. > > > > > > Arne > > > I accept the principle but openvpn only uses PEM-enc, that I know of. > > > > So, why switch to .pem when it has never been used before by openvpn? > > If you are all happy to let it go that way then so-be-it, > > Hopefully this clarifies things: > > - the default output format of OpenSSL is PEM-encoded ; openssl uses the > default extension .pem > > - the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but > they've just been named differently by the easy-rsa tools to ensure that > the files can be easily loaded on Windows > > - FTR: nearly all webservers I have ever seen are configured to use a > hostcert.pem and hostkey.pem and my guess is that there are (still) > more Linux-based webservers out there than OpenVPN clients and servers. > > Having said that, I do agree that after using .crt/.key files left and > right (to accomodate Windows users) for over 15 years, it does seem > confusing to start using files named .pem for peer-fingerprinting all > of sudden. On the other hand, with peer-fingerprinting you don't > HAVE a .crt file (at least, you don't need one, technically) but only > a .key file. So choosing a different extension for peer-fingerprinting > does have its merits. FTR: Openvpn still exchanges the full certificates in peer-fingerprint mode. > > HTH, > > JJK > -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgptC5ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ2t0ggAxDZnJr8UhxV79fyAjnScANMeWbN3XZ/QqQuTsgaJp85Fibbz weT1TfvihZ5l1rS6vh1nIDyTtoNRpqLHMxlaNWnmgN9tR4IRlQZuVR8svZl1 UYmrAm1H5g83yHef60nnIiOxGe8tnLdy/fmjqoRFsHaBwSM87zTQ8uG+UJnq GIGhHbdLYWaH4C9SrJ+p64pZYdm3jaQpwZHdeg3rPdvHAgUixX13KWBU J2UYseRDBLcvNfz6gAgQDtTJtdT9edH3h6m4Tyu0AsIw016hfREeNe20uzrX uyQ6jGGovT2ki9alVN9P5v1k9uYVC0/1mYnFBLR8PI8effQd/zfLiA== =KICZ -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
Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Thursday, 20 May 2021 22:22, Jan Just Keijser wrote: > On 20/05/21 23:12, tincantech wrote: > > > [...] > > > > > > So, why switch to .pem when it has never been used before by openvpn? > > > > If you are all happy to let it go that way then so-be-it, > > > > Hopefully this clarifies things: > > > > > > - the default output format of OpenSSL is PEM-encoded ; openssl uses the > > > default extension .pem > > > > > > - the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but > > > they've just been named differently by the easy-rsa tools to ensure > > > that > > > the files can be easily loaded on Windows > > > > > > - FTR: nearly all webservers I have ever seen are configured to use a > > > hostcert.pem and hostkey.pem and my guess is that there are (still) > > > more Linux-based webservers out there than OpenVPN clients and > > > servers. > > > Having said that, I do agree that after using .crt/.key files left and > > > right (to accomodate Windows users) for over 15 years, it does seem > > > confusing to start using files named .pem for peer-fingerprinting all > > > of sudden. On the other hand, with peer-fingerprinting you don't > > > HAVE a .crt file (at least, you don't need one, technically) but only > > > a .key file. So choosing a different extension for peer-fingerprinting > > > does have its merits. > > FTR: Openvpn still exchanges the full certificates in peer-fingerprint > > mode. > meh ... I guess it was easier to implement it that way at the TLS level... I cannot comment on the code but there is the case of older clients which require self-signed server".crt" (Easy-RSA) in place of the CA cert. > > IMO that does add a "+1" to using .crt/.key extensions - otherwise it > might confuse the heck out of end users (like overwriting the private > key with the public cert etc ... ) That is another good point. > How do the examples distinguish between the cert and the private key in > this case then? Generally, the distinction between what is private and what is public has not been very well covered. Other than the notable exception of "Protect your Private CA key at all costs!" I have included this Private v Public information in the easy-pfp output. Seems like the only way to get things done sometimes is do-it-yourself ;-) Anyway, all other points aside, the point is that: Changing to .pem (not PEM) feels like an unnecessary complication. Thanks for all your input R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgptYeACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ0haQf/VyfMNC8x8r+8okE+aKW+kp+OMA58J6R7xOdv7D518BsBSJNX BAqDiM1lalAwDvU7edKKMXhc0U2BOgMiaVOXp54jkZvXo7O5tt57A1O+tTKv GNPzqDrhfGQRuaplHTMeiSkcWZOSmyNwIAW0vroCmiPBnGY2/F5GIL8T83Dp qiNsST7Fug+u4nVUv/BUE2K81/B3pNz4Jy6hX2QMmq5LdRJgtNU37AAsZAQ5 Zwr4bewl/l8q36VjsX4QYNQgQekXdK8oT7LXZuqEy+tf4RnVHA8YDQZ2Ed5t tfUUg/b02w3Ml6k9Wt3SHDgoXMAW0utUxxOWCMGVnEhuDRWg0kQ3rw== =B+MM -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
Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
-‐‐ Original Message ‐‐‐
On Thursday, 20 May 2021 22:35, tincantech via Openvpn-devel
wrote:
> Hi,
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 20 May 2021 22:22, Jan Just Keijser janj...@nikhef.nl wrote:
>
> > On 20/05/21 23:12, tincantech wrote:
> >
> > > [...]
> > >
> > > > > So, why switch to .pem when it has never been used before by openvpn?
> > > > > If you are all happy to let it go that way then so-be-it,
> > > > > Hopefully this clarifies things:
> > > >
> > > > - the default output format of OpenSSL is PEM-encoded ; openssl uses
> > > > the
> > > > default extension .pem
> > > >
> > > > - the OpenVPN .crt and .key files are ALSO PEM-encoded by default, but
> > > > they've just been named differently by the easy-rsa tools to ensure
> > > > that
> > > > the files can be easily loaded on Windows
> > > >
> > > > - FTR: nearly all webservers I have ever seen are configured to use a
> > > > hostcert.pem and hostkey.pem and my guess is that there are (still)
> > > > more Linux-based webservers out there than OpenVPN clients and
> > > > servers.
> > > > Having said that, I do agree that after using .crt/.key files left
> > > > and
> > > > right (to accomodate Windows users) for over 15 years, it does seem
> > > > confusing to start using files named .pem for peer-fingerprinting
> > > > all
> > > > of sudden. On the other hand, with peer-fingerprinting you don't
> > > > HAVE a .crt file (at least, you don't need one, technically) but
> > > > only
> > > > a .key file. So choosing a different extension for
> > > > peer-fingerprinting
> > > > does have its merits.
> > > >
>
> > > FTR: Openvpn still exchanges the full certificates in
> > > peer-fingerprint mode.
> > >
>
> > meh ... I guess it was easier to implement it that way at the TLS level...
>
> I cannot comment on the code but there is the case of older clients which
> require
> self-signed server".crt" (Easy-RSA) in place of the CA cert.
>
> > IMO that does add a "+1" to using .crt/.key extensions - otherwise it
> > might confuse the heck out of end users (like overwriting the private
> > key with the public cert etc ... )
>
> That is another good point.
>
> > How do the examples distinguish between the cert and the private key in
> > this case then?
>
> Generally, the distinction between what is private and what is public
> has not been very well covered. Other than the notable exception of
> "Protect your Private CA key at all costs!"
>
> I have included this Private v Public information in the easy-pfp output.
> Seems like the only way to get things done sometimes is do-it-yourself ;-)
>
> Anyway, all other points aside, the point is that: Changing to .pem (not PEM)
> feels like an unnecessary complication.
>
I would like to hammer one final nail into this discussion.
Openvpn option names and inline tags ALL use ificate .crt and .key.
They do not use .pem or PEM and none of the Official online documentation,
to date, references use of a {name}.pem file, other than far-flung cases.
The files generated in this tutorial will all be PEM encoded regardless.
This is why I asked the question of why Openvpn suddenly chooses to change
to a .pem extension and add this unnecessary complication.
Real users may see this as another hurdle which they just don't want to jump.
Do you want to drive them away .. ?
As I am also banned from #openvpn-meeting, so I leave this for you to discuss.
--
Richard
-BEGIN PGP SIGNATURE-
Version: ProtonMail
wsBzBAEBCAAGBQJgpvNyACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ1U5wgAza4n5mxniWpvVrkSxRCN3TEc0MEafFb+Eza0uL/l9i5tVDDQ
A4ZwjBuRGgteJzNhbe3Q+YJzZZ1hjf9k9FjPwGtnUK49IZZt8OOe60bfiQt7
aSmhKMRyZzzjRgSv6QNdPWsZEB3JceZ572+EIi5zfQmz6V1q8USsPQPaUZoa
k65YA9Z+pU6xsm1+lKMLGbi8rzIvIhNYCEIZ4pGl5OzckQP7o7JKUanhOoHH
7KrD5Nu5ad4CtgMv72RYWCbmW5vsqIcOrYJIG7mASodCTGkL2JH5F2i8fVUJ
rg5OrvVViLewxTYyGCVc+PZ7ukB6l/bEYd8efA1G4carr6+hRDTfSA==
=T6wH
-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
Re: [Openvpn-devel] [PATCH v2 2/2] Add detailed man page section to setup a OpenVPN setup with peer-fingerprint
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
‐‐‐ Original Message ‐‐‐
On Friday, 21 May 2021 00:40, tincantech wrote:
> I would like to hammer one final nail into this discussion.
>
> Openvpn option names and inline tags ALL use ificate .crt and
> .key.
>
> They do not use .pem or PEM and none of the Official online documentation,
> to date, references use of a {name}.pem file, other than far-flung cases.
>
> The files generated in this tutorial will all be PEM encoded regardless.
One final blow to the nail:
There is still the outstanding problem of --remote-cert-tls
which this tutorial does not discuss or solve.
The user log will show a WARNING message which they *cannot* solve
by means of your documentation.
--
Thanks
R
Unfairly banned.
-BEGIN PGP SIGNATURE-
Version: ProtonMail
wsBzBAEBCAAGBQJgpvv5ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec
9muQuJ2gkQf9FDId8dPnTrdC4+UHLhFOJOAYelk9SDQ1a3PSVhbag2ZO2FvM
3pCKfqdqSB0zYuu3rXBSdBoToovKw2Zc+8tnF8MaH6Oqm5+cmnRDfc03ZfDs
auqD04xIACnt3cPYAXXU+qXxGC8GpwLiUlEIEzlTcTsBrZyLMJhMPx146Dpe
MNRQtmYW+FqJfYHO7OscIb1uwUQ4WeWLY+76GkqhRMSPY6hrZ6CRU9htSdoU
w+B7KOGCKVE/FsyABNOz4IRNdnM3FMzvAvRD0UcOxJnmz/2BjImP6qNa7D0f
VGyg1kvnYQViVOOjE17ejvqbnLcRJRD53gRJcHpb/45UbVWNjSq04A==
=C3te
-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
[Openvpn-devel] --tls-verify runs twice for a single cert in Peer-fingerprint mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Is this expected ? Server log: 2021-05-24 14:58:03 us=534606 10.10.201.226:60276 TLS CRYPT V2 VERIFY SCRIPT OK 2021-05-24 14:58:03 us=558066 10.10.201.226:60276 VERIFY KU OK 2021-05-24 14:58:03 us=558105 10.10.201.226:60276 Validating certificate extended key usage 2021-05-24 14:58:03 us=558120 10.10.201.226:60276 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication 2021-05-24 14:58:03 us=558130 10.10.201.226:60276 VERIFY EKU OK * EasyTLS-verify => CN: cli-arch-v21x connection allowed 2021-05-24 14:58:03 us=573751 10.10.201.226:60276 VERIFY SCRIPT OK: depth=0, CN=cli-arch-v21x 2021-05-24 14:58:03 us=573782 10.10.201.226:60276 VERIFY OK: depth=0, CN=cli-arch-v21x 2021-05-24 14:58:03 us=573911 10.10.201.226:60276 VERIFY KU OK 2021-05-24 14:58:03 us=573928 10.10.201.226:60276 Validating certificate extended key usage 2021-05-24 14:58:03 us=573939 10.10.201.226:60276 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication 2021-05-24 14:58:03 us=573948 10.10.201.226:60276 VERIFY EKU OK * EasyTLS-verify => CN: cli-arch-v21x connection allowed 2021-05-24 14:58:03 us=588472 10.10.201.226:60276 VERIFY SCRIPT OK: depth=0, CN=cli-arch-v21x 2021-05-24 14:58:03 us=588508 10.10.201.226:60276 VERIFY OK: depth=0, CN=cli-arch-v21x 2021-05-24 14:58:03 us=590929 10.10.201.226:60276 peer info: IV_VER=2.6_git Client log: 2021-05-24 15:06:44 us=111054 TLS: Initial packet from [AF_INET]10.10.101.101:17332, sid=ae12d90b 6b413bf6 2021-05-24 15:06:44 us=120475 VERIFY KU OK 2021-05-24 15:06:44 us=121197 Validating certificate extended key usage 2021-05-24 15:06:44 us=122354 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-05-24 15:06:44 us=122737 VERIFY EKU OK * TLS Verify Script OK 2021-05-24 15:06:44 us=130217 VERIFY SCRIPT OK: depth=0, CN=srv-wiscii-v21x 2021-05-24 15:06:44 us=130598 VERIFY OK: depth=0, CN=srv-wiscii-v21x 2021-05-24 15:06:44 us=131581 VERIFY KU OK 2021-05-24 15:06:44 us=132268 Validating certificate extended key usage 2021-05-24 15:06:44 us=132828 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2021-05-24 15:06:44 us=133364 VERIFY EKU OK * TLS Verify Script OK 2021-05-24 15:06:44 us=137990 VERIFY SCRIPT OK: depth=0, CN=srv-wiscii-v21x 2021-05-24 15:06:44 us=138614 VERIFY OK: depth=0, CN=srv-wiscii-v21x Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgq7M5ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ1+vAgApEpHTOh5m9D706+WEOMvXq6PiKxfLnnjowOMLS1ut+ts0Kj6 8JHutbqJarT+0rhiezfDlKqqdXrDLaW/5bfF0M0f9J8+BgZNGIKXSM2Tp39f lSqJIF0kMdD/RQKYxGu5TaO3eLaaWTBbEdkyAHa+t74E7fIiTtxEdvgqVkWm 423h3PSsdnHcOaCQkM7KOGilmpq+Wz/5KEtjVlzhKyfscqtw3RUvtFgKOXYj p+axmfzY1aqkQNQTz98nC4w06Vao7XUSQtjWYfznVdDd8rP/hHmWDwLtYNyR yQnN+iPHg5JsAdmrQ+6m99bX+C8btSHUPfN/0jAifkZjmEwP/I9ckA== =cwb8 -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
Re: [Openvpn-devel] --tls-verify runs twice for a single cert in Peer-fingerprint mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Monday, 24 May 2021 18:39, Selva Nair wrote: > Hi, > > On Mon, May 24, 2021 at 10:09 AM tincantech via Openvpn-devel > openvpn-devel@lists.sourceforge.net wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > Hi, > > Is this expected ? > > Server log: > > 2021-05-24 14:58:03 us=534606 10.10.201.226:60276 TLS CRYPT V2 VERIFY > > SCRIPT OK > > 2021-05-24 14:58:03 us=558066 10.10.201.226:60276 VERIFY KU OK > > 2021-05-24 14:58:03 us=558105 10.10.201.226:60276 Validating certificate > > extended key usage > > 2021-05-24 14:58:03 us=558120 10.10.201.226:60276 ++ Certificate has EKU > > (str) TLS Web Client Authentication, expects TLS Web Client Authentication > > 2021-05-24 14:58:03 us=558130 10.10.201.226:60276 VERIFY EKU OK > > * EasyTLS-verify => CN: cli-arch-v21x connection allowed > > 2021-05-24 14:58:03 us=573751 10.10.201.226:60276 VERIFY SCRIPT OK: > > depth=0, CN=cli-arch-v21x > > 2021-05-24 14:58:03 us=573782 10.10.201.226:60276 VERIFY OK: depth=0, > > CN=cli-arch-v21x > > 2021-05-24 14:58:03 us=573911 10.10.201.226:60276 VERIFY KU OK > > 2021-05-24 14:58:03 us=573928 10.10.201.226:60276 Validating certificate > > extended key usage > > 2021-05-24 14:58:03 us=573939 10.10.201.226:60276 ++ Certificate has EKU > > (str) TLS Web Client Authentication, expects TLS Web Client Authentication > > 2021-05-24 14:58:03 us=573948 10.10.201.226:60276 VERIFY EKU OK > > * EasyTLS-verify => CN: cli-arch-v21x connection allowed > > 2021-05-24 14:58:03 us=588472 10.10.201.226:60276 VERIFY SCRIPT OK: > > depth=0, CN=cli-arch-v21x > > 2021-05-24 14:58:03 us=588508 10.10.201.226:60276 VERIFY OK: depth=0, > > CN=cli-arch-v21x > > 2021-05-24 14:58:03 us=590929 10.10.201.226:60276 peer info: IV_VER=2.6_git > > This looks like an unintended consequence of how and when OpenSSL > executes the verify callback. If there are no verification errors, the > callback is called only once for each depth with preverify_ok = 1. > When there are errors (as is the case when CA is missing), for each > depth and each error we get a callback. (Ref: OpenSSL docs on > SSL_CTX_set_verify). > > Even for self-signed certs one would get a call with an error saying > certificate is self-signed and then possibly another call with > signature verification success. For a cert issued by a CA, one would > first get an "issuer missing" error followed by a "signature > verification" error and no success calls unless there are intermediate > certs. > > This was not an issue before fingerprint support. In that case we do > not proceed further when OpenSSL reports a verify error. > > The easiest option for scripts may be to be prepared to be called > mutiple times with the same cert and same depth. I think we should > export the verification error-status to the env so that the script > could make a more informed decision. Note: In the logs above, the script is executed *before* Openvpn/Openssl verification, so exporting error-status to env for script seems unlikely. > Our internal callback is not meant to be executed multiple times with > same depth, but the side effects appear to be benign -- like repeated > VERIFY OK in the logs. > > Selva Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgq+wRACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3oqQf9ELeVXn5uhviySVqMzIRyCKQAY9zMrdvFSLgNcEOJbiBYcv6Y WIzDoVfODy0jGIx44dsjODw2jM9hWP27FSj/uG8RuTCv7gmO/zDvJIKL6qEn EcpnLxLBvyJcfu7zfW80kBNhYcHyys3DSSL2khtzbT+75OM3Kvo7pUNJUAhl czUF07j7o8KmUGq2wB8E70Y7i+U07j2Dcs0+oDRhY3hBsnHHmWPSm32fBPLZ uSbRPm4btNe4a/R83uMRkWTgL1U/2dTKKPb3PyVE7bGWfeB5BmkuUQsPx5q6 bofIkWaDYG+1pW6nyTxMZ2drihC2c9vA/OHmLG6HUYxBIaYPW/JZLQ== =s/jt -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
Re: [Openvpn-devel] --tls-verify runs twice for a single cert in Peer-fingerprint mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I may be wrong but this is the order as it appears to me: ‐‐‐ Original Message ‐‐‐ On Monday, 24 May 2021 18:39, Selva Nair wrote: > > Server log: > > 2021-05-24 14:58:03 us=534606 10.10.201.226:60276 TLS CRYPT V2 VERIFY > > SCRIPT OK --tls-crypt-v2-verify script > > 2021-05-24 14:58:03 us=558066 10.10.201.226:60276 VERIFY KU OK > > 2021-05-24 14:58:03 us=558105 10.10.201.226:60276 Validating certificate > > extended key usage > > 2021-05-24 14:58:03 us=558120 10.10.201.226:60276 ++ Certificate has EKU > > (str) TLS Web Client Authentication, expects TLS Web Client Authentication > > 2021-05-24 14:58:03 us=558130 10.10.201.226:60276 VERIFY EKU OK --remote-cert-tls client > > * EasyTLS-verify => CN: cli-arch-v21x connection allowed --tls-verify > > 2021-05-24 14:58:03 us=573751 10.10.201.226:60276 VERIFY SCRIPT OK: > > depth=0, CN=cli-arch-v21x > > 2021-05-24 14:58:03 us=573782 10.10.201.226:60276 VERIFY OK: depth=0, > > CN=cli-arch-v21x Openvpn/Openssl verify Then it repeats. I just wanted to clarify that and I may also be wrong in my understanding. R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgq+5zACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ23wAf9GluCVmrwY47qboOJX79NMSJ9Q0aVy7Q7F+rkwDwTwxkGA6zd 2wi4Q9NNgNd+c4Y4nEd6gtCFgYWDN5ScFi4xfwla1rmCWn2jom/HpNGC8i6D IZHpOEuW1qQFV7iNOB3VoVggOiuUteChJ55RE380R3RvMypJDxo7wQIU5hak xAiTqbvYYmNfTKFUN4GSxn+6ioGIc+KtQsr0P/VWslh6Cg8cGmfJoK1RhSfs i1J/MtiGiuRY/2bpZBwo1G2P1gQgbIKtoZyBzjwxCivOAM34RLz3vszNm3hj 9g44xzJze5n7i9FK9uRZIm8hyJM34frpk2qimuIQTKrqDUin1Z/L2A== =rUbS -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
Re: [Openvpn-devel] --tls-verify runs twice for a single cert in Peer-fingerprint mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, ‐‐‐ Original Message ‐‐‐ On Monday, 24 May 2021 21:43, Arne Schwabe wrote: > Am 24.05.2021 um 16:07 schrieb tincantech via Openvpn-devel: > > > Hi, > > Is this expected ? > > I might to check if it is even a good idea to allow tls-verify and other > verify options together peer-fingerprint. (You could implement > peer-fingerprint with tls-verify as well. Since we haven't published 2.6 > yet we might just make the combination very limited to avoid allowing > all kind of crazy combinations and having to support those. > > Arne Posted in -devel not -users for that very reason. I am not questioning the code, only bringing you test data. Thanks R -BEGIN PGP SIGNATURE- Version: ProtonMail wsBzBAEBCAAGBQJgrDE5ACEJEE+XnPZrkLidFiEECbw9RGejjXJ5xVVVT5ec 9muQuJ3xZwf/cgA0qvrIM2XUNnXWE9VcR98jeGkFh10rmucI5QlApd+78v1w uCv/2udPYrJVD2gcsy59nT+tyNcTaewv4WM7x6P9dh5fSvQaX58yZSn1kbV/ wva46qCRYIUDTA9833gNCjkvdDSdCSJPiTYYBDqE/LABAmVqUdGlP4mlqcv3 Ls+9/bEpGkeiqUC53vazWIBWQfeogGin6d0TUel2rV7wm/hB6Luo13K5BTsK vDuTorFUUft7pPVjTsjo19Q5zVDj3No30xhOKJGGINg16Q5xeH5hfQzJw5QK KZvplCjUgKAeJJX+Zx6DnDv/i07ISWBpSw5/9LK6LRd9fRHUTAgA9Q== =BDnA -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
Re: [Openvpn-devel] [PATCH 1/2] Improve documentation of AUTH_PENDING related directives
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Him
I read through it and it looks good to me.
One tiny omission inserted: Scroll to end.
Regards
R
Sent with ProtonMail Secure Email. Which still can't handle patches.
‐‐‐ Original Message ‐‐‐
On Wednesday, 2 June 2021 04:42, wrote:
> From: Selva Nair selva.n...@gmail.com
>
> Also fix some typos.
>
> Signed-off-by: Selva Nair selva.n...@gmail.com
>
> doc/man-sections/server-options.rst | 4 ++
> doc/management-notes.txt | 101 +---
> 2 files changed, 67 insertions(+), 38 deletions(-)
>
> diff --git a/doc/man-sections/server-options.rst
> b/doc/man-sections/server-options.rst
> index 036323b9..047f2270 100644
> --- a/doc/man-sections/server-options.rst
> +++ b/doc/man-sections/server-options.rst
> @@ -460,6 +460,10 @@ fast hardware. SSL/TLS authentication must be used in
> this mode.
> The UI version of a UI if one is running, for example
> :code:`de.blinkt.openvpn 0.5.47` for the Android app.
>
> - :code:`IV_SSO=[crtext,][openurl,][proxy_url]`
> - Additional authentication methods supported by the client.
>
>
> - This may be set by the client UI/GUI using ``--setenv``
>
>
> - When `--push-peer-info` is enabled the additional information consists
> of the following data:
>
> diff --git a/doc/management-notes.txt b/doc/management-notes.txt
> index 3aff6eb6..9f064764 100644
> --- a/doc/management-notes.txt
> +++ b/doc/management-notes.txt
> @@ -199,7 +199,7 @@ Command examples:
> COMMAND -- kill
>
>
> -In server mode, kill a particlar client instance.
> +In server mode, kill a particular client instance.
>
> Command examples:
>
> @@ -407,6 +407,7 @@ RECONNECTING -- A restart has occurred.
> EXITING -- A graceful exit is in progress.
> RESOLVE -- (Client only) DNS lookup
> TCP_CONNECT -- (Client only) Connecting to TCP server
> +AUTH_PENDING -- (Client only) Authentication pending
>
> Command examples:
>
> @@ -437,6 +438,11 @@ Fields (e)-(h) are shown for CONNECTED state,
> (e) is available starting from OpenVPN 2.1
> (f)-(i) are available starting from OpenVPN 2.4
>
> +For AUTH_PENDING, if (c) is present, it would read
> +as "timeout number" where number is the number of seconds
> +before authentication will timeout. It is printed as an
> +unsigned integer (%u).
> +
> Real-time state notifications will have a ">STATE:" prefix
> prepended to them.
>
> @@ -608,7 +614,7 @@ COMMAND -- client-pending-auth (OpenVPN 2.5 or higher)
> Instruct OpenVPN server to send AUTH_PENDING and INFO_PRE message
> to signal a pending authenticating to the client. A pending auth means
> that the connecting requires extra authentication like a one time
> -password or doing a single sign one via web.
> +password or doing a single sign on via web.
>
> client-pending-auth {CID} {EXTRA} {TIMEOUT}
>
> @@ -624,22 +630,22 @@ the timeout proposed by the server, even if the timeout
> is shorter.
> If the client does not receive a packet from the server for hand-window the
> connection times out regardless of the timeout. This ensures that the
> connection
> still times out relatively quickly in case of network problems. The client
> will
> -continously send PULL_REQUEST messages to the server until the timeout is
> reached.
> +continuously send PULL_REQUEST messages to the server until the timeout is
> reached.
> This message also triggers an ACK message from the server that resets the
> hand-window based timeout.
>
> Both client and server limit the maximum timeout to the smaller value of half
> the
> --tls-reneg minimum time and --hand-window time (defaults to 60s).
>
> -For the format of EXTRA see below. For the OpenVPN server this is a stateless
> +For the format of {EXTRA} see below. For OpenVPN server this is a stateless
> operation and needs to be followed by a client-deny/client-auth[-nt] command
> (that is the result of the out of band authentication).
>
> Before issuing a client-pending-auth to a client instead of a
> client-auth/client-deny, the server should check the IV_SSO
> -environment variable if the method is support. The currently
> -defined method are crtext for challenge/response using text
> -(e.g. TOTP), openurl and proxy_url for opening an URL in the client to
> +environment variable for whether the method is supported. Currently
> +defined methods are crtext for challenge/response using text
> +(e.g., TOTP), openurl and proxy_url for opening a URL in the client to
> continue authentication. A client supporting the first two methods would
> set
>
> @@ -649,17 +655,30 @@ The variable name IV_SSO is historic as AUTH_PENDING
>
