Re: [Openvpn-devel] [PATCH] ssh_util: fix prototype style

[Simon Matter]

Hi,

Typo, subject should probably be s/ssh_util/ssl_util

Regards,
Simon

> Function prototypes should have the return type on the same line as the
> function name itself. Fix this in ssl_util.h.
>
> Signed-off-by: Antonio Quartulli 
> ---
>  src/openvpn/ssl_util.h | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/src/openvpn/ssl_util.h b/src/openvpn/ssl_util.h
> index f38294c1..3695ca3c 100644
> --- a/src/openvpn/ssl_util.h
> +++ b/src/openvpn/ssl_util.h
> @@ -41,10 +41,8 @@
>   * @return  The content of the variable as NULL terminated string or NULL
> if the
>   *  variable cannot be found.
>   */
> -char *
> -extract_var_peer_info(const char *peer_info,
> -  const char *var,
> -  struct gc_arena *gc);
> +char *extract_var_peer_info(const char *peer_info, const char *var,
> +struct gc_arena *gc);
>
>  /**
>   * Extracts the IV_PROTO variable and returns its value or 0
> @@ -52,8 +50,7 @@ extract_var_peer_info(const char *peer_info,
>   *
>   * @param peer_info peer info string to search for IV_PROTO
>   */
> -unsigned int
> -extract_iv_proto(const char *peer_info);
> +unsigned int extract_iv_proto(const char *peer_info);
>
>  /**
>   * Takes a locally produced OCC string for TLS server mode and modifies
> as
> @@ -67,6 +64,6 @@ extract_iv_proto(const char *peer_info);
>   * @param gcgc_arena to allocate the returned string in
>   * @return  the modified string or options on error
>   */
> -const char *
> -options_string_compat_lzo(const char *options, struct gc_arena *gc);
> +const char *options_string_compat_lzo(const char *options, struct
> gc_arena *gc);
> +
>  #endif
> --
> 2.30.2
>
>
>
> ___
> 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] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi,
>
> On Mon, Apr 05, 2021 at 10:16:07AM +0200, Simon Matter wrote:
>> Then I misunderstood what is written here?
>>
>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--compress
>>
>> "Compression is not recommended and is a feature users should avoid
>> using.
>> To signal this clearly, --comp-lzo and --compress are discouraged and
>> considered deprecated features. Beginning with 2.5, these options will
>> no
>> longer enable compression, just enable the compression framing to be
>> able
>> to receive compressed packets."
>>
>> That made me feel compression support in 2.5 is only on a compatibility
>> level.
>
> This is half-correct, and half-incomplete.  Look at
>
>   --allow-compression yes
>
> (new in 2.5).
>
> Yes, 2.5 will no longer send compressed packets unless explicitly
> permitted
> by "allow-compression yes" - but the infrastructure is still there, and
> still tested, but moved from "this is something everybody will want" to
> "if you know what you are doing and why, you can still have it".
>
> Regarding your other mail where you doubted that "there will be a
> discussion"
> - well, I can assure you that there are discussions about every feature we
> take out of OpenVPN (and usually, mails to openvpn-devel and openvpn-users
> to figure out who might still be using it).  Many of these discussions do
> not happen on the list but on the #openvpn-devel and #openvpn-meeting
> IRC channels - but Samuli is sending the meeting minutes to the -devel
> list (and they are on the trac web page), so we try to make transparent
> what we discuss and why.
>
>
> As always, code is a balance between features, maintenance effort, bugs,
> and security...
>
> gert

Ok, thanks for explaining.

Regards,
Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi Simon
>
> On 05/04/2021 09:38, Simon Matter wrote:
>>> Hi,
>>>
>>> On Sat, Apr 03, 2021 at 03:07:11PM +0200, Simon Matter wrote:
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
>>>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472
>>>
>>> This is indeed fairly significant - and if WAN circuits are full and/or
>>> cost money per Gbyte, compression is still a win.
>>>
>>> I'm more of a compression fan than not :-) - so this will be
>>> interesting
>>> discussions indeed.
>>
>> Hi Gert,
>>
>> Based on the answers I got on this list I'm afraid there won't be any
>> discussion and compression is gone. That's really sad as it is a useful
>> feature for many use cases as I was easily able to show.
>>
>
>
> at the moment there is neither a patch nor a point on any meeting agenda
> about removing compression from the OpenVPN codebase.
>
> Please don't hastily draw such conclusions.
>
> So far it was *you* opening this discussion about compression removal as
> OT of the patch in the subject. We only expressed our personal opinions
> about your statements.

Then I misunderstood what is written here?

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--compress

"Compression is not recommended and is a feature users should avoid using.
To signal this clearly, --comp-lzo and --compress are discouraged and
considered deprecated features. Beginning with 2.5, these options will no
longer enable compression, just enable the compression framing to be able
to receive compressed packets."

That made me feel compression support in 2.5 is only on a compatibility
level.

Regards,
Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi,
>
> On Sat, Apr 03, 2021 at 03:07:11PM +0200, Simon Matter wrote:
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
>> Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472
>
> This is indeed fairly significant - and if WAN circuits are full and/or
> cost money per Gbyte, compression is still a win.
>
> I'm more of a compression fan than not :-) - so this will be interesting
> discussions indeed.

Hi Gert,

Based on the answers I got on this list I'm afraid there won't be any
discussion and compression is gone. That's really sad as it is a useful
feature for many use cases as I was easily able to show.

Regards,
Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi,
>
> On 03/04/2021 12:06, Simon Matter wrote:
>> Our use case is simple, we don't want ANY application in our company to
>> consume more WAN bandwidth than is absolutely needed. Of course we're
>> using compression like in rsync where it's possible, but that's not
>> possible everywhere and with every application. So we also try to catch
>> those cases by using compression over the VPN links. In case there is no
>> compressible data, it doesn't hurt much, but it can help a lot with
>> compressible data.
>
> Out of curiosity, would you be able to provide statistics of how much
> you are saving and with which application protocol?

No, I can not show applications but I can tell you it's from a huge number
of different devices. There are thin clients but also a zoo of document
printers, different label printer types, barcode scanning devices, payment
terminals, DECT VoIP phones, alarm systems, lots of embedded systems,
document scanners, video cameras and the list goes on. It's quite
difficult to analyze every protocol and see how or if it can be compressed
which is why it's nice to know things get at least compressed when running
over the WAN links.

Example status shows this:

Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-compress bytes,833300152
Apr  3 15:00:30 gw-X1 openvpn[1477]: post-compress bytes,796650159
Apr  3 15:00:30 gw-X1 openvpn[1477]: pre-decompress bytes,343572096
Apr  3 15:00:30 gw-X1 openvpn[1477]: post-decompress bytes,510118472

Apr  3 15:00:09 gw-X2 openvpn[1502]: pre-compress bytes,3152837867
Apr  3 15:00:09 gw-X2 openvpn[1502]: post-compress bytes,3142711232
Apr  3 15:00:09 gw-X2 openvpn[1502]: pre-decompress bytes,3045691308
Apr  3 15:00:09 gw-X2 openvpn[1502]: post-decompress bytes,4980566715

It shows at least that it does something. It's clear that the gain is not
so big but, this status doesn't show the negative effect that one stupid
protocol can have on the connection. If there is one device doing lots of
compressible traffic during half an hour per day, this can greatly disturb
connectivity during the half an hour. That's half an hour too much.

Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi,
>
> On Sat, Apr 03, 2021 at 11:52:59AM +0200, Simon Matter wrote:
>> > It sounds like there is no answer to this?
>> > Then why are we even discussing further?
>>
>> It could be at least one feature to prevent people from moving over to
>> WireGuard?
>
> Unless people can come up with real use cases why compression makes
> sense for them, and just move over to wireguard "BECAUSE IT HAS NO
> COMPRESSION EITHER, BUT YOU TOOK IT AWAY FROM ME!! STAMP FOOT!" this
> is hardly a compelling argument.

Our use case is simple, we don't want ANY application in our company to
consume more WAN bandwidth than is absolutely needed. Of course we're
using compression like in rsync where it's possible, but that's not
possible everywhere and with every application. So we also try to catch
those cases by using compression over the VPN links. In case there is no
compressible data, it doesn't hurt much, but it can help a lot with
compressible data.

That's the only reason why OpenVPN was better for us.

Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi,
>
> On 03/04/2021 11:18, Simon Matter wrote:
>>> If you have a use case that you think can benefit big time by having
>>> compression, please feel free to describe it in details. Therefore
>>> might
>>> be saner ways to address it.
>>>
>
> It sounds like there is no answer to this?
> Then why are we even discussing further?

It could be at least one feature to prevent people from moving over to
WireGuard?

Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi,
>
> On 03/04/2021 10:32, Simon Matter wrote:
>> I'm not asking to enable it by default or even compile it by default.
>> I'm
>> only asking to keep the code in so those who know what they are doing
>> can
>> enable it as a compile time option or expert mode option or something
>> like
>> that.
>
> If you ask everybody, they always knew what they were doing, even when
> something went wrong.
>
> If there is no real usecase for a feature, and this feature is known to
> be a potential risk, it is our duty to make sure people will not shoot
> themselves in the foot.
>
> If you have a use case that you think can benefit big time by having
> compression, please feel free to describe it in details. Therefore might
> be saner ways to address it.
>
>
> If somebody feels being expert enough and knows what he is doing more
> than the others, he can still re-add the feature (i.e. by reverting any
> patch that might be removing the code) and recompile OpenVPN. The beauty
> of Open Source :-)

I knew such answers will come :-)

But, back to security, why do you still allow OpenVPN being built on M$
Windows then? That's the real place where people are comforted with snake
oil and may be tempted to feel safe when using an OpenVPN tunnel but in
reality are vulnerable. Isn't this much worse than leaving compression in
as a compile time option?

Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

>
>>
>> To me it seems like you can of course build a scenario where compression
>> _could_ be a problem some how, but there are certainly many use cases
>> where it can be considered almost impossible to have your security
>> weakaned by compression. I mean, there is also the SSH VPN mode with c> be used with compression and I've never heard someone saying it's less
>> secure with compression.
>
> That will be also affected by VORACLE style attacks. But SSH VPN and SSH
> is also by no mean safe against these kind of attacks. They might be
> harder to pull off but the underlying attacks still apply.
>
>> In our case where we connect several subnets via OpenVPN and there goes
>> a
>> lot of different traffic from dozens of hosts in every location, I still
>> fail to understand how our security would be impacted by compression?
>
> The attacks are not that easy to understand. So not to patronise you but
> if you if you don't understand it, then it might be better to err on the
> safe side?
>
>> In the end my only question is is it worth to remove compression from
>> OpenVPN in the long run, or is this not planned?
>>
>
> Attacks are becoming better and better if there is a vector to attack.
> But Beast/Crime/VORACLE have shown that these attacks are possible, so
> enabling compression by default is no longer safe.

I'm not asking to enable it by default or even compile it by default. I'm
only asking to keep the code in so those who know what they are doing can
enable it as a compile time option or expert mode option or something like
that.

