Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Jonathan K. Bullard]

On Thu, Feb 16, 2023 at 9:24 AM Arne Schwabe  wrote:
>
> Am 16.02.23 um 14:11 schrieb Jonathan K. Bullard:
> > Not yet seeing anything about 2.5.9 at
> > https://openvpn.net/community-downloads/
> > <https://openvpn.net/community-downloads/>. (From the New York City
> > metropolitan area.)
> >
> > Maybe caches need updating?
> >
>
> I reached out to our the website team and the statement they gave to
> rely to the community is:
>
> We're working on the Community 2.5.9 release and shall have it updated
> on the website very soon. Thank you for your patience and love to the
> OpenVPN Community and please come back to check our website later today.
>
>
> They also gave me a time of 11:30 am pst, which is about in about 5
> hours from now. And I am not happy with this response either.
>
> Arne

Thanks for the update! And congratulations on, and thanks for, the new release!

Jon


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Jonathan K. Bullard]

(Sorry for my earlier top-post.)

On Thu, Feb 16, 2023 at 7:51 AM Frank Lichtenheld  wrote:
>
> The OpenVPN community project team is proud to release OpenVPN 2.5.9. This is
> a small bugfix release.
>

Was this sent a bit early? There is no 2.5.9 tag at
https://github.com/OpenVPN/openvpn/tags.

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.5.9 released

[Jonathan K. Bullard]

Not yet seeing anything about 2.5.9 at
https://openvpn.net/community-downloads/. (From the New York City
metropolitan area.)

Maybe caches need updating?

Best regards,

Jon Bullard




On Thu, Feb 16, 2023 at 7:51 AM Frank Lichtenheld 
wrote:

> The OpenVPN community project team is proud to release OpenVPN 2.5.9. This
> is
> a small bugfix release.
>
> The Windows MSI installers are now built against OpenSSL 1.1.1t which
> contains
> several security fixes.
>
> List of changes in OpenVPN:
>
> 
>
> Source code and Windows installers can be downloaded from our download
> page:
>
> 
>
> Debian and Ubuntu packages are available in the official apt repositories:
>
> 
>
> On Red Hat derivatives we recommend using the Fedora Copr repository.
>
> 
>
> Regards,
> --
>   Frank Lichtenheld
>
>
> ___
> 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] [PATCH 7/7] add message about changing default values

[Jonathan K. Bullard]

Hi,

On Mon, Sep 13, 2021 at 8:37 AM Gert Doering  wrote:
>
> Hi,
>
> On Sat, Sep 04, 2021 at 11:56:29AM +0200, Antonio Quartulli wrote:
> > Add warning at startup to notify users about the change.
> [..]
> > +/* Give a general warning at the end of initialisation that defaults
> > + * have changed */
> > +msg(M_WARN, "Note that modernisation of defaults in OpenVPN 2.6 limits 
> > "
> > +"compatibility with old versions. See Changes.rst and "
> > +"--compat-mode in the manual for details.");
> >  }
>
> I have my doubts if this is a good way forward.
>
> This warning will be printed on *every single startup* on OpenVPN now.
>
> Is this useful?  Or will people just ignore it.  Like, "all of a sudden
> my Tunnelblick shows some giberrish in red at me, but the VPN is working,
> so let's just ignore all warnings now".

( Actually, Tunnelblick will show it in **yellow** : )

I don't think the warning will be very useful. Most Tunnelblick users
don't look at the log. Those who do usually ignore warnings. Those who
look at the log and don't ignore warnings often focus on ones which
sound scary but whose benefits usually outweigh the risks or ask why
the VPN works even though there are warnings. (Maybe there's less of a
distinction between warning and error in other languages than there is
in English? Or our translations aren't as clear about the
distinction?)

Tunnelblick warnings usually include a "do not warn about this again"
option, which the OpenVPN log can't include.


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Include utun device number in utun error messages

[Jonathan K. Bullard]

Hi,

On Sat, Jul 25, 2020 at 7:51 PM Arne Schwabe  wrote:
>
> For lack of a better API (or knowledge about a better API) we try to
> open utun devices on macOS by trying utun0 to utun255 and use the
> first one that works. On my Mac I have already 4 devices that
> do nothing but are just there and another VPN connection resulting in a
> number of error messages. This explicitly  shows in the log that we
> tried the devices instead of some unspecific error.
>
> This changes the log from:
>
> Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opened utun device utun5
>
> to
>
> Opening utun0 failed (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun1 failed (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun2 failed (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun3 failed (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opening utun4 failed (connect(AF_SYS_CONTROL)): Resource busy (errno=16)
> Opened utun device utun5

Feature-ACK. The failure messages have concerned some Tunnelblick
users. This _might_ help clarify things for them and it certainly
won't hurt.

I have not tested the code, but it looks fine.

Note that the last half of the patch consists only of whitespace
changes (starting at "@@ -5682,15 +5685,15 @@).

Note also that macOS itself creates some utun devices, which is why
the failures to open happen even on a clean install of macOS and only
OpenVPN. The number created depends on the version of macOS and the
Apple services such as iCloud Drive and Screen Sharing that are
enabled.

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: Unified success messages for setting mtu

[Jonathan K. Bullard]

Hi,

On Mon, Jul 6, 2020 at 11:43 AM Gert Doering  wrote:
>
> Acked-by: Gert Doering 
>
> Thanks :-) - given that this is somewhat trivial, I have not actually
> run a binary to look at the messages.  I have counted arguments and done
> a test build to see if new warnings show up (no).
>
> I *do* see an old warning...
>
> tun.c: In function 'windows_set_mtu':
> tun.c:5523:21: warning: format '%u' expects argument of type 'unsigned int', 
> but argument 5 has type 'DWORD {aka long unsigned int}' [-Wformat=]
>  msg(M_WARN, "TUN: Setting %s mtu failed: %s [status=%u if_index=%d]",

It's ok if this is only for Windows code (I assume it is because of
the name of the function) because x86 and ARM have the same
endian-ness and are the only Windows platforms (that I know of).
However, it would still be better to use "%lu" to avoid the warning
and to future-proof it for any _new_ Windows platform that's
different. (Although I admit Microsoft is unlikely to do that.)

Best regards,

Jon


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC] Challenges with OpenVPN and configuring DNS

[Jonathan K. Bullard]

Hi. There's a lot here and I haven't digested all of it, but have a
couple of comments about macOS and Tunnelblick, below.

On Tue, Jun 23, 2020 at 6:57 PM David Sommerseth
 wrote:
>
>
> Hi,
>
> Arne and I have discussed the challenge of DNS configuration and we have paid
> attention to a recent discussion here on the mailing list as well [1].  We
> have tried to consider various platforms and have a few proposals for unifying
> and documenting DNS configuration as much as possible.
>
> [1]
> 
> Message-Id: 
>
>
> DNS configuration has become fairly advanced in the later OS releases,
> compared to the traditional "send all requests to this DNS server" we're
> all very well used to.
>
> Scenarios we have considered:
>
>  * Exclusive DNS resolver
>All DNS lookup requests should go to a specified DNS server regardless
>of the host configuration prior to the VPN connection.
>
>  * Split-DNS
>Only selected "route domains" should use the provided DNS server
>
>  * Windows has it's own DOMAIN setting which may impact how it handles
>DNS and NetBios configurations
>
>  * Some platforms differentiates between "search domains" (which is the
>typical 'search' option in /etc/resolv.conf)  and "route domains" (which
>domains should use a specific DNS resolver)

Tunnelblick implements "search domains" by setting a list of macOS
"SearchDomains". It isn't well documented, but as I understand it, a
name that doesn't resolve is suffixed with the first "search domain"
in the list and the result is looked up. If that doesn't resolve, the
name is suffixed with the next "search domain" in the list, and the
process is repeated. Is that what "the typical 'search' option in
/etc/resolv.conf" does?

Currently Tunnelblick on macOS does not implement "route domains" —
but they are "on my list".



> For platform implementations we have considered the following:
>
> * macOS
>   Tunnelblick uses external scripts which are well tested and seems to
>   work fine.  Will it make sense to implement native DNS configuration
>   support into OpenVPN on macOS?  This might mean we need to link OpenVPN
>   against some Objective-C code to communicate directly with the network
>   configuration APIs.  It could also be possible to implement this as an
>   external plug-in, which extends OpenVPN's current behavior.

Building support for macOS network changes into OpenVPN would be a
challenge to maintain.

The combination of

 * Supporting Apple's annual release of a new version of macOS which
often changes the way changes to the network setup are done (probably
four times in the past ten years); and

 * Apple's terrible or nonexistent documentation; and

 * Supporting multiple versions of macOS that each use a different mechanism

means there's a lot of work to do. (I know, because I'm doing it : )

That said, it would be cleaner/nicer to implement it within OpenVPN or
as a plug-in, instead of having it happen in the "up", "down", and
"reconnect" scripts. I can't commit to being involved in working on
that, though I might provide comments or advice occasionally.

(As an aside, Apple tends to throw away stuff that works in favor of
new, shiny stuff and they do that all the time. They've been pushing
developers to use Swift, not Objective-C for a while now. Tunnelblick
has stuck with Objective-C, but it isn't clear how long Apple will
keep supporting it.  Even so, I agree that code for macOS is
integrated into OpenVPN, the code should be written in Objective-C.)

Best regards,

Jon


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jonathan K. Bullard]

Hi,

On Fri, Jul 3, 2020 at 3:39 AM Jan Just Keijser  wrote:
>
> Hi,
>
> On 02/07/20 23:04, David Sommerseth wrote:
> > On 30/06/2020 16:15, Jan Just Keijser wrote:
> >> hi,
> >>
> >> On 30/06/20 16:11, Gert Doering wrote:
> >>> Hi,
> >>>
> >>> On Tue, Jun 30, 2020 at 04:07:52PM +0200, Jan Just Keijser wrote:
>  @@ -5697,6 +5740,11 @@ build_dhcp_options_string(struct buffer *buf, 
>  const struct tuntap_options *o)
>    write_dhcp_u32_array(buf, 42, (uint32_t *)o->ntp, o->ntp_len, 
>  );
>    write_dhcp_u32_array(buf, 45, (uint32_t *)o->nbdd, o->nbdd_len, 
>  );
> 
>  +for (int i=0; i < o->domain_search_list_len; i++)
>  +{
>  +write_dhcp_search_str(buf, 119, o->domain_search_list[i], 
>  );
>  +}
> >>> I assume that this won't work.  In the DHCP answer, it must be a single
> >>> option with the concatenated list, not multiple answers with a single
> >>> domain name each.
> >>>
> >>> gert
> >>>
> >> see https://tools.ietf.org/html/rfc3397
> >>
> >> "
> >>
> >> In the above diagram, Searchstring is a string specifying the
> >> searchlist.  If the length of the searchlist exceeds the maximum
> >> permissible within a single option (255 octets), then multiple
> >> options MAY be used, as described in "Encoding Long Options in the
> >> Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396 
> >> ].
> >>
> >> "
> >>
> >>
> >> so you MAY use this option multiple times - and wireshark groks it fine. I 
> >> don't have a Windows 10
> >> client to test it against, however, so I am hoping that someone (Selva?) 
> >> can do that for me.
> >>
> > Hi,
> >
> > Can we please see this discussion also in context of this mail thread, which
> > tries to look a broader at this challenge?
> >
> > Message-Id: 
> > URL:
> > 
> >
> > One change in that RFC since last time is that we will move IV_PROTO to be
> > only about the OpenVPN wire protocol (features/settings only affecting
> > protocol for the communication between the OpenVPN end-points themselves).
> > The DNS settings and more related to host configuration and similar will be
> > moved into an IV_FEAT field.  Except of that, nothing else has changed from
> > the initial mail.
> >
> > The main purpose of that RFC is to ensure we handle DNS and --dhcp-options
> > consistently across all OpenVPN implementations we care about, and that we
> > document this properly.
> >
>
> I see one as an implementation issue (can we specify a particular DHCP
> option more than once) and one as an OpenVPN protocol issue.
> I fully agree that it's time to think about and overhaul the DNS
> settings for OpenVPN but I also believe that further abusing the option
> 'dhcp-option' is not the best way forward.

+1


>   The option 'dhcp-option'
> only really applies to the Windows tap-win adapter as that is the only
> adapter where you can use DHCP to add/change settings. AFAIK even the
> new win-tun adapter does not use DHCP for this. Hence the term 'dhcp-'
> is moot.

If you mean the term 'dhcp' should not be used in the name of the
option, I agree. Perhaps something like "interface-option" would be
better.

But the _option_ isn't only for Windows tap-win adaptor. The option's
arguments are passed to scripts via $foreign_option_* environment
variables (on macOS, at least, and I think on most or all platforms).
And the Tunnelblick scripts use them to modify network settings, sort
of as if they came from DHCP, but not actually using DHCP.


> Thus, moving forward, I'd be more in favor of overhauling this
> *completely* and review all 'dhcp-option' flags to see how we can
> a) specify then more logically and more neutrally
> b) implement these features for each of the different platforms:
>
> Windows+tap-win: use DHCP
> Windows+win-tun:   use netsh ?
> Linux:  use systemd? use scripts
> BSD: scripts? systemd?
> MacOS:   just copy what Jonathan is using ;)

+1 here, too, for overhauling this "completely".

I'll have further comment soon on the other thread:
> > Message-Id: 
> > URL:
> > 

Best regards,

Jon


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Patch] New man page corrections - windows-options.rst

[Jonathan K. Bullard]

Improves English diction and/or grammar of man page.

Acked-by: Jonathan K. Bullard 

On Tue, Jun 30, 2020 at 9:11 PM Richard Bonhomme  wrote:
>
> Signed-off-by: Richard Bonhomme 
> ---
>  doc/man-sections/windows-options.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/man-sections/windows-options.rst 
> b/doc/man-sections/windows-options.rst
> index 5ae7116c..72424d6b 100644
> --- a/doc/man-sections/windows-options.rst
> +++ b/doc/man-sections/windows-options.rst
> @@ -231,7 +231,7 @@ Windows-Specific Options
>directive is not specified, OpenVPN will use the SystemRoot environment
>variable.
>
> -  This option have changed behaviour in OpenVPN 2.3. Earlier you had to
> +  This option has changed behaviour since OpenVPN 2.3. Earlier you had to
>define ``--win-sys env`` to use the SystemRoot environment variable,
>otherwise it defaulted to :code:`C:\\WINDOWS`. It is not needed to use
>the ``env`` keyword any more, and it will just be ignored. A warning is
> @@ -239,7 +239,7 @@ Windows-Specific Options
>
>  --windows-driver drv
>Specifies which tun driver to use. Values are :code:`tap-windows6`
> -  (default) and :code:`wintun`.  This is Windows-only option.
> +  (default) and :code:`wintun`.  This is a Windows-only option.
>:code:`wintun`" requires ``--dev tun`` and the OpenVPN process to run
>elevated, or be invoked using the Interactive Service.
>
> --
> 2.17.1
>
>
>
> ___
> 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] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jonathan K. Bullard]

Hi,

On Sun, Jun 21, 2020 at 11:15 AM Selva Nair  wrote:
>
> Hi,
>
> On Sun, Jun 21, 2020 at 7:14 AM Gert Doering  wrote:
> >
> > Hi,
> >
> > going through OpenVPN threads that went stale - I think this is
> > actually a nice addition (read: other people have already asked
> > me if this can be done).
> >
> > On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote:
> > > So, for what it's worth, I've dusted off the patch again and rebased it
> > > to the current openvpn master tree. See attached. Note that I did only
> > > rudimentary testing, as I don't use Windows 10 a lot and I was testing
> > > using a mingw cross-compile only. In wireshark I *do* see that the
> > > correct DHCP offer is sent to the tap-win adapter.
> > >
> > > Also note that I implemented multiple search domains by separating them
> > > using semi-colons, e.g.
> > >
> > > --dhcp-option SEARCH example.com;example.org;example.nl;example.de
> > >
> > > etc as that was easier to implement
> >
> > The patch looks okay-ish on quick reading.
>
> Feature wise yes, but some improvements needed..
>
> I do not like that option format
>
> "example.com; example.org" with quotes will parse right and fail later
> on because of the space, for example. And, we support multiple
> statements of dhcp options like DNS, so this is counter-intuitive.
> It's only a little more work to support a more forgiving format.
>
> >
> > > Also note that I did not fully implement the RFC3397 encoding of the
> > > search list, as that requires one to merge domain names that occur more
> > > than once - that would have made the code far more complicated.
> >
> > Indeed.  I haven't looked at what other DHCP implementations do, but
> > "correct" encoding definitely sounds like quite a bit of extra code just
> > to save a few bytes on the wire - might come handy if you have many
> > subdomains of a long internal DNS domain, though, but this can be
> > added "if needed".
>
> Same as my thoughts, the encoding part could be kept simple as in here
> and possibly improved later. But option format is hard to change or
> deprecate.

I agree.


> > More interesting is the question "which option to use" - it should
> > be synchronized between openvpn platform handlers.  So if systemd-networkd
> > uses "SEARCH-DOMAIN" it would make sense to use that for windows
> > as well.
>
> I think we need both --- the current one retained as the connection
> specific suffix which would be just one entry and then this search
> list. As we allow multiple entries for DOMAIN right now, a user
> friendly approach would be to continue doing so but internally treat
> all but the first as a part of --dhcp-option DOMAIN-SEARCH. We could
> also deprecate the use of multiple entries in the dhcp-option DOMAIN
> keyword.

