Re: [Openvpn-devel] [PATCH] Increase TLS Control Channel Buffer Size

[Ning Wei via Openvpn-devel]

 Both of key_method_2_write and key_method_2_read take TLS_Channel_Bug_Size as 
buffer size.  The current size, 2048 is not enough to read/write a long 
password response.  I have notice the management interface has a much smaller 
than 2048 buffer size to read/write.  Currently, if the management interface is 
not used, increasing tls channel buffer size will serve the need.
As token provider, the size of token can be bigger or smaller.  Sometime, it 
has more than 1600 as a token.  To accommodate that, a bigger buffer size will 
be needed.
ThanksNing
On Monday, March 19, 2018, 10:11:25 PM PDT, Selva Nair 
 wrote:  
 
 Hi,

On Mon, Mar 19, 2018 at 5:00 PM, Ning Wei  wrote:
> Sorry, I did not state the intent clearly in the request.
>
> We wanted to use password field to pass authentication string, such as Token
> string,
> which can be long, the user auth plug in on the sever side can validate the
> token as
> the part authentication step.
>
> Acquiring a token, such as JWT, usually involves user interaction with the
> token broker
> service provider.  So it is better to do this on the client side.

Its hard for me to imagine what authentication would need to pass more
than ~1600 bytes  (that's about the current limit based on the 2048
byte buffer).
Unless you are trying to fit in data unrelated to auth in the token. The U2F
registration case I mentioned earlier would be such an example.

How large is the data you need to transfer? If its not purely
authentication data
(i.e., a challenge string + signature at most), sending it as password is not
the right approach. If there is extra text included for convenience,
pre-compressing
may help.

How do you plan to pass the "password" to openvpn client -- from stdin? The
management i/f will not let you pass such a long password or username.

>
> I agreed on the following statement.  To support a long password field in
> TLS channels,
> the Buf size of 4096 is not enough in key_method_2_write.  Should we propose
> to
> increase the buffer size further?

Increasing to 4096 looks marginally useful to me and will fit a reasonably sized
user name (say < 128 bytes) and a largish challenge-response (upto ~3400 bytes)
leaving space for other things. Beyond that is unlikely to be necessary.

I mentioned the overhead in key_method_2_write only because your logic
behind this increase didn't make sense to me.

>
> "Further, even a TLS_CHANNEL_BUF_SIZE of 4096 does not support a
> password that long as there are other things like username, key-source,
> local-options that have to fit into the buffer (see key_method_2_write). So
> what's the logic behind 4096?"
>
> Regards,
> Ning
> On Friday, March 16, 2018, 10:30:45 AM PDT, Selva Nair
>  wrote:
>
>
> Hi,
>
> Apologies in advance if I'm misreading the intent of this patch.
>
> On Fri, Mar 16, 2018 at 12:40 PM, Ning Wei via Openvpn-devel
>  wrote:
>> Increase TLS_CHANNEL_BUF_SIZE to 4096. When the build is enabled with
>> ENABLE_PKCS11, the password field can be 4096.  The old size of
>> TLS_CHANNEL_BUF_SIZE was 2048, which is not enough.
>
> I do not follow the logic behind this. Sure, ENABLE_PKCS11 increases the
> password buffer size to 4096, but pkcs11 password is only consumed
> locally, not sent out to the remote.
>
> Now, even if a auth-user-pass password or challenge response gets as
> large as 4096 bytes, there are other places in the code that
> need "fixing" to permit such long "passwords" (or response) -- e.g., it
> cannot
> be submitted via the management as the parser expects a max line
> length of 255 and word length of 255.
>
> Further, even a TLS_CHANNEL_BUF_SIZE of 4096 does not support a
> password that long as there are other things like username, key-source,
> local-options that have to fit into the buffer (see key_method_2_write). So
> what's the logic behind 4096?
>
> Finally, are there any particular challenge-response framework that requires
> such long responses? Even for U2F, we wouldn't need to send a response
> that large. U2F registration response could get very long (still mostly
> under
> 2000 bytes), but doing U2F key registration via the authentication channel
> is
> not a good implementation. Authentication responses are much smaller.
>
> In short, it looks premature to increase this value before we start
> supporting long responses via the management, and a real practical
> need for long challenge response strings that won't fit in the current
> 2048 bytes (minus overhead) arise.
>
> Selva

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

Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[fragmentux]

I am not convinced 'iperf -r' is reliable (bold claim maybe .. )

iperf3 have dropped -r in favour of -R "reverse mode"
server sends and client receives. but not both on the same run ..

After numerous hangs and some bazaar results with iperf2
i opted to upgrade to iperf3 .. still some slightly odd results
but no hangs so far ..

regards


--
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, 21st Mar 2018)