Simon



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

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Hi,
>
> On Fri, Apr 02, 2021 at 08:35:36PM +0200, Simon Matter wrote:
>> What I'm still wondering is why is compression so dangerous with OpenVPN
>> but not so with things like SSH or SCP?
>
> The problem is adversary-controlled traffic in a VPN tunnel, like
> "you surf on a web site, and there is java script that makes your
> browser send carefully crafted requests while someone looks at your
> VPN tunnel from the outside".
>
> If compression is active, an attacker can see if "the parts of the
> header that he can not see" are similar to "the parts that the java
> script creates", due to compression making the resulting packets
> smaller if sequences are identical.
>
> Supposedly you can use this to steal stuff like session cookies,
> which java script would normally not be able to see.
>
>
> Now, I personally find this all a bit unrealistic in practice - it's
> quite a number of "ifs", and even then, it's unclear if possible in
> practice, or even interesting enough, given the myriard of easier to
> exploit attack vectors.
>
> But it *is* a possible attack, and if weighting "is this a good feature?"
> against maintenance effort and possible security effects, compression
> starts drifting towards the negative side (because most traffic inside
> VPNs is already compressed or encrypted anyway today, so compression won't
> have a big effect).
>
>
> Now, in ssh, you copy files of your own choice.  Compression is useful
> there, if the files are not already compressed.  An attacker won't be
> able to manipulate just *part* of one file, to see if the neighbouring
> 100 bytes are "similar"... so this class of attacks does not exist.
>

To me it seems like you can of course build a scenario where compression
_could_ be a problem some how, but there are certainly many use cases
where it can be considered almost impossible to have your security
weakaned by compression. I mean, there is also the SSH VPN mode with chttps://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix 'compress migrate' for 2.2 clients.

[Simon Matter]

> Commit 8fa8a17528c001a introduces "compress migrate" to move old clients
> that have "compress" or "comp-lzo" in their config towards a connection
> without compression.  This is done by looking at incoming OCC strings
> to see if the client has compression enabled, and at incoming IV_
> strings to see whether it can do "compress stub-v2" or needs to be sent
> "comp-lzo no".

Hi,

What I'm still wondering is why is compression so dangerous with OpenVPN
but not so with things like SSH or SCP?

Say I connect from my client to my server via SSH with compression is
fine. Doing the same trough an OpenVPN tunnel with compression using an
unencrypting tool like telnet is considered dangerous. I fail to
understand how the SSH tunnel can be considered okay and the OpenVPN
tunnel is not?

I've read a lot of the CRIME and BREACH stuff but still don't really
understand.

Thanks,
Simon

>
> That check fails for 2.2 clients that do not send *any* peer-info by
> default, so the server will not push back any "disable compression"
> command.  It works if the client connects with "--push-peer-info".
>
> Fix: turn around the order of checks, treat "no peer_info" the same
> as "peer_info does not contain IV_COMP_STUBv2".
>
> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/multi.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 5c495036..56b4fc0d 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -2485,14 +2485,9 @@ multi_client_connect_compress_migrate(struct
> multi_context *m,
>  struct options *o = >context.options;
>  const char *const peer_info = mi->context.c2.tls_multi->peer_info;
>
> -if (!peer_info)
> -{
> -return CC_RET_SUCCEEDED;
> -}
> -
>  if (o->comp.flags & COMP_F_MIGRATE &&
> mi->context.c2.tls_multi->remote_usescomp)
>  {
> -if(strstr(peer_info, "IV_COMP_STUBv2=1"))
> +if(peer_info && strstr(peer_info, "IV_COMP_STUBv2=1"))
>  {
>  push_option(o, "compress stub-v2", M_USAGE);
>  }
> --
> 2.26.3
>
>
>
> ___
> 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 0/1] reliable: retransmit if 3 follow-up ACKs are received

[Simon Matter]

> Hi,
>
> On Thu, Apr 01, 2021 at 08:20:48AM +0200, Simon Matter wrote:
>> > Yes. But it only affects the control channel. For data channel we
>> never
>> > do retransmits.
>>
>> OK, but it still could help in case of things like VoIP UDP over OpenVPN
>> UDP with lots of small packets going over the link with low package
>> loss?
>
> No, because VoIP-over-OpenVPN would be "data channel".
>
> It would help with "control channel handshake takes very long due to
> packet
> loss".
>
> There's a different patchset floating around (I think it's a PR, actually)
> that promises to add data-channel redundancy and being able to recover
> some
> amount of packet loss without retransmit.  Which I find very interesting,
> but this has not been followed up due to "it's complex and nobody has
> time"
> reasons.
>
> gert

Thanks for the explanation!

Simon



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

Re: [Openvpn-devel] [PATCH 0/1] reliable: retransmit if 3 follow-up ACKs are received

[Simon Matter]

>
> Am 31.03.2021 um 21:39 schrieb Simon Matter:
>>> This is my second attempt at sending this patch, this time without
>>> mixing up commit message and cover letter, and from an account that
>>> (I hope) doesn't hate mailing lists.
>>>
>>> This patch changes reliable_send() to resend a packet if at least three
>>> later packets have been ACKed. This improves performance when there are
>>> small amounts of packet loss.
>>>
>>> The patch was originally written by Steffan Karger for OpenVPN-NL.
>>> I added some comments as suggested by Arne Schwabe.
>>>
>>> Steffan Karger (1):
>>>reliable: retransmit if 3 follow-up ACKs are received
>>>
>> Hi Max,
>>
>> Just a shy question, am I right that this will work with UDP
>> connections?
>>
>> If so then I'm interested to test it.
>
> Yes. But it only affects the control channel. For data channel we never
> do retransmits.

OK, but it still could help in case of things like VoIP UDP over OpenVPN
UDP with lots of small packets going over the link with low package loss?

Simon



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

Re: [Openvpn-devel] [PATCH 0/1] reliable: retransmit if 3 follow-up ACKs are received

[Simon Matter]

> This is my second attempt at sending this patch, this time without
> mixing up commit message and cover letter, and from an account that
> (I hope) doesn't hate mailing lists.
>
> This patch changes reliable_send() to resend a packet if at least three
> later packets have been ACKed. This improves performance when there are
> small amounts of packet loss.
>
> The patch was originally written by Steffan Karger for OpenVPN-NL.
> I added some comments as suggested by Arne Schwabe.
>
> Steffan Karger (1):
>   reliable: retransmit if 3 follow-up ACKs are received
>

Hi Max,

Just a shy question, am I right that this will work with UDP connections?

If so then I'm interested to test it.

Regards,
Simon



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

Re: [Openvpn-devel] [ovpn-dco] sudden network disconnection

[Simon Matter]