The man page says to use "DOMAIN" to set the"domain suffix", but there
is no documented way to specify the computer's domain. The man page
doesn't indicate that multiple --dhcp-option DOMAIN options are
allowed, but it specifically states that multiple DNS and WINS are
allowed (for example, "Repeat this option to set secondary DNS server
addresses").

(Note that bad formatting on the online version of the man page [1]
makes it hard to see that "DOMAIN" is allowed at all, since it is
merged into the prior paragraph. Also note that the opening paragraph
for the --dhcp-option section of the man page implies it is only for
Windows tap adaptors, which hasn't been true for at least 11 years!)

For many years, Tunnelblick has
 1. Accepted multiple SEARCH-DOMAIN or DOMAIN-SEARCH entries to set
the search domains, which is in keeping with the way multiple DNS and
WINS entries are interpreted.
 2. Ignored all but the last "--dhcp-option DOMAIN…" entry in $foreign_option_X.
 3. Used that last entry to set the computer's domain.
 4. Under certain conditions, prepended the search domains with that last entry.

Best regards,

Jon Bullard

[1] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/#


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [Openvpn-users] Multiple DNS search suffixes on Windows

[Jonathan K. Bullard]

Hi!

On Sun, Jun 21, 2020 at 7:15 AM Gert Doering  wrote:
>
> Hi,
>
> going through OpenVPN threads that went stale - I think this is
> actually a nice addition (read: other people have already asked
> me if this can be done).
>
> On Thu, Mar 05, 2020 at 01:53:12PM +0100, Jan Just Keijser wrote:
> > So, for what it's worth, I've dusted off the patch again and rebased it
> > to the current openvpn master tree. See attached. Note that I did only
> > rudimentary testing, as I don't use Windows 10 a lot and I was testing
> > using a mingw cross-compile only. In wireshark I *do* see that the
> > correct DHCP offer is sent to the tap-win adapter.
> >
> > Also note that I implemented multiple search domains by separating them
> > using semi-colons, e.g.
> >
> > --dhcp-option SEARCH example.com;example.org;example.nl;example.de
> >
> > etc as that was easier to implement
>
> The patch looks okay-ish on quick reading.
>
> > Also note that I did not fully implement the RFC3397 encoding of the
> > search list, as that requires one to merge domain names that occur more
> > than once - that would have made the code far more complicated.
>
> Indeed.  I haven't looked at what other DHCP implementations do, but
> "correct" encoding definitly sounds like quite a bit of extra code just
> to save a few bytes on the wire - might come handy if you have many
> subdomains of a long internal DNS domain, though, but this can be
> added "if needed".
>
>
> More interesting is the question "which option to use" - it should
> be synchronized between openvpn platform handlers.  So if systemd-networkd
> uses "SEARCH-DOMAIN" it would make sense to use that for windows
> as well.
>
> Is there an option in Tunnelblick to set MacOS DNS and search list?  If
> yes, what option do they use?

I apologize for not noticing this earlier. Two points to consider:

1. Tunnelblick does not accept "--dhcp-option SEARCH". Tunnelblick
accepted DOMAIN-SEARCH starting in 2013, but users kept trying to use
SEARCH-DOMAIN and then complaining when it didn't work, so in 2017
Tunnelblick started accepting also SEARCH-DOMAIN. If Windows starts
using "SEARCH" I suppose we can add that, too. (**Sigh**.)

2. As is the case with using --dhcp-option to set DNS and WINS
servers, Tunnelblick was designed to accept only one search domain per
option, so one would use "--dhcp-option SEARCH-DOMAIN example.com
--dhcp-option SEARCH-DOMAIN example.org --dhcp-option SEARCH-DOMAIN
example.de" to set those three search domains. Our "up" script accepts
multiple $foreign_option_X options and constructs appropriate
instructions to have macOS use all of them. Parsing multiple search
domains contained in one $foreign_option_X could be added but I'd
rather avoid that if possible. (We'd probably have to do that if
Windows does it. **Sigh**, again.)


 > Does anyone know about commercial VPN providers basing their clients
> on OpenVPN?

I don't think commercial VPN providers would use search domains. I
think search domains would be used more by universities, corporations,
etc. that want an easy way for their users to access their internal
servers.


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.4.9 released

[Jonathan K. Bullard]

Hi,

On Fri, Apr 17, 2020 at 9:22 PM Antonio Quartulli  wrote:
>
> Hi,
>
> On 18/04/2020 00:41, Jonathan K. Bullard wrote:
> > Hi,
> >
> > On Fri, Apr 17, 2020 at 5:35 PM Gert Doering  wrote:
> >>
> >> ... the new subkeys are just a few weeks old, so we need to publish
> >> a new key bundle with the new subkeys.
> >
> > So until a new security-keys-2020.asc (or whatever you will call it)
> > is published on the OpenVPN website, I can't verify the download?
> >
> > Of course, if the download was compromised, the website probably was,
> > so any key published on it is, too.
> >
> > Sigh.
>
> If the updated key was pushed to the keyserver (it should), you can
> delete and re-fetch it from the keyserver directly.

That worked, thanks,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.4.9 released

[Jonathan K. Bullard]

Hi,

On Fri, Apr 17, 2020 at 5:35 PM Gert Doering  wrote:
>
> ... the new subkeys are just a few weeks old, so we need to publish
> a new key bundle with the new subkeys.

So until a new security-keys-2020.asc (or whatever you will call it)
is published on the OpenVPN website, I can't verify the download?

Of course, if the download was compromised, the website probably was,
so any key published on it is, too.

Sigh.

Thanks for the info, though, Gert.

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.4.9 released

[Jonathan K. Bullard]

 IHi,

On Fri, Apr 17, 2020 at 8:47 AM Samuli Seppänen  wrote:
>
> The OpenVPN community project team is proud to release OpenVPN 2.4.9. It
> can be downloaded from here:
>
> 

I'm having trouble verifying 2.4.9.tar.gz with GPG. I'm pretty
clueless about gpg, but I think it may not have been signed with the
correct key.

When I try to verify the signature:

$ gpg -v --verify openvpn-2.4.9.tar.gz.asc openvpn-2.4.9.tar.gz
gpg: Signature made Fri Apr 17 07:18:44 2020 EDT
gpg:using RSA key 333D46306CF9D9F1F630DB8D96AEC408005D6BB4
gpg: Can't check signature: No public key

But I have the Security Mailing List GPG key (downloaded 2019-10-31)
and used it to verify earlier downloads [1]. I downloaded a fresh copy
of the key, but it is identical to my old one. I tried re-importing:

$ gpg --import security-key-2019.asc
gpg: key 12F5F7B42F2B01E7: "OpenVPN - Security Mailing List
" not changed
gpg: Total number processed: 1
gpg:  unchanged: 1

Which I interpret as "the identical key was already loaded".

$ gpg --list-public-keys --keyid-format LONG
pub   rsa4096/12F5F7B42F2B01E7 2017-02-09 [SC] [expires: 2027-02-07]
  F554A3687412CFFEBDEFE0A312F5F7B42F2B01E7
uid [ unknown] OpenVPN - Security Mailing List 

This is with gpg (GnuPG) 2.2.3, libgcrypt 1.8.1

Any suggestions?

Jon Bullard

[1] 2.4.8 verifies OK (although the key has now expired):

$ gpg --verify openvpn-2.4.8.tar.gz.asc  openvpn-2.4.8.tar.gz
gpg: Signature made Wed Oct 30 08:49:58 2019 EDT
gpg:using RSA key 82175D35AA8D0E8BDE5F4F9E5DC351805ACFEAC6
gpg: Good signature from "OpenVPN - Security Mailing List
" [unknown]
gpg: Note: This key has expired!
Primary key fingerprint: F554 A368 7412 CFFE BDEF  E0A3 12F5 F7B4 2F2B 01E7
 Subkey fingerprint: 8217 5D35 AA8D 0E8B DE5F  4F9E 5DC3 5180 5ACF EAC6


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2 2/2] When auth-user-pass file has no password, query the management

[Jonathan K. Bullard]

Hi,

On Mon, Mar 30, 2020 at 2:06 PM  wrote:
>
> From: Selva Nair 
>
> When only username is found in the file, redirect the auth-user-pass
> query to the management if management-query-passwords is enabled.
> Otherwise the user is prompted on console, if available, as before.
>
> This changes the behaviour for those who run from the command line,
> with --management-query-passwords, but still expect the prompt
> on the console.
>
> Note that the management will prompt for both username and password
> ignoring the username read from the file. As most GUIs can save the
> the username, this is a one-time inconvenience.
>
> Currently, the password is queried on the console (or systemd)
> in such cases. This is not sensible when console is not available
> (windows GUI, tunnelblick etc.) or when the log is redirected
> to a file on Windows (for some reason prompt goes to the log file).
>
> Trac # 757
>
> Signed-off-by: Selva Nair 
> ---
>
> v2: Following discussions with Jonathan and Gert, removed the dependence
> on stdout redirection and applied to all platforms.
>
>  src/openvpn/misc.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
> index 0d5ac30..546cd71 100644
> --- a/src/openvpn/misc.c
> +++ b/src/openvpn/misc.c
> @@ -261,6 +261,22 @@ get_user_pass_cr(struct user_pass *up,
>  {
>  strncpy(up->password, password_buf, USER_PASS_LEN);
>  }
> +/* The auth-file does not have the password: get both username
> + * and password from the management if possible.
> + * Otherwise set to read password from console.
> + */
> +#if defined(ENABLE_MANAGEMENT)
> +else if (management
> + && (flags & GET_USER_PASS_MANAGEMENT)
> + && management_query_user_pass_enabled(management))
> +{
> +msg(D_LOW, "No password found in %s authfile '%s'. Querying 
> the management", prefix, auth_file);
> +if (!auth_user_pass_mgmt(up, prefix, flags, auth_challenge))
> +{
> +return false;
> +}
> +}
> +#endif
>  else
>  {
>  password_from_stdin = 1;

Works for Tunnelblick, thanks!

One minor point: in all four places, plus in the email subject, "the
management" should be changed to "the management interface".

"Management interface" is the term that is used on the man page.

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/2] When auth-user-pass file has no password, query the management

[Jonathan K. Bullard]

On Mon, Mar 30, 2020 at 12:30 PM Selva Nair  wrote:

> That is, if management-query-passwords is enabled and auth file is
> missing password, query the management, not on console irrespective
> of other options and OS. If that's acceptable, I'll submit a v2.

That's fine with me (and Tunnelblick), thanks.

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/2] When auth-user-pass file has no password, query the management

[Jonathan K. Bullard]

Hi,

On Mon, Mar 30, 2020 at 11:12 AM Selva Nair  wrote:
> Jonathan K. Bullard  wrote:
> >
> > If the OS X command line user was using --management-query-passwords
> > (as Tunnelblick does), they wouldn't see the password prompt on
> > /dev/tty, would they?
>
> In case of auth-file missing password, they would see it on /dev/tty
> on linux, and I would guess on OSX as well, but I've not checked.

The password prompt appears on /dev/tty on OS X only if --daemon is not used.

If --daemon and --management-query-passwords are used but --askpass is
not (whether or not --auth-nocache is also used), which is typical for
a Tunnelblick configuration on OS X, the following appears in the log:

 neither stdin nor stderr are a tty device and you have neither a
  controlling tty nor systemd - can't ask for 'Enter Auth Password:'.
  If you used --daemon, you need to use --askpass to make
  passphrase-protected keys work, and you can not use
  --auth-nocache.
 Exiting due to fatal error

if --daemon, --management-query-passwords, and --askpass are all used
(whether or not --auth-nocache is used), you get:

 Need password(s) from management interface, waiting...

If Windows GUI uses --daemon, that could be an additional requirement
that would work for Tunnelblick and OS X, which would mean one less
incompatibility between Windows and OS X.

Or it could test for Windows || (OS X && --daemon).

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/2] When auth-user-pass file has no password, query the management

[Jonathan K. Bullard]

Hi,

On Sun, Mar 29, 2020 at 7:58 PM Selva Nair  wrote:
>
> Hi,
>
> On Sun, Mar 29, 2020 at 7:13 PM Jonathan K. Bullard  
> wrote:

> > On a Mac using Tunnelblick (which uses the management interface with
> > management-query-passwords enabled), if the auth-user-pass file
> > contains only the password (and a LF), then the following occurs:
> >
> >  neither stdin nor stderr are a tty device and you have neither a
> > controlling tty nor systemd - can't ask for 'Enter Auth Password:'.
> > If you used --daemon, you need to use --askpass to make
> > passphrase-protected keys work, and you can not use --auth-nocache.
> >  Exiting due to fatal error
>
> In those cases it looks obviously wrong to use auth-file with username
> only, and I would consider that a user error. The purpose of
> my patch was to handle only some naive usages where the user
> expects the console prompt to get automatically directed to the GUI.
> Indeed, that does happen (from user's POV) for all cases except user-pass
> with only username in a file.
>
> But I agree, we should do something like this for other GUIs such as
> tunnelblick too.
>
> >
> > Note: Tunnelblick uses the "--log" option to redirect output to a
> > file. I am assuming that's what is meant by "stdout is redirected to a
> > log file".
>
> Yes, that's right. However, that logic wont be proper on OS-X, would it?
> Command line users who use --log can still see password
> prompt on /dev/tty. We'll be breaking that behaviour.

If the OS X command line user was using --management-query-passwords
(as Tunnelblick does), they wouldn't see the password prompt on
/dev/tty, would they? Your patch checks for that, so wouldn't you only
need to change
 && defined(_WIN32)
to something like
 && (defined(_WIN32) || TARGET_OSX)
 (and add OS X to the comment at the start of the patch).


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/2] When auth-user-pass file has no password, query the management

[Jonathan K. Bullard]

Hi,

On Sun, Mar 29, 2020 at 4:34 PM  wrote:
>
> From: Selva Nair 
>
> If only username is found in the file, redirect the auth-user-pass
> query to the management on Windows if (i) management-query-passwords
> is enabled and (ii) stdout is redirected to a log file. These
> restrictions avoid regressive behaviour: those running from the
> command line will continue to get the prompt on the console
> and if both username and password are in the file those will
> continue to get used.
>
> Note that the management will prompt for both username and password
> ignoring the username read from the file. As the GUI saves the
> username, this is a one-time inconvenience.
>
> Currently, the password is queried on the console (or systemd)
> in such cases. This is not sensible on windows if log file is
> redirected (prompt goes to the log file), or the console
> is not available as happens when the GUI is in use.

Why only Windows? I'd like this for macOS, too!

On a Mac using Tunnelblick (which uses the management interface with
management-query-passwords enabled), if the auth-user-pass file
contains only the password (and a LF), then the following occurs:

 neither stdin nor stderr are a tty device and you have neither a
controlling tty nor systemd - can't ask for 'Enter Auth Password:'.
If you used --daemon, you need to use --askpass to make
passphrase-protected keys work, and you can not use --auth-nocache.
 Exiting due to fatal error

Note: Tunnelblick uses the "--log" option to redirect output to a
file. I am assuming that's what is meant by "stdout is redirected to a
log file".

It would be nice to have the same behavior on both Windows and Mac.
For Tunnelblick, too, the username from the file would be lost but, as
with the Windows GUI, the user can opt to save it so it isn't asked
for again.

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Removing --disable-server option from OpenVPN

[Jonathan K. Bullard]

Oops.

On Wed, Sep 18, 2019 at 6:54 AM Jonathan K. Bullard  wrote:
>
> Hi,
>
> On Wed, Sep 18, 2019 at 6:38 AM Samuli Seppänen  wrote:
> >
> > Hi,
> >
> > We are considering removing the --disable-server option from OpenVPN in 2.5.
> >
> > Do you use (and need) it, or know of somebody using (and needing) it?
>
> As far as I know, it is not used by any Tunnelblick users.
>
> Also, note that it doesn't appear on the 2.4 man page [1]. (Even
> substituting "–" for "--".)
>
> Best regards,
>
> Jon Bullard
>
> [1] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

I misunderstood -- it's a compile-time option, not an OpenVPN option.
Tunnelblick doesn't use it for our builds.

Sorry for the noise.

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Removing --disable-server option from OpenVPN

[Jonathan K. Bullard]

Hi,

On Wed, Sep 18, 2019 at 6:38 AM Samuli Seppänen  wrote:
>
> Hi,
>
> We are considering removing the --disable-server option from OpenVPN in 2.5.
>
> Do you use (and need) it, or know of somebody using (and needing) it?

As far as I know, it is not used by any Tunnelblick users.

Also, note that it doesn't appear on the 2.4 man page [1]. (Even
substituting "–" for "--".)

Best regards,

Jon Bullard

[1] https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 0/5] Implement additional two step authentication methods

[Jonathan K. Bullard]

Hi,

On Thu, Jun 13, 2019 at 2:35 PM Selva Nair  wrote:
>
> Hi
>
> On Thu, Jun 13, 2019 at 10:42 AM Arne Schwabe  wrote:
> >
> > These patches mainly implement forwarding passing/forwarding extra
> > messages between management interface on server and client side.
> >
> > These new extra messages can be used to implement a two step
> > authentication like TOTP (Google Authenticator) or web based
> > out of band (like SAML).
> >
> > Since this requires a tight integration on both client and
> > server side, it is currently only supported with the management
> > interface.
> >
> > Arne Schwabe (5):
> >   Implement parsing and sending INFO and INFO_PRE control messages
> >   Implement forwarding client CR_RESPONSE messages to management
> >   Implement support for signalling IV_SSO to server
> >   Implement sending response to challenge via CR_RESPONSE
> >   Implement sending SSO challenge to clients
>
> I haven't looked at the patches, but a quick question. I haven't come across 
> any
> 2FA mechanisms that cannot be handled (in principle) by the current static an
> dynamic CR in OpenVPN.

+1. What functionality does this new mechanism add?

Tunnelblick implements 2FA through the management interface using the
existing static and dynamic challenge-response mechanism. For a
dynamic challenge, for example. Tunnelblick gets a response from the user in
a popup window or from a user-specified script. (A script is usually
used to get the response from hardware devices.)

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Fwd: [PATCH] Remove deprecated --compat-x509-names and --no-name-remapping

[Jonathan K. Bullard]

Sorry, sent to Steffan but not the list:

-- Forwarded message -
From: Jonathan K. Bullard 
Date: Wed, Oct 24, 2018 at 7:00 AM
Subject: Re: [Openvpn-devel] [PATCH] Remove deprecated
--compat-x509-names and --no-name-remapping
To: Steffan Karger 


Hi,

The actual option name is --compat-names, not --compat-x509-names, so
the subject line of this email should be

 "[Openvpn-devel] [PATCH] Remove deprecated --compat-names and
--no-name-remapping"

The existing source code (as of commit 2b15c11) uses compat-names
everywhere except one place, which is in a message (shown in the
patch, see below).

In addition, https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
says --compat-names was deprecated in 2.3 and removed in 2.5. There is
no mention of --compat-x509-names.


On Wed, Oct 24, 2018 at 6:13 AM Steffan Karger
 wrote:
>
> As promised, remove these options for OpenVPN 2.5.
>
> If a user still uses these, print an error that the user should update it's
> configuration. Just printing a warning would cause much more confusing
> errors, somewhere in middle of a failed connection attempt because the
> (non-compat) names no longer match the expected names.



> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -2422,10 +2422,6 @@ options_postprocess_verify_ce(const struct options 
> *options, const struct connec
>  {
>  msg(M_USAGE, "--stale-routes-check requires --mode server");
>  }
> -if (compat_flag(COMPAT_FLAG_QUERY | COMPAT_NO_NAME_REMAPPING))
> -{
> -msg(M_USAGE, "--compat-x509-names no-remapping requires --mode 
> server");
> -}
>  }
>  #endif /* P2MP_SERVER */

That's the sole reference to --compat-x509-names in the source code
that I found (as of commit 2b15c11).

Best regards,

Jon Bullard


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] Clarify and expand management interface documentation

[Jonathan K. Bullard via Openvpn-devel]

Clarify and expand the documentation for the management interface:

* Add examples of static and dynamic challenge/response sequences in
the "COMMAND -- password and username" section.

* Expand the "Challenge/Response" section with more detail.

* Use "management interface client" throughout (instead of "management
client", which was used in several places previously).

* Clarify when both a username and password are needed, not just a
username or a password.

* Clarify that an exit with a fatal error for a dynamic C/R will occur
only if "--auth-retry none" (the default) is in effect.

* Fix a typo. ("posesses" => "possesses").

Signed-off-by: Jonathan K. Bullard 
---
v2:
 * Incorporate Selva Nair’s suggestions (thanks!).
 * Remove incorrect quotes in Example 8.
 * Use "base 64" throughout instead of "base64".

 doc/management-notes.txt | 232 ---
 1 file changed, 159 insertions(+), 73 deletions(-)

diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index 96470d0..3935715 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -12,7 +12,8 @@ as a client or server.

 The management interface is implemented using a client/server TCP
 connection or unix domain socket where OpenVPN will listen on a
-provided IP address and port for incoming management client connections.
+provided IP address and port for incoming management interface client
+connections.

 The management protocol is currently cleartext without an explicit
 security layer.  For this reason, it is recommended that the
@@ -104,7 +105,7 @@ be in the list, and it will cause the management interface
 to save the "forget-passwords" string in its list of echo
 parameters.

-The management client can use "echo all" to output the full
+The management interface client can use "echo all" to output the full
 list of echoed parameters, "echo on" to turn on real-time
 notification of echoed parameters via the ">ECHO:" prefix,
 or "echo off" to turn off real-time notification.
@@ -118,10 +119,10 @@ like this:

 Essentially the echo command allowed us to pass parameters from
 the OpenVPN server to the OpenVPN client, and then to the
-management client (such as a GUI).  The large integer is the
+management interface client (such as a GUI).  The large integer is the
 unix date/time when the echo parameter was received.

-If the management client had issued the command "echo on",
+If the management interface client had issued the command "echo on",
 it would have enabled real-time notifications of echo
 parameters.  In this case, our "forget-passwords" message
 would be output like this:
@@ -141,8 +142,8 @@ COMMAND -- exit, quit

 Close the managment session, and resume listening on the
 management port for connections from other clients. Currently,
-the OpenVPN daemon can at most support a single management client
-any one time.
+the OpenVPN daemon can at most support a single management interface
+client any one time.

 COMMAND -- help
 ---
@@ -167,7 +168,7 @@ The hold flag setting is persistent and will not
 be reset by restarts.

 OpenVPN will indicate that it is in a hold state by
-sending a real-time notification to the management
+sending a real-time notification to the management interface
 client, the parameter indicates how long OpenVPN would
 wait without UI (as influenced by connect-retry exponential
 backoff). The UI needs to wait for releasing the hold if it
@@ -275,7 +276,7 @@ COMMAND -- password and username
   OpenVPN is indicating that it needs a password of type
   "Private Key".

-  The management client should respond to this query as follows:
+  The management interface client should respond as follows:

 password "Private Key" foo

@@ -283,8 +284,8 @@ COMMAND -- password and username

 >PASSWORD:Need 'Auth' username/password

-  OpenVPN needs a --auth-user-pass password.  The management
-  client should respond:
+  OpenVPN needs a --auth-user-pass username and password.  The
+  management interface client should respond:

 username "Auth" foo
 password "Auth" bar
@@ -307,7 +308,8 @@ COMMAND -- password and username
 >PASSWORD:Verification Failed: 'Private Key'

   Example 4: The --auth-user-pass username/password failed,
-  and OpenVPN is exiting:
+  and OpenVPN will exit with a fatal error if '--auth-retry none'
+  (which is the default) is in effect:

 >PASSWORD:Verification Failed: 'Auth'

@@ -322,6 +324,37 @@ COMMAND -- password and username

 >PASSWORD:Auth-Token:foobar

+  Example 7: Static challenge/response:
+
+>PASSWORD:Need 'Auth' username/password SC:1,Please enter token PIN
+
+  OpenVPN needs an --auth-user-pass username and password and the
+  response to a challenge. The u

Re: [Openvpn-devel] [PATCH] Clarify and expand management interface documentation

[Jonathan K. Bullard via Openvpn-devel]

Thanks, Selva. I agree with all of your comments except two, details below:

On August 2, 2018 11:32 AM, Selva Nair  wrote:

> >  >NEED-OK:Need 'token-insertion-request' confirmation MSG:Please insert 
> > your cryptographic token
> >
> >
> > -   The management client, if it is a GUI, can flash a dialog
> >
> > -   The management interface client, if it is a GUI, can flash a dialog
> > box containing the text after the "MSG:" marker to the user.
> > When the user acknowledges the dialog box,
> >
> >
> > -   the management client can issue this command:
> >
> > -   the management interface client can issue this command:
>
> can issue should be "must issue" isn't it?

Other examples use "should", which I like better.


>
> >   needok token-insertion-request ok
> >
> >
> > or
> > @@ -486,10 +516,10 @@ Example:
> >
> >  >NEED-STR:Need 'name' input MSG:Please specify your name
> >
> >
> > -   The management client, if it is a GUI, can flash a dialog
> >
> > -   The management interface client, if it is a GUI, can flash a dialog
> > box containing the text after the "MSG:" marker to the user.
> > When the user acknowledges the dialog box,
> >
> >
> > -   the management client can issue this command:
> >
> > -   the management interface client can issue this command:
>
> Same here -- clarify that a response must be provided?

Same here : ) -- other examples use "should", which I like better.