[fragmentux]

On 22/03/18 19:33, Jan Just Keijser wrote:

Hi Selva,

On 22/03/18 18:12, Selva Nair wrote:
On Thu, Mar 22, 2018 at 12:16 PM, Jan Just Keijser  
wrote:

Hi Eric, all,

On 22/03/18 04:25, Eric Thorpe wrote:

Hi All,

One of the Viscosity developers here. The TAP driver used by 
Viscosity is

based on the OpenVPN TAP-Windows driver. We're surprised to hear of any
performance differences, as the changes we've made are very minimal.

Besides a name and version number change, the only other modification 
is a
change to the reported network adapter speed, which has Windows 
report the

driver as 1000 Mbit instead of 100 Mbit.

This change was made not because of any actual performance gains, but
because of user reports that certain firewall or AV software tries to 
QoS

the adapter based on its reported adapter speed, which is of course a
problem if the VPN connection is capable of more than 100 Mbit.

Please find a patch file of the changes attached.


first of all, thanks for responding so quickly.
I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 
based)

compared to OpenVPN 2.4.5 and I am seeing a performance difference in a
gigabit test setup.  Strangely enough, it turns out that it's the 
*absence

of* AES256-GCM that makes my Viscosity client faster.
My test setup is as follows:

- server: CentOS 7, openvpn 2.4.4, gigabit ethernet
- client: Win7 Pro, gigabit ethernet:

Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):

viscosity:
380 Mbps +/- 10 Mbps to server
100 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
377 Mbps +/- 10 Mbps to server
   99 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5 (aes256-gcm)
  240 Mbps +/- 8 Mbps to server
   55 Mbps +/- 5 Mpbs from server

So strangely enough it seems that AES-256-GCM is **slower** for Windows
clients. Note that in this setup the server config never changed.

I haven't tested openvpn itself but have noticed in openssl speed
tests that AES-256-CBC is significantly faster than AES-256-GCM on
Windows (opposite to Linux). That was with openssl 1.0.x, probably
1.1.0 is similar (2.4.5 Windows release is built with 1.1.0).

However, the raw cipher speeds are much larger than these throughputs
so its surprising that the change of cipher alone makes such a
difference.

Why is the throughput so asymmetric?


thanks for the confirmation; as for the assymmetry: that can be due to 
many factors, including hardware differences (there is asymmetry on 
Linux as well). It could also be due to the way the tap driver works, 
but I have never been able to get my finger on that , and I don't use 
Windows often enough to bother.





Thought I would have a look at this and I do not find this asymmetry ..


vpn & iperf server = Linux debian 8
iperf version 2.0.5 (08 Jul 2010) pthreads

Mon Mar 26 12:39:03 2018 us=287116 OpenVPN 2.5_git+ipv6pf 
[git:master/902c1f1c71ac+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan  1 2018
Mon Mar 26 12:39:03 2018 us=287135 library versions: OpenSSL 1.0.1t  3 
May 2016, LZO 2.08



vpn & iperf client (1) = Windows 10
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:25:46 2018 us=107859 OpenVPN 2.4.5 
[git:2.4/161afbebdc2b7e24+] x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] 
[LZ4] [PKCS11] [AEAD] built on Mar  1 2018


Mon Mar 26 21:25:46 2018 us=107859 Windows version 6.2 (Windows 8 or 
greater) 64bit


Mon Mar 26 21:25:46 2018 us=107859 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10



vpn & iperf client (2) = Linux Arch
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:36:17 2018 us=258243 OpenVPN 2.4.4 
x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] 
[MH/PKTINFO] [AEAD] built on Sep 26 2017
Mon Mar 26 21:36:17 2018 us=258256 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10





*** Output from server iperf:


client: iperf -c 10.56.101.238 -r -l 4M -t 30

* Linux server (vpn and iperf) -- AES-256-CBC **

iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)



* Windows client (vpn and iperf)

[  4] local 10.56.101.238 port 5001 connected with 10.56.101.110 port 51370
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-30.1 sec   480 MBytes   134 Mbits/sec

Client connecting to 10.56.101.110, TCP port 5001
TCP window size:  416 KByte (WARNING: requested  867 MByte)

[  4] local 10.56.101.238 port 48867 connected with 10.56.101.110 port 5001
[  4]  0.0-30.3 sec   568 MBytes   157 Mbits/sec


iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)

Re: [Openvpn-devel] Summary of the community meeting (Wed, 21st Mar 2018)

[fragmentux]

On 26/03/18 22:21, fragmentux wrote:



On 22/03/18 19:33, Jan Just Keijser wrote:

Hi Selva,

On 22/03/18 18:12, Selva Nair wrote:
On Thu, Mar 22, 2018 at 12:16 PM, Jan Just Keijser 
 wrote:

Hi Eric, all,

On 22/03/18 04:25, Eric Thorpe wrote:

Hi All,

One of the Viscosity developers here. The TAP driver used by 
Viscosity is

based on the OpenVPN TAP-Windows driver. We're surprised to hear of any
performance differences, as the changes we've made are very minimal.

Besides a name and version number change, the only other 
modification is a
change to the reported network adapter speed, which has Windows 
report the

driver as 1000 Mbit instead of 100 Mbit.

This change was made not because of any actual performance gains, but
because of user reports that certain firewall or AV software tries 
to QoS

the adapter based on its reported adapter speed, which is of course a
problem if the VPN connection is capable of more than 100 Mbit.

Please find a patch file of the changes attached.


first of all, thanks for responding so quickly.
I've done some further testing with Viscosity 1.6.8 (openvpn 2.3.14 
based)

compared to OpenVPN 2.4.5 and I am seeing a performance difference in a
gigabit test setup.  Strangely enough, it turns out that it's the 
*absence

of* AES256-GCM that makes my Viscosity client faster.
My test setup is as follows:

- server: CentOS 7, openvpn 2.4.4, gigabit ethernet
- client: Win7 Pro, gigabit ethernet:

Speeds (using "iperf -s" and "iperf -c 10.200.0.1 -r -l 4M -t 30"):

viscosity:
380 Mbps +/- 10 Mbps to server
100 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5  --ncp-disable --cipher aes-256-cbc --auth sha256
377 Mbps +/- 10 Mbps to server
   99 Mbps +/- 5 Mpbs from server

Openvpn 2.4.5 (aes256-gcm)
  240 Mbps +/- 8 Mbps to server
   55 Mbps +/- 5 Mpbs from server

So strangely enough it seems that AES-256-GCM is **slower** for Windows
clients. Note that in this setup the server config never changed.

I haven't tested openvpn itself but have noticed in openssl speed
tests that AES-256-CBC is significantly faster than AES-256-GCM on
Windows (opposite to Linux). That was with openssl 1.0.x, probably
1.1.0 is similar (2.4.5 Windows release is built with 1.1.0).

However, the raw cipher speeds are much larger than these throughputs
so its surprising that the change of cipher alone makes such a
difference.

Why is the throughput so asymmetric?


thanks for the confirmation; as for the assymmetry: that can be due to 
many factors, including hardware differences (there is asymmetry on 
Linux as well). It could also be due to the way the tap driver works, 
but I have never been able to get my finger on that , and I don't use 
Windows often enough to bother.





Thought I would have a look at this and I do not find this asymmetry ..


vpn & iperf server = Linux debian 8
iperf version 2.0.5 (08 Jul 2010) pthreads

Mon Mar 26 12:39:03 2018 us=287116 OpenVPN 2.5_git+ipv6pf 
[git:master/902c1f1c71ac+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan  1 2018
Mon Mar 26 12:39:03 2018 us=287135 library versions: OpenSSL 1.0.1t  3 
May 2016, LZO 2.08



vpn & iperf client (1) = Windows 10
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:25:46 2018 us=107859 OpenVPN 2.4.5 
[git:2.4/161afbebdc2b7e24+] x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] 
[LZ4] [PKCS11] [AEAD] built on Mar  1 2018


Mon Mar 26 21:25:46 2018 us=107859 Windows version 6.2 (Windows 8 or 
greater) 64bit


Mon Mar 26 21:25:46 2018 us=107859 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10



vpn & iperf client (2) = Linux Arch
iperf version 2.0.10 (11 Aug 2017) pthreads

Mon Mar 26 21:36:17 2018 us=258243 OpenVPN 2.4.4 
x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] 
[MH/PKTINFO] [AEAD] built on Sep 26 2017
Mon Mar 26 21:36:17 2018 us=258256 library versions: OpenSSL 1.1.0g  2 
Nov 2017, LZO 2.10





*** Output from server iperf:


client: iperf -c 10.56.101.238 -r -l 4M -t 30

* Linux server (vpn and iperf) -- AES-256-CBC **

iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)



* Windows client (vpn and iperf)

[  4] local 10.56.101.238 port 5001 connected with 10.56.101.110 port 51370
[ ID] Interval   Transfer Bandwidth
[  4]  0.0-30.1 sec   480 MBytes   134 Mbits/sec

Client connecting to 10.56.101.110, TCP port 5001
TCP window size:  416 KByte (WARNING: requested  867 MByte)

[  4] local 10.56.101.238 port 48867 connected with 10.56.101.110 port 5001
[  4]  0.0-30.3 sec   568 MBytes   157 Mbits/sec


iperf -s

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)