> Hi Antonio,
>
> As you know I am porting opvn-dco to my router whose kernel is V4.14.76.
> After solving AF_NETLINK group issue we discussed
> yesterday.  It finally works. But I encounter another issue :-( .  When
> testing the performance with iperf3, disconnection occurs
> and recovers after a few seconds and then again.

Just a guess, could it have something to do with missing entropy?

Maybe for such tests a passthrough mode in the kernel module without
encryption could help to debug. Or, as a second option, a non encryption
mode in OpenVPN to test. I think this is or was available.

Simon



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

Re: [Openvpn-devel] Add --up-pre with the same functionality as --down-pre

[Simon Matter]

> On 01/10/2020 17:03, Simon Matter wrote:
>> I really can't understand why this small patch was refused for years and
>> I
>> still feel nobody ever really looked at it.
>
> Perhaps this also an indication of the corner case this patch is covering?
>
> This patch started 7 years ago.  There has been 2 other users being
> supportive
> in the Trac ticket, where at least one of them do have another functional
> alternative (--management with --management-hold).
>
> From what I recall from the last review years ago, the behavior was also
> not
> well defined in restart scenarios (--up-restart) - where the script might
> be
> run with different privileges, the --chroot might also change things.
> Which
> makes this patch very fragile for users.
>
> All of these issues are avoided with the --management and
> --management-hold.

How do all these issues affect --up-pre but not the existing --down-pre?
Why was --down-pre never removed over all the years if it makes things so
fragile for users?

>
> And if you still require more flexibility when starting client
> configurations,
> you should rather consider OpenVPN 3 Linux - which can be much more fine
> grained controlled via an API.  OpenVPN 3 Linux can also be used by
> unprivileged users out-of-the-box, resulting in better security for what
> is
> being executed and when it is being executed.

OpenVPN 3 Linux is not an option here as it is limited to Linux.

Regards,
Simon



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

Re: [Openvpn-devel] Add --up-pre with the same functionality as --down-pre

[Simon Matter]

Hi Arne,

> Am 22.11.17 um 17:58 schrieb Simon Matter:
>> Hi,
>>
>> In our situation we have the requirement to run scripts before tun/tap
>> is
>> opened, not after. While this could be hacked into the init script, the
>> proper way seems to add it to openvpn as --up-pre option. That's
>> independent from any init scripts / systemd service file and works the
>> same way as --down-pre, only for the up status.
>>
>> My initial feature wish, posted 5 years ago, was turned down as won't
>> fix:
>> https://community.openvpn.net/openvpn/ticket/284
>>
>> But there are people who wish it and they have good reasons to wish it.
>> Just yesterday someone asked again:
>> https://community.openvpn.net/openvpn/ticket/284#comment:10
>>
>> Without going into much details
>
> This patch currently misses a commit message anyway but a good commit
> should explain why this change is a good one.
>
>> just one thing why --up + --up-pre is
>> better than hacking around outside of openvpn: the command called with
>> --up also gets additional run time information from openvpn by
>> parameters
>> and environmental variables. You don't get all those information when
>> calling anything from outside of openvpn before openvpn actually starts.
>>
>> If you feel there are good reasons to still refuse this patch, please
>> let
>> me know.
>
> I am just looking at this patch since it is still in the review queue.
>
> - Missing documentation.
> - pre-up flag is wrong in terms of scripts. If we add this, it needs to
> be a different script because otherwise you will break use cases that
> also need the --up script.
>
> Also having down and down-pre but then only not also up/up-pre but a up
> with flag breaks the symmetry and is confusing.

One of us is confused here.

What you say is missing in my patch is not missing at all. It simply
brings both, the "up" and the "down" functionality to the same level!

I modeled the --up-pre option EXACTLY the same way as the EXISTING
--down-pre option. It works the same way now for "up" as it is working
since many years for "down".

The existing man entry for --down-pre says:

--down-pre
  Call ``--down`` cmd/script before, rather than after, TUN/TAP close.

The patched man entry for --up-pre says:

--down-pre
  Call --down cmd/script before, rather than after, TUN/TAP close.

Why should --down-pre use another script while the existing code for
--up-pre doesn't do?


I really can't understand why this small patch was refused for years and I
still feel nobody ever really looked at it.

I know we could fiddle something with systemd now on Linux to get a
similar functionality but it's still not the same. And if you have mixed
environments with other Unices then it's really a mess.

So, it's a non intrusive, small patch which fixes the symmetry between
"up" and "down" path in openvpn.

Regards,
Simon



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

Re: [Openvpn-devel] is anybody running tests on Fedora ?

[Simon Matter via Openvpn-devel]

> пн, 4 мая 2020 г. в 16:41, Samuli Seppänen :
>
>> Hi,
>>
>> We do have a Fedora 30 buildslave and run fping tests there. It also
>> seems to run t_client IPv6 ping tests.
>>
>
> can you please run the following
>
>
> dnf whatprovides fping6

I don't know about the EPEL packages but with recent fping builds, there
is no such thing like an fping6 - it's gone.

Regards,
Simon



___
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

[Simon Matter via Openvpn-devel]

> 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?

Hi,

A long time ago I was asking them to also show MD5/SHAXXX checksums so I
can easily verify the downloads. My request was turned down for reasons I
still don't understand. At least it could give us some peace of mind when
downloading OpenVPN and the PGP stuff doesn't work or is not used by the
person downloading it.

Regards,
Simon



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

Re: [Openvpn-devel] [PATCH] Fix various spelling mistakes

[Simon Matter via Openvpn-devel]

Hi,

> diff --git a/src/openvpn/console.h b/src/openvpn/console.h
> index 0ffd6683..62beacae 100644
> --- a/src/openvpn/console.h
> +++ b/src/openvpn/console.h
> @@ -33,9 +33,9 @@
>   */
> struct _query_user {
>  char *prompt; /**< Prompt to present to the user */
> -size_t prompt_len;/**< Lenght of the prompt string */
> +size_t prompt_len;/**< Length of the prompt string */
>  char *response;   /**< The user's response */
> -size_t response_len;  /**< Lenght the of the user reposone */
> +size_t response_len;  /**< Length the of the user reposone */
 
response

Regards,
Simon



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

Re: [Openvpn-devel] Summary of the community meeting (Wed, 28th Nov 2018)

[Simon Matter]

> Hi Jan Just,
>
> (forgot to add openvpn-devel in previous mail)
>
> Some background information.
>
> In openvpn3 we decided not to implement fragments, because:
>
>  - this is quite a big feature which has to be supported through the whole
> stack (client, server, kernel module)
>  - we assume that it is not used by most of users
>
> However, for those who needs --fragment, we'll implement:
>
>  - mssfix support, this should solve problems with tcp-based protocols
>  - sending icmp "packet too big" for other protocols, we assume that
> they'll respect icmp response
>
> --fragment is/was very useful on a system where you do not / cannot change
>> the tun MTU size. Up to Windows XP, this was not
>> possible without rebooting the OS. Since Vista, it *is* possible to
>> change
>> the MTU of an adapter on the fly (as explained in my
>> trusty old cookbook, of course ;))
>>
>
> As James wrote a while ago (13 years ago :)
>
> https://openvpn.net/archive/openvpn-users/2005-10/msg00354.html
>
>> A lot of experience gained during the OpenVPN 1.x releases showed that
> it's best to fix the tunnel MTU at
>> 1500 and vary the other parameters (and use --mssfix to prevent
> fragmentation rather than a lower tunnel MTU).
>
> Don't know if still holds. Assuming that we can change tun-mtu on any
> supported platforms, do you think that it is better
> to do _that_, rather than have mssfix/icmp ptb workaround?
>
>
>> With that, it would be possible to fix the link-mtu to 1500 (or
>> whatever is set on the outbound interface) and then subtract the header
>> size to get a meaningful tun-mtu size.
>>
>
> Do you think 1500 is a safe value? Arne just mentioned today that his
> network interface MTU is 1500 and router's MTU is 1492 due to
> PPPoE, and openvpn2 works because it assumes that mtu is 1450.

I also think 1500 isn't safe because different types ob internet
connections may reduce it, like the mentioned PPPoE.

Regards,
Simon



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

Re: [Openvpn-devel] Discussion: Moving forward with compression and voracle

[Simon Matter]

> On 29-08-18 17:18, Jan Just Keijser wrote:
>> Since when can I not type in
>>   rm -rf /
>> any more ?  did someone build in a flag into the "rm" command to stop me
>> from doing so? I sure hope not.
>
> $ sudo docker run --rm debian rm -rf /
> rm: it is dangerous to operate recursively on '/'
> rm: use --no-preserve-root to override this failsafe
>
> This has been like this for a long while (and not just for debian).
>
> -Steffan
>
> PS: "rm -rf /*" will try to rm (almost) everything ;-)

Still, using OpenVPN with compression makes much more sense than using "rm
-rf /". I really vote against removing compression from OpenVPN!

Regards,
Simon


--
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] Summary of the community meeting (Wed, 18th Apr 2018)

[Simon Matter]

Hi,

I'm just wondering what happened to the proposed 2.4.6 release? Will it
come anytime soon?

Regards,
Simon

> Hi,
>
> Here's the summary of the IRC meeting.
> ---
>
> COMMUNITY MEETING
>
> Place: #openvpn-meeting on irc.freenode.net
> Date: Wednesday 18th Apr 2018
> Time: 11:30 CET (10:30 UTC)
>
> Planned meeting topics for this meeting were here:
>
> 
>
> The next meeting has not been scheduled yet.
>
> Your local meeting time is easy to check from services such as
>
> 
>
> SUMMARY
>
> cron2, dazo, mattock, ordex, plaisthos and syzzer participated in
> this meeting.
>
> --
>
> Discussed upcoming OpenVPN 2.4.6 release. It will contain what
> release/2.4 has now, plus one security fix which is under embargo. The
> tree will be pushed to buildbot tomorrow afternoon after which the
> release machinery starts for good.
>
> The 2.4.6 release will include an updated tap-windows6 driver with a
> small security fix. The fix will not get a CVE as exploitation requires
> local admin privileges and is not remotely exploitable. It was agreed
> that we should update PRODUCT_VERSION in tap-windows6 from 9,0,0,21 to
> 9,22,1,601. This means it will be in-line with the real version
> (9.22.1). The old, confusing PRODUCT_VERSION string seems to be just
> historic baggage brought over from tap-windows (i.e. the old NDIS 5
> driver).
>
> --
>
> Discussed unit testing the netlink code and in particular the msg()
> function. Noted that we have mock_msg.c already which does minimal
> logging, which renders it more suitable for unit testing.
>
> --
>
> Discussed the location of the next hackathon. One possibility is Lviv,
> Ukraine, where OpenVPN Inc. has a rather large team. It is easily
> accessible for EU citizens as no visa is required.
>
> ---
>
> Full chatlog attached.
>
> --
> Samuli Seppänen
> Community Manager
> OpenVPN Technologies, Inc
>
> irc freenode net: mattock
>
>
> --
> 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

[Openvpn-devel] tls fix for upcoming 2.4.5

[Simon Matter]

Hi,

I've just done some test builds with 2.4.5 tagged version.

Attached patch makes it build with older systems. Do you see any issue
with the change?

Regards,
Simon--- openvpn-2.4.5/src/openvpn/openssl_compat.h.orig	2018-02-28 21:56:54.0 +0100
+++ openvpn-2.4.5/src/openvpn/openssl_compat.h	2018-03-01 11:44:57.0 +0100
@@ -672,14 +672,18 @@
 {
 return TLS1_VERSION;
 }
+#ifdef SSL_OP_NO_TLSv1_1
 if (!(sslopt & SSL_OP_NO_TLSv1_1))
 {
 return TLS1_1_VERSION;
 }
+#endif
+#ifdef SSL_OP_NO_TLSv1_2
 if (!(sslopt & SSL_OP_NO_TLSv1_2))
 {
 return TLS1_2_VERSION;
 }
+#endif
 return 0;
 }
 #endif /* SSL_CTX_get_min_proto_version */--
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

[Simon Matter]

> On 20/01/18 18:22, Selva Nair wrote:
>> Hi,
>>
>> Does openvpn-vagrant include any VM provisioning with openssl-0.9.8?
>> Until recently I had access to a few old debian boxes but now all
>> updated and 0.9.8 testing is getting harder.
>
> 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?

If it's possible without too many headaches, I'd appreciate if
openssl-0.9.8 support would be kept in during the 2.4 series.

Regards,
Simon


--
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] OVPN vs IPSec performance as a transport

[Simon Matter]

> -SNIP-
> I haven't taken the time to fully understand the tests you've done etc.
> [And it does seem you are not some neophyte blindly hacking your way
> through this...]
>
> However, I will tell you that it's *very* common for people to do things
> that appear very similarly as you describe, and find the IPSec throughput
> is vastly better then OpenVPN. [That's always been my experience in any
> benchmarking I've done - and I've done some.]  Each time I've seen it
> discussed - I've seen repeated threads all pointing to the kernel vs user
> space arguments.
>
> And all my own testing also shows that to be the case.
>
> IIRC, in the platforms I've tested, OVPN isn't CPU constrained - the
> connection will max out throughput far earlier than CPU exhaustion. IPSec
> will scale more or less directly with CPU performance - and at max
> throughput the CPU handling encryption will max out. (I suppose this might
> not be true in a system with in-hardware AES or other encryption
> off-loading - and the ethernet interface will become the bottleneck, not
> the CPU - but where I've run tests, that was never the case. It's,
> admittedly, been a while since I've done any real throughput tests on a
> test-bed setup.)
>
> TK> Again, keep in mind that full wire speed is realized with no vpn, and
> TK> with IPSec.
> TK> So, to reason this through a little:
>
> 1) TK> - No vpn = fast.
> 2) TK> - IPSec = fast.
> 3) - OVPN->>OVPN = even faster
> 4) - OVPN->>OVPN->routing/hardware = slow, down to about 200Mbps from
> 1+Gbps.
>
>
> I may certainly be wrong, but I'd be *really* skeptical about #3. I've

I may be wrong but I think it's simply the effect of LZO compression and
the nature of transferred data. Without LZO (or any other compression like
LZ4) I'm quite sure the speed is almost identical to #2 with IPSec.

> *never* seen a case where the performance of OpenVPN is better than IPSec
> on the same platform.
>
> And if #3 is wrong, your "tinkering" with #4 will never yield something
> useful.
> Obviously, I'd want to be pretty sure the straight OVPN <-> OVPN tests are
> accurate before trying to solve #4.

Still, I believe a dump on host B should reveal where the bottleneck is.
I'm also not sure the simple 'ethtool -K {dev} rx off tx off' is enough
here. Did you also look at ethernet features

- scatter-gather
- TCP segmentation  offload
- UDP  fragmentation offload
- generic segmentation offload
- generic receive offload

I know that the default settings can slow down data transfers horribly
with some traffic shaping configurations. I expect they can also have an
effect here.

Regards,
Simon
- large receive offload


--
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] OVPN vs IPSec performance as a transport

[Simon Matter]

Hi,