I'll send a v2 incorporating your other comments soon.

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Clarify and expand management interface documentation

[Jonathan K. Bullard via Openvpn-devel]

Clarify and expand the documentation for the management interface:

* Add examples of static and dynamic challenge/response sequences in
the "COMMAND -- password and username" section.

* Expand the "Challenge/Response" section with more detail.

* Use "management interface client" throughout (instead of "management
client", which was used in several places previously).

* Clarify when both a username and password is needed, not just a
username or a password.

* Clarify that an exit with a fatal error for a dynamic C/R will occur
only if "--auth-retry none" (the default) is in effect.

* Update the list of UIs that support challenge/response.

* Fix a typo. ("posesses" => "possesses").

Signed-off-by: Jonathan K. Bullard 
---
 doc/management-notes.txt | 213 ---
 1 file changed, 147 insertions(+), 66 deletions(-)

diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index 96470d0..174b3bf 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -12,7 +12,8 @@ as a client or server.

 The management interface is implemented using a client/server TCP
 connection or unix domain socket where OpenVPN will listen on a
-provided IP address and port for incoming management client connections.
+provided IP address and port for incoming management interface client
+connections.

 The management protocol is currently cleartext without an explicit
 security layer.  For this reason, it is recommended that the
@@ -104,7 +105,7 @@ be in the list, and it will cause the management interface
 to save the "forget-passwords" string in its list of echo
 parameters.

-The management client can use "echo all" to output the full
+The management interface client can use "echo all" to output the full
 list of echoed parameters, "echo on" to turn on real-time
 notification of echoed parameters via the ">ECHO:" prefix,
 or "echo off" to turn off real-time notification.
@@ -118,10 +119,10 @@ like this:

 Essentially the echo command allowed us to pass parameters from
 the OpenVPN server to the OpenVPN client, and then to the
-management client (such as a GUI).  The large integer is the
+management interface client (such as a GUI).  The large integer is the
 unix date/time when the echo parameter was received.

-If the management client had issued the command "echo on",
+If the management interface client had issued the command "echo on",
 it would have enabled real-time notifications of echo
 parameters.  In this case, our "forget-passwords" message
 would be output like this:
@@ -141,8 +142,8 @@ COMMAND -- exit, quit

 Close the managment session, and resume listening on the
 management port for connections from other clients. Currently,
-the OpenVPN daemon can at most support a single management client
-any one time.
+the OpenVPN daemon can at most support a single management interface
+client any one time.

 COMMAND -- help
 ---
@@ -167,7 +168,7 @@ The hold flag setting is persistent and will not
 be reset by restarts.

 OpenVPN will indicate that it is in a hold state by
-sending a real-time notification to the management
+sending a real-time notification to the management interface
 client, the parameter indicates how long OpenVPN would
 wait without UI (as influenced by connect-retry exponential
 backoff). The UI needs to wait for releasing the hold if it
@@ -275,7 +276,7 @@ COMMAND -- password and username
   OpenVPN is indicating that it needs a password of type
   "Private Key".

-  The management client should respond to this query as follows:
+  The management interface client should respond as follows:

 password "Private Key" foo

@@ -283,8 +284,8 @@ COMMAND -- password and username

 >PASSWORD:Need 'Auth' username/password

-  OpenVPN needs a --auth-user-pass password.  The management
-  client should respond:
+  OpenVPN needs a --auth-user-pass username and password.  The
+  management interface client should respond:

 username "Auth" foo
 password "Auth" bar
@@ -307,7 +308,8 @@ COMMAND -- password and username
 >PASSWORD:Verification Failed: 'Private Key'

   Example 4: The --auth-user-pass username/password failed,
-  and OpenVPN is exiting:
+  and OpenVPN will exit with a fatal error if '--auth-retry none'
+  (which is the default) is in effect:

 >PASSWORD:Verification Failed: 'Auth'

@@ -322,6 +324,34 @@ COMMAND -- password and username

 >PASSWORD:Auth-Token:foobar

+  Example 7: Static challenge/response:
+
+>PASSWORD:Need 'Auth' username/password SC:1,Please enter token PIN
+
+  OpenVPN needs an --auth-user-pass username and password and the
+  response to a challenge. The user's response to "Please enter
+  token PIN" should be obtained and included in the mana

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

Hi,

On Tue, Jul 24, 2018 at 12:02 AM, Selva Nair  wrote:
> Hi,
>
> On Mon, Jul 23, 2018 at 10:58 PM, Jonathan K. Bullard
>  wrote:
>> I was testing Tunnelblick with Selva's C/R server and config (thanks
>> again for that) and there was a problem. Maybe I'm (still)
>> misunderstanding something, but a SIGUSR1 restart asks for the normal
>> username/password instead of a static C/R.
>>
>> That is, the first thing after the restart is ">PASSWORD:Need 'Auth'
>> username/password" instead of ">PASSWORD:Need 'Auth' username/password
>> SC:1,Type something (e.g., hello): ".
>
> I think that's a side effect of my test config using both static challenge and
> dynamic challenge together. Not a realistic use case, I suppose. I did
> that to keep
> the server side verify simple for a quick validation of patches that
> touch user-auth.

OK; makes sense.


> But it was probably not a good approach for properly testing what happens on
> signals or during TLS renegotiation.

I was testing more than the test was designed to do, so that's understandable.


> If you wish I can amend my server side verify script so that you can test
> static and dynamic challenge each separately.

That would be great, but don't do it just for me. If you do it for
yourself, let me know, though, and I'll try it.


>> Should Tunnelblick save the static challenge info (like it saves the
>> dynamic challenge info) and use it again whenever it sees a
>> ">PASSWORD:Need 'Auth' username/password"? (Except when there is also
>> a pending dynamic challenge, in which case it would use that instead.)

(I tried doing that and all worked well, so I was thinking that was it.)


> Normally SIGUSR1 restart should re-prompt with the static challenge if in use.

OK, thanks. I won't commit the code that saves and reuses the static C/R info.


>> Also, there's an oddity (that doesn't cause a problem) in that the
>> first thing Tunnelblick sees over the management interface for the
>> original connection is "ENTER PASSWORD:SUCCESS: password is correct"
>> -- that comes even before ">INFO:OpenVPN Management Interface Version
>> 1 -- type 'help' for more info", and long before any username or
>> password has been entered.
>
> The ENTER PASSWORD: is for the management-password, isn't it?

Of course it is. Mystery solved, thanks!


Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

Hi,

On Mon, Jul 23, 2018 at 10:31 PM, Selva Nair  wrote:
> On Sat, Jul 21, 2018 at 1:21 PM, Jonathan K. Bullard
>  wrote:
>
>> Some, perhaps including Selva's $payingCustomer, may not want to use
>> Tunnelblick betas or use OpenVPN 2.5 until it is released.
>
> I missed this last time... Its Gert who has $$payingCustomer(s) :)

Oops, sorry. (Sorry you don't have $payingCustomers, too : )

Oh, and sorry for my top-post, too : (

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

I was testing Tunnelblick with Selva's C/R server and config (thanks
again for that) and there was a problem. Maybe I'm (still)
misunderstanding something, but a SIGUSR1 restart asks for the normal
username/password instead of a static C/R.

That is, the first thing after the restart is ">PASSWORD:Need 'Auth'
username/password" instead of ">PASSWORD:Need 'Auth' username/password
SC:1,Type something (e.g., hello): ".

Should Tunnelblick save the static challenge info (like it saves the
dynamic challenge info) and use it again whenever it sees a
">PASSWORD:Need 'Auth' username/password"? (Except when there is also
a pending dynamic challenge, in which case it would use that instead.)

Also, there's an oddity (that doesn't cause a problem) in that the
first thing Tunnelblick sees over the management interface for the
original connection is "ENTER PASSWORD:SUCCESS: password is correct"
-- that comes even before ">INFO:OpenVPN Management Interface Version
1 -- type 'help' for more info", and long before any username or
password has been entered.

Once I get everything working (and I understand it myself), I plan to
submit a patch to doc/management-notes.txt that will (I hope) clarify
the C/R documentation.

Thanks,

Jon

On Thu, Jul 19, 2018 at 4:22 PM, Selva Nair  wrote:
> Hi,
>
> Here is the config. There are no secrets, so just input anything
> against the username/password/static challenge prompts (use short
> non-empty strings). For dynamic challenge, the answer must be correct
> for the connection to succeed.
>
> If the server is down please ping me.
>
> Selva
>
> On Thu, Jul 19, 2018 at 3:14 PM, Gert Doering  wrote:
>> Hi,
>>
>> On Thu, Jul 19, 2018 at 02:38:55PM -0400, Selva Nair wrote:
>>> On Thu, Jul 19, 2018 at 1:52 PM, Gert Doering  wrote:
>>> > On Thu, Jul 19, 2018 at 11:43:17AM -0400, Jonathan K. Bullard wrote:
>>> >> Thank you, Selva! (Now all I need to do is get it working!)
>>> >
>>> > Looking very much forward to see this happen :-)
>>> >
>>> > ($payingCustomer )
>>>
>>> Send some ??/$$ from $payingCustomer this way :)
>>
>> I might elicit some funding for Beer at the Hackathon... *tempt*
>>
>> (They do already sponsor our fun - all my buildslaves run on their vmware
>> farm and eat their bandwith... :-) - just no direct flow of money)
>>
>>> Jon: I have a server for testing static and dynamic challenge. If
>>> interested I can send you a config. Or use access server with a free
>>> test license. Mine will just challenge with 1 + 1 = ? kind of
>>> questions, nothing fancy.
>>
>> Interest!  (Though I might actually have the config already, just
>> never came around to work on it)
>>
>> gert
>> --
>> "If was one thing all people took for granted, was conviction that if you
>>  feed honest figures into a computer, honest figures come out. Never doubted
>>  it myself till I met a computer with a sense of humor."
>>  Robert A. Heinlein, The Moon is a Harsh Mistress
>>
>> Gert Doering - Munich, Germany 
>> g...@greenie.muc.de

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

Hi,

On Thu, Jul 19, 2018 at 2:38 PM, Selva Nair  wrote:
> Jon: I have a server for testing static and dynamic challenge. If
> interested I can send you a config. Or use access server with a free
> test license. Mine will just challenge with 1 + 1 = ? kind of
> questions, nothing fancy.

Thanks, Selva! Your testing server worked fine and I have Tunnelblick
doing dynamic challenge/response properly now.

However, dynamic C/R needs to include '--auth-retry interact' to work
because the default is to fail fatally. From what I understand, the
configs generated by Open Access Server don't include '--auth-retry
interact', but apparently OpenVPN GUI for Windows forces that option
because it can assume that it is always being used interactively.
Tunnelblick can't assume that because it can be and is used
non-interactively (for example. to connect to a VPN when the computer
starts up and nobody is logged in to interact with).

I can think of four ways to deal with this problem:

 1. Have Tunnelblick require that the user include 'auth-retry
interact' in the OpenVPN configuration file.

 2. Have Tunnelblick guess if the configuration is interactive and, if
it is, to include '--auth-retry interact' in the command line when
starting OpenVPN.

 3. Have Tunnelblick send 'auth-retry interact' through the management
interface as soon as it sees a ">PASSWORD:Verification Failed: 'Auth'
['CRV…" message.

 4. Patch OpenVPN so that the connection will be restarted instead of
getting a fatal error if the error message starts with
">PASSWORD:Verification Failed: 'Auth' ['CRV", ignoring --auth-retry.

The problem with 1 is that it means a Windows config will not work
with Tunnelblick unless the config is changed. I could add a checkbox
to enable it, or to disable it, but that's a pain for users and
clutters up the GUI.

The problem with 2 is that if the guess is incorrect it will break
existing setups and cause them to loop trying to connect instead of
simply failing. I could add a checkbox to enable it, or to disable it,
but that's a pain for users and clutters up the GUI.

The problem with 3 is that it may not work, or it may work only
sometimes because of a race between OpenVPN processing the failure
message and processing the 'auth-retry interact' from the management
interface.

One problem I see with 4 is that I don't think that OpenVPN code
(other than in OpenVPN GUI) actually "knows" about dynamic C/R. It
looks to me to be simply a convention between the OpenVPN GUI (and
other GUIs) and the scripts that run on the OpenVPN server. It would
also break a dynamic C/R setup in which 'auth-retry nointeract' was
specified, or in which no 'auth-retry' was included, but they wouldn't
be working setups anyway.

Another problem with 4 is that presumably it wouldn't appear until
OpenVPN 2.5, which means that it Tunnelblick would require OpenVPN 2.5
(which is included in Tunnelblick betas) for dynamic C/R to work.
Some, perhaps including Selva's $payingCustomer, may not want to use
Tunnelblick betas or use OpenVPN 2.5 until it is released.

The good things about 4 are that it would be a pretty small patch (I
think) and it would "automatically" fix what I consider to be an
OpenVPN configuration error.

4 is the best solution from a narrow thinking-only-of-Tunnelblick
perspective. Would you all consider a patch that does 4?

Best regards, and thanks for all your help,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

Hi Arne,

(For some reason Gmail put your post in my spam folder, so I just saw it now.)

On Thu, Jul 19, 2018 at 11:49 AM, Arne Schwabe  wrote:
> Am 19.07.18 um 17:43 schrieb Jonathan K. Bullard:
>> Thank you, Selva! (Now all I need to do is get it working!)
>>
>
> If you do all that stuff, be sure to also look at static-challenge that
> can be part of openvpn files, e.g.
>
> static-challenge "Please enter your gauth code" 1

Support for static challenge is in the latest Tunnelblick beta
(released yesterday) and works as far as I can tell. Dynamic is also
in the beta, but doesn't work because I completely misunderstood how
it was supposed to work, as evidenced by this thread.

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

Hi, Selva,

On Thu, Jul 19, 2018 at 2:38 PM, Selva Nair  wrote:
>> Jon: I have a server for testing static and dynamic challenge. If
> interested I can send you a config. Or use access server with a free
> test license. Mine will just challenge with 1 + 1 = ? kind of
> questions, nothing fancy.

Thanks for the offer. Configurations for testing both static and
dynamic challenge would be great. Please send them (or directions for
downloading them).

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

Thank you, Selva! (Now all I need to do is get it working!)

Best regards,

Jon


On Thu, Jul 19, 2018 at 11:39 AM, Selva Nair  wrote:
> Hi,
>
> On Thu, Jul 19, 2018 at 10:48 AM, Jonathan K. Bullard
>  wrote:
>> Thank you very much, Selva.
>>
>> On Wed, Jul 18, 2018 at 10:48 PM, Selva Nair  wrote:
>> 
>>> There are two messages involved:
>>>
>>> 1. First comes the fake auth failure message which contains the
>>> challenge string. The format of this is as you have quoted above. The
>>> single quoted string between the square brackets is what is actually
>>> sent by the server. This should be parsed as
>>>
>>> CRV1:flags:state_id:base64_username:challenge
>>> (note that there is no colon at the end)
>>>
>>> So in the above example
>>> flags = R,E
>>> state_id = Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6I
>>> base64_username = Y3Ixh
>>> challenge = Please enter token PIN:
>>>
>>> In this case the last colon is a part of the challenge as its not a
>>> part of the protocol.
>>>
>>> As the daemon thinks auth failed, this will trigger a restart. On
>>> restart the client openvpn daemon will prompt for username password as
>>> usual. So
>>>
>>> 2. The usual auth prompt comes as
>>>
>>>>PASSWORD:Need 'Auth' username
>>>>PASSWORD:Need 'Auth' password
>>>
>>> The GUI should remember that this prompt follows the
>>> verification-failure message that contained a CRV1 challenge and be
>>> ready to respond accordingly. And should be responded to in the same
>>> format as usual user-auth response but this time with the decoded
>>> username as username and the specially formatted challenge response
>>> (see below) as the password.
>>
>> I  _completely_  misunderstood how this works! I apologize for being so 
>> dense.
>>
>> Can you confirm that the following is correct?
>>
>>  1. When the GUI gets a ">PASSWORD:Verification Failed: 'Auth'
>> ['CRV1:…" message, it just stores the info.
>>
>>  2. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth'
>> username" request, it responds with the decoded username from the
>> stored info.
>>
>>  3. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth'
>> password" request, it asks the user for a password (using the prompt
>> from the info) and sends that back with the "state_id" from the stored
>> info and formatted as described.
>>
>
> Yes, yes and partially yes :) -- instead of each time, make it the "first 
> time".
> (see below)
>
>>  4. Any later ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…"
>> messages overwrite the old info the GUI stored.
>>
>
> Yes.
>
>> Or do 2. and 3. only happen once, and after that responses to
>> ">PASSWORD:Need 'Auth' username" and ">PASSWORD:Need 'Auth' password"
>> should revert back to the normal behavior until another
>> ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" message is received?
>
> One should revert back to the usual auth-user-pass state after
> responding to the challenge. So, save the challenge and associated
> info on receiving it and clear it on using it. Then the logic would
> be: if a saved challenge is present use it to "construct" the response
> for 'Auth' requests, else use the usual auth-user-pass procedure.
>
> Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

Thank you very much, Selva.

On Wed, Jul 18, 2018 at 10:48 PM, Selva Nair  wrote:

> There are two messages involved:
>
> 1. First comes the fake auth failure message which contains the
> challenge string. The format of this is as you have quoted above. The
> single quoted string between the square brackets is what is actually
> sent by the server. This should be parsed as
>
> CRV1:flags:state_id:base64_username:challenge
> (note that there is no colon at the end)
>
> So in the above example
> flags = R,E
> state_id = Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6I
> base64_username = Y3Ixh
> challenge = Please enter token PIN:
>
> In this case the last colon is a part of the challenge as its not a
> part of the protocol.
>
> As the daemon thinks auth failed, this will trigger a restart. On
> restart the client openvpn daemon will prompt for username password as
> usual. So
>
> 2. The usual auth prompt comes as
>
>>PASSWORD:Need 'Auth' username
>>PASSWORD:Need 'Auth' password
>
> The GUI should remember that this prompt follows the
> verification-failure message that contained a CRV1 challenge and be
> ready to respond accordingly. And should be responded to in the same
> format as usual user-auth response but this time with the decoded
> username as username and the specially formatted challenge response
> (see below) as the password.

I  _completely_  misunderstood how this works! I apologize for being so dense.

Can you confirm that the following is correct?

 1. When the GUI gets a ">PASSWORD:Verification Failed: 'Auth'
['CRV1:…" message, it just stores the info.

 2. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth'
username" request, it responds with the decoded username from the
stored info.

 3. Each time after 1., when the GUI gets a ">PASSWORD:Need 'Auth'
password" request, it asks the user for a password (using the prompt
from the info) and sends that back with the "state_id" from the stored
info and formatted as described.

 4. Any later ">PASSWORD:Verification Failed: 'Auth' ['CRV1:…"
messages overwrite the old info the GUI stored.

Or do 2. and 3. only happen once, and after that responses to
">PASSWORD:Need 'Auth' username" and ">PASSWORD:Need 'Auth' password"
should revert back to the normal behavior until another
">PASSWORD:Verification Failed: 'Auth' ['CRV1:…" message is received?


Thanks so much, Selva,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Dynamic challenge/response questions

[Jonathan K. Bullard]

I'm trying to implement dynamic challenge/response in Tunnelblick and
have some questions. I've been using the management-interface
documentation [1] as my guide.

1. Is what the management interface sends something like (all on one line):

>PASSWORD:Verification Failed: 'Auth' 
>['CRV1:R,E:Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l:Y3Ix:Please enter token PIN:']

and not just the challenge all by itself?


