Re: [Openvpn-users] * UPDATE * OpenVPN v2.4.3 and v2.3.17 releases

[Jason Haar]

Does using tls-auth protect against these latest security issues? ie if you
are running older versions but require tls-auth, then would that block
attacks from hackers who don't have your tls-auth file?

Thanks

On Fri, Jun 23, 2017 at 1:29 AM, David Sommerseth <
open...@sf.lists.topphemmelig.net> wrote:

>
> Hi,
>
> We are in an unfortunate situation that our Cloudflare front is
> providing various results, depending on a lot of factors (region,
> browser, computer, etc, etc).  And it causes a massive noise on people
> trying to download and verify that these downloads are correct.
>
> As most of this noise have been related to the source code downloads, I
> have setup an emergency wiki page where an alternative download URL is
> provided ... In addition the proper SHA256 checksums and proper
> signature files are available too.
>
> This will hopefully help people to get the right download.
>
> 
>
>
> We will go more carefully through our release process and figure out how
> to avoid this mess with the next release.  The discussion have already
> been initiated [1], and we will dig into this for the next release.
>
> [1]
>  sourceforge.net/msg14937.html>
>
>
> On behalf of the OpenVPN core community team, I am truly sorry for this
> mess.  This is not how we want our releases to appear.
>
>
> --
> 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-users mailing list
> Openvpn-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>
>


-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Motion to elect Samuli to be the official maintainer of OpenVPN at Debian

[Bernhard Schmidt]

On 20.06.2017 18:08, Samuli Seppänen wrote:

Hi,

I haven't seen the original mail, no idea why

> Thanks for nominating me :).
> 
> On 20/06/2017 18:40, Javier Santos wrote:
>> June 20, 2017
>> 
>> Hi guys,
>> 
>> Our friend, Samuli, has been creating .deb files of the latest
>> version of OpenVPN (Community Edition) for quite some time.
>> 
>> I proposed that Samuli be the official maintainer of said software
>> for Debian. Debian users benefit because:
>> 
>> 1. updates are available on the same day that the Windows version
>> is posted for download. There is a significant time gap between the
>> version created by Samuli and the one that is available on Debian's
>> backport-repository. As an example look at the time when Samuli
>> made the latest version of OpenVPN available and compare it with
>> the time that the backported version of Debian Jessie is made
>> available by its official maintainer.
> 
> Our OpenVPN packages don't have to conform to Debian's packaging 
> policies. That is part of the reason why we can publish new Debian 
> packages at OpenVPN release time. Having Debian "in the middle" would
> in all likelihood make OpenVPN releases more time-consuming and
> tricky to organize.

To explain this a bit more, it is quite impossible to release new
OpenVPN upstream versions within Debian stable. Debian policy is that as
soon as the development of a Debian release is frozen no new upstream
releases are introduced. Only security fixes and important crash fixes
are allowed to be (selectively) backported while retaining the version
number. So that's why Debian Stretch has 2.4.0 plus security patches up
to 2.4.2 (2.4.3 is probably pending the security team right now).

Note that Debian unstable does not suffer from this, except during
freeze. 2.4.3 has been uploaded today, see
https://tracker.debian.org/news/850579

Also note that the maintainer is looking for someone to take over
maintainership, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=86 .


>> 2. there is no need to fetch updates from a separate repository
>> outside of Debian ones. Users can just install backported version
>> from Debian backport-repository.
> 
> The Debian backports repository brings with it lots of "other stuff" 
> besides OpenVPN. People would need to set the "Pin-Priority"
> correctly to avoid accidentally upgrading more than what they want.#

Not quite, the backports repo is marked "NotAutomatic", so it should not
pull in new versions unconditionally.

Bernhard

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

[Openvpn-users] Packet flow, take 2

[Pippin1st via Openvpn-users]

Hi,

Attached DIA file.

Thanks Pippin

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

[Openvpn-users] Packet flow, take 2

[Pippin1st via Openvpn-users]

Hello,

This is a follow-up on my previous subject, "Packet flow and ICMP/MTU question"

Now I wanted to put more detail and found following document that was stored
on my NAS but never thought about it untill i came accross it again:
http://www.delaat.net/rp/2010-2011/p09/report.pdf
Comparing TCP performance of tunneled and non-tunneled traffic using OpenVPN
Authors: Berry Hoekstra bhoekstra@...
Damir Musulin dmusulin@...
Supervisor: Jan Just Keijser Nikhef
August 24, 2011 Version 1.1 | Revision 191"

Looking at the picture on page 7, example endpoint 1:
Encrypt->Fragment
That looks not in line with the "final" diagram 5 attached at the end in
"Packet flow and ICMP/MTU question".
PNG file: 
https://sourceforge.net/p/openvpn/mailman/attachment/iEV-I4txJAonM1va1nJkfrKurjTr4OtRU_nCiqIHMviaVsaBq_4eruUrubrkUlWLWZEXTS7pxuWSwEk2hK9P1fB1DAdfqhrCzrCQSUCZYnA%3D%40protonmail.com/1/
DIA file: 
https://sourceforge.net/p/openvpn/mailman/attachment/w4VA6JqQC8WRBGEj0ACm0HEMnlGuDyzbbo0eaJOFNtteEabY3JDl9XZkUcPeJT0y-RNoJi52bYFuUdy8-wzVOrFPH73PMTIDhcYXROz6ijE%3D%40protonmail.com/1/