> That would explain it if it always worked that way.
> But I can get 400%+ wire speed from A to B with compressible data, and
> 102% with incompressible data.  If I do the same test from B to A or A
> to B, I get those results.  If I hop off of that to C, speed goes from
>>1Gbps to sub-200Mbps.  In either case, the data has left the kernel
> space to arrive at "nc", so just simply saying "it's kernel vs user"
> doesn't answer it.

So if I understand correctly you are able to get wire speed over the
OpenVPN link as long as you don't route traffic further via an other
simple router?

Maybe you could try those two things:
1) Disable all LZO compression just to make sure it has nothing to do with
it.

2) Run tcpdump/wireshark on B and look in detail how data is moved over
the different tun and ethernet devices. I'm sure you should see something
there at least if you compare it with a run made without OpenVPN.

BTW, you don't have any iptables rules on any of the boxes, do you?

And, you could check all the kinds of checksumming and offloading on your
ethernet interfaces. Those settings can have a huge impact if they do
things wrong.

Regards,
Simon


--
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] Add --up-pre with the same functionality as --down-pre

[Simon Matter]

Hi,

In our situation we have the requirement to run scripts before tun/tap is
opened, not after. While this could be hacked into the init script, the
proper way seems to add it to openvpn as --up-pre option. That's
independent from any init scripts / systemd service file and works the
same way as --down-pre, only for the up status.

My initial feature wish, posted 5 years ago, was turned down as won't fix:
https://community.openvpn.net/openvpn/ticket/284

But there are people who wish it and they have good reasons to wish it.
Just yesterday someone asked again:
https://community.openvpn.net/openvpn/ticket/284#comment:10

Without going into much details just one thing why --up + --up-pre is
better than hacking around outside of openvpn: the command called with
--up also gets additional run time information from openvpn by parameters
and environmental variables. You don't get all those information when
calling anything from outside of openvpn before openvpn actually starts.

If you feel there are good reasons to still refuse this patch, please let
me know.

Regards,
Simondiff -Naur openvpn-2.4.0.orig/doc/openvpn.8 openvpn-2.4.0/doc/openvpn.8
--- openvpn-2.4.0.orig/doc/openvpn.8	2016-12-26 14:01:34.0 +0100
+++ openvpn-2.4.0/doc/openvpn.8	2016-12-30 11:45:16.0 +0100
@@ -1845,6 +1845,12 @@
 .B route add \-net 10.0.0.0 netmask 255.255.255.0 gw $5
 .\"*
 .TP
+.B \-\-up\-pre
+Call
+.B \-\-up
+cmd/script before, rather than after, TUN/TAP open.
+.\"*
+.TP
 .B \-\-up\-delay
 Delay TUN/TAP open and possible
 .B \-\-up
diff -Naur openvpn-2.4.0.orig/src/openvpn/init.c openvpn-2.4.0/src/openvpn/init.c
--- openvpn-2.4.0.orig/src/openvpn/init.c	2016-12-26 12:51:00.0 +0100
+++ openvpn-2.4.0/src/openvpn/init.c	2016-12-30 12:05:15.0 +0100
@@ -1573,6 +1573,27 @@
 }
 #endif
 
+/* actually run the up script based on --up-pre flag */
+if (c->options.up_pre)
+{
+run_up_down (c->options.up_script,
+ c->plugins,
+ OPENVPN_PLUGIN_UP,
+ "[unknown-dev]",
+#ifdef _WIN32
+ TUN_ADAPTER_INDEX_INVALID,
+#endif
+ dev_type_string (c->options.dev, c->options.dev_type),
+ TUN_MTU_SIZE (>c2.frame),
+ EXPANDED_SIZE (>c2.frame),
+ NULL,
+ NULL,
+ "init",
+ NULL,
+ "up",
+ c->c2.es);
+}
+
 /* initialize (but do not open) tun/tap object */
 do_init_tun(c);
 
@@ -1639,23 +1660,26 @@
 do_ifconfig(c->c1.tuntap, c->c1.tuntap->actual_name, TUN_MTU_SIZE(>c2.frame), c->c2.es);
 }
 
-/* run the up script */
-run_up_down(c->options.up_script,
-c->plugins,
-OPENVPN_PLUGIN_UP,
-c->c1.tuntap->actual_name,
+/* actually run the up script based on --up-pre flag */
+if (!c->options.up_pre)
+{
+run_up_down(c->options.up_script,
+c->plugins,
+OPENVPN_PLUGIN_UP,
+c->c1.tuntap->actual_name,
 #ifdef _WIN32
-c->c1.tuntap->adapter_index,
+c->c1.tuntap->adapter_index,
 #endif
-dev_type_string(c->options.dev, c->options.dev_type),
-TUN_MTU_SIZE(>c2.frame),
-EXPANDED_SIZE(>c2.frame),
-print_in_addr_t(c->c1.tuntap->local, IA_EMPTY_IF_UNDEF, ),
-print_in_addr_t(c->c1.tuntap->remote_netmask, IA_EMPTY_IF_UNDEF, ),
-"init",
-NULL,
-"up",
-c->c2.es);
+dev_type_string(c->options.dev, c->options.dev_type),
+TUN_MTU_SIZE(>c2.frame),
+EXPANDED_SIZE(>c2.frame),
+print_in_addr_t(c->c1.tuntap->local, IA_EMPTY_IF_UNDEF, ),
+print_in_addr_t(c->c1.tuntap->remote_netmask, IA_EMPTY_IF_UNDEF, ),
+"init",
+NULL,
+"up",
+c->c2.es);
+}
 
 #if defined(_WIN32)
 if (c->options.block_outside_dns)
diff -Naur openvpn-2.4.0.orig/src/openvpn/options.c openvpn-2.4.0/src/openvpn/options.c
--- openvpn-2.4.0.orig/src/openvpn/options.c	2016-12-26 12:51:00.0 +0100
+++ openvpn-2.4.0/src/openvpn/options.c	2016-12-30 12:09:19.0 +0100
@@ -301,6 +301,7 @@
 "  Execute as: cmd tun/tap-dev tun-mtu link-mtu \\\n"
 "  ifconfig-local-ip ifconfig-remote-ip\n"
 "  (pre --user or --group UID/GID change)\n"
+"--up-pre: Run --up command before TUN/TAP open.\n"
 "--up-delay  : Delay tun/tap open and possible --up script execution\n"
 "  until after TCP/UDP 

Re: [Openvpn-devel] [PATCH v4] Add per session pseudo-random jitter to --reneg-sec intervals

[Simon Matter]

Hi,

> From: Simon Matter <simon.mat...@invoca.ch>
>
> While we were suffering from the "TLS Renegotiation Slowdown" bug here
> https://community.openvpn.net/openvpn/ticket/854 we realized that there is
> still room for improvement in our use case.
>
> It appears that TLS renegotiation is getting more and more expensive in
> terms of CPU cycles with recent changes for more security. To make things
> worse, we realized that most renegotiation procedures took place at almost
> the same time and increased the CPU load too much during these periods.
> That's especially true on large, multi-instance openvpn setups.
>
> I've created attached patch to add a per session pseudo-random component
> to
> the --reneg-sec intervals so that renegotiation is evenly spread over
> time.
> It is configured by simply adding a second value to --reneg-sec as
> described in the --help text:
>
> --reneg-sec max [min] : Renegotiate data chan. key after at most max
>   (default=3600) and at least min (default 90% of max on
>   servers and equal to max on clients).
>
> The jitter is only enabled by default on servers, because the actual reneg
> time is min(reneg_server, reneg_client).  Introducing jitter at both ends
> would bias the actual reneg time to the min value.
>
> Note that the patch also slightly changes the log output to show the sec
> value in the same way as the bytes/pkts values:
>
> TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0
>
> The idea and first versions of this patch are from Simon Matter.  Steffan
> Karger later incorporated the mailing list comments into this patch.  So
> credits go to Simon, and all bugs are Steffan's fault ;-)
>
> Signed-off-by: Simon Matter <simon.mat...@invoca.ch>
> Signed-off-by: Steffan Karger <stef...@karger.me>
> ---
> v3: incorporate comments from openvpn-devel@, don't add jitter by
> default on the client side.
> v4: fix printing of reneg interval, clarify/typofix comments

I've tested it and it works as expected, thanks!

Regards,
Simon


--
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 v3] Add per session pseudo-random jitter to --reneg-sec intervals

[Simon Matter]

Hi Steffan,

While running your v3 version of the patch I found an issue with the
modified logging. It gives the following error while building

gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include  -I../../include
-I../../src/compat   -DPLUGIN_LIBDIR=\"/usr/lib64/openvpn/plugins\" 
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  
-m64 -mtune=generic -std=c99 -c -o ssl.o ssl.c
ssl.c: In function 'tls_process':
ssl.c:2735:9: warning: format '%lld' expects argument of type 'long long
int', but argument 3 has type 'time_t' [-Wformat=]
 msg(D_TLS_DEBUG_LOW, "TLS: soft reset sec=%lld/%d bytes="
counter_format
 ^
and the log output is also corrupted

TLS: soft reset sec=14774687501680/336605974
bytes=18446744069414584320/581335 pkts=0/0
TLS: soft reset sec=14787572403571/77375 bytes=18446744069414584320/885
pkts=0/-1080308296
TLS: soft reset sec=14164802145506/6746662
bytes=18446744069414584320/86778 pkts=0/0
TLS: soft reset sec=15264313773538/186529 bytes=18446744069414584320/1108
pkts=0/13935244

Please have a look at the attached v4 patch which fixes it for me. The
output is now

TLS: soft reset sec=3474/3474 bytes=8470454/-1 pkts=108673/0
TLS: soft reset sec=3489/3489 bytes=429623769/-1 pkts=656033/0
TLS: soft reset sec=3517/3517 bytes=89365/-1 pkts=877/0
TLS: soft reset sec=3537/3537 bytes=206142/-1 pkts=1123/0

which seems reasonable to me.
In the patch I've modified the lines below:

 msg(D_TLS_DEBUG_LOW,
-"TLS: soft reset sec=%d bytes=" counter_format "/%d pkts="
counter_format "/%d",
-(int)(ks->established + session->opt->renegotiate_seconds -
now),
+"TLS: soft reset sec=%d/%d bytes=" counter_format "/%d pkts="
counter_format "/%d",
+(int)(now - ks->established), session->opt->renegotiate_seconds,
 ks->n_bytes, session->opt->renegotiate_bytes,

I'm not a developer and not a git user, so please accept my hand crafted
patch work :-)

Thanks and regards,
Simon

> From: Simon Matter <simon.mat...@invoca.ch>
>
> While we were suffering from the "TLS Renegotiation Slowdown" bug here
> https://community.openvpn.net/openvpn/ticket/854 we realized that there is
> still room for improvement in our use case.
>
> It appears that TLS renegotiation is getting more and more expensive in
> terms of CPU cycles with recent changes for more security. To make things
> worse, we realized that most renegotiation procedures took place at almost
> the same time and increased the CPU load too much during these periods.
> That's especially true on large, multi-instance openvpn setups.
>
> I've created attached patch to add a per session pseudo-random component
> to
> the --reneg-sec intervals so that renegotiation is evenly spread over
> time.
> It is configured by simply adding a second value to --reneg-sec as
> described in the --help text:
>
> --reneg-sec max [min] : Renegotiate data chan. key after at most max
>   (default=3600) and at least min (default 90% of max on
>   servers and equal to max on clients).
>
> The jitter is only enabled by default on servers, because the actual reneg
> time is min(reneg_server, reneg_client).  Introducing jitter at both ends
> would bias the actual reneg time to the min value.
>
> Note that the patch also slightly changes the log output to show the sec
> value in the same way as the bytes/pkts values:
>
> TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0
>
> The idea and first versions of this patch are from Simon Matter.  Steffan
> Karger later incorporated the mailing list comments into this patch.  So
> credits go to Simon, and all bugs are Steffan's fault ;-)
>
> Signed-off-by: Simon Matter <simon.mat...@invoca.ch>
> Signed-off-by: Steffan Karger <stef...@karger.me>
> ---
> v3: incorporate comments from openvpn-devel@, don't add jitter by
> default on the client side.
>
>  doc/openvpn.8 | 26 +-
>  src/openvpn/init.c| 15 ++-
>  src/openvpn/options.c | 11 +--
>  src/openvpn/options.h |  1 +
>  src/openvpn/ssl.c |  6 +++---
>  5 files changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index a4189ac2..eb5258f9 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -33,7 +33,7 @@
>  .\" .ft -- normal face
>  .\" .in +|-{n} -- indent
>  .\"
> -.TH openvpn 8 "25 August 2016"
> +.TH openvpn 8 "04 April 2017"
>  .\"*
>  .SH NAME
>  openvpn \- secure IP tunnel daemon.
> 

Re: [Openvpn-devel] [PATCH v3] Add per session pseudo-random jitter to --reneg-sec intervals

[Simon Matter]

Hi Steffan,

Thanks for taking the time to improve this!

Regards,
Simon

> From: Simon Matter <simon.mat...@invoca.ch>
>
> While we were suffering from the "TLS Renegotiation Slowdown" bug here
> https://community.openvpn.net/openvpn/ticket/854 we realized that there is
> still room for improvement in our use case.
>
> It appears that TLS renegotiation is getting more and more expensive in
> terms of CPU cycles with recent changes for more security. To make things
> worse, we realized that most renegotiation procedures took place at almost
> the same time and increased the CPU load too much during these periods.
> That's especially true on large, multi-instance openvpn setups.
>
> I've created attached patch to add a per session pseudo-random component
> to
> the --reneg-sec intervals so that renegotiation is evenly spread over
> time.
> It is configured by simply adding a second value to --reneg-sec as
> described in the --help text:
>
> --reneg-sec max [min] : Renegotiate data chan. key after at most max
>   (default=3600) and at least min (default 90% of max on
>   servers and equal to max on clients).
>
> The jitter is only enabled by default on servers, because the actual reneg
> time is min(reneg_server, reneg_client).  Introducing jitter at both ends
> would bias the actual reneg time to the min value.
>
> Note that the patch also slightly changes the log output to show the sec
> value in the same way as the bytes/pkts values:
>
> TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0
>
> The idea and first versions of this patch are from Simon Matter.  Steffan
> Karger later incorporated the mailing list comments into this patch.  So
> credits go to Simon, and all bugs are Steffan's fault ;-)
>
> Signed-off-by: Simon Matter <simon.mat...@invoca.ch>
> Signed-off-by: Steffan Karger <stef...@karger.me>
> ---
> v3: incorporate comments from openvpn-devel@, don't add jitter by
> default on the client side.
>
>  doc/openvpn.8 | 26 +-
>  src/openvpn/init.c| 15 ++-
>  src/openvpn/options.c | 11 +--
>  src/openvpn/options.h |  1 +
>  src/openvpn/ssl.c |  6 +++---
>  5 files changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index a4189ac2..eb5258f9 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -33,7 +33,7 @@
>  .\" .ft -- normal face
>  .\" .in +|-{n} -- indent
>  .\"
> -.TH openvpn 8 "25 August 2016"
> +.TH openvpn 8 "04 April 2017"
>  .\"*
>  .SH NAME
>  openvpn \- secure IP tunnel daemon.
> @@ -4957,10 +4957,26 @@ Renegotiate data channel key after
>  packets sent and received (disabled by default).
>  .\"*
>  .TP
> -.B \-\-reneg\-sec n
> -Renegotiate data channel key after
> -.B n
> -seconds (default=3600).
> +.B \-\-reneg\-sec max [min]
> +Renegotiate data channel key after at most
> +.B max
> +seconds (default=3600) and at least
> +.B min
> +seconds (default is 90% of
> +.B max
> +for servers, and equal to
> +.B max
> +for clients).
> +
> +The effective
> +.B reneg\-sec
> +value used is per session pseudo-uniform-randomized between
> +.B min
> +and
> +.B max\fR.
> +
> +With the default value of 3600 this results in an effective per session
> value
> +in the range of 3240..3600 seconds for servers, or just 3600 for clients.
>
>  When using dual\-factor authentication, note that this default value may
>  cause the end user to be challenged to reauthorize once per hour.
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 1ed2c55e..0b64930e 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -2693,7 +2693,20 @@ do_init_crypto_tls(struct context *c, const
> unsigned int flags)
>  to.packet_timeout = options->tls_timeout;
>  to.renegotiate_bytes = options->renegotiate_bytes;
>  to.renegotiate_packets = options->renegotiate_packets;
> -to.renegotiate_seconds = options->renegotiate_seconds;
> +if (options->renegotiate_seconds_min < 0)
> +{
> +/* Add 10% jitter to the reneg-sec of each connection by default
> */
> +int auto_jitter = options->mode != MODE_SERVER ? 0 :
> +get_random() % max_int(options->renegotiate_seconds / 10,
> 1);
> +to.renegotiate_seconds = options->renegotiate_seconds -
> auto_jitter;
> +}
> +else
> +{
> +/* Add user-specific jitter to the renge-sec of each connection
> */
&g

Re: [Openvpn-devel] [PATCH v2] lz4: Move towards a newer LZ4 API

[Simon Matter]

Hi,

While we are at it, I found it useful to see the used LZ4 version at
runtime as it is done with LZO and other libraries.

I've patched my rpms with the patch attached.

Regards,
Simon

> We are using a deprecated function, LZ4_compress_limitedOutput(), which
> will be removed with time.  The correct function to use is
> LZ4_compress_default().
> Both function takes the same number of arguments and data types, so the
> change
> is minimal.
>
> This patch will also enforce the system LZ4 library to be at least v1.7.1.
>  If
> the system library is not found or it is older, it will be build using the
> bundled
> LZ4 library.  The version number requirement is based on the LZ4 version
> we ship.
>
> The changes in configure.ac for the version check is modelled around the
> same
> approach we use for OpenSSL.  Plus it does a few minor reformats and
> improvements
> to comply with more recommend autoconf coding style.
>
> This patch is a result of the discussions in this mail thread:
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14135.html
>
> Signed-off-by: David Sommerseth 
>
> ---
> v2 - Don't use LZ4 version based #ifdef wrapper function
>  Do the LZ4 version check in ./configure
> ---
>  configure.ac   | 72
> +++---
>  src/openvpn/comp-lz4.c |  3 ++-
>  2 files changed, 53 insertions(+), 22 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 6f1044e8..74443353 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1088,37 +1088,67 @@ dnl
>  AC_ARG_VAR([LZ4_CFLAGS], [C compiler flags for lz4])
>  AC_ARG_VAR([LZ4_LIBS], [linker flags for lz4])
>  if test "$enable_lz4" = "yes" && test "$enable_comp_stub" = "no"; then
> -AC_CHECKING([for LZ4 Library and Header files])
> -havelz4lib=1
> -
> -# if LZ4_LIBS is set, we assume it will work, otherwise test
> -if test -z "${LZ4_LIBS}"; then
> - AC_CHECK_LIB(lz4, LZ4_compress,
> - [ LZ4_LIBS="-llz4" ],
> - [
> - AC_MSG_RESULT([LZ4 library not found.])
> - havelz4lib=0
> - ])
> +if test -z "${LZ4_CFLAGS}" -a -z "${LZ4_LIBS}"; then
> + # if the user did not explicitly specify flags, try to autodetect
> + PKG_CHECK_MODULES([LZ4],
> +   [liblz4 >= 1.7.1],
> +   [have_lz4="yes"],
> +   [] # If this fails, we will do another test next
> + )
>  fi
>
>  saved_CFLAGS="${CFLAGS}"
> +saved_LIBS="${LIBS}"
>  CFLAGS="${CFLAGS} ${LZ4_CFLAGS}"
> -AC_CHECK_HEADERS(lz4.h,
> -   ,
> -   [
> -AC_MSG_RESULT([LZ4 headers not found.])
> -havelz4lib=0
> -   ])
> -
> -if test $havelz4lib = 0 ; then
> - AC_MSG_RESULT([LZ4 library or header not found, using version in
> src/compat/compat-lz4.*])
> +LIBS="${LIBS} ${LZ4_LIBS}"
> +
> +# If pkgconfig check failed or LZ4_CFLAGS/LZ4_LIBS env vars
> +# are used, check the version directly in the LZ4 include file
> +if test "${have_lz4}" != "yes"; then
> + AC_CHECK_HEADERS([lz4.h],
> +  [have_lz4h="yes"],
> +  [])
> +
> + if test "${have_lz4h}" = "yes" ; then
> + AC_MSG_CHECKING([additionally if system LZ4 version >= 1.7.1])
> + AC_COMPILE_IFELSE(
> + [AC_LANG_PROGRAM([[
> +#include 
> +  ]],
> +  [[
> +/* Version encoding: MMNNPP (Major miNor Patch) - see lz4.h for details
> */
> +#if LZ4_VERSION_NUMBER < 10701L
> +#error LZ4 is too old
> +#endif
> +  ]]
> + )],
> + [
> + AC_MSG_RESULT([ok])
> + have_lz4="yes"
> + ],
> + [AC_MSG_RESULT([system LZ4 library is too old])]
> + )
> + fi
> +fi
> +
> +# if LZ4_LIBS is set, we assume it will work, otherwise test
> +if test -z "${LZ4_LIBS}"; then
> + AC_CHECK_LIB([lz4],
> +  [LZ4_compress],
> +  [LZ4_LIBS="-llz4"],
> +  [have_lz4="no"])
> +fi
> +
> +if test "${have_lz4}" != "yes" ; then
> + AC_MSG_RESULT([ usuable LZ4 library or header not found, using 
> version
> in src/compat/compat-lz4.*])
>   AC_DEFINE([NEED_COMPAT_LZ4], [1], [use copy of LZ4 source in compat/])
>   LZ4_LIBS=""
>  fi
>  OPTIONAL_LZ4_CFLAGS="${LZ4_CFLAGS}"
>  OPTIONAL_LZ4_LIBS="${LZ4_LIBS}"
> -AC_DEFINE(ENABLE_LZ4, 1, [Enable LZ4 compression library])
> +AC_DEFINE(ENABLE_LZ4, [1], [Enable LZ4 compression library])
>  CFLAGS="${saved_CFLAGS}"
> +LIBS="${saved_LIBS}"
>  fi
>
>
> diff --git a/src/openvpn/comp-lz4.c b/src/openvpn/comp-lz4.c
> index e056caa8..bdb3247d 100644
> --- a/src/openvpn/comp-lz4.c
> +++ b/src/openvpn/comp-lz4.c
> @@ -43,6 +43,7 @@
>
>  #include "memdbg.h"
>
> +
>  static void
>  lz4_compress_init(struct 

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

[Simon Matter]

> Hi,
>
> On Wed, Jun 21, 2017 at 04:18:41PM +0200, Simon Matter wrote:
>> An additional source of confusion seems that the tarball of the .gz and
>> .xz files don't match. Maybe this could easily be fixed in the build
>> process.
>
> .gz is built with "make distcheck", .xz right after from the same
> tree with "make dist-xz".
>
> What differs?

The check sum of both extracted tarballs, not really their content.

I suggest to create .xz from .gz instead of building another tarball. That
way the extracted tarballs from .gz and .xz share the same checksum ->
less confusion in case something goes wrong - as it did with 2.4.2 and
now.

Thanks,
Simon


--
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)

[Simon Matter]

>>> I believe it is Cloudflare playing tricks on us again.
>>>
>>> Attached are the proper signature files and below a list of the SHA256
>>> checksums:
>>>
>>> 7aa86167a5b8923e54e8795b814ed77288c793671f59fd830d9ab76d4b480571
>>> openvpn-2.4.3.tar.xz
>>>
>>> This is based on the files I've already pushed to the Fedora builder
>>> (koji), which
>>
>> I have the following sums:
>>
>> 15e15fc97f189b52aee7c90ec8355aa77469c773125110b4c2f089abecde36fb
>> openvpn-2.4.3.tar.xz
>>
>
> Those sha256sums are the correct ones.

That's the problem, which one is the correct one for openvpn-2.4.3.tar.xz?

7aa86167a5b8923e54e8795b814ed77288c793671f59fd830d9ab76d4b480571

or

15e15fc97f189b52aee7c90ec8355aa77469c773125110b4c2f089abecde36fb

Thanks,
Simon


--
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)

[Simon Matter]

> On 21/06/17 13:48, Jonathan K. Bullard 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:
>>
>> $ 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?
>
> 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 have the following sums:

af806c47623aa1d8246cf0790984766f61c8d0a63ea0b04127ff5c6c65e46088 
openvpn-2.3.17.tar.gz
d300029416b045666f2dc957bdde407ba97894428b5ad8433df789e793ccc1d3 
openvpn-2.3.17.tar.xz
cee3d3ca462960a50a67c0ebd186e01b6d13db70275205663695152c9aca8579 
openvpn-2.4.3.tar.gz
15e15fc97f189b52aee7c90ec8355aa77469c773125110b4c2f089abecde36fb 
openvpn-2.4.3.tar.xz

So 2.3.17 seems fine but what about 2.4.3? What is the real final check
sum for openvpn-2.4.3.tar.gz and openvpn-2.4.3.tar.xz?

Thanks,
Simon


--
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)