2. Is the final ":" in the above part of the prompt to be shown to the
user, or is it a delimiter showing the end of the prompt?


3. Is the response back to the management interface really like this:

Username: cr1 ("Y3Ix" base64 decoded)
Password: CRV1::Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l::8675309

I ask because the syntax for the username/password for a
NON-challenge/response response back to the management interface is

username "Auth" THE_USERNAME
password "Auth" THE_PASSWORD

which has "username" and "password" in lower-case and without the ":"s.


4. Can the Username and Password fields sent to the OpenVPN management
interface be quoted (and must double-quotes within the fields be
escaped), as with the NON-challenge/response response?


Thanks,

Jon Bullard

[1] 
https://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [OpenVPN/openvpn-gui] UI showing green connected status despite not beeing able to create a route (#9)

[Jonathan K. Bullard]

Hi,

On Fri, Jul 6, 2018 at 3:24 PM, Selva Nair  wrote:
>
> Hi,
>
> Copying the devel list as a reminder that "we" have been asking for this 
> change for a long time :)
>
> On Fri, Jul 6, 2018 at 2:48 PM, Gert Doering  wrote:
>>
>> Hi,
>>
>> On Fri, Jul 06, 2018 at 08:25:02AM -0700, Selva Nair wrote:
>> > Can we do something about this in openvpn core, so that the GUI can be 
>> > report route errors?
>>
>> Currently when we get CONNECTED,SUCCESS we turn the icon green. If we get
>>
>> CONENCTED,ERROR we keep it amber and the state as "connecting.." even if
>>
>> the initialization sequence completes.
>> >
>> > So route errors can still be treated as non-fatal but we want to get 
>> > CONNECTED,ERROR in such cases.

+1 to routing errors causing CONNECTED,ERROR (I didn't even know that
was possible). This confuses many Tunnelblick users.

I'd be happy for routing errors to cause a FATAL error as long as the
errors weren't caused by "route already exists" or something like
that. But I assume that's too much trouble.


Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Make up/down script errors not FATAL

[Jonathan K. Bullard]

Hi.

On Mon, Jul 2, 2018 at 9:24 PM,  wrote:
>
> From: Selva Nair 
>
> Instead log only a warning.
>
> This helps user interfaces enforce a safer script-security setting
> without causing a FATAL error.


Can you expand on that? What "safer script secuity settings' do you
have in mind? Tunnelblick (and I think all Linux) use script-security
2 to allow for up/down scripts that implement DNS and other settings.

My initial reaction is that I'd rather a problem in the up/down
scripts generates a fatal error, so if there's a problem in the
Tunnelblick scripts somebody will report it. In my experience, almost
nobody pays attention to warnings, and mostly, those who do are
worried about warning that don't matter.

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v5] Add Interactive Service developer documentation

[Jonathan K. Bullard]

Hi,

On Sat, Jun 9, 2018 at 12:23 PM, Selva Nair  wrote:
>
> Hi,
>
> On Thu, Apr 19, 2018 at 7:23 AM, Simon Rozman  wrote:
> > The OpenVPN Interactive Service documentation from
> > https://community.openvpn.net/openvpn/wiki/OpenVPNInteractiveService was
> > upgraded with a description of the client-service communication flow,
> > service registry configuration, and non-default instance installation.



> > Giving it a second thought, there is no point into packaging this file for 
> > non-Windows distributions, since the Interactive Service is 
> > Windows-specific.
>
> We have a common source distribution for all platforms and it includes
> Windows only bits like the interactive service sources. IMO, this does
> belong there.

+1: It should be included. It is of interest to non-Windows folks like
me, too, even if we don't use it directly.

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Specify platform and version on command line.

[Jonathan K. Bullard]

Hi.

On Fri, Apr 13, 2018 at 1:23 PM, Micah Morton  wrote:
> From 557d2e73bf21ddb9d07b43f716c7914d610e7392 Mon Sep 17 00:00:00 2001
> From: Micah Morton 
> Date: Fri, 13 Apr 2018 09:55:22 -0700
> Subject: [PATCH] Specify platform and version on command line.
>
> Add --iv-plat and --iv-plat-rel command line args, and use the values
> passed to these args to set IV_PLAT and IV_PLAT_REL info that is pushed
> to the server.

Sounds reasonable, but the new options should be documented on the man
page and in the usage message that's shown to users (in options.c) and
that should be included in this patch.

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Depreciate IPv4-related options.

[Jonathan K. Bullard]

Hi,

On Sun, Apr 1, 2018 at 11:34 AM, Gert Doering  wrote:
> Hi,
>
> On Sun, Apr 01, 2018 at 10:19:37AM -0400, Selva Nair wrote:
>> On Sun, Apr 1, 2018 at 2:30 AM, Gert Doering  wrote:
>>
>> > As discussed in trac #208 and on IRC with Antonio, OpenVPN 2.5 will
>> > be IPv6-only.  Removal of IPv4-related code and options will dramatically
>> > reduce code complexity, confusing options, bugs and user questions.
> [..]
>>
>> Nice try :)
>
> Hah, caught in the act ;-)
>
> (Apologies to Jonathan for scaring you about new user support issues...)

No apologies necessary! I fell for it completely and have no excuse. I
probably laughed as hard as anyone else when I read your private reply
that pointed out today's date.

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Depreciate IPv4-related options.

[Jonathan K. Bullard]

 Hi,

On Sun, Apr 1, 2018 at 2:30 AM, Gert Doering  wrote:
> As discussed in trac #208 and on IRC with Antonio, OpenVPN 2.5 will
> be IPv6-only.  Removal of IPv4-related code and options will dramatically
> reduce code complexity, confusing options, bugs and user questions.
>
> Add deprecation warnings for IPv4-related config options to 2.4 branch,
> so users have enough time to move their setups to work on IPv6-only
> before 2.5 will be released.

Are you proposing to remove all IPv4 support from OpenVPN 2.5, so that
an IPv6 connection will be required and an IPv4-only connection will
not work?

Or is this is about removing IPv4-only options and code and leaving
options and code that work for either IPv4 or IPv6, so users could
continue to have an IPv4-only setup by changing the names of a few
options in their configuration files?

Either way, can anyone give an approximate release date for 2.5, so we
can have a time frame for the change? (Even a "not before" date would
be very helpful in evaluating the impact of these proposed changes.)

Best regards,

Jon Bullard (Tunnelblick developer)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenSSL version(s) officially supported by OpenVPN?

[Jonathan K. Bullard]

Hi.

On Wed, Mar 7, 2018 at 4:25 AM, Steffan Karger
<steffan.kar...@fox-it.com> wrote:
>
> Hi,
>
> On 06-03-18 23:16, Jonathan K. Bullard wrote:
> > Can someone clarify which versions of OpenSSL OpenVPN supports (that
> > is, "works with when linked statically")?
> >
> > From what I gather:
> >
> >  * OpenVPN 2.3.18 supports OpenSSL 1.0.2n
> >  * OpenVPN 2.4.5 supports OpenSSL 1.0.2n and 1.1.0g
> >  * OpenVPN 2.5 will support OpenSSL 1.0.2n and 1.1.0g
> >
> > Is that correct? (I assume OpenVPN 2.5 won't remove support for
> > OpenSSL 1.0.2, which ends "Long Term Support" on 2019-12-31.)
>
> Our configure.ac is "the truth" here.  It says:
>
> OpenVPN 2.3 should work with OpenSSL 0.9.6+  (But, < 1.1)
> OpenVPN 2.4 should work with OpenSSL 0.9.8+
> OpenVPN master should work with OpenSSL 1.0.1+
>
> Where master is of course still in flux, so we might increase the
> minimum version at some point before the 2.5 release.

Thank you very much,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenSSL version(s) officially supported by OpenVPN?

[Jonathan K. Bullard]

Hi.

Inspired by the recent discussion about LibreSSL support:

Can someone clarify which versions of OpenSSL OpenVPN supports (that
is, "works with when linked statically")?

>From what I gather:

 * OpenVPN 2.3.18 supports OpenSSL 1.0.2n
 * OpenVPN 2.4.5 supports OpenSSL 1.0.2n and 1.1.0g
 * OpenVPN 2.5 will support OpenSSL 1.0.2n and 1.1.0g

Is that correct? (I assume OpenVPN 2.5 won't remove support for
OpenSSL 1.0.2, which ends "Long Term Support" on 2019-12-31.)

Thanks in advance,

Jon Bullard (Tunnelblick developer)

PS: Tunnelblick bundles versions of OpenVPN linked with OpenSSL and
LibreSSL. I am considering including versions linked with different
OpenSSLs, too.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Properly respond to SIGTERM received during DNS resolution.

[Jonathan K. Bullard]

Hi, I'd like to reopen this patch -- it seems to have gotten lost.

The patch is so old the line numbers are wrong but the code doesn't
seem to have changed.

I'm top-posting because this thread doesn't show up in the SourceForge
archive[1] (???) so I've extracted the relevant parts below. There was
some top-posting but nothing was really out-of-order, so I've tried to
make the thread intelligible and include everything relevant below.

On Tue, Apr 12, 2016 at 11:42 AM, Fish <fish.t...@gmail.com> wrote:
> In `link_socket_init_phase2`, it used to be the case that any received
> signal will be overwritten by SIGUSR1 if the socket cannot be created
> (e.g. when DNS resolution fails), which consequently prevents OpenVPN from
> responding to SIGTERM and exiting. This patch adds an additional check of
> whether the received signal during DNS resolution is SIGTERM or not, and
> prematurely exits from `link_socket_init_phase2` when receiving a SIGTERM.
> ---
>  src/openvpn/socket.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
> index 9bcf4d4..5e8abe1 100644
> --- a/src/openvpn/socket.c
> +++ b/src/openvpn/socket.c
> @@ -1905,6 +1905,11 @@ link_socket_init_phase2 (struct link_socket *sock,
> }
> }
>
> +  if (sig_info->signal_received == SIGTERM)
> +   {
> + goto done;
> +   }
> +
>/* Socket still undefined, give a warning and abort connection */
>if (sock->sd == SOCKET_UNDEFINED)
> {

On Tue, Apr 12, 2016 at 11:46 AM, Gert Doering <g...@greenie.muc.de> wrote:
> That is the "on DNS failure, the client loops forever and is not killable"
> problem, right?
>
> (I'm not sure I'm reading the description right, to understand the
> actual issue this is fixing - but if I'm reading it right, then this
> makes sense :-)  - what about SIGINT?)


On Tue, Apr 12, 2016 at 11:48 AM, Fish Wang <fish.t...@gmail.com> wrote:
>
> Right, it's for the "on DNS failure, the client loops forever and is not 
> killable" problem.


On Tue, Apr 12, 2016 at 12:25 PM, Jonathan K. Bullard
<jkbull...@gmail.com> wrote:
> Feature ACK; this should make DNS hangs much easier to deal with for
> GUIs such as Tunnelblick.
>
> The "hang forever" problem can be avoided by using --resolve-retry.
>

On Tue, Apr 12, 2016 at 1:18 PM, Arne Schwabe <a...@rfc2549.org> wrote:
> Am 12.04.16 um 17:42 schrieb Fish:
>> In `link_socket_init_phase2`, it used to be the case that any received
>> signal will be overwritten by SIGUSR1 if the socket cannot be created
>> (e.g. when DNS resolution fails)
>
> That should not happen in the first place, doesn't register_signal keep
> care of not overwriting higher priority signals?

On Tue, Apr 12, 2016 at 10:07 PM, Fish Wang <fish.t...@gmail.com> wrote:
>
> No, the patch won't fix that issue. I may send out another patch later to fix 
> that problem if I have free time this week.

On Tue, Apr 12, 2016 at 10:11 PM, Fish Wang <fish.t...@gmail.com> wrote:
> Check out the code in socket.c [1]. This is where the received signal is 
> overwritten by SIGUSR1.
>
>   /* Socket still undefined, give a warning and abort connection */
>   if (sock->sd == SOCKET_UNDEFINED)
> {
>   msg (M_WARN, "Could not determine IPv4/IPv6 protocol");
>   sig_info->signal_received = SIGUSR1;
>   goto done;
> }
> [1] https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/socket.c#L1909

Note that theses lines are immediately below the patch. The last three
lines of the patch (which are not changed in the patch) are the same
as the first three lines shown above.

Best regards,

Jon Bullard

[1] 
https://sourceforge.net/p/openvpn/mailman/openvpn-devel/?viewmonth=201604=250=threaded

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Fwd: [PATCH 2/3] Allow external EC key through --management-external-key

[Jonathan K. Bullard]

Hi.

On Mon, Jan 22, 2018 at 12:31 PM, Selva Nair  wrote:
> What about extending the current "version" command with an argument
> where the client states the version of "management-speak" that it
> supports. Current management version is 1, we increase it to 1.1 and
> unless the client says "version 1.1" or more we do not send PK_SIGN.
> The client could do that when it gets the version message or any time
> later. The response to version command (current management version and
> openvpn daemon's version stays the same). No full-fledged cap
> negotiation, but good enough.

That sounds reasonable; easy to implement in Tunnelblick


> The UX would be much better that way.

Absolutely.

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Jonathan K. Bullard]

Hi,

On Mon, Jan 22, 2018 at 7:33 AM, David Sommerseth
 wrote:
> Let me rather twist this question around ... Do we want to support OpenSSL
> 0.9.8?  Are there any Linux distributions or other OSes out there in the wild
> which is still supported which are also based on openssl-0.9.8?
>
> Officially we dropped RHEL 5 support and moved to RHEL 6 as the oldest Linux
> distribution we support OpenVPN on.  RHEL 6 ships with an openssl-1.0.1e 
> baseline.
>
> For the other platforms ... In Windows, we define what we want to use - as we
> need to embed OpenSSL in our own package.  I believe most of the current
> stable *BSDs and derivatives are on an OpenSSL 1.x base (or the LibreSSL fork)
> too (but I don't know that for a fact yet).  I expect Tunnelblick and macOS
> users to use a far newer OpenSSL library too.

Dropping 0.9.8 isn't a problem for Tunnelblick, which embeds OpenSSL 1.0.2.

However, 0.9.8 (patched by Apple, as I understand it) is included in
macOS up through Sierra. So people using command-line openVPN would
have problems unless they've replaced OpenSSL.

(Apple's latest system, "High Sierra" symlinks openvpn to LibreSSL,
which opens a different can of worms : )

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Follow up on sending messages to the GUI

[Jonathan K. Bullard]

Hi,

On Sat, Dec 2, 2017 at 7:08 AM, Jonathan K. Bullard <jkbull...@gmail.com> wrote:
> Hi,
>
> On Fri, Dec 1, 2017 at 10:58 AM, Selva Nair <selva.n...@gmail.com> wrote:
>>
>> Hi,
>>
>> On Fri, Dec 1, 2017 at 8:53 AM, Arne Schwabe <a...@rfc2549.org> wrote:
>>>
>>> Am 30.11.2017 um 03:03 schrieb Selva Nair:
>>>
>>> Cross-posting to users and devel as this may be of interest to both.
>>>
>>> Hi,
>>>
>>> I have made a draft implementation of this feature that was discussed in a 
>>> previous thread. A test executable (GUI only) is in this pre-release:
>>>
>>> https://github.com/selvanair/openvpn-gui/releases/tag/v11-echo-msg
>>>
>>> It would be great if anyone can test this out[*].
>>>
>>> Thanks,
>>>
>>> Selva
>>>
>>> [*] Although virtually any text can be sent, some familiarity with openvpn 
>>> config/ccd parsing/quoting and push processing is necessary to get it right 
>>> for non-trivial messages that contain comment characters, commas, new lines 
>>> etc... Short and simple messages must be easy, though.
>>>
>>>
>>> Could we have some text stating that clients might only display one message 
>>> per connect? At the moment you can have multiple "echo msg-notify 
>>> message-title" pushed by the server. I would like to avoid in my client to 
>>> implement logic to display multiple messages. If one message allowed the 
>>> message can become just an Android notification without special logic
>>
>>
>> Yes, we can and probably should document that some clients may only
>> display one message. Do you also want to say that some clients may
>> interpret msg-window as msg-notify?
>>
>> Even in case of Windows desktop, I think it may be better to display
>> only one message per connection as otherwise it starts to get very
>> noisy. At most one message window and one notification.
>>
>> Jon, do you plan to document the proposed "echo msg" specs in management
>> notes or elsewhere?  The single message per connect limitation
>> could be specified there.
>
> I'll be happy to try to document the protocol between OpenVPN and the
> GUI, including the "msg*" commands and others such as
> "forget-passwords", "setenv", etc., which we've discussed. However,
> I'm thinking it should be a separate "doc/gui-notes.txt" document.
>
> In a separate document it would be easier to make it clear that it is
> describing the protocol between the configuration and the GUIs and not
> get lost in the complexity of the management interface itself.

Below is a first draft of documentation for all of the "echo" commands
sent from OpenVPN via the management interface (typically, to a GUI).

I think it's important to include info about how the each of the
common open GUIs interpret the commands in this document, so those who
want to use --echo will have a single place to look.

I'm doing this inline in this email, not as a patch for several
reasons: because it's easier to read that way, because I'd like to get
it at least close to acceptance before proposing it as a patch, and
because I'm not really proficient with OpenVPN's patching process and
there will probably be several versions of the patch. (If someone else
wants to do this as a patch from right now, I'm happy to have them
take it over.)

The section on quoting should be examined carefully -- I didn't test
any of that.

And I don't know which commands will be implemented on Android so I
left that as "??".

Best regards,

Jon



*** New document starts after the next line ***

Management Interface "echo" protocol


THIS IS A PRELIMINARY VERSION OF THIS DOCUMENT. ALL INFORMATION IN IT
IS SUBJECT TO CHANGE.



CONTENTS
THE OPENVPN --ECHO OPTION
ENVIRONMENT COMMAND
MESSSAGE COMMANDS
PASSWORD COMMANDS
QUOTING
COMMMAND DETAILS


=
THE OPENVPN --ECHO OPTION
=

The OpenVPN --echo option causes commands to be sent out through the
management interface, typically to a Graphic User Interface (GUI) such
as "OpenVPN for Android", "Tunnelblick" (for macOS), or "Windows
OpenVPN GUI". It can be included in a configuration file or on a
command line, or can be pushed from the server.

This docu

Re: [Openvpn-devel] Follow up on sending messages to the GUI

[Jonathan K. Bullard]

Hi,

On Fri, Dec 1, 2017 at 10:58 AM, Selva Nair  wrote:
>
> Hi,
>
> On Fri, Dec 1, 2017 at 8:53 AM, Arne Schwabe  wrote:
>>
>> Am 30.11.2017 um 03:03 schrieb Selva Nair:
>>
>> Cross-posting to users and devel as this may be of interest to both.
>>
>> Hi,
>>
>> I have made a draft implementation of this feature that was discussed in a 
>> previous thread. A test executable (GUI only) is in this pre-release:
>>
>> https://github.com/selvanair/openvpn-gui/releases/tag/v11-echo-msg
>>
>> It would be great if anyone can test this out[*].
>>
>> Thanks,
>>
>> Selva
>>
>> [*] Although virtually any text can be sent, some familiarity with openvpn 
>> config/ccd parsing/quoting and push processing is necessary to get it right 
>> for non-trivial messages that contain comment characters, commas, new lines 
>> etc... Short and simple messages must be easy, though.
>>
>>
>> Could we have some text stating that clients might only display one message 
>> per connect? At the moment you can have multiple "echo msg-notify 
>> message-title" pushed by the server. I would like to avoid in my client to 
>> implement logic to display multiple messages. If one message allowed the 
>> message can become just an Android notification without special logic
>
>
> Yes, we can and probably should document that some clients may only
> display one message. Do you also want to say that some clients may
> interpret msg-window as msg-notify?
>
> Even in case of Windows desktop, I think it may be better to display
> only one message per connection as otherwise it starts to get very
> noisy. At most one message window and one notification.
>
> Jon, do you plan to document the proposed "echo msg" specs in management
> notes or elsewhere?  The single message per connect limitation
> could be specified there.

I'll be happy to try to document the protocol between OpenVPN and the
GUI, including the "msg*" commands and others such as
"forget-passwords", "setenv", etc., which we've discussed. However,
I'm thinking it should be a separate "doc/gui-notes.txt" document.

In a separate document it would be easier to make it clear that it is
describing the protocol between the configuration and the GUIs and not
get lost in the complexity of the management interface itself.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Follow up on sending messages to the GUI

[Jonathan K. Bullard]

Hi,

On Thu, Nov 30, 2017 at 10:26 PM, Selva Nair <selva.n...@gmail.com> wrote:

> Hi Jon,
>
> On Thu, Nov 30, 2017 at 8:41 PM, Jonathan K. Bullard <jkbull...@gmail.com>
> wrote:
>
>> Thanks, Selva,
>>
>> On Wed, Nov 29, 2017 at 9:03 PM, Selva Nair <selva.n...@gmail.com> wrote:
>> >
>> > I have made a draft implementation of this feature that was discussed
>> in a previous thread. A test executable (GUI only) is in this pre-release:
>> >
>> > https://github.com/selvanair/openvpn-gui/releases/tag/v11-echo-msg
>> 
>> >
>> > Also see some technical notes included in the above link.
>>
>> The technical notes say
>>
>>  In case of "echo msg text" the previous text, if any, is appended
>> with a new line. An empty text in this case will just add a new line.
>>
>>
> That was a poor way of saying that "echo msg text" will display a single
> line of text, not two lines as would be expected if an '\n' is
> automatically
> appended.
>
>
>> Is that the same as
>>
>>  In case of "echo msg text" the previous text, if any, is appended
>> with text and then a new line. An empty text in this case will just
>> add a new line.
>>
>>
> Yes, that would be a less confusing way to word it provided an
> additional remark is added: that the last newline so added is ignored
> during
> display (see below).
>
>
>> ? (That is, the new line comes after the text, not after the previous
>> text.)
>>
>
> Well, here is what I thought should happen:
>
> echo msg Text
> echo msg-window title
>
> should display "Text" as a single line (ignoring any "soft" linebreaks
> added by the UI for display purposes). For this to happen no '\n' should
> get appended to "Text".
>
> echo msg Text1
> echo msg Text2
> echo msg-window title
>
> leads to "Text1\nText2"  displayed in 2 lines
>
> Alternatively the one could say "msg Text" implicitly appends a newline
> character(s) to "Text" except that the last implicit newline does not
> cause an
> empty line to be displayed.
>
> Isn't that the expected behaviour?
>

That's fine with me.


 Selva
>

> P.S: In reality I add about a line of blank space at the top and bottom
> before display
> for aesthetic reasons, but that is beside the point.
>

Let's leave that as implementation defined. It may be different in
notifications and windows, too.

Best regards,

Jon
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Follow up on sending messages to the GUI

[Jonathan K. Bullard]

Thanks, Selva,

On Wed, Nov 29, 2017 at 9:03 PM, Selva Nair  wrote:
>
> I have made a draft implementation of this feature that was discussed in a 
> previous thread. A test executable (GUI only) is in this pre-release:
>
> https://github.com/selvanair/openvpn-gui/releases/tag/v11-echo-msg

>
> Also see some technical notes included in the above link.

The technical notes say

 In case of "echo msg text" the previous text, if any, is appended
with a new line. An empty text in this case will just add a new line.

Is that the same as

 In case of "echo msg text" the previous text, if any, is appended
with text and then a new line. An empty text in this case will just
add a new line.

? (That is, the new line comes after the text, not after the previous text.)

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Implement "status 4" (JSON) for management interface

[Jonathan K. Bullard]

Hi,

On Tue, Nov 14, 2017 at 7:40 AM, David Sommerseth
 wrote:
>
> On 14/11/17 12:02, Gert Doering wrote:
>> JSON is very trivial to produce (unlike XML, or netlink).  The escaping
>> rules on producing are also very easy - basically, encode things in double
>> quotes, and escape the set of { BS, FF, NL, CR, Tab, Backslash, Quote }
>> with a single backslash before the corresponding character.

My reading of the RFC [1] (maybe not the only RFC for JSON?) is that
all control characters must be escaped (all characters < 0x20). And
the quotation mark that must be escaped is the double-quote (0x22),
not the single-quote (0x27).

Also, the escaping needs to be of the form \u where  is the
URF-16 code unit for the character. That's easy for these characters
-- I think it's printf("\\u%04d", ch) since all the characters we are
escaping are in the Basic Multilingual Plane (U+ through U+).


> 
>
> Right, all those are single byte characters - and that's fairly simple
> ... but that ignores various quirks which easily appears with multi-byte
> characters - especially when "looping" through a value, byte by byte.
> We support UTF-8 in certificate subject fields.  So this escaper needs
> to handle those classes the stackoverflow mentions, plus beware of
> multi-byte strings (so we need to use the plethora of mb* related
> functions).
>
> In a clean 8-bit ASCII only-world, things are less complicated.
>
> Heiko and I have looked into the "simple" world of revamping the argv
> parser (to avoid our own "homebrewed" printf-like processing and base it
> on what is in the C library) and even this pre-parsing we need to do
> have popped up with surprises.  The argv caller scope mostly covers
> parsing strings which is defined by us developers so the variations are
> not as broad, and luckily format strings is not expected to contain
> UTF-8 chars.  But I do not for a second think processing certificate
> subject strings will as easy as those values we need to parse (typically
> CN) are not generated by us but a broad range of users.  Who knows what
> kind of funny tricks they'll throw at our code?

How does OpenVPN currently handle escaping when generating CSV? If we
don't do it correctly for multi-byte strings for CSV, do we need to
for JSON?

>From what I can tell, the only problematic character that needs to be
escaped is the backslash (0x5C). All the other characters that need to
be escaped are less than 0x40, so they will never appear as part of a
multi-byte sequence. That one character makes this difficult, but IMO
the problem is simple enough that it could be done within OpenVPN.
That would be my preference, instead of adding another dependency.

Best regards,

Jon Bullard

[1] https://www.ietf.org/rfc/rfc4627.txt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Implement "status 4" (JSON) for management interface

[Jonathan K. Bullard]

Hi,

On Tue, Nov 14, 2017 at 3:31 AM, Gert Doering  wrote:
> Hi,
>
> On Mon, Nov 13, 2017 at 01:16:46PM +0100, David Sommerseth wrote:
>> But we should consider if we want to make use of a JSON library
>> producing the JSON streams.  The reason is to ensure the output is
>> according to the specification and that escaping if contents is
>> consistent and proper.  Imagine if someone puts a double-quote into the
>> CN field of a certificate?
>>
>>  CN="} Lets explode things, O=Hacktivist0
>>
>> Or other characters which needs escaping.
>
> I'm not convinced we want to import a new library dependency and a heap
> of #ifdef for this.
>
> Escaping on *output* is pretty trivial ("characters from 
> need to be encoded ") - and as long as we do not need to parse
> *incoming* JSON, a full-blown new library is mainly adding complications
> (like, configure flags, #ifdefs, library version dependencies, ...).

+1

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] contrib: Remove keychain-mcd code

[Jonathan K. Bullard]

On Tue, Jul 25, 2017 at 9:03 AM, David Sommerseth  wrote:
> After the security audits performed by Cryptography Engineering the
> spring of 2017 [1], there were several concerns about the contrib code
> for the macOS keychain support.  After more careful review of this
> code base, it was considered to be in such a bad shape that it will
> need a massive overhaul.  There were more issues than what the security
> audit revealed.
>
> It was attempted several times to get in touch with the contributor
> of this code; with no response at all [2].  There has however
> been some discussions with the Tunnelblick project [3]. There is one
> person there willing to go through this and improve the situation.
> The main Tunnelblick maintainer is also willing to include the improved
> code to their project instead of having this as a contrib code in
> the upstream OpenVPN project.
>
> So this patch just removes the code which we will no longer
> ship as part of OpenVPN - and the Tunnelblick project will take
> over the responsibility for this code base on their own.  And since
> this code base is purely macOS specific, this seems to be a far
> better place for this code to reside.

ACK to removing this code.

I will add the code to the Tunnelblick project if/when it is fixed.

It should be noted, however, that what is added to Tunnelblick will
have many modifications and will be integrated into Tunnelblick's
existing code for the OpenVPN management interface. It will not have
the separate "keychain-mcd" daemon which is in the keychain-mcd code
that is being removed from OpenVPN.

And: thanks, David, for your work on this.

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Implement block-ipv6

[Jonathan K. Bullard]

Hi.

I have one small nit-pick.

On Thu, Jul 6, 2017 at 11:33 AM, Arne Schwabe  wrote:
> This can be used to redirect all IPv6 traffic to the tun interface, 
> effectively black holing the IPv6 traffic. Without ICMPv6 error messages this 
> will result in timeouts when the server does not send error codes.
> block-ipv6 allows client side only blocking on all platforms that OpenVPN 
> supports IPv6. On Android it is only way to do sensible IPv6 blocking on 
> Android < 5.0 and broken devices (Samsung).

[snip]
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 505c5b2e..04505251 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -226,6 +226,8 @@ static const char usage_message[] =
>  "  Add 'bypass-dns' flag to similarly bypass tunnel for 
> DNS.\n"
>  "--redirect-private [flags]: Like --redirect-gateway, but omit actually 
> changing\n"
>  "  the default gateway.  Useful when pushing private 
> subnets.\n"
> +"--block-ipv6 : (client only) Instead sending IPv6 to the server 
> generate\n"
> +"   ICMPv6 host unreachable messages.\n"
>  "--client-nat snat|dnat network netmask alias : on client add 1-to-1 NAT 
> rule.\n"
>  #ifdef ENABLE_PUSH_PEER_INFO
>  "--push-peer-info : (client only) push client info to server.\n"
> @@ -2083,6 +2085,11 @@ options_postprocess_verify_ce(const struct options 
> *options, const struct connec
>  msg(M_USAGE, "--lladdr can only be used in --dev tap mode");
>  }
>
> +if (options->block_ipv6 && !options->ifconfig_ipv6_remote)
> +{
> +msg(M_USAGE, "--block-ipv6 needs a valid --ifconfig-ipv6 
> configuration");
> +}
> +
>  /*
>   * Sanity check on MTU parameters
>   */
> @@ -2241,6 +2248,7 @@ options_postprocess_verify_ce(const struct options 
> *options, const struct connec
>  msg(M_USAGE, "TCP server mode allows at most one --remote address");
>  }
>
> +
>  #if P2MP_SERVER
>
>  /*
> @@ -6346,6 +6354,11 @@ add_option(struct options *options,
>  #endif
>  options->routes->flags |= RG_ENABLE;
>  }
> +else if (streq(p[0], "block-ipv6"))
> +{
> +VERIFY_PERMISSION(OPT_P_ROUTE);
> +options->block_ipv6 = true;
> +}
>  else if (streq(p[0], "remote-random-hostname") && !p[1])
>  {
>  VERIFY_PERMISSION(OPT_P_GENERAL);

This (8th line from the end):

 +else if (streq(p[0], "block-ipv6"))

should be:

 +else if (streq(p[0], "block-ipv6") && !p[1])

So "block-ipv6 abc" will be detected as an error.

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.4.3 released (with security fixes)

[Jonathan K. Bullard]

On Wed, Jun 21, 2017 at 12:48 PM, Matthias Andree
 wrote:
>
> Am 21.06.2017 um 16:33 schrieb Samuli Seppänen:
> > On 21/06/2017 17:06, Simon Matter wrote:
> >>> On Wed, Jun 21, 2017 at 6:47 AM, Samuli Seppänen 
> >>> wrote:
>  The OpenVPN community project team is proud to release OpenVPN 2.4.3. It
>  can be downloaded from here:
> 
>  
> >>> Hi. Thanks for this release.
> >>>
> >>> Verifying the PGP signature on 2.3.17.tar.gz works fine (so did 2.4.2
> >>> a few weeks ago), but trying to verify the signature on 2.4.3.tar.gz
> >>> fails with:
> >> I wanted to ask this during the 2.4.2 hickup but now I really ask because
> >> there is confusion again with 2.4.3:
> >>
> >> Could you please add check sums of all release files so that one can
> >> easily check to have the correct download. Even MD5 works better no check
> >> sum :-)
> >>
> >> Regards,
> >> Simon
> >>
> > Makes sense. I'll see if I could tackle that tomorrow.
> >
> > Meanwhile I added a test script which downloads every release file and
> > verifies their signatures. I will run this script as part of the release
> > process.
>
> It makes no sense at all. Don't start that!
>

I disagree. Having the checksums would have saved me a lot of time
today because I would have immediately known which file was corrupt --
the binary or the signature file -- without bothering the list. It
might help rule out Cloudflare as a suspected cause of the problem.


> You already provide detached GnuPG signatures, which are better suited
> for most purposes and incidentally also cover the "checksum" purpose.

Yes, "most purposes", but not "all purposes".

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.4.3 released (with security fixes)

[Jonathan K. Bullard]

On Wed, Jun 21, 2017 at 7:48 AM, Jonathan K. Bullard <jkbull...@gmail.com>
wrote:

> On Wed, Jun 21, 2017 at 6:47 AM, Samuli Seppänen <sam...@openvpn.net>
> wrote:
> > The OpenVPN community project team is proud to release OpenVPN 2.4.3. It
> > can be downloaded from here:
> >
> > <http://openvpn.net/index.php/open-source/downloads.html>
>
> Hi. Thanks for this release.
>
> Verifying the PGP signature on 2.3.17.tar.gz works fine (so did 2.4.2
> a few weeks ago), but trying to verify the signature on 2.4.3.tar.gz
> fails with:


I downloaded 2.4.3.tar.gz and 2.4.3.tar.gz.asc several times in the past
few hours and always got a bad copy of 2.4.3.tar.gz. Then I restarted my
computer and downloaded again: same thing. Then I downloaded with Safari
(instead of Chrome, which I had been using) -- and the downloaded
2.4.3.tar.gz was different and its signature verifies properly (the
2.4.3.tar.gz.asc was identical in all cases). So I went back to Chrome and
downloaded again -- bad copy. Firefox: good copy. Then Chrome again: good
copy.

So all seems OK now, but something is or was flakey with my computer,
Chrome, Cloudflare, my ISP… (or some combination).
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] ***UNCHECKED*** Re: OpenVPN 2.4.3 released (with security fixes)

[Jonathan K. Bullard]

On Wed, Jun 21, 2017 at 8:40 AM, David Sommerseth
<open...@sf.lists.topphemmelig.net> wrote:
> On 21/06/17 14:30, David Sommerseth wrote:
>> On 21/06/17 13:48, Jonathan K. Bullard wrote:
>>> On Wed, Jun 21, 2017 at 6:47 AM, Samuli Seppänen <sam...@openvpn.net> wrote:
>>>> The OpenVPN community project team is proud to release OpenVPN 2.4.3. It
>>>> can be downloaded from here:
>>>>
>>>> <http://openvpn.net/index.php/open-source/downloads.html>
>>>
>>> Hi. Thanks for this release.
>>>
>>> Verifying the PGP signature on 2.3.17.tar.gz works fine (so did 2.4.2
>>> a few weeks ago), but trying to verify the signature on 2.4.3.tar.gz
>>> fails with:
>>>
>>> $ gpg2 -v --verify /XXX/openvpn-2.4.3.tar.gz.asc
>>>
>>> gpg: armor header: Version: GnuPG v1
>>> gpg: assuming signed data in '/XXX/openvpn-2.4.3.tar.gz'
>>> gpg: Signature made Wed Jun 21 06:19:19 2017 EDT
>>> gpg:using RSA key D72AF3448CC2B034
>>> gpg: using subkey D72AF3448CC2B034 instead of primary key 12F5F7B42F2B01E7
>>> gpg: using pgp trust model
>>> gpg: BAD signature from "OpenVPN - Security Mailing List
>>> <secur...@openvpn.net>" [unknown]
>>> gpg: binary signature, digest algorithm SHA1, key algorithm rsa4096
>>>
>>> The SHA256 ofopenvpn-2.4.3.tar.gz is
>>>  84a01aa3df0c12a3552ca3baaa39d700137b5bce4b6de683fe87fb79bfa5df0b
>>>
>>> The SHA256 of openvpn-2.4.3.tar.gz.asc is
>>>  695afa06fcf94f9e8bd2ee63267332d14e52fe24dd58c470e42dafbea371e437
>>>
>>> The files were downloaded from
>>> https://openvpn.net/index.php/open-source/downloads.html at about
>>> 10:24 UCT today from the New York City area.
>>>
>>> For reference, here is the output from verifying 2.3.17:
>>>
>>> $ gpg2 -v --verify /Users/jonathanbullard/Desktop/openvpn-2.3.17.tar.gz.asc
>>>
>>> gpg: armor header: Version: GnuPG v1
>>> gpg: assuming signed data in
>>> '/Users/jonathanbullard/Desktop/openvpn-2.3.17.tar.gz'
>>> gpg: Signature made Wed Jun 21 06:18:55 2017 EDT
>>> gpg:using RSA key D72AF3448CC2B034
>>> gpg: using subkey D72AF3448CC2B034 instead of primary key 12F5F7B42F2B01E7
>>> gpg: using pgp trust model
>>> gpg: Good signature from "OpenVPN - Security Mailing List
>>> <secur...@openvpn.net>" [unknown]
>>> gpg: WARNING: This key is not certified with a trusted signature!
>>> gpg:  There is no indication that the signature belongs to the 
>>> owner.
>>> Primary key fingerprint: F554 A368 7412 CFFE BDEF  E0A3 12F5 F7B4 2F2B 01E7
>>>  Subkey fingerprint: B596 06E2 D8C6 E10B 80BE  2B31 D72A F344 8CC2 B034
>>> gpg: binary signature, digest algorithm SHA1, key algorithm rsa4096
>>>
>>> Any ideas or suggestions?
>>
>> I believe it is Cloudflare playing tricks on us again.
>>
>> Attached are the proper signature files and below a list of the SHA256 
>> checksums:
>>
>> d300029416b045666f2dc957bdde407ba97894428b5ad8433df789e793ccc1d3  
>> openvpn-2.3.17.tar.xz
>> b206065f4a1720c022fde710c0449b5b25e9dda8ca2911a82bacf21b9fcb4e29  
>> openvpn-2.3.17.tar.xz.asc
>> 7aa86167a5b8923e54e8795b814ed77288c793671f59fd830d9ab76d4b480571  
>> openvpn-2.4.3.tar.xz
>> 9f5f089f4a4b3e270ddb53cb0b689f4c0bad89d7e2ee08a1d4666e7ab869f210  
>> openvpn-2.4.3.tar.xz.asc
>>
>> This is based on the files I've already pushed to the Fedora builder (koji), 
>> which
>> I downloaded soon after the swupdates.openvpn.net server was updated.
> Lets try to attach the _proper_ signature file for v2.4.3.  I managed to
> send the signature for the previous (v2.4.2) release in the previous mail.

Thanks.

My original post was about the .tar.**gz**, but I downloaded (at about
12:45 UCT) both openvpn-2.4.3.tar.xz and openvpn-2.4.3.tar.xz.asc, and
verifying fails. However, verifying the .tar.xz against the .asc in
your email succeeds. So the problems seem to be with the .asc (for the
tar.xz, at least), not with the .tar.gz itself.

And I tried using a VPN : ) to download from London, hoping to get a
different CloudFlare server, but get the same (bad) .targ.gz and/or
.tar.gz.asc as my original downloads.

Should swupdates.openvpn.net be publicly accessible? It doesn't
resolve for me using Google DNS.

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.4.3 released (with security fixes)

[Jonathan K. Bullard]

On Wed, Jun 21, 2017 at 6:47 AM, Samuli Seppänen  wrote:
> The OpenVPN community project team is proud to release OpenVPN 2.4.3. It
> can be downloaded from here:
>
> 

Hi. Thanks for this release.

Verifying the PGP signature on 2.3.17.tar.gz works fine (so did 2.4.2
a few weeks ago), but trying to verify the signature on 2.4.3.tar.gz
fails with:

$ gpg2 -v --verify /XXX/openvpn-2.4.3.tar.gz.asc

gpg: armor header: Version: GnuPG v1
gpg: assuming signed data in '/XXX/openvpn-2.4.3.tar.gz'
gpg: Signature made Wed Jun 21 06:19:19 2017 EDT
gpg:using RSA key D72AF3448CC2B034
gpg: using subkey D72AF3448CC2B034 instead of primary key 12F5F7B42F2B01E7
gpg: using pgp trust model
gpg: BAD signature from "OpenVPN - Security Mailing List
" [unknown]
gpg: binary signature, digest algorithm SHA1, key algorithm rsa4096

The SHA256 ofopenvpn-2.4.3.tar.gz is
 84a01aa3df0c12a3552ca3baaa39d700137b5bce4b6de683fe87fb79bfa5df0b

The SHA256 of openvpn-2.4.3.tar.gz.asc is
 695afa06fcf94f9e8bd2ee63267332d14e52fe24dd58c470e42dafbea371e437

The files were downloaded from
https://openvpn.net/index.php/open-source/downloads.html at about
10:24 UCT today from the New York City area.

For reference, here is the output from verifying 2.3.17:

$ gpg2 -v --verify /Users/jonathanbullard/Desktop/openvpn-2.3.17.tar.gz.asc

gpg: armor header: Version: GnuPG v1
gpg: assuming signed data in
'/Users/jonathanbullard/Desktop/openvpn-2.3.17.tar.gz'
gpg: Signature made Wed Jun 21 06:18:55 2017 EDT
gpg:using RSA key D72AF3448CC2B034
gpg: using subkey D72AF3448CC2B034 instead of primary key 12F5F7B42F2B01E7
gpg: using pgp trust model
gpg: Good signature from "OpenVPN - Security Mailing List
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: F554 A368 7412 CFFE BDEF  E0A3 12F5 F7B4 2F2B 01E7
 Subkey fingerprint: B596 06E2 D8C6 E10B 80BE  2B31 D72A F344 8CC2 B034
gpg: binary signature, digest algorithm SHA1, key algorithm rsa4096

Any ideas or suggestions?

Thanks,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Problem with sig for 2.3.16?

[Jonathan K. Bullard]

On Fri, May 19, 2017 at 6:41 PM, David Sommerseth
<open...@sf.lists.topphemmelig.net> wrote:
> On 19/05/17 21:23, Jonathan K. Bullard wrote:
[snip]
> > OK, I get that, but the key file from the link David provided (and
> > which was also in his reply to the email announcing 2.3.16):
> >
> >  <http://pgp.mit.edu/pks/lookup?op=get=0x12F5F7B42F2B01E7>
> >
> > is not identical to the "Security mailing list GPG key" I just
> > downloaded from the "sig" page.
> >
> > Is that a problem?
>
> What is the difference you see?  To mem both looks identical when
> importing them into GPG.  But I haven't dug too deep into the details.

The contents of the files were different, which bothered me. I now
understand that that is OK -- I apologize for being too paranoid :)

They import identically for me, so all is well.


> One detail though, the "real" key ID is always the finger print.  Then
> there is two types of key IDs, one short and one long.  But those are
> just from the last bytes from the fingerprint.
>
> Key fingerprint: F554 A368 7412 CFFE BDEF  E0A3 12F5 F7B4 2F2B 01E7
> Key ID - long:  12F5 F7B4 2F2B 01E7
> Key ID - short:   2F2B 01E7

Ah. Thanks for the explanation. That makes sense! :)


> When I import both keys into the different brand new GPG key rings, I do
> get the same result when listing these keys.  But I haven't dug too deep
> into the context.  Plus the pgp.mit.edu site might have done some
> non-critical, minor changes in how the key looks like - compared to
> Samuli's version.

Yes, that's apparently what happened.


> That said, this security key is based upon the recommended sub-key
> approach [0].  That means that those of us among the developers can only
> use that key for signing and decryption data and with a fairly short
> lifetime (1 year).  They are not capable to sign other keys, updating
> the lifetime of the keys or any operation requiring the master key.  So
> I highly doubt Samuli have done anything special with that key.  Only I
> have the master key, which is well stored on a protected medium which is
> offline the very most of the time.
>
>
> [0] <https://alexcabal.com/creating-the-perfect-gpg-keypair/>

Thank you for your clear explanations, David -- and your patience!

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Problem with sig for 2.3.16?

[Jonathan K. Bullard]

On Fri, May 19, 2017 at 1:44 PM, Samuli Seppänen <sam...@openvpn.net> wrote:
> On 19/05/2017 17:50, David Sommerseth wrote:
>> On 19/05/17 16:28, Jonathan K. Bullard wrote:
>>> When I try to verify the signature on openvpn-2.3.16.tar.gz (using
>>> openvpn-2.3.16.tar.gz.asc) from the "Downloads" page [1], I get the
>>> following:
>>>
>>>  gpg: assuming signed data in `XXX/openvpn-2.3.16.tar.gz'
>>>  gpg: Signature made Thu May 18 16:56:48 2017 EDT using RSA key ID 
>>> 8CC2B034
>>>  gpg: Can't check signature: public key not found
>>>
>>> The signatures on openvpn-2.3.15.tar.gz (downloaded last week) and on
>>> openvpn-2.4.2.tar.gz both verify fine.
>>>
>>> I think this is because Samuli's new key's ID is not 8CC2B034, it is
>>> 40864578 (if I understand correctly what is meant by "ID".)
>>
>> Samuli have an old key (0x198D22A3, RSA-1024) and a new key (0x40864578,
>> RSA-2048).  He have switched to the new key and prefers to use that one.
>>
>> We decided just a few days ago that we will switch to use the
>> secur...@openvpn.net key for signing the officially released tarballs.
>>
>>
>>> Is 8CC2B034 the "Security mailing list GPGP key" on the "GnuPG Public
>>> Key" page [2]?
>> The proper key is:
>> pub   4096R/0x12F5F7B42F2B01E7 2017-02-09 [expires: 2027-02-07]
>> Key fingerprint = F554 A368 7412 CFFE BDEF  E0A3 12F5 F7B4 2F2B 01E7
>> uid   OpenVPN - Security Mailing List <secur...@openvpn.net>
>>
>> Which can also be found here:
>> <http://pgp.mit.edu/pks/lookup?op=get=0x12F5F7B42F2B01E7>
>>
>>
>>> The link on that page to that key is broken (and includes
>>> Javascript!).
>>
>> Yes!  I discovered the same issue and reported it internally a couple of
>> hours ago.  I expect it to be fixed in not too long.
>>
>
> Hi,
>
> Joomla did not seem to like the fact that file name was
> secur...@openvpn.net.key.asc. So I renamed it as security.key.asc. That
> seems to work fine.

Thanks!

> Right now the signature situation is a bit confusing, as 2.4.2 is still
> signed with my new key, and 2.3.16 is using the secur...@openvpn.net
> key. That is all documented here, though:
>
> <https://openvpn.net/index.php/open-source/documentation/sig.html>

OK, I get that, but the key file from the link David provided (and
which was also in his reply to the email announcing 2.3.16):

 <http://pgp.mit.edu/pks/lookup?op=get=0x12F5F7B42F2B01E7>

is not identical to the "Security mailing list GPG key" I just
downloaded from the "sig" page.

Is that a problem?

(Sorry if this is something that's common knowledge.)

Best regards,

Jon

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Problem with sig for 2.3.16?

[Jonathan K. Bullard]

When I try to verify the signature on openvpn-2.3.16.tar.gz (using
openvpn-2.3.16.tar.gz.asc) from the "Downloads" page [1], I get the
following:

 gpg: assuming signed data in `XXX/openvpn-2.3.16.tar.gz'
 gpg: Signature made Thu May 18 16:56:48 2017 EDT using RSA key ID 8CC2B034
 gpg: Can't check signature: public key not found

The signatures on openvpn-2.3.15.tar.gz (downloaded last week) and on
openvpn-2.4.2.tar.gz both verify fine.

I think this is because Samuli's new key's ID is not 8CC2B034, it is
40864578 (if I understand correctly what is meant by "ID".)

Is 8CC2B034 the "Security mailing list GPGP key" on the "GnuPG Public
Key" page [2]? The link on that page to that key is broken (and
includes Javascript!).

Best regards,

Jon

[1] https://openvpn.net/index.php/open-source/downloads.html
[2] https://openvpn.net/index.php/open-source/documentation/sig.html

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] OpenVPN 2.3.16 released

[Jonathan K. Bullard]

On Fri, May 19, 2017 at 5:29 AM, Samuli Seppänen  wrote:
>
> The OpenVPN community project team is proud to release OpenVPN 2.3.16.
> It can be downloaded from here:
>
> 
>
> This is a minor release that fixes a few bugs. This release was made
> primarily because CloudFlare managed to serve obsolete pre-release
> OpenVPN 2.3.15 tarballs which lack a fix for CVE-2017-7478:

Were all copies of openvpn-2.3.15.tar.gz that were downloaded from the
website pre-release versions and not the final versions, or only some?

If only some were the pre-release version, is there a way to tell if a
tarball was the pre-release version or was the actual version? (The
SHA256s of both would be helpful here.)

(I will release three new versions of Tunnelblick with 2.3.16 anyway;
I'd just like to know.)

Best regards to all,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] The future of contrib/keychain-mcd

[Jonathan K. Bullard]

Hi.

Several weeks ago "kaloprominat" submitted PR #369 [1] to Tunnelblick.
It incorporates the keychain-mcd code into Tunnelblick. (I don't know
if that triggered your scrutiny of keychain-mcd or if that is a
coincidence.)

I have not finished reviewing the PR, but it includes fixes for
several problems that were found in the keychain-mcd code. When I
finished my review I was going to suggest that kaloprominat submit the
fixes as patches to OpenVPN.

I would like to add this feature to Tunnelblick (assuming it is fully
fixed, of course), particularly because it will allow Tunnelblick
users to use security tokens that are integrated into the macOS
Keychain. Currently, Tunnelblick uses pkcs11-helper for this, but the
Tunnelblick implementation is broken, so this would fix an outstanding
issue for Tunnelblick users.

So although I can't commit to maintaining this code, I would like to
encourage someone else to do so : )

Best regards,

Jon Bullard

[1] https://github.com/Tunnelblick/Tunnelblick/pull/369

On Fri, May 5, 2017 at 7:21 PM, David Sommerseth
 wrote:
>
> Hi,
>
> We have had the contrib/keychain-mcd code under a more thorough code
> review lately.  And there are several issues found during that review
> which really needs to be improved.
>
> Basically most of the functions handling memory management have a very
> ambitious coding style.  The result of functions allocating memory is
> never checked, just presumes it is fine.  That will in most scenarios
> work perfectly fine, until the day where one of these allocations fails
> and the rest of the code starts tries to use a NULL pointer instead.
>
> I have tried to get in touch with the contributor (on Cc) directly two
> times in April (12th and 21st) already and have not heard anything at all.
>
> We in the core team would like to see this issue resolved, but it can't
> drag out forever.  So I propose that unless someone who is interested in
> this code shows up within the end of May 2017, that code is in high risk
> of being completely removed from our source tree.
>
> Please do get in touch ASAP if you use this code and would like to help
> improving it.
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Technologies, Inc
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Use SHA256 for the internal digest, instead of MD5

[Jonathan K. Bullard]

On Sun, Dec 25, 2016 at 6:20 PM, Steffan Karger  wrote:
> Hi,
>
> On 18-12-16 22:26, Gert Doering wrote:
>> On Sun, Dec 18, 2016 at 05:40:55PM +0100, Steffan Karger wrote:
>>> Our internal options digest uses MD5 hashes to store the state, instead of
>>> storing the full options string.  There's nothing wrong with that, but it
>>> would still be better to use SHA256 because:
>>>  * That makes it easier to make OpenVPN "FIPS-compliant" (forbids MD5)
>>>  * We don't have to explain anymore that MD5 is fine too
>>>
>>> The slightly less bytes for the digest (16 instead of 32) and operations
>>> per connection setup are not worth sticking to MD5.
>>
>> I can't find very clear information on "which versions of OpenSSL do
>> support sha256", but since we have a trac ticket about our windows
>> builds having issues with sha256 certificates we might take this
>> opportunity to revisit minimum OpenSSL versions supported in master
>> from now on...
>
> The oldest OpenSSL we support in release/2.4 and master is 0.9.8, and
> has SHA256 support (was introduced in 2004).  Also, the --tls-crypt
> feature already unconditionally requires SHA256 to be available.

The OpenSSL included in macOS  (was OS X) 10.11 and 10.12 (the two
most recent versions) is 0.9.8zh (an Apple-patched version) and as far
as I can tell, it does not seem to include SHA256 (i.e., "openssl sha1
foo" works but "openssl sha256 foo" doesn't).

That's not a problem for Tunnelblick because Tunnelblick static-links
in a more recent version of OpenSSL. But it could be a problem for
anyone who uses a non-Tunnelblick OpenVPN binary from the command
line.

- Jon

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of today's (Monday, 10th Oct 2016) community meeting

[Jonathan K. Bullard]

Hi,

On Thu, Nov 3, 2016 at 8:26 AM, Gert Doering <g...@greenie.muc.de> wrote:
>
> On Wed, Nov 02, 2016 at 06:19:26AM -0400, Jonathan K. Bullard wrote:
> > On Mon, Oct 10, 2016 at 4:26 PM, Samuli Seppänen <sam...@openvpn.net>
> wrote:
> > > Discussed OpenVPN 2.3.13 release. Three things are missing:
> > >
> > > 1. recursive routing
> > > 2. block-outside-dns v2
> > > 3. 64MB renegotiation for 64-bit block ciphers
> > >
> > > Cron2 will take care of 1-2, and syzzer will tackle 3.
>
> 2.3.13 has been released, but 1. and 2. are actually still missing - I've
> lost track of 2., and 1. did not work out.  3. is in.
>
> 2.3.14 will follow "in a few weeks", having 1.+2..  But don't wait for it.


Thanks, for both the release and the forecast (I understand that it it
a"guesstimate, not a commitment).

For me/Tunnelblick, #3 was the important one; as I understand it #2 is
Windows-only so irrelevant.

(I won't wait! I expect to release a new Tunnelblick beta later today or
tomorrow.)
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Summary of today's (Monday, 10th Oct 2016) community meeting

[Jonathan K. Bullard]

On Mon, Oct 10, 2016 at 4:26 PM, Samuli Seppänen  wrote:
> Discussed OpenVPN 2.3.13 release. Three things are missing:
>
> 1. recursive routing
> 2. block-outside-dns v2
> 3. 64MB renegotiation for 64-bit block ciphers
>
> Cron2 will take care of 1-2, and syzzer will tackle 3.
>
> --
>
> Preliminary release date for OpenVPN 2.4-alpha1 was set to late this week.
> If we don't get Windows test reports then we may have to postpone the
> release a bit. OpenVPN 2.3.13 release date was set to "early next week".

Sorry to be a pest, but is there an update on when 2.3.13 might be released?

I know the focus is on 2.4 because of the looming Debian deadline, but
I've been holding off on releasing a version of Tunnelblick until it
could include 2.3.13 along with a 2.4_alpha. I can release without
2.3.13 if necessary.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Thanks to both Gert and Arne for their answers.

On Wed, Oct 12, 2016 at 9:12 AM, Arne Schwabe  wrote:
>> What I should have asked is: with this patch will an OpenVPN client
>> still send out IPv4 packets if there are no IPv6 options specified or
>> pulled from the server?

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Thanks, Arne. Sorry if I wasn't a clear as I should have been.

On Wed, Oct 12, 2016 at 8:08 AM, Arne Schwabe <a...@rfc2549.org> wrote:
>
> Am 12.10.16 um 13:17 schrieb Jonathan K. Bullard:
> > Hi.
> >
> > On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe <a...@rfc2549.org> wrote:
> >> This option was useful when Ipv6 tun support was
> >> non standard and was an internal/user specified flag
> >> that tracked the Ipv6 capability of the tun device.
> >>
> >> All supported OS support IPv6. Also tun-ipv6 is
> >> pushable by the remote so not putting tun-ipv6
> >> does not forbid ipv6 addresses.
> > How will this patch affect a VPN on a system that has IPv6 disabled?
> >
> >
> Short version: Fail as miserable as before.

Connections don't fail in the situation I describe (IPv6 disabled at
the OS level). At least not when there are no IPv6 options enabled in
the OpenVPN configuration or pushed from the server, which is the
setup that many VPN service providers use.


> You might think that leaving out tun-ipv6 might fix your
> problem but tun-ipv6 is a pushable option and the server-ipv6 macro will
> push it, so you end up with tun-ipv6 without having it in the client config.

The problem was not that the server was pushing tun-ipv6 (the
configurations and server pushes did not have any IPv6 references).
The problem was that the OS prefers IPv6 over IPv4 when both were
available. So the OS was sending out IPv6 packets, which caused
information leakage. The solution was not leaving out the tun-ipv6
option, but disabling IPv6 in the OS.

What I should have asked is: with this patch will an OpenVPN client
still send out IPv4 packets if there are no IPv6 options specified or
pulled from the server?

If yes, the connection will succeed. If no, then disabling IPv6 in the
OS will cause failed connections. (Unless with IPv6 disabled the OS
translates IPv6 packets to IPv4 and sends them, which seems unlikely
to me.)

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Remove tun-ipv6 Option. Instead assume that IPv6 is always supported.

[Jonathan K. Bullard]

Hi.

On Wed, Oct 12, 2016 at 5:13 AM, Arne Schwabe  wrote:
>
> This option was useful when Ipv6 tun support was
> non standard and was an internal/user specified flag
> that tracked the Ipv6 capability of the tun device.
>
> All supported OS support IPv6. Also tun-ipv6 is
> pushable by the remote so not putting tun-ipv6
> does not forbid ipv6 addresses.

How will this patch affect a VPN on a system that has IPv6 disabled?

To prevent information leakage, Tunnelblick has an option in tun mode
that forces the OS to disable IPv6 (via a "networksetup -setv6off" OS
X command.)

The information leakage when using IPv6 in a VPN is described in [1].
As of the date of the article (June 2015), the problem was common
among VPN service providers. The "disable IPv6" feature was added to
Tunnelblick because disabling IPv6 was the only way that a user of
such services could protect themselves. It isn't clear if all VPN
service providers have fixed their configurations yet (or will ever
fix their configurations).

Best regards,

Jon Bullard

[1] http://www.eecs.qmul.ac.uk/~hamed/papers/PETS2015VPN.pdf

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Topics for today's (Monday, 10th Oct 2016) community meeting

[Jonathan K. Bullard]

On Mon, Oct 10, 2016 at 8:56 AM, Samuli Seppänen  wrote:
>
> We're going to have an IRC meeting today starting at 20:00 CEST (18:00
> UTC) on #openvpn-meeting  irc.freenode.net. You do not have to be
> logged in to Freenode to join the channel.

I can't attend the meeting, so here is a simple (maybe stupid, too!) question:

Will 2.4alpha1 come directly from the master branch?

Tunnelblick betas include a  copy of OpenVPN built from the GitHub
master branch (along with a 2.3 copy with 2.3.x), so it would be nice
to know that it includes something close to 2.4alpha1. Tunnelblick
3.6.9beta1, for example, includes a copy of OpenVPN built from the
GitHub master branch as of bae1ad7 [1]. The latest beta includes
LibreSSL and OpenSSL versions of each OpenVPN, too.

Best regards,

Jon Bullard

[1] 
https://github.com/OpenVPN/openvpn/commit/bae1ad7005fd9a1fadeed56370a9ac5422a33fee

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Have the same username/password length regardless of PKCS#11 enablement

[Jonathan K. Bullard]

On Thu, Sep 22, 2016 at 6:04 AM, David Sommerseth  wrote:
> If running an OpenVPN client with --enable-pkcs11 and a server without
> and having a username and/or password with more than 128 characters,
> the authentication will fail as the server truncates the password
> to 128 bytes.
>
> This makes things easier and more predictable.  Username/passwords
> can be up to 4096 bytes, regardless of the --enable-pkcs11 state.

Hi David,

1. Minor quibble: "Characters" is a bit misleading because (I think)
it is actually the number of bytes that is limited -- a UTF-8 string
of 256 bytes may represent fewer than 256 characters.

2. The management interface limits usernames, passwords, and private
keys to 255 or 256 bytes. The following error is sent by over the
management interface in response to a 275 byte password ("a-y"
repeated 11 times):

ERROR: Options error: Parameter at TCP:0 is too long (256 chars max):
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcde

Note that although the error message says 256 characters is the
maximum, there are only 255 characters/bytes in the password it sends
back. Perhaps an off-by-one error? (And I am pretty sure that "bytes"
is what is limited, not "characters", as per above.)

Best regards,

Jon Bullard

--
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] The end of the Gmane archive

[Jonathan K. Bullard]

Yesterday Lars Ingebrigtsen, who established and has run Gmane since
2002, posted an article saying that Gmane might go away [1].

He posted an update [2] which says the Gmane archive *has* gone away
and unless someone steps up to take it over, it is gone for good.

The OpenVPN mailing list archives are still available on SourceForge,
but it might be worth thinking about adding openvpn-dev and
openvpn-users to The Mail Archive [3] or some other such service.

[1] https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane
[2] 
https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
[3] https://www.mail-archive.com

Re: [Openvpn-devel] [PATCH 3/7] vlan: Add global, per-client 802.1q-based options

[Jonathan K. Bullard]

On Sun, Apr 3, 2016 at 2:51 PM, Mike Auty  wrote:
>
> This patch add the new global "--vlan-tagging" boolean switch.  This specifies
> whether openvpn should handle 802.1q tagged packets in any way.
>
> This patch also adds the new global '--vlan-accept tagged|untagged|all' which
> specifies the behaviour of the tap device with regards to 802.1q vlan tagged
> packets.
>
> This patch also adds the new "--vlan-pvid" integer option.




> @@ -7178,6 +7224,45 @@ add_option (struct options *options,
>options->keying_material_exporter_length = ekm_length;
>  }
>  #endif
> +#ifdef ENABLE_VLAN_TAGGING
> +  else if (streq (p[0], "vlan-tagging"))
> +{
> +  VERIFY_PERMISSION (OPT_P_GENERAL);
> +  options->vlan_tagging = true;
> +}
> +  else if (streq (p[0], "vlan-accept") && p[1])
> +{
> +  VERIFY_PERMISSION (OPT_P_GENERAL);
> +  if (streq (p[1], "tagged"))
> +   {
> + options->vlan_accept = VAF_ONLY_VLAN_TAGGED;
> +   }
> +  else if (streq (p[1], "untagged"))
> +   {
> + options->vlan_accept = VAF_ONLY_UNTAGGED_OR_PRIORITY;
> +   }
> +  else if (streq (p[1], "all"))
> +   {
> + options->vlan_accept = VAF_ALL;
> +   }
> +  else
> +   {
> + msg (msglevel, "--vlan-accept must be 'tagged', 'untagged' or 
> 'all'");
> + goto err;
> +   }
> +}
> +  else if (streq (p[0], "vlan-pvid") && p[1])
> +{
> +  VERIFY_PERMISSION (OPT_P_GENERAL|OPT_P_INSTANCE);
> +  options->vlan_pvid = positive_atoi (p[1]);
> +  if (options->vlan_pvid < OPENVPN_8021Q_MIN_VID ||
> + options->vlan_pvid > OPENVPN_8021Q_MAX_VID)
> +   {
> + msg (msglevel, "the parameter of --vlan-pvid parameters must be >= 
> %u and <= %u", OPENVPN_8021Q_MIN_VID, OPENVPN_8021Q_MAX_VID);
> + goto err;
> +   }
> +}
> +#endif
>else
>  {
>int i;


NAK. This should include testing for extra parameters supplied in
error with the options, as the rest of the option-handling code does.
Something like the following (for each of the three new options):

+  else if (streq (p[0], "vlan-tagging") && !p[1])

Re: [Openvpn-devel] Options that are "safe" for users to modify?

[Jonathan K. Bullard]

Thanks, Selva.

On Sat, Dec 12, 2015 at 5:43 PM, Selva Nair  wrote:
> I suppose, not just adding but also removing options will be allowed. There
> could be more options that are ok (i.e not unsafe) to remove but not change.

What I'm proposing isn't to allow "add/remove/modify" options in the
OpenVPN configuration file, but to allow the replacement of the
contents of files that are referred to in options in it. I admit that
is a much less general approach.


>> --pkcs1

Sorry, should have been --pkcs12


>> --static

Sorry, should have been --secret


>> --ta
>
> --ta ?

Oops. No, sorry, that was just plain wrong.

The corrected list is:

--askpass
--auth-user-pass
--ca
--cert
--dh
--extra-certs
--key
--pkcs12
--secret
--tls-auth

I'm not clear at all about --crl-verify. Would it ever be used in a
client? Would there be a security risk if a client erased the contents
of the file? (Would that allow a client to connect to a server that
has a revoked certificate which would otherwise not be allowed?
**That** would be a security problem.)


> As remote cant change, several more options may be safe, though note
> necessarily very useful. Here are a couple of options that could help when
> the server is updated, for example
>
> --topology  t  (mainly to remove from client so that a new setting at the
> server can take effect through push -- say moving from net30 to subnet)
> --comp-lzo
> --secret  (for non-tls)
> --auth
> --cipher

I'm not (at this point, anyway) talking about changing options in the
configuration file, I'm talking about changing the contents of files
**referred to** in the configuration file. (So yes to --secret, which
I mistyped as --static, but no to the others. I think they are
configuration changes that warrant an admin doing them.)

Re: [Openvpn-devel] Options that are "safe" for users to modify?

[Jonathan K. Bullard]

Hi.

On Sat, Dec 12, 2015 at 5:23 PM, Arne Schwabe  wrote:
> Might not really be related to this but have looked into the work that
> provides the certificates and keys via the managment console? We have
> even have a contrib program that gets certificates from the Mac OS X
> keychain and provides them to OpenVPN.

Thanks, but I think that should be a separate discussion. That would
work for some situations, but the keychain (actually, OS X has several
keychains) may not be accessible to OpenVPN; files are always
accessible, even before a user is logged in. And I don't think (I'm
doing this from memory, so I might be wrong) that the Keychain patch
allows **all** of the encryption info to be taken from the keychain: I
don't think it allows --secret, --ta, etc.

[Openvpn-devel] Options that are "safe" for users to modify?

[Jonathan K. Bullard]

Inspired by Gert, I am considering adding a new feature to Tunnelblick
(FOSS GUI for OpenVPN on OS X) and would like your reactions. In an
earlier thread on openvpn-users, my original more grandiose idea was
(with good reason) NAKed. It was also suggested that openvpn-devel was
a better place for the discussion.

The goal is to allow a non-admin to update keys and certificates
without needing the admin authorization that is currently required by
Tunnelblick. Changing Tunnelblick so that it runs OpenVPN as the user
is one way of doing that, but is much more work and has broader
consequences than what I am proposing and I'd like to avoid discussion
of that in this thread if possible.

Tunnelblick currently "secures" OpenVPN configuration files and the
files they reference (e.g., "targets" of --ca, --key, etc.) by making
them writable only by root. A user can change a configuration only by
getting admin authorization. (Some files may be readable only by root,
too, but that's not relevant here.)

What I am proposing is for Tunnelblick to allow the user to replace
certain files referred to in a configuration without admin
authorization. This would be done by allowing changes to files
referenced by options that are on a whitelist. So what options should
go on that whitelist?

My tentative plan is to allow users to update without authorization
any files that are the "targets" of the following options:

--askpass
--auth-user-pass
--ca
--cert
--dh
--extra-certs
--key
--pkcs1
--static
--ta
--tls-auth

I'm not proposing to let the user modify the files directly -- they
would continue to be writable only by root. The files would be
modified by the same privileged Tunnelblick daemon that starts OpenVPN
as root ( and which will enforce the restrictions).

The original implementation would only replace files but it could be
extended to replace inline options in the configuration file itself,
too.

My hope is that it would be "safe" to allow this, in the sense that
the user couldn't get themselves into much trouble: no escalation of
privileges, no messing up routing tables, etc. I think the worst that
could happen is that a configuration would stop working. (But I'd like
some reassurance that that is true, which is why I'm asking for your
advice.)

For anyone interested, it would work like this: the simplest
Tunnelblick configuration is a folder with an extension of ".tblk"
that contain one .ovpn file and all the files referred to in that
file. A Tunnelblick configuration is installed or replaced by
double-clicking it, which invokes Tunnelblick to do the
installation/replacement. Currently, installing or replacing (or
deleting) a Tunnelblick configuration requires getting authorization
from an admin; the plan is to skip the authorization if replacing and
the only changes are to files as described above. So double-clicking a
.tblk for the original installation would need admin authorization,
but double-clicking it to replace a configuration would not, as long
as the only changes were to the files described above. Double-clicking
a replacement .tblk that includes a modified OpenVPN configuration
file itself (or script files, etc.) would continue to require admin
authorization. System admins would distribute a single .tblk that
could be used to do either an original install or a replacement;
Tunnelblick would figure out which it was and get authorization or
not. The ability to do these non-admin-authorized replacements would
be disabled by default and would need to be authorized by an admin, so
it would only work for users if the admin wants it to.

Reactions? Thanks in advance. (Oh, and please don't blame Gert for any
of this; any good ideas are his but I'm to blame for any bad ones : )

Re: [Openvpn-devel] Docs or Bug: --push options no longer require double quotes

[Jonathan K. Bullard]

On Sat, Jul 25, 2015 at 3:45 PM, Gert Doering  wrote:
> Hi,
>
> On Sat, Jul 25, 2015 at 01:34:46PM +0100, debbie...@gmail.com wrote:
>> As the title states --push no longer requires options to be double quoted.
>
> Well, *did* it require double quotes at some point?  If yes, when?

Double-quotes may not be required in a configuration file, but they
are required (or single-quotes, or the space must be escaped) if the
option is used on a command line, e.g.,

 openvpn --push "redirect-gateway def1" ...

Otherwise "redirect-gateway" is considered the "option" to --push, and
"def1" will be interpreted as something else (a config file? an
error?).

This is true of **any** single argument to an Openvpn command line
option: if it contains spaces or tabs, it must be enclosed in
double-quotes (or single-quotes, or have the spaces escaped with
backslashes).

It is also true of arguments in a configuration file if there is more
than one argument to the option and the first argument contains
spaces. For example, --secret file [direction]:

 secret "file-path with spaces" 0

I think it is best to always enclose any single argument that contains
spaces with double-quotes, even in a configuration file. This makes it
completely unambiguous, and future-proofs the file if a later version
of OpenVPN allows an optional argument to the option.

Re: [Openvpn-devel] [PATCH] Add TFTP and WPAD DHCP options

[Jonathan K. Bullard]

On Thu, Jul 2, 2015 at 2:56 AM, Jan Just Keijser  wrote:
> Attached is the patch to add the TFTP and WPAD DHCP options. The patch
> is based on openvpn 2.3.7 as I did not know how to do a windows mingw
> build of the git version ...
> The patch was tested on Windows XP 32bit and Windows 7sp1 64bit.
> A 64bit windows binary can be found @
> http://www.nikhef.nl/~janjust/openvpn-2.3.7-dhcp-win64.exe
>
> Signed-off-by: Jan Just Keijser 



NAK, but easy to fix (I think). Three small problems are described below.

> @@ -6153,6 +6157,14 @@
> {
>   o->disable_nbt = 1;
> }
> + else if (streq (p[1], "TFTP") && p[2])
> +   {
> + o->tftp = p[2];
> +   }
> + else if (streq (p[1], "WPAD") && p[2])
> +   {
> + o->wpad_url = p[2];
> +   }
>else
> {
>   msg (msglevel, "--dhcp-option: unknown option type '%s' or
> missing parameter", p[1]);

1. Shouldn't "dhcp_option_address_parse()" be used to set o->tftp and
o->wpad_url? (In the code just before this, it is used for NTP, WINS,
etc.)


> --- openvpn-2.3.7/src/openvpn/tun.c 2015-06-08 08:16:35.0 +0200
> +++ /tmp/build-x86_64/openvpn-2.3.7/src/openvpn/tun.c   2015-07-02
> 11:30:19.979658823 +0200
> @@ -4692,6 +4692,23 @@
>  buf_write_u8 (buf,  4);  /* length of the vendor specified field */
>  buf_write_u32 (buf, 0x002);
>}
> +
> +write_dhcp_str (buf, 66, o->tftp, );
> +write_dhcp_str (buf, 150, o->tftp, );
> +
> +  /* IE6 seems to requires an extra charachter at the end of the URL */



2. This should be "character", not "charachter".

3. This should be documented on the man page, too.

Re: [Openvpn-devel] [Patch] Version 2: Fail if options have extra parameters

[Jonathan K. Bullard]

On Wed, Jun 3, 2015 at 2:33 AM, Arne Schwabe  wrote:
> ACK. But some things I noticed (should go into separate patch)
>
> We do not catch
>
> --connection foo, it is silently ignored

I noticed a few such problems, mostly in options that I couldn't find
consistent documentation for. I didn't want to risk introducing
problems until I understood them better. I expect to submit individual
patches for each one at some point.

[Openvpn-devel] [Patch] Version 2: Fail if options have extra parameters

[Jonathan K. Bullard]

This is a new thread with version 2 of the patch; the first submission
included the wrong .patch file and was withdrawn.

The attached patch causes an error if an option has extra
parameters; previously they were ignored (ticket #557 at
https://community.openvpn.net/openvpn/ticket/557).

This feature was discussed on the openvpn-devel mailing list (
http://thread.gmane.org/gmane.network.openvpn.devel/9599).

The patch is for the master branch only -- the consensus of the
mailing list discussion was that the patch should not be included in
the 2.3 branch.

The (modified) message "Unrecognized option or missing or extra
parameter(s)" is used except for a few options:

 * The --help option: An extra parameter for --help generates a
specific error message after showing the syntax message. This is done
to help a user who tries "--help tls-cipher" or similar, hoping to get
more information about the "tls-cipher" option.

 * The --dhcp-option option: It has its own similar message, into
which " or extra" has been inserted.

 * Ten options such as --up that accept a command (instead of a
path) already detect extra parameters and generate specific error
messages that mention double-quoting commands which contain imbedded
spaces.


extra-parameters-v2.patch
Description: Binary data

Re: [Openvpn-devel] [Patch] Fail if options have extra parameters

[Jonathan K. Bullard]

Please ignore this patch; it is an old version. I will resubmit. Sorry for
the noise.

On Fri, May 29, 2015 at 11:54 AM, Jonathan K. Bullard <jkbull...@gmail.com>
wrote:

> Sorry, forgot to add a link to the ticket for this:
>
> https://community.openvpn.net/openvpn/ticket/557
>
> On Fri, May 29, 2015 at 11:38 AM, Jonathan K. Bullard
> <jkbull...@gmail.com> wrote:
> > The attached patch causes an error if an option has are extra
> > parameters; previously they were ignored.
> >
> > This feature was discussed on the openvpn-devel mailing list:
> > http://thread.gmane.org/gmane.network.openvpn.devel/9599
> >
> > The patch is for the master branch only -- the consensus of the
> > mailing list discussion was that the patch should not be included in
> > the 2.3 branch.
> >
> > The (modified) message "Unrecognized option or missing or extra
> > parameter(s)" is used except for a few options:
> >
> >  * The --help option: An extra parameter for --help generates a
> > specific error message after showing the syntax message. This is done
> > to help a user who tries "--help tls-cipher" or similar, hoping to get
> > more information about the "tls-cipher" option.
> >
> >  * The --dhcp-option option: It has its own similar message, into
> > which " or extra" has been inserted.
> >
> >  * Ten options such as --up that accept a command (instead of a
> > path) already detect extra parameters and generate specific error
> > messages that mention double-quoting commands which contain imbedded
> > spaces.
>

Re: [Openvpn-devel] [Patch] Fail if options have extra parameters

[Jonathan K. Bullard]

Sorry, forgot to add a link to the ticket for this:

https://community.openvpn.net/openvpn/ticket/557

On Fri, May 29, 2015 at 11:38 AM, Jonathan K. Bullard
<jkbull...@gmail.com> wrote:
> The attached patch causes an error if an option has are extra
> parameters; previously they were ignored.
>
> This feature was discussed on the openvpn-devel mailing list:
> http://thread.gmane.org/gmane.network.openvpn.devel/9599
>
> The patch is for the master branch only -- the consensus of the
> mailing list discussion was that the patch should not be included in
> the 2.3 branch.
>
> The (modified) message "Unrecognized option or missing or extra
> parameter(s)" is used except for a few options:
>
>  * The --help option: An extra parameter for --help generates a
> specific error message after showing the syntax message. This is done
> to help a user who tries "--help tls-cipher" or similar, hoping to get
> more information about the "tls-cipher" option.
>
>  * The --dhcp-option option: It has its own similar message, into
> which " or extra" has been inserted.
>
>  * Ten options such as --up that accept a command (instead of a
> path) already detect extra parameters and generate specific error
> messages that mention double-quoting commands which contain imbedded
> spaces.

[Openvpn-devel] [Patch] Fail if options have extra parameters

[Jonathan K. Bullard]

The attached patch causes an error if an option has are extra
parameters; previously they were ignored.

This feature was discussed on the openvpn-devel mailing list:
http://thread.gmane.org/gmane.network.openvpn.devel/9599

The patch is for the master branch only -- the consensus of the
mailing list discussion was that the patch should not be included in
the 2.3 branch.

The (modified) message "Unrecognized option or missing or extra
parameter(s)" is used except for a few options:

 * The --help option: An extra parameter for --help generates a
specific error message after showing the syntax message. This is done
to help a user who tries "--help tls-cipher" or similar, hoping to get
more information about the "tls-cipher" option.

 * The --dhcp-option option: It has its own similar message, into
which " or extra" has been inserted.

 * Ten options such as --up that accept a command (instead of a
path) already detect extra parameters and generate specific error
messages that mention double-quoting commands which contain imbedded
spaces.


extra-parameters.patch
Description: Binary data

[Openvpn-devel] [Patch] Fix null pointer dereference in options.c

[Jonathan K. Bullard]

(At Gert's request, I am posting this to openvpn-devel.)

This patch fixes a null pointer dereference in options.c.

Below are versions for openvpn-master and openvpn-2.3; they differ
only in the line number reference.


2.3 branch

diff -U 4 -r openvpn-release-2.3/src/openvpn/options.c
openvpn-fix-peer-id-2.3/src/openvpn/options.c
--- openvpn-release-2.3/src/openvpn/options.c 2015-05-18
12:30:14.0 -0400
+++ openvpn-fix-peer-id-2.3/src/openvpn/options.c 2015-05-21
06:52:38.0 -0400
@@ -7058,9 +7058,9 @@
   VERIFY_PERMISSION (OPT_P_GENERAL);
   options->persist_config = true;
   options->persist_mode = 1;
 }
-  else if (streq (p[0], "peer-id"))
+  else if (streq (p[0], "peer-id") && p[1])
 {
   VERIFY_PERMISSION (OPT_P_PEER_ID);
   options->use_peer_id = true;
   options->peer_id = atoi(p[1]);



Master branch

diff -U4 -r openvpn-master/src/openvpn/options.c
openvpn-fix-peer-id-master/src/openvpn/options.c
--- openvpn-master/src/openvpn/options.c 2015-05-18 12:25:46.0 -0400
+++ openvpn-fix-peer-id-master/src/openvpn/options.c 2015-05-20
23:38:41.0 -0400
@@ -7043,9 +7043,9 @@
   VERIFY_PERMISSION (OPT_P_GENERAL);
   options->persist_config = true;
   options->persist_mode = 1;
 }
-  else if (streq (p[0], "peer-id"))
+  else if (streq (p[0], "peer-id") && p[1])
 {
   VERIFY_PERMISSION (OPT_P_PEER_ID);
   options->use_peer_id = true;
   options->peer_id = atoi(p[1]);

Re: [Openvpn-devel] OpenVPN argument parsing of most options ignores "extra" parameters

[Jonathan K. Bullard]

On Mon, May 4, 2015 at 9:26 AM, Jonathan K. Bullard wrote:
> If I have a
> configuration that has worked for many years I might be more likely to
> not notice one warning among all the output in a typical log at the
> default "verb 3" setting.

Correction: the default setting is "verb 1", not "verb 3".

However, almost all of the configurations I see from people
troubleshooting Tunnelblick include "verb 3", and eight of the ten
sample configuration files in OpenVPN 2.3.6 include "verb 3". So I
think my conclusions are still valid: a typical log includes a lot of
information and warnings are easily overlooked in a configuration that
was worked for years.

Re: [Openvpn-devel] Request peer review of modified OpenVPN client software

[Jonathan K. Bullard]

On Tue, May 12, 2015 at 7:27 AM, Lisa Minogue  wrote:

> Can I conclude from your above statements that applying obfuscation
> patches to the standard OpenVPN client software may actually introduce
> security vulnerabilities?
>

The openvpn_xorpatch

which
as introduced and discussed in this thread
 does have some vulnerabilities
See Tunnelblick openvpn_xorpatch
 for a
further discussion of the patch.

Most of the vulnerabilities are null pointer dereferences or other errors
when parsing the "scramble" option or are triggered by unlikely values for
its parameters. However, one is a potential buffer overflow which can occur
while the VPN is active and could potentially be triggered by carefully
constructed traffic.

Re: [Openvpn-devel] OpenVPN argument parsing of most options ignores "extra" parameters

[Jonathan K. Bullard]

On Sun, May 3, 2015 at 12:33 PM, Steffan Karger <stef...@karger.me> wrote:
> On 17-04-15 11:28, Jonathan K. Bullard wrote:
> > I would like to propose a patch which complains if OpenVPN options
> > include parameters that are not expected.
>
> I agree that silently ignoring extra parameters is not nice. However, I
> think that breaking configs after they have worked for many years might
> result in too many unpleasant surprises for our users. How would you
> feel about just issuing a warning for ignored extra parameters?

Thanks for your comment. It's a difficult balance.

In my opinion a warning is not sufficient: if a configuration has an
extra parameter, the user probably **thinks** that the parameter is
doing something. In that situation, I would personally would rather
have an unpleasant surprise than continue in ignorance. If I have a
configuration that has worked for many years I might be more likely to
not notice one warning among all the output in a typical log at the
default "verb 3" setting.

The "fix" if a config fails is very simple: remove the extra parameter
or insert a line break if one is missing. You can then connect, and
OpenVPN's behavior will not have changed except that if a line break
was inserted then the previously ignored option will be used. If the
parameter was supposed to do something important, then more thought
might be required, but in that case, it is probably even **more**
important that the configuration breaks.

Perhaps it could go into OpenVPN 2.4 but not 2.3? As I understand it,
2.3 is gets security and bug fixes, so many people probably don't test
it as thoroughly as a new release; some probably won't test it at all
-- those are the ones that you are presumably worried about. When 2.4
is released, most people will test it at least cursorily before
deploying it. If extra parameters cause a failure, it will be
immediately obvious and can be fixed easily.

Although usually ignoring extra parameters would not cause security
problems, to the extent they do, the concept of OpenVPN being "secure
by default" is jeopardized by not causing an error. Something like
ignoring a "--redirect-gateway def1" -- which would cause traffic to
be "leaked" outside of the VPN -- could be considered a security risk.

Re: [Openvpn-devel] [PATCH v3] Mac OS X Keychain management client

[Jonathan K. Bullard]

On Mon, Feb 23, 2015 at 8:10 AM, David Woodhouse  wrote:
> On Mon, 2015-02-23 at 13:59 +0100, Arne Schwabe wrote:
>>
>> All fine. My rationale was like, if I want a certificate with a certain
>> SUBJECT (e.g. CN=schw...@mycoolca.com) etc. it should not matter for men
>> wether I get it from OS X, Windows or Android Certificate store.
>
> The canonical way of representing that would be
>  pkcs11:object=schw...@mycoolca.com

That representation loses the "CN=" (and maybe doesn't allow for
additional search options -- I'm not sure).

OpenVPN already has an entire set of options that deal with PKCS-11.
This patch is a completely different, parallel way of dealing with
certificates, so I'm not sure why a "pkcs11:" scheme is needed. I
probably would not implement it in Tunnelblick myself.

There are two things here: (A) what this "select" string is and (B)
where/how to find the cert.

As to "what this 'select' string is" -- well, for "future-proofing", I
would want it to be labeled as a selection string in case we want to
pass something else at some time in the future.

Adding a scheme makes sense to me -- the "file:" scheme looks
interesting, but it isn't part of this patch. But I think the scheme
should be optional, so the configuration could include (the
platform-independent):

 --management-external-keychain select:CN=schw...@mycoolca.com

and have it use the Keychain on OS X, Android Certificate Store on
Android, something-I-don't-know on Windows, etc.

The tricky aspect of that is that the default would really depend on
the management interface software, which really means it depends on
the GUI. It is conceivable that two GUIs for the same platform could
have different defaults (although I assume both Tunnelblick and
Viscosity would use Keychain as the default, accessing it with
keychain-mcd).

Re: [Openvpn-devel] [PATCH v3] Mac OS X Keychain management client

[Jonathan K. Bullard]

On Mon, Feb 23, 2015 at 4:00 AM, Gert Doering  wrote:
>
> On Mon, Feb 23, 2015 at 09:28:31AM +0100, Arne Schwabe wrote:
> > > What do you think of the change?
> > I like the idea. You could  make the macos-keychain in the string optional.
>
> What Arne said (both parts of it) :-)

I agree -- the argument to --needs-external-cert should be optional.

Note: the argument to --needs-external-cert should be passed on to
"RSA_SIGN", too. (I think Vasily omitted that from his writeup.)

So the idea would be:

 * Add an optional UTF-8 string argument to --needs-external-cert.
(Perhaps the docs should say this requires support from the management
interface software and that currently such support is only available
when using certain GUIs on OS X.)

 * OpenVPN passes that argument to RSA_SIGN and NEEDS-CERTIFICATE,
passing an empty string if the argument does not appear.

 * OS X GUIs such as Tunnelblick and Viscosity see the new RSA_SIGN or
NEEDS-CERTIFICATE argument and use keychain-mcd to deal with it. Other
GUIs ignore it or use something that does something equivalent to what
keychain-mcd does on OS X.

I'm not sure exactly how to add an argument to RSA_SIGN and
NEEDS-CERTIFICATE without breaking existing management interface
software but assume that is possible. (Also, the argument may need to
be escaped when it is passed to RSA_SIGN or NEEDS-CERTIFICATE if it
contains characters that are used as delimiters.)

[Openvpn-devel] [PATCH] Fix mismatch of fprintf format specifier and argument type

[Jonathan K. Bullard]

This fixes a warning about a mismatch between a fprintf format string
and an argument type on Darwin-64-bit builds:

%lu specifies type 'unsigned long' but the argument has type
'__darwin_suseconds_t' (aka 'int')
--- openvpn/src/openvpn/error.c 2015-01-23 13:17:50.0 -0500
+++ patched/src/openvpn/error.c 2015-02-03 22:12:32.0 -0500
@@ -319,7 +319,7 @@
 
  fprintf (fp, "%lu.%06lu %x %s%s%s%s",
   tv.tv_sec,
-  tv.tv_usec,
+  (unsigned long)tv.tv_usec,
   flags,
   prefix,
   prefix_sep,

Re: [Openvpn-devel] New OpenVPN Windows installers (I004 and I604) released

[Jonathan K. Bullard]

On Tue, Oct 21, 2014 at 6:43 AM, Gert Doering  wrote:
> Yes, exactly.  In essence, you have a windows service running with full
> privileges, which is instructed by the GUI to run an openvpn.exe process
> (with user privs, so OpenVPN can't do damage) and OpenVPN communicates
> back to the service what should be ifconfig'ed and what routes should
> be installed.  So the network config is done by the service, and
> undone when OpenVPN exits or crashes.

That's what I am hoping for -- either an extension to the management
interface, or an similar but separate interface.


> Unfortunately, right now, there is nothing at all yet - there is most of
> the code, but it's still living in Heiko's private tree.  We plan to meet
> in person in November ("Munich Hackathon") and hopefully this will unravel
> the knot that's holding up this change.

I look forward to hearing about it.

> How do you handle things in Tunnelblick today?  Run OpenVPN "as root"?

Yes, exactly. I'd love to make that not necessary.

Thanks for the info.

Jon

Re: [Openvpn-devel] Easy-RSA v3 release planning

[Jonathan K. Bullard]

On Tue, Jul 15, 2014 at 12:05 AM, Eric Crist <ecr...@secure-computing.net>
wrote:

> Josh and I spoke on this today and we're going to push to close a couple
> bugs and try to get an RC-2 published some time this week.
>

Terrific. Thanks for the update.



> On Jul 14, 2014, at 22:57:29, Jonathan K. Bullard <jkbull...@gmail.com>
> wrote:
>
> > On Tue, Dec 17, 2013 at 9:05 PM, Josh Cepek <josh.ce...@usa.net> wrote:
> > The notable fix since -rc1 has been support for OpenSSL-0.9.8 (commit
> > 8b1fe01.) While I hope this isn't a common need, the fix was simple
> > enough, and this is still a supported OpenSSL version.
> >
> > Any update on the availability of an -rc2 with this fix?
>

Re: [Openvpn-devel] Easy-RSA v3 release planning

[Jonathan K. Bullard]

On Tue, Dec 17, 2013 at 9:05 PM, Josh Cepek  wrote:

> The notable fix since -rc1 has been support for OpenSSL-0.9.8 (commit
> 8b1fe01.) While I hope this isn't a common need, the fix was simple
> enough, and this is still a supported OpenSSL version.
>

Any update on the availability of an -rc2 with this fix?

[Openvpn-devel] Recently-disclosed LZO vulnerability and OpenVPN's use of LZO

[Jonathan K. Bullard]

A recent *"Lab Mouse Security research blog" entry*

claimed
that a bug exists in several implementations of the LZO algorithm commonly
used by OpenVPN and that the bug causes a security vulnerability.

A rebuttal on the "RealTime Data Compression" blog
 points
out that the circumstances required to exploit the vulnerability make
exploitation unlikely. Among other requirements, the rebuttal says that a
problem only happens with block sizes larger than 8MB.

Am I correct to assume that OpenVPN's use of LZO is restricted to much
smaller block sizes? I assume the block sizes that OpenVPN uses LZO for are
limited to the maximum packet size, which would be on the order of 1500
bytes or so (because of MTU size limits).

Or does OpenVPN ever use LZO on larger amounts of data? Is there any
possibility of OpenVPN using LZO on 8MB?

* Also see the discussion on the LZ4 discussion board
; the vulnerability was
actually discovered by Ludvig Strigeus
 eighteen months ago.

Re: [Openvpn-devel] [Openvpn-users] [PATCH] Add support for specifying the syslog facility, as requested in trac #188.

[Jonathan K. Bullard]

On Fri, May 2, 2014 at 11:20 AM, David Sommerseth <
openvpn.l...@topphemmelig.net> wrote:

> The core principle in OpenVPN's option
>  parsing is that the last argument wins.  So if you have f.ex. --ping-exit
> 3
> times in a command line and two times in a config file, it's the last one
> which really sets the option.  --syslog-facility should be no different.
>
> IMO, distro init.d scripts should add the config file as the last argument
> when they kick off openvpn.  If they add stuff which overrides the config
> file, then it's a bug in the init.d script.
>

That might be good for distros, but Tunnelblick purposefully starts OpenVPN
with "--management" *after* "--config"; other GUIs may do this, too.
Tunnelblick does this to make sure that the management interface is used
only by Tunnelblick. (Tunnelblick separately warns the user if the
configuration file contains "--management" or other problematic options.)

For some options, it is the *first* argument that wins: "--log",
"--log-append", and I think "--daemon" (and possibly some other options
like "--syslog"). Tunnelblick puts --log and --daemon first to make sure it
controls logging. (Tunnelblick sends the log to a file, which it monitors,
instead of logging through the management interface, so Tunnelblick (the
GUI) does not need to be running when the OpenVPN instance is running --
for example, when nobody is logged in.)

Re: [Openvpn-devel] English language? Re: [PATCH] Support non-ASCII characters in Windows tmp path

[Jonathan K. Bullard]

On Wed, Dec 4, 2013 at 4:35 AM, Matthias Andree wrote:

> Am 19.11.2013 18:36, schrieb Heiko Hund:
> > +  msg (M_WARN, "Could not get temporary directory. Path is too
> long."
> > +  "  Consider to use --tmp-dir");
>
> I think when touching the code, we ought to change all occurrences to
> "Consider using --tmp-dir".
>
> Native speakers or linguists correct me, but since most usage references
> I found were "consider + object" (object often a noun), the -ing form
> would have to be used here.
>

As a native English speaker, I agree; "Consider using --tmp-dir" is correct.

(As an American, I have almost no formal knowledge of grammar or diction,
so I can't cite why :-)

Re: [Openvpn-devel] [Patch v7] Add support of utun devices under Mac OS X

[Jonathan K. Bullard]

On Fri, Jun 21, 2013 at 6:48 AM, Arne Schwabe  wrote:
> Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" 
> utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do 
> not work together).
>
> When OpenVPN is compiled with utun support it will if no dev-node is given 
> first try to use utun and if that is not available will try the traditional 
> tun devices
>
> v2: Fixed tap support, get device name via ioctl, add manage
> v3.1: Fix compiling without if/utun.h, fix manage errors
> v4/v5: Don't try open to dynamically open utun0 -255 when early utun 
> initialization fails, fix fallback to tun, give fatal error message when utun 
> fails but no tun fallback should be done
> v6: add commit message change log, replace strstr with strncmp, move 
> #includes to the top of the file
> v7: Throw error if a user does the strange combination of --dev tun 
> --dev-type tap and --dev-node utun

v7 works on 10.4 through 10.9, tested several different situations on
each. I didn't test it on an actual tap connection, but all the
tun/utun connections I tried worked, and the fallback to tun on 10.4
and 10.5 worked, and the misconfiguration of "--dev tun --dev-type tap
--dev-node utun" was caught.

This looks good to me, for either 2.3.x (because it will fix problems
people have with tuntaposx) or 2.4 (because it is a new feature).

Thanks, Arne.

Re: [Openvpn-devel] [Patch v3.1] Add support of utun devices under Mac OS X

[Jonathan K. Bullard]

On Thu, Jun 20, 2013 at 4:58 AM, Arne Schwabe  wrote:
> I have a OS X 10.6 VM with Xcode 3.2.6 installed and this VM has the
> if/utun.h header. I probably was added somewhere between 10.6.0 and 10.6.8.

Ah. Thanks for mentioning this. That makes sense.


> I changed the M_ERR to M_WARN. It should now work on 10.5.x but without
> a 10.5 to test on it is difficult to say...

OK, thanks; now I better understand how the error handling works.


On Thu, Jun 20, 2013 at 5:05 AM, Arne Schwabe  wrote:
> Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" 
> utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do 
> not work together).
>
> When OpenVPN is compiled with utun support it will if no dev-node is given 
> first try to use utun and if that is not available will try the traditional 
> tun devices
>
> Parts of the patches are inspired from Peter Sagerson's 
>  utun patch
> Signed-off-by: Arne Schwabe 


First, I should mention that the most recent version of this patch (in
your Thu, Jun 20, 2013 at 5:05 AM email) seems to make some other,
major changes, too, at least when compared to the earlier version (in
your  email of Tue, Jun 18, 2013 at 1:23 AM). I have ignored those
changes (I don't really understand them), and I have just made the
changes that I mentioned, plus one typo that you caught that I missed,
and the M_ERR to M_WARN changes.

Unfortunately, this patch still fails if the utun code is included and
executed on 10.5.

A minor problem is that for each of the 255 attempts to get a utun
device (device #0 through device #254), it generates the following
warning message:
 Opening utun (ioctl(CTLIOCGINFO)): No such file or directory
It's ugly, but cosmetic. Perhaps it could be displayed only at verb=4
and higher? (I don't know how to do that.)

The larger problem is that it still fails to connect, with the error message:
 Error retrieving utun interface name: Bad file descriptor (errno=9)

I think this is because open_darwin_utun ignores the error (fd == -1)
returned from utun_open_helper.

If so, it can be fixed by changing open_darwin_utun as follows:

 else
 {
 fd = utun_open_helper (ctlInfo, utunnum);
 }

+if (fd==-1)
+   tt->is_utun = false;
+   return;
+
 /* Retrieve the assigned interface name. */
 if (getsockopt (fd, SYSPROTO_CONTROL, UTUN_OPT_IFNAME, utunname,
_len))
 msg (M_ERR | M_ERRNO, "Error retrieving utun interface name");

 tt->actual_name = string_alloc (utunname, NULL);

(I added the " tt->is_utun = false;" just to be sure; I'm not clear on
the initialization of tt->is_utun, and it is used in the test that
follows the call to open_darwin_utun to test for success/failure.)

After making that change, it works on OS X 10.5.8 and 10.4.11.

Re: [Openvpn-devel] [Patch v2] Add support of utun devices under Mac OS X

[Jonathan K. Bullard]

On Tue, Jun 18, 2013 at 1:23 AM, Arne Schwabe  wrote:
>
> Mac OS X 10.7+ natively supports tun devices (called utun). The "standard" 
> utun.ko driver is sometimes problematic (e.g. VmWare Fusion 5 and tun.ko do 
> not work together).
>
> When OpenVPN is compiled with utun support it will if no dev-node is given 
> first try to use utun and if that is not available will try the traditional 
> tun devices
>
> Parts of the patches are inspired from Peter Sagerson's 
>  utun patch
> Signed-off-by: Arne Schwabe 

I am anxious to see utun incorporated into OpenVPN and like the
functionality this patch provides. I have several comments, all based
on the updated patch in Arne's 2013-06-18 email.

(Because I am using an old version of OpenVPN, the line numbers in my
files don't correspond to those Arne's patch was based on, so the
code/patches I show below are pseudo-diffs from the code as patched by
Arne's patch, not diffs from any existing code or diffs from his
patch.)

First, I propose three minor wording changes:

Two changes in doc/openvpn.8:

-to select a speficic utun instance. To force using the tun.kext (/dev/tunX) use
+to select a specific utun instance. To force using the tun.kext (/dev/tunX) use

and

-option openvpn will try to first open utun first fallback to tun.kext.
+option openvpn will first try to open utun, and fall back to tun.kext.

One change in src/openvpn/tun.c

-  msg (M_INFO, "Openend utun device %s", utunname);
+  msg (M_INFO, "Opened utun device %s", utunname);



Second, I created an experimental build of Tunnelblick that
incorporates this patch into OpenVPN 2.3.2. Because Tunnelblick is
built in OS X 10.6.8 with Xcode 3.2.2 with the 10.6 SDK (to support
PPC and OS X 10.4 - 10.9), it doesn't have /net/if_utun.h, so it
doesn't set HAVE_NET_IF_UTUN_H. That combination (TARGET_DARWIN is
set, but not HAVE_NET_IF_UTUN_H) generates errors that require some
changes:

The "}" at the end of open_tun() needs to be conditionalized (Here is
the entire routine to clarify why):

 open_tun (const char *dev, const char *dev_type, const char
*dev_node, struct tuntap *tt)
 {
 #ifdef HAVE_NET_IF_UTUN_H
 /* If dev_node does not start start with utun assume regular tun/tap */
 if ((!dev_node && strcmp (dev, "tun")==0) ||
 (dev_node && (strstr (dev_node, "utun") == dev_node)))
 {
 /* Try utun first and fall back to normal tun if utun fails
  * and dev_node is not specified */
 open_darwin_utun(dev, dev_type, dev_node, tt);

 /* No explicit utun and utun failed, try the generic way) */
 if (!dev_node && !tt->is_utun)
 {
 msg (M_INFO, "Failed to open utun device. Falling back to
/dev/tun device");
 open_tun_generic (dev, dev_type, NULL, true, true, tt);
 }
 }
 else
 {
 #endif
 /* Use plain dev-node tun to select /dev/tun style
  * Unset dev_node variable prior to passing to open_tun_generic to
  * let open_tun_generic pick the first available tun device */

 if (dev_node && strcmp (dev_node, "tun")==0)
 dev_node=NULL;

 open_tun_generic (dev, dev_type, dev_node, true, true, tt);
+#ifdef HAVE_NET_IF_UTUN_H
}
+#endif
}

(Or, if you want, you can move the existing #endif up one line instead.)


The changes to write_tun and read_tun need to be conditioned on
HAVE_NET_IF_UTUN_H being defined:

 int
 write_tun (struct tuntap* tt, uint8_t *buf, int len)
 {
+#ifdef HAVE_NET_IF_UTUN_H
   if (tt->is_utun)
 return write_tun_header (tt, buf, len);
   else
+#endif
 return write (tt->fd, buf, len);
 }

 int
 read_tun (struct tuntap* tt, uint8_t *buf, int len)
 {
+#ifdef HAVE_NET_IF_UTUN_H
  if (tt->is_utun)
 return read_tun_header (tt, buf, len);
   else
+#endif
return read (tt->fd, buf, len);
 }

The resulting binary works on 10.5.8, 10.6.8, and 10.7.5. (Of course,
it uses tun, not utun.)



I removed all the the references to HAVE_NET_IF_UTUN_H (so the utun
code is compiled even though it is not it is available in the SDK
being used) and changed:

-#include 
+#define UTUN_CONTROL_NAME "com.apple.net.utun_control"
+#define UTUN_OPT_IFNAME   2

> Note: This change should not be put in an OpenVPN patch; it is solely to 
> allow me to compile it with the 10.6 SDK.

(The values for the UTUN_* variables are taken from 10.7), and it
built without problems.



The resulting binary works fine and uses utun on 10.6.8 and 10.7.5.

(Interesting that utun isn't in the 10.6 SDK but utun works on 10.6.8.
Since it isn't in the SDK, I assume it may be flakey and/or only in
some OS X > 10.6.0. If it is flakey in 10.6.8, that's a problem
because it will be used by default, but if it is just that it isn't in
all of 10.6.*, that should be OK.)

On 10.5.8, however, attempting to connect to a server 

Re: [Openvpn-devel] building on OSX (for Tunnelblick)

[Jonathan K. Bullard]

On Tue, Apr 2, 2013 at 9:46 AM, Arne Schwabe  wrote:

> > Tunnelblick is still being built on OS X 10.6.8 with Xcode 3.2.2
> > because it still supports PowerPC, which later versions of Xcode
> > (which are required for use on 10.7+) don't support.
> Is there a specific reason for Xcode 3.2.2? I set up a 10.6.8 snow
> leopard with 3.2.2 and did not have net/if_utun.h. However Xcode 3.2.6
> includes net/if_utun.h and utun works on the test machine (and also
> include the powerpc-* gcc binaries)
>

Xcode 3.2.6 does not generate PPC code for the *Tunnelblick* part (written
in Objective-C).

At least, it doesn't have a way to select an architecture of "Universal
32-bit" (meaning 32-bit PPC & i386), only "32-bit Intel", "64-bit Intel",
or "Standard (32/64-bit Intel)".

There is an "Other" setting, but I haven't been able to set that to
anything that makes "Universal 32-bit" (meaning 32-bit PPC & i386).

In the past I've been willing to forego 64-bit to get 32-bit PPC/Intel, but
of course 32/64 PPC/Intel would be great.