Picture on page 7, (Compress?)-Encrypt-Fragment ???

Diagram 5, Compress-Fragment-Encrypt ???

Attached new PNG 6.
Will send DIA file in next message.

Comments are welcome, thanks

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

[Openvpn-users] * UPDATE * OpenVPN v2.4.3 and v2.3.17 releases

[David Sommerseth]

Hi,

We are in an unfortunate situation that our Cloudflare front is
providing various results, depending on a lot of factors (region,
browser, computer, etc, etc).  And it causes a massive noise on people
trying to download and verify that these downloads are correct.

As most of this noise have been related to the source code downloads, I
have setup an emergency wiki page where an alternative download URL is
provided ... In addition the proper SHA256 checksums and proper
signature files are available too.

This will hopefully help people to get the right download.




We will go more carefully through our release process and figure out how
to avoid this mess with the next release.  The discussion have already
been initiated [1], and we will dig into this for the next release.

[1]



On behalf of the OpenVPN core community team, I am truly sorry for this
mess.  This is not how we want our releases to appear.


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc




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

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

[Samuli Seppänen]

Hi,

> So just trying to hijack this discussion which is to be found a few more
> places elsewhere in this mail thread.  No need to let this discussion
> run longer.
> 
> There are several area where we definitely can improve the release
> process.  Last round where we managed to mess up the 2.3.15 release, so
> I wrote a brand new "prepare release tarballs" script, which also
> handles the signing.  This script _was_ used to produce the files to be
> pushed out for the 2.4.3/2.3.17 releases.
> 
> But for reasons unknown to me, those tarballs got re-created somewhere
> later in the release chain.  The contents of all tarballs are

The tarballs were created by my release script which is available on our
internal Bitbucket. I always try to be very careful in what I upload,
but some mistakes seem unavoidable due to the really complex nature of
the release process.

My release script predates the script you wrote for OpenVPN 2.4.2
release. My script operates on the assumption that a fully up-to-date
Git repository with release tags and everything is available. This has
generally been the case, as we've usually updated Git first and _then_
started the release machinery.

For me it would be easiest if I could handle the entire release process
starting from an fully up-to-date Git repository. That would allow my
script(s) to automatically handle most technical parts of the release:

- Produce the tarballs
- Sign them with the secur...@openvpn.net key
- Verify the signatures
- Generate changelogs for Trac and Debian packages
- Generate a man-page suitable for copy-and-pasting in Trac
- Generate a CloudFlare flush file
  - Copy-and-paste to CloudFlare to flush caches for all the files;
this is a routine release procedure nowadays
- Push everything to the download servers
- Download everything from the download servers _and_ verify the signatures

All of this is already handled and works well enough. I _can_ use
tarballs as the source, but I also need a Git repo to get Git logs, so
the tarballs are a bit redundant.

> essentially the same, but due to the "nice" artefact that the tar format
> is non-deterministic on the output, even though the input is the same,
> that begins to prepare the stage for this chaos.  Especially when what
> is being uploaded is partly from the initial run and then some files
> from a different run.
> 
> All that is history now.  Now we need to look forward.  Many good points
> have been raised.
> 
> - Do we need .tar.gz and .zip files?  Where and why?
>   The fewer source tarballs we need to handle, the less chance for
>   errors

I would love if we could drop everything except tar.xz. This way the
amount of files and signatures on the download page would drop
significantly. I think it would be reasonable to expect that people who
need OpenVPN _sources_ on Windows are able to extract tar.xz, especially
if we document how it can be done.

> 
> - Improve Makefile.am to not generate dist-gz files when running
>   distcheck.  The distcheck run often provides very good indicator if we
>   have packaged all the needed files in the source tarball.  If this
>   doesn't pass, something is really wrong.
> 
> - Do we really need to re-create the source tarballs which the new
>   ./dev-tools/gen-release-tarballs.sh?  Why?

No. But another question is whether we need gen-release-tarballs.sh
which implements a limited subset of the release script I had written
earlier? The gen-release-tarballs.sh came as a surprise to me -
otherwise I would told you that what it does is already covered.

Before answering the question, though, we should figure out our overall
release strategy.

> 
> - What can be done with Cloudflare to fully ensure their caches are
>   truly purged when we ask for it?  As Jonathan noticed, their caches
>   are tightly connected to the web browser and have a non-deterministic
>   behaviour across browsers, even on the same computer.
> 

As mentioned above, I've routinely purge CloudFlare caches for all
release files on every release for a long time. Initially this was
because CloudFlare cached 404's for some people. Occasionally issues
arose when a wrong version of a file ended up on the download server.

Regardless of all these precautions we still get some CloudFlare-related
complaints on every release.

> - What else in the release process can be automated and put into a
>   script?  This to ensure consistency between all releases we do.

The following things rob a surprising amount of time from me during a
release:

1. Producing release announcement in three different formats:
   - Download page
   - Forums
   - Mailing list
2. Playing with various Git repos
   - easy-rsa-old, openvpn-build, openvpn-gui, openvpnserv2
   - For each of them in one or more branches
 - Pushing to my fork
 - Pushing version changes and tags to upstream repo
   - Must ensure that what is pushed is the bare minimum
3. Building and testing Debian packages
4) Building and testing Windows inst