[Simon Matter]

>> 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 :-)

An additional source of confusion seems that the tarball of the .gz and
.xz files don't match. Maybe this could easily be fixed in the build
process.

Simon


--
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)

[Simon Matter]

> 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


--
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 release/2.4] configure.ac: fix building against static openssl

[Simon Matter]

> On 31/05/17 15:51, Simon Matter wrote:
>>> Hi,
>>>
>>> On Wed, May 31, 2017 at 11:14:33AM +0200, David Sommerseth wrote:
>>>> On 31/05/17 09:02, Gert Doering wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote:
>>>>>> If we really do care for supporting 0.9.8, in release/2.4 - I can
>>>> give
>>>>>> this an ACK.  Otherwise, I think it might be better to backport
>>>>>> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f.
>>>>>
>>>>> You are the one that objects most violently if we break users'
>>>> expectations
>>>>
>>>> Yes and no.  In regards to end users, I am very careful.  In regards
>>>> to
>>>> package maintainers, I am less weary as they won't distribute failing
>>>> builds to end users.  This change hits package building, not the end
>>>> user.
>>>
>>> Well, this is a somewhat simplistic world view, with "package builders"
>>> and "package installers".
>>>
>>> People are stuck on older enterprise distributions, for whatever
>>> reasons,
>>> but want a newer openvpn version - so they get the source bundle, and
>>> compile.  Which is a perfectly fine deployment model - and we should
>>> not
>>> break things in 2.4.3 that worked just fine in 2.4.2 for them (unless
>>> there is a strong reason, like "we have a vulnerability here that we
>>> cannot fix unless we abandon an older API").
>>
>> I strongly support your view, Gert. I really hope we do not see such
>> breakage in minor stable releases.
>
> Do you depend on building against OpenSSL 0.9.8?  If so, which
> OS/distribution do you use?

Yes, I have a case with very customized CentOS 5 systems where we also
backport security related patches. Of course the same could be done for
openvpn but it's easier to just follow the current 2.4 stream. That's why
my suggestion to keep all the compat hacks in 2.4.x and kick them out only
in the main devel branch. I guess that's what most package maintainers
expect to happen and it keep mailing lists quiet.

Regards,
Simon


--
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 release/2.4] configure.ac: fix building against static openssl

[Simon Matter]

> Hi,
>
> On Wed, May 31, 2017 at 11:14:33AM +0200, David Sommerseth wrote:
>> On 31/05/17 09:02, Gert Doering wrote:
>> > Hi,
>> >
>> > On Wed, May 31, 2017 at 02:31:40AM +0200, David Sommerseth wrote:
>> >> If we really do care for supporting 0.9.8, in release/2.4 - I can
>> give
>> >> this an ACK.  Otherwise, I think it might be better to backport
>> >> 039a89c331e9b7998d804 + 79ea67f77ca3afe91222f.
>> >
>> > You are the one that objects most violently if we break users'
>> expectations
>>
>> Yes and no.  In regards to end users, I am very careful.  In regards to
>> package maintainers, I am less weary as they won't distribute failing
>> builds to end users.  This change hits package building, not the end
>> user.
>
> Well, this is a somewhat simplistic world view, with "package builders"
> and "package installers".
>
> People are stuck on older enterprise distributions, for whatever reasons,
> but want a newer openvpn version - so they get the source bundle, and
> compile.  Which is a perfectly fine deployment model - and we should not
> break things in 2.4.3 that worked just fine in 2.4.2 for them (unless
> there is a strong reason, like "we have a vulnerability here that we
> cannot fix unless we abandon an older API").

I strongly support your view, Gert. I really hope we do not see such
breakage in minor stable releases.

Regards,
Simon


--
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] Please check the 2.3.15 downloads

[Simon Matter]

Hi,

I'm not sure what the correct 2.3.15 tarball is.

The one available from
https://openvpn.net/index.php/open-source/downloads.html doesn't have the
CVE-2017-7478 included.

Isn't there still something wrong there?

Thanks,
Simon


--
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] Require minimum OpenSSL 1.0.1

[Simon Matter]

> Hi,
>
> On 11-04-17 19:31, David Sommerseth wrote:
>> As RHEL 5 has reached EOL, we no longer need to support OpenSSL v0.9.8.
>> This also makes it possible to remove a few workaronds which was
>> needed earlier, as well as some left overs from v0.9.6.
>>
>> This also makes ./configure really stop running unless a new enough
>> OpenSSL library is found.
>>
>> Compile tested on RHEL7.3 and RHEL6.7 (mock chroot build), both shipping
>> openssl-1.0.1e.
>>
>> Signed-off-by: David Sommerseth 
>> ---
>>  configure.ac  |  6
>> +++---
>>  doc/openvpn.8 |  1 -
>>  .../keying-material-exporter-demo/keyingmaterialexporter.c|  3 +--
>>  sample/sample-plugins/log/log_v3.c|  3 +--
>>  src/openvpn/ssl_openssl.c |  3 ---
>>  src/openvpn/ssl_openssl.h | 11
>> ---
>>  src/openvpn/ssl_verify_openssl.c  |  6
>> ++
>>  7 files changed, 7 insertions(+), 26 deletions(-)
>>
>> diff --git a/configure.ac b/configure.ac
>> index 2406ad8..acea060 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -859,9 +859,9 @@ if test "${enable_crypto}" = "yes" -a
>> "${with_crypto_library}" = "openssl"; then
>>  # if the user did not explicitly specify flags, try to 
>> autodetect
>>  PKG_CHECK_MODULES(
>>  [OPENSSL],
>> -[libcrypto >= 0.9.8, libssl >= 0.9.8],
>> -[have_openssl="yes"],
>> -[have_openssl="no"] # Provide if-not-found to prevent 
>> erroring out
>> +[libcrypto >= 1.0.1, libssl >= 1.0.1],
>> +[have_openssl="yes"],
>> +[AC_MSG_ERROR([Minimum supported OpenSSL version is 
>> 1.0.1])]
>>  )
>>
>>  OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
>> diff --git a/doc/openvpn.8 b/doc/openvpn.8
>> index a9f5db7..c3248fd 100644
>> --- a/doc/openvpn.8
>> +++ b/doc/openvpn.8
>> @@ -2773,7 +2773,6 @@ OPENVPN_PLUGIN_TLS_FINAL callback.
>>  Note that exporter labels have the potential to collide with existing
>> PRF
>>  labels. In order to prevent this, labels MUST begin with "EXPORTER".
>>
>> -This option requires OpenSSL 1.0.1 or newer.
>>  .\"*
>>  .SS Server Mode
>>  Starting with OpenVPN 2.0, a multi-client TCP/UDP server mode
>> diff --git
>> a/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
>> b/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
>> index 177977d..a72b374 100644
>> ---
>> a/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
>> +++
>> b/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
>> @@ -143,8 +143,7 @@ session_user_set(struct session *sess, X509 *x509)
>>  {
>>  continue;
>>  }
>> -/* bug in OpenSSL 0.9.6b ASN1_STRING_to_UTF8 requires this
>> workaround */
>> -unsigned char *buf = (unsigned char *)1;
>> +unsigned char *buf = NULL;
>>  if (ASN1_STRING_to_UTF8(, val) <= 0)
>>  {
>>  continue;
>> diff --git a/sample/sample-plugins/log/log_v3.c
>> b/sample/sample-plugins/log/log_v3.c
>> index 9037225..d3014f3 100644
>> --- a/sample/sample-plugins/log/log_v3.c
>> +++ b/sample/sample-plugins/log/log_v3.c
>> @@ -197,7 +197,7 @@ x509_print_info(X509 *x509crt)
>>  X509_NAME *x509_name;
>>  X509_NAME_ENTRY *ent;
>>  const char *objbuf;
>> -unsigned char *buf;
>> +unsigned char *buf = NULL;
>>
>>  x509_name = X509_get_subject_name(x509crt);
>>  n = X509_NAME_entry_count(x509_name);
>> @@ -228,7 +228,6 @@ x509_print_info(X509 *x509crt)
>>  {
>>  continue;
>>  }
>> -buf = (unsigned char *)1; /* bug in OpenSSL 0.9.6b
>> ASN1_STRING_to_UTF8 requires this workaround */
>>  if (ASN1_STRING_to_UTF8(, val) <= 0)
>>  {
>>  continue;
>> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
>> index d7cc2ba..645ccf5 100644
>> --- a/src/openvpn/ssl_openssl.c
>> +++ b/src/openvpn/ssl_openssl.c
>> @@ -254,10 +254,7 @@ tls_ctx_set_options(struct tls_root_ctx *ctx,
>> unsigned int ssl_flags)
>>  sslopt |= SSL_OP_NO_TLSv1_2;
>>  }
>>  #endif
>> -#ifdef SSL_OP_NO_COMPRESSION
>> -/* Disable compression - flag not available in OpenSSL 0.9.8 */
>>  sslopt |= SSL_OP_NO_COMPRESSION;
>> -#endif
>>  SSL_CTX_set_options(ctx->ctx, sslopt);
>>  }
>>
>> diff --git a/src/openvpn/ssl_openssl.h b/src/openvpn/ssl_openssl.h
>> index 6ca4cb6..60a1f5e 100644
>> --- a/src/openvpn/ssl_openssl.h
>> +++ b/src/openvpn/ssl_openssl.h
>> @@ -33,17 +33,6 @@
>>  #include 
>>
>>  /**
>> - * SSL_OP_NO_TICKET tells OpenSSL to disable "stateless session

Re: [Openvpn-devel] [PATCH] Make --cipher/--auth none more explicit on the risks

[Simon Matter]

> The warning provided to --cipher and --auth using the 'none' setting may
> not have been too clearly understandable to non-developers or people not
> fully understanding encryption and cryptography.  This tries to improve
> that.
>
> While at it, also break up the long source lines.
>
> Signed-off-by: David Sommerseth 
> ---
>  src/openvpn/crypto.c | 11 +--
>  src/openvpn/init.c   |  5 -
>  2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 909f725..8a5c723 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -784,7 +784,10 @@ init_key_type(struct key_type *kt, const char
> *ciphername,
>  {
>  if (warn)
>  {
> -msg(M_WARN, "*** WARNING ***: null cipher specified,
> no encryption will be used");
> +msg(M_WARN, "*** WARNING ***: '--cipher none' was
> specified. "
> +"This means NO encryption will be performed and tunnelled
> "
> +"data WILL be transmitted in clear text over the network!
> "
> +"PLEASE DO RECONIDER THIS SETTING!");

Hi

Small typos, you may want to 's/RECONIDER/RECONSIDER/g' the patches.

Regards,
Simon



--
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 v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

>
>
> On 06/04/17 12:52, Steffan Karger wrote:
>> Hi,
>>
>> On 6 April 2017 at 12:26, David Sommerseth
>> <open...@sf.lists.topphemmelig.net> wrote:
>>> On 06/04/17 11:45, Simon Matter wrote:
>>>>
>>>>> I like Arne's and David's suggestion - the existing option "as is"
>>>>> will
>>>>> enable X% jitter, while a second parameter can specify a more
>>>>> specific
>>>>> range.  Following Arne's argument about users and percent math, it
>>>>> might
>>>>> indeed be better to have "min max" here ("3500 3600"), because that
>>>>> is
>>>>> really easy to understand and explain.
>>>>
>>>> After all the discussion I prefer the simple solution. I've changed my
>>>> systems to the reduced 10% jitter and I'm wondering if it has to be
>>>> made
>>>> more complicated than this? I works very well and after some hours the
>>>> renegs have spread very well. If you ask me it's perfectly fine that
>>>> way
>>>> as long as the docs clearly state that a pseudo random 10% us deducted
>>>> from reneg-sec automatically to spread renegs.
>>>
>>> It must be configurable, based on many years experience with helping
>>> out
>>> on configuring OpenVPN tunnels.  There are millions of OpenVPN
>>> configurations out in the world (and I don't even think I'm
>>> exaggerating
>>> that much even), many small ones and quite some large ones.  There are
>>> VPN service providers with several hundred thousands paying customers,
>>> and there are an enormous amount of VPN service providers in addition.
>>> In addition to all the private and corporate deployments.
>>>
>>> So enforcing a good feature equally on all these configurations will
>>> backfire at us.
>>>
>>> And the more I think about the 10% randomness vlaue (or any
>>> percentage),
>>> I really wonder how clever that is.  If a site uses --reneg-sec 1800 (I
>>> have seen that), that means a 3 minute window.  If a site uses 14400 (4
>>> hours, I've seen that too), that gives a 24 minute window.  These
>>> window
>>> sizes may be perfectly fine.  But depending on the amount of connected
>>> users, this may be troublesome too.
>>>
>>> Last night I chatted with krzee on #openvpn-devel about this.  He does
>>> quite some cool stuff with OpenVPN and have lots of IP phones
>>> connecting
>>> to VPN servers.  He said that randomness by default may not be ideal
>>> for
>>> some of the setups he manages.   But he loves the idea behind this
>>> feature.
>>>
>>> Krzee argued that configurations explicitly setting --reneg-sec 3600
>>> should not have any randomness.  If a configuration does _not* set
>>> --reneg-sec, it may have randomness with 1 hour as the base.  And those
>>> wanting better control of the time window should use:
>>>   --reneg-sec min max
>>>
>>> I initially was of the opinion --reneg-sec 3600 should have randomness
>>> (the 10-17% base).  But after having slept on it, I think Krzee have a
>>> good point.  Setting --reneg-sec explicitly with only a single value
>>> should not have any randomness.
>>>
>>> With the 1 hour default, not setting --reneg-sec gives a time window of
>>> 6 minutes with 10%.  That is a reasonable default unless explicitly
>>> overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec
>>> 3000 4000 (with a 1000 seconds large time window)
>>
>> Wow, this discussion suddenly caught some attention!  I'll chip in too.
>>
>> I was fine with not making this configurable, but the discussion
>> convinced me that people really want to be able to configure this, so
>> I agree we should.
>>
>> As for the option, I think Arne's proposal is the best:
>>   --reneg-sec max [min]
>> where  == --reneg-sec 3600 == --reneg-sec 3600 3240 (assuming
>> 10% default randomization)
>
> The Initial proposal was --reneg-sec [min] max (horrible)
>
>>
>> Why? Because this
>> 1) doesn't change the meaning of the first argument based on whether
>> the second is present.  That's just confusing.
>> 2) does by default what we expect is best for most users: randomize
>> the reneg-sec value
>> 3) still allows administrators to disable randomization
>> 4) 'max' and 'min' are hard to misinterpret ('window', 'jitter' or
>>

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> Web servers these days are also multi-threaded (or "multi-forked"), so
> they can utilize multiple cores more efficiently.  OpenVPN is *single
> threaded*.  So when one client starts a TLS renegotiation, it blocks all
> the other connected clients until the renegotiation have completed.
> When you then have 100 connected clients spending 1-2 seconds on each
> renegotiation happening at the same time, you will have 100-200 seconds
> of slow and lagging VPN tunnel.  This does not mean that you will see a
> CPU spike, as each client is handled serialized (one by one) - not in
> parallel.

That's only true for single instance servers, with multiple OpenVPN
instances and limited CPU cores this quickly becomes an issue.

Simon


--
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 v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> Hi,
>
> On Wed, Apr 05, 2017 at 07:00:54PM +0100, debbie10t wrote:
>> > Optional option does not mean that it is disabled by default. If you
>> > don't the randomness you would need to do:
>> >
>> > reneg-sec 3600 3600
>> >
>> > the optional argument also allows it to fine tune it to your needs.
>>
>> As the reason for --reneg-sec is to specify how long a key should exist,
>> I don't see any further need to make the "random window" be specifically
>> configurable .. The reneg-sec period will remain as specified (def 3600)
>> except for the first run, where --reneg-sec is started from a random
>> time between now and then.  There after returning to "normal" with full
>> randomisation of all connected clients --reneg-sec being spread over the
>> *entire* period of --reneg-sec nn and not some unnecessary window.
>
> Setups with 2FA will have to re-enter auth credentials on reneg.  Having
> OpenVPN all of a sudden default to "it could be asking 5 minutes after
> connection for the credentials again" is massive annoyance - and brings
> no real benefit anyway.
>
> It makes sense to jitter reneg-sec somewhat (like, 10%-ish), but changing
> behaviour too much is not bringing much benefit - you don't need to
> spread the reneg over the whole period anyway, as different clients
> connect and disconnect at different times anyway.  Just if all of them
> connect at the same time, the identically-timed renegs are a problem.

That's exactly what happens in the event of an OpenVPN restart on the
central server. Our router clients may all restart for updates at the same
time and our desktop clients are automatically started in the morning most
of them at the same time.

> I like Arne's and David's suggestion - the existing option "as is" will
> enable X% jitter, while a second parameter can specify a more specific
> range.  Following Arne's argument about users and percent math, it might
> indeed be better to have "min max" here ("3500 3600"), because that is
> really easy to understand and explain.

After all the discussion I prefer the simple solution. I've changed my
systems to the reduced 10% jitter and I'm wondering if it has to be made
more complicated than this? I works very well and after some hours the
renegs have spread very well. If you ask me it's perfectly fine that way
as long as the docs clearly state that a pseudo random 10% us deducted
from reneg-sec automatically to spread renegs.

Simon


--
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 v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

>
>
> On 05/04/17 17:13, debbie10t wrote:
>>
>>
>> On 05/04/17 16:58, David Sommerseth wrote:
>>> On 05/04/17 17:53, David Sommerseth wrote:
 On 05/04/17 16:42, debbie10t wrote:
>
>>
>
> A different approach could be like so:
>
> --reneg-sec 3600
> --reneg-sec-1sttime-rand 1|0 (The name here for detail)

>>
>>>
>>> Oh, and in regards to the first-time/non-first-time  if we decide
>>> for such flexibility, that can be a flag after the randomness.
>>>
>>> For example  --reneg-sec 3600 12 first-only
>>>
>>> I am far from convinced if that should be configurable or not.  But
>>> still, this approach is still far better than introducing new options.
>>>
>>
>> Ok - accept that new options is not preferred but ..
>>
>> I like the idea of "first-only" addition (which is more or less as I
>> proposed anyway) - And so, instead of having randomness in the reneg-sec
>> itself, it is only randomness in the first run, after that the expected
>> behaviour would be restored.  eg: --reneg-sec 3600
>>
>> To my mind (as a non programmer) this essentially boils down to
>> setting the first --reneg-sec timer to something between 1 and
>> 3600 (default). This affords a much larger window for the scattering
>> of clients and further behaviour is "as expected now".
>>
>> and it looks very non-instrusive to me ..
>>
>
> To clarify:  --reneg-sec 3600 RAND
>
> Where RAND indicates that the first-run timer should run from a random
> integer from 1 upto the value of --reneg-sec.  RAND does not require a
> user to specify an amount.

But then, why not just do it always and forget about the additional option?

Simon


--
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 v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> On 05/04/17 09:31, Steffan Karger wrote:
>> Hi,
>>
>> On 05-04-17 08:57, Gert Doering wrote:
>>> On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote:
>>>> I've attached v2 now which works without any config change:
>>> [..]
>>>> I prefer this version as it allows everybody to profit from it without
>>>> touching any config files.
>>>
>>> I can see the reasoning, but 25% feels a bit on the high side :-) - so
>>> let the ratholing begin what the number should be.
>>>
>>> Steffan, any views from the crypto side of things?
>>
>> Not really.  I think the feature makes sense, and I like that this will
>> only *substract* from the set time (so not exceed any set limits).
>>
>> (And I agree that 25% feels on the high side - my gut says somewhere
>> around 10%, but I have no analysis to show why that would be better.
>> I'll leave picking that number to you.)
>
> The default is 60 minutes.  With 25% that means a time window of 15
> minutes, so reneg-sec will occur between 45-60 minutes.
>
> I see this can be too much for some sites, and perhaps too little on
> sites which have many users.   With 10%, the reneg-window is reduced to
> 54-60 minutes.  For larger sites, this is most likely too small of a
> window - though far better than everyone at "exactly" 60 minutes.
>
> But I am also wondering if this randomness should only occur on the
> first renegotiation.
>
> If you have a 6 minutes time window and 100 connected clients, there is
> a big chance that at some point the randomness will cause a similar
> congestion again, as multiple clients to have the same delay.  With 25%
> that chance is lower, but the chance increases again with more clients.
>
> So what if this randomness instead only occurs on the _first_
> negotiation and then respect the --regneg-sec setting?  Then clients
> will somewhat spread out and then keep a certain predictable
> renegotiation load.  And if using 17%, you get a time window of roughly
> 10-11 minutes where renegotiation happens.  With 100 clients, that means
> roughly (with a theoretical, ideal and even spread) 10 clients per
> minute.  Which is more reasonable.  With 200 clients, it is still
> getting crowded but not too bad.
>
> But all that said ... I think it would be wise to have an optional
> argument to --reneg-sec (in addition to the 'sec' argument we have
> today) which can be used to further open or close this time window.
> Larger sites will most likely want a larger time window than smaller ones.
>
> Btw ... is --reneg-sec pushable?  (Too lazy to check the code, man page
> says "no").  If not, it would probably be a good idea to enable that.

As I understand it client and server have 60 min. by default. Whatever is
configured, the smaller value wins. That means, bad clients can set their
reneg-sec to very low values and trash the server on the other end. From
the server side this looks more or less like a DDOS.

In our environment we have set reneg-sec=0 on all clients because we want
the server to have control over it. That's fine because we have only
trusted clients. Making it pushable could be a solution to overwrite bad
settings in clients. A more radical solution was to just remove the option
on the client side.

Regards,
Simon


--
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 v2] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

>> Hi,
>>
>> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>>> Interesting to see that there is zero interest in this patch here.
>>
>> This is a misinterpretation.
>>
>
> Hi Gert,
>
> Thanks for the explanation, I'll be patient then :)
>
> If it's preferred for the patch to keep it even simpler and compatible the
> current configs, it could be broken down to something like this in init.c:

I've attached v2 now which works without any config change:

--reneg-sec n
Renegotiate data channel key after n seconds (default=3600).

Note that the effective value used here is a per session pseudo-
randomized 25% of n deducted from n.  With the default value  of
3600 this results in an effective per session value in the range
of 2701 ... 3600 seconds.


I prefer this version as it allows everybody to profit from it without
touching any config files.

Thanks,
Simon

openvpn-2.4.1-reneg-sec_randomize.patch
Description: Binary data
--
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] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> Hi,
>
> On Tue, Apr 04, 2017 at 08:29:49AM +0200, Simon Matter wrote:
>> Interesting to see that there is zero interest in this patch here.
>
> This is a misinterpretation.
>

Hi Gert,

Thanks for the explanation, I'll be patient then :)

If it's preferred for the patch to keep it even simpler and compatible the
current configs, it could be broken down to something like this in init.c:

#define RENEG_RND_PCT 25

to.renegotiate_seconds = max_int((int)options->renegotiate_seconds -
(get_random() % (options->renegotiate_seconds / (100 / RENEG_RND_PCT))),
1);


With the default config this should result in reneg times in the range of
2700 ... 3600 seconds.

Thanks,
Simon


--
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] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

Hi,

>> Hi,
>>
>> Initially I've created this RFE but have been told to send it to
>> the devel list instead:
>>
>> https://community.openvpn.net/openvpn/ticket/865
>>
>> Unfortunately I'm not a developer and have never used git so please bear
>> with me as I send a classic patch to the list.
>>
>> As suggested by user "syzzer" I also tried to improve the patch and here
>> it is:
>>
>> ---%<---
>> While we were suffering from the "TLS Renegotiation Slowdown" bug here
>> https://community.openvpn.net/openvpn/ticket/854 we realized that there
>> is
>> still room for improvement in our use case.
>>
>> It appears that TLS renegotiation is getting more and more expensive in
>> terms of CPU cycles with recent changes for more security. To make
>> things
>> worse, we realized that most renegotiation procedures took place at
>> almost
>> the same time and increased the CPU load too much during these periods.
>> That's especially true on large, multi-instance openvpn setups.
>>
>> I've created attached patch to add a per session pseudo-random component
>> to
>> the --reneg-sec intervals so that renegotiation is evenly spread over
>> time.
>> It is configured by simply adding a second value to --reneg-sec as
>> described
>> in the --help text:
>>
>> --reneg-sec n [r] : Renegotiate data chan. key after n seconds
>> default=3600)
>> and if r is specified, add a per session
>> pseudo-random
>> component in the range of 1 ... r to n (default=0).
>>
>> Note that the patch also slightly changes the log output to show the sec
>> value
>> in the same way as the bytes/pkts values:
>>
>> TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0
>> ---%<---
>>
>>
>> The patch is tested and seems to work well in my environment. As always,
>> comments are very welcome.
>>
>> Would be nice to have this patch accepted and included in OpenVPN 2.4.2.
>
> Any comments on this patch? Would be nice to get some feedback :)
>
> Simon

Interesting to see that there is zero interest in this patch here.

I'm very sure a lot of people are suffering this issue without knowing it.
On heavy loaded multi instance servers OpenVPN tends to lose packets every
hour (with default reneg-sec settings).

That's only in a short period of time but still very annoying for things
like VoIP over the VPN links.

We only found this out after the problem became worse with the bug
mentioned above introduced in OpenVPN 2.4.0. The problem has always been
there but we only became aware of it with the 2.4.0 release.

I guess I'll change the patch then to work without any changes to the
config. That way our binary builds are still compatible with the upstream
version but still improve the issue mentioned above.

For those interested to see how the problem shows up, try this:

Run "prettyping -i 0.1 " to different locations in different
terminals and let it run for a longer time. You will easily see the hourly
packet losses in the patterns. Prettyping is here
https://raw.githubusercontent.com/denilsonsa/prettyping/master/prettyping

Regards,
Simon


--
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] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

> Hi,
>
> Initially I've created this RFE but have been told to send it to
> the devel list instead:
>
> https://community.openvpn.net/openvpn/ticket/865
>
> Unfortunately I'm not a developer and have never used git so please bear
> with me as I send a classic patch to the list.
>
> As suggested by user "syzzer" I also tried to improve the patch and here
> it is:
>
> ---%<---
> While we were suffering from the "TLS Renegotiation Slowdown" bug here
> https://community.openvpn.net/openvpn/ticket/854 we realized that there is
> still room for improvement in our use case.
>
> It appears that TLS renegotiation is getting more and more expensive in
> terms of CPU cycles with recent changes for more security. To make things
> worse, we realized that most renegotiation procedures took place at almost
> the same time and increased the CPU load too much during these periods.
> That's especially true on large, multi-instance openvpn setups.
>
> I've created attached patch to add a per session pseudo-random component
> to
> the --reneg-sec intervals so that renegotiation is evenly spread over
> time.
> It is configured by simply adding a second value to --reneg-sec as
> described
> in the --help text:
>
> --reneg-sec n [r] : Renegotiate data chan. key after n seconds
> default=3600)
> and if r is specified, add a per session pseudo-random
> component in the range of 1 ... r to n (default=0).
>
> Note that the patch also slightly changes the log output to show the sec
> value
> in the same way as the bytes/pkts values:
>
> TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0
> ---%<---
>
>
> The patch is tested and seems to work well in my environment. As always,
> comments are very welcome.
>
> Would be nice to have this patch accepted and included in OpenVPN 2.4.2.

Any comments on this patch? Would be nice to get some feedback :)

Simon


--
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] Add per session pseudo-random component to --reneg-sec intervals

[Simon Matter]

Hi,

Initially I've created this RFE but have been told to send it to
the devel list instead:

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

Unfortunately I'm not a developer and have never used git so please bear
with me as I send a classic patch to the list.

As suggested by user "syzzer" I also tried to improve the patch and here
it is:

---%<---
While we were suffering from the "TLS Renegotiation Slowdown" bug here
https://community.openvpn.net/openvpn/ticket/854 we realized that there is
still room for improvement in our use case.

It appears that TLS renegotiation is getting more and more expensive in
terms of CPU cycles with recent changes for more security. To make things
worse, we realized that most renegotiation procedures took place at almost
the same time and increased the CPU load too much during these periods.
That's especially true on large, multi-instance openvpn setups.

I've created attached patch to add a per session pseudo-random component to
the --reneg-sec intervals so that renegotiation is evenly spread over time.
It is configured by simply adding a second value to --reneg-sec as described
in the --help text:

--reneg-sec n [r] : Renegotiate data chan. key after n seconds default=3600)
and if r is specified, add a per session pseudo-random
component in the range of 1 ... r to n (default=0).

Note that the patch also slightly changes the log output to show the sec
value
in the same way as the bytes/pkts values:

TLS: soft reset sec=3084/3084 bytes=279897/-1 pkts=1370/0
---%<---


The patch is tested and seems to work well in my environment. As always,
comments are very welcome.

Would be nice to have this patch accepted and included in OpenVPN 2.4.2.

Regards,
Simon

openvpn-2.4.1-reneg-sec_random.patch
Description: Binary data
--
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