Re: [Openvpn-users] "PID_ERR large diff" messages

[Steffan Karger]

Hi.

On 16-03-2021 11:44, Ralf Hildebrandt wrote:
> I noticed these in my logcheck output. Should I wory?
> 
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [66] [SSL-0] 
> [____0___] 0:627607 
> 0:627541 t=1615815597[0] r=[-2,64,15,66,1] sl=[41,64,64,528]
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [70] [SSL-0] 
> [0____0__] 0:627612 
> 0:627542 t=1615815597[0] r=[-2,64,15,70,1] sl=[36,64,64,528]
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [92] [SSL-0] 
> [00_0____] 0:627635 
> 0:627543 t=1615815597[0] r=[-2,64,15,92,1] sl=[13,64,64,528]
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [92] [SSL-0] 
> [000_0___] 0:627636 
> 0:627544 t=1615815597[0] r=[-2,64,15,92,1] sl=[12,64,64,528]
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [92] [SSL-0] 
> [_0______] 0:627637 
> 0:627545 t=1615815597[0] r=[-2,64,15,92,1] sl=[11,64,64,528]
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [92] [SSL-0] 
> [0_0_____] 0:627638 
> 0:627546 t=1615815597[0] r=[-2,64,15,92,1] sl=[10,64,64,528]
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [92] [SSL-0] 
> [00_0____] 0:627639 
> 0:627547 t=1615815597[0] r=[-2,64,15,92,1] sl=[9,64,64,528]
> Mar 15 14:39:57 openvpn-igel-int ovpn-server-udp[1089]: 
> ITC00E0C5247DB8/84.130.190.9:55871 PID_ERR large diff [92] [SSL-0] 
> [000_0___] 0:627640 
> 0:627548 t=1615815597[0] r=[-2,64,15,92,1] sl=[8,64,64,528]

Not unless you see them a lot. This just means that some old (reordered)
packets are dropped by openvpn because replay protection checks can no
longer guarantee that this is not a replayed packet. So it *might* be an
availability issue, but won't affect connection security.

If you see these a lot, it might be worth checking the network between
client and server to see why this packet reordering happens.

Otherwise just reduce the log level to 3, which is a very reasonable
setting for production servers and will no longer show these warnings.

-Steffan


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

Re: [Openvpn-users] Using CCD to provide tls-version-min possible?

[Steffan Karger]

Hi,

On Thu, 27 Aug 2020 at 06:39, William Muriithi  wrote:
> I have a client that has an old openVPN client that can't currently connect 
> to the server because he doesn't meet the minimal TLS version.  I would 
> rather not lower the TLS version on the server side for all the clients and 
> was wondering if its possible to allow just one client with a lower TLS 
> version.
>
> Can one use client-config-dir to provide a client with a unique TLS version 
> to use between the server and the client?

That's not possible, because the ccd files are parsed *after* the TLS
handshake has occurred.

It would indeed be nice to not reduce tls-version-min for all clients,
but the way out would rather be to upgrade your old client. Or if you
must, run a second OpenVPN instance for legacy clients with a
different tls-version-min.


-Steffan


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

Re: [Openvpn-users] [ext] Re: State of the Art settings for cipher & auth?

[Steffan Karger]

Hi,

On 18-03-2020 14:27, Ralf Hildebrandt wrote:
>>> cipher AES-256-CBC
>>> auth SHA256
>>
>> AES-256-GCM is what you want, because it's less overhead than -CBC+SHA
>> (AEAD, crypt-and-hash in one go)
> 
> tls-version-min 1.2
> tls-cipher  TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
> ncp-cipher  AES-256-GCM:AES-256-CBC
> authSHA256
> dh  none
> ecdh-curve  secp384r1
> 
> like on https://www.privacy-handbuch.de/handbuch_97a.htm ?

This seems good advise, yes. If you can update all configs: consider
also adding "cipher AES-256-GCM" (or CBC if you have 2.3 peers around)
to prevent any corner cases where OpenVPN might fall back to BF-CBC.

If performance is an issue, you might consider using AES-128, which is
slightly faster and good enough for most purposes, though possibly not
secure against future quantum computers.

Further: in order or preference, use --tls-crypt-v2 (not released yet,
new in OpenVPN 2.5), --tls-crypt (2.4+) or --tls-auth.

-Steffan


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

Re: [Openvpn-users] wireguard encryption settings in openvpn

[Steffan Karger]

On 09-04-2020 15:45, Johannes Bauer wrote:
> On 09.04.20 12:50, Jan Just Keijser wrote:
>> I'd rephrase that:   not every advance in a TLS library does
>> automatically add that capability to OpenVPN.
>>
>> What I mean by that is that some of the newer algorithms in OpenSSL (or
>> mbedTLS) *DO* become available in OpenVPN automatically (e.g.
>> ARIA-256-GCM from OpenSSL 1.1.1) . But you are absolutely right in the
>> sense that it is a shame that some many new developments in a crypto lib
>> (like GCM modes and AEAD ciphers) take such a long time to get added to
>> OpenVPN.
>> I don't quite grap why chacha20 is not available in OpenVPN - it seems
>> to be "just another" AEAD cipher, but I am sure that Steffan can shed
>> light on this.
> 
> Hm, interesting. Yeah from the API perspective I do not know why
> ChaCh20/Poly1305 should be different than any other AEAD stream cipher.
> Especially when you already have support for GCM, which essentially
> makes the underlying block cipher behave as a stream cipher, the API
> should be identical. Maybe I'm missing something here.

Already done. Will be part of the 2.5 release:

https://github.com/OpenVPN/openvpn/commit/6d0d0af

-Steffan


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

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

[Steffan Karger]

Hi,

On 26-12-2019 09:15, Yevgeny Kosarzhevsky wrote:
> On Tue, 24 Dec 2019 at 17:39, Steffan Karger  wrote:
>> --no-iv is a bad option. It's removed from the master branch on January
>> 2017, and will not return.
> 
> Yes I know. It's totally good when you wish to reduce total packet size though
> 

No, it's not. It introduces a hard to assess and often unacceptable
security risk. We strongly advise against using this option. This is why
the option will be gone in 2.5.

If you want small packet overhead, use the AES-GCM modes instead. Most
of the AES-GCM IV is implicit, leaving just 4 bytes per packet.

That said, of course you're free to aim a gun at your foot if you really
want to. Until 2.5, that is ;-)

-Steffan


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

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

[Steffan Karger]

On 24-12-2019 08:27, Yevgeny Kosarzhevsky wrote:
> Yes I am using it to build some patched versions as well as no-replay
> and no-iv options to build plain tunnels.

If by "plain tunnels" you mean no encryption (--cipher none), --no-iv is
a no-op. It only does something for CBC, CFB and OFB cipher modes.

--no-iv is a bad option. It's removed from the master branch on January
2017, and will not return.

-Steffan


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

Re: [Openvpn-users] length ca file

[Steffan Karger]

Hoi Hans, JJK,

On 26-04-19 17:59, Jan Just Keijser wrote:
> On 26/04/19 17:08, j.witvl...@mindef.nl wrote:
>> With the “ca” parameter, you should provide the full trust-chain of
>> the ca’s and sub0ca that signed the used certificate.
>>
>> And, as far as I can remember, you can concatenate multiple
>> (pem-formatted) chains into one file.
>>
> correct , at least for the openssl-linked version of OpenVPN

The same goes for mbedtls.

>> Is there a limit on the length, or on the number of certificates, or
>> on the number of trust-chains ?
>>
> not really, AFAIK. I'd have to look through the OpenSSL source code to
> see if there is an actual limit

For mbedtls, there's no artificial limit. As long as the file size can
be malloc'd and the entire parsed chain fits into RAM, mbedtls won't
complain. I didn't look into OpenSSL, but I don't expect it to have a
limit either.

You should probably realize though that the entire chain is traversed
until a match is found for each connecting client. So creating a
(really?) long list of certificates will decrease connection setup
performance. To optimize the happy flow, you could put the most-used CA
is at the start of the file.

>> I currently have 22 CA-certificates yielding a file of 46K.  Is that
>> too much ??
>>
> 46 K should be fine. However, you can try to reduce it by only including
> the BEGIN CERTIFICATE/END CERTIFICATE blobs, the rest is fluff. Most
> certificate blobs are about 1.5 KB in size, so you might be able to
> reduce it to about 33 KB

True, but this only has influence on startup time and SIGUSR1/SIGHUP
restarts. Both openssl and mbedtls parse the file once on load, and only
keep the parsed representation in memory. The size of the parsed
information does not depend on "fluff" in the ca file, only on the
actual certificates in it.

That said, I don't expect 22 CAs will incur a noticeable performance hit
on a modern server/desktop CPU. It might make a difference if you're
running openvpn on a slow embedded CPU though.

-Steffan


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

Re: [Openvpn-users] Why is the authentication tag transmitted before the encrypted data?

[Steffan Karger]

Hi Pieter,

[ Adding in -devel, because this really is more of a devel topic. ]

On 15-03-19 15:29, Pieter Hulshoff wrote:
> I was wondering why the authentication tag is transmitted before the
> encrypted data in stead of after it (like in e.g. MACsec).

As far as I understand, mostly because the V1 data channel protocol put
the HMAC before the ciphertext. James might remember why the original
data channel protocol put the tag in front.

The current GCM wire spec was proposed by James in
<54648eac.70...@openvpn.net>
(https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09516.html).

I had a short (off-list) discussion with James in 2015 where I proposed
moving the tag to the end of the data frame, to facilitate hardware
implementations. But because (software) implementation of the proposed
protocol had already progressed, we ended up not adopting that proposal.

-Steffan


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

Re: [Openvpn-users] Frame format AES-GCM data packets

[Steffan Karger]

Hi Jan Just,

On 07-11-18 15:50, Jan Just Keijser wrote:
> AES-256-GCM:
> 
> crypto_adjust_frame_parameters:
>    packet_id_size= 4 bytes
>    cipher_kt_iv_size = 12 bytes
>    cipher_kt_tag_size = 16 bytes
>    cipher_kt_block_size = 16 bytes
>    hmac_length = 0 bytes
> crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by
> 48 bytes

Hm, this is indeed what OpenVPN does, but I think it's wrong. In AEAD
mode we should not adjust for the IV size, because we only send the
packet ID on the wire. It seems that nobody has noticed that before.

So now we have to consider whether we can fix that without even more
surprising side effects, like peers disagreeing on the correct link/tun
mtu...

-Steffan


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

Re: [Openvpn-users] Frame format AES-GCM data packets

[Steffan Karger]

Hi Jan,

On 07-11-18 16:22, Jan Just Keijser wrote:
> in CBC mode, "auth sha256"  leads to an  MTU adjustment of 68 bytes
> leaving everything else constant, "auth sha512" leads to an MTU
> adjustment of 68+32=100 bytes:
> 
> crypto_adjust_frame_parameters: packet_id_size= 4 bytes
> crypto_adjust_frame_parameters: cipher_kt_iv_size = 16 bytes
> crypto_adjust_frame_parameters: cipher_kt_block_size = 16 bytes
> crypto_adjust_frame_parameters: hmac_length = 64 bytes
> crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by
> 100 bytes
> 
> and
>   /usr/sbin/ip link set dev tun1 up mtu 1396
> 
> so I cannot tell whether the entire HMAC is transmitted over the wire
> with every packet, but I *DO* see that OpenVPN subtracts another 32
> bytes from the tun-mtu if I increase the HMAC size from SHA256 (32
> bytes) to SHA512 (64 bytes).
> Again, I am not saying that this is the correct behaviour, I am just
> stating this is the *observed* behaviour.

Yes, this is intended and correct behaviour. In CBC mode, the HMAC tag
size depends on the chosen algorithm. OpenVPN could have chosen to
truncate the tags; just sending the first 256 bits of HMAC-SHA512
authentication tags is perfectly secure too. The design of this data
packet format is from long before my time so I can only speculate about
the reason, but I guess the original design only included HMAC-SHA1 and
later on someone added support for other algorithms without rethinking
whether to send all the tag data or just part of it.

I think Pieter's question was about whether the 8-byte part of the AEAD
IV was transmitted over the wire or not. It is not, because there is no
need to. This was proposed by James in this mail:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09681.html

-Steffan


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

Re: [Openvpn-users] Frame format AES-GCM data packets

[Steffan Karger]

Hi Pieter,

On 29-10-18 13:55, Pieter Hulshoff wrote:
> Thank you for the links. How should I interpret this?
> 
> /GCM IV format:/ 
> |[ - packet ID - ] [ - HMAC key data - ]|
>
> This would be a 4 byte packet ID combined with 8 byte HMAC key data to
> form a 12 byte IV? Does the TLS negotiation deliver an 8 byte HMAC key
> in this mode or is only part of the HMAC key used (and if so: which part)?

That is correct. The implicit part of the IV contains the first 8 bytes
of the 'hmac key' as calculated by the data channel key derivation. We
can do that because that key isn't used in AEAD mode.

See key_ctx_update_implicit_iv() in ssl.c for the implementation in openvpn.

> /P_DATA_V1 GCM data channel crypto format:/ 
> |[ opcode ] [ - packet ID - ] [ TAG ] [ * packet payload * ]|
>
> I read this as 1 byte opcode, 4 byte packet ID, 16 byte TAG, payload
> data (no padding, contrary to AES-CBC mode), and where AES-CBC encrypts
> the packet ID, AES-GCM only authenticates this field. Is this correct?

Correct.

> /P_DATA_V2 GCM data channel crypto format:/ 
> |[ - opcode/peer-id - ] [ - packet ID - ] [ TAG ] [ * packet payload
> * ]|
> 
> This is the same as V1, with the 3 byte peer-id field added?

Correct.

-Steffan


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

Re: [Openvpn-users] Frame format AES-GCM data packets

[Steffan Karger]

Hi Pieter,

On Mon, 29 Oct 2018 at 12:14, Pieter Hulshoff
 wrote:
> I'm trying to determine the data packet format for AES(-256)-GCM usage. Where 
> can I find documentation describing the data packets (IP, UDP, IV, MAC, 
> encrypted data, etc) for this mode or is someone willing to give me a 
> rundown? I'm familiar with the V1/V2 AES-CBC+HMAC-SHA-256 frame format 
> already, and am trying to determine the differences with regards to 
> AES(-256)-GCM.

It's all in the doxygen:
https://build.openvpn.net/doxygen/group__data__crypto.html

Or if you prefer reading it from the source file:
https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/crypto.h#L87

-Steffan


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

Re: [Openvpn-users] Elliptic Curves - Confirm differences (and evaluate) new settings

[Steffan Karger]

Hi,

On 07-10-18 10:39, t...@thlu.de wrote:
> OS: Debian 9.5, Raspian 9.4
> Openvpn: 2.4.6
> 
> Is it possible to confirm, that ECDH is really used? I have done 3
> tries, and it seems, all of them come to the same result:
> 
> 1 (old):
> dh   /etc/openvpn/dh.pem
> tls-auth /etc/openvpn/ta.key 0
> 
> 2:
> dh none
> ecdh-curve secp384r1
> tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
> tls-crypt /etc/openvpn/ta.key
> 
> 3:
> dh /etc/openvpn/dh.pem
> ecdh-curve secp384r1
> tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
> tls-crypt /etc/openvpn/ta.key
> 
> The Log-Result (Verb 3) is allways the same.
> Sun Oct  7 10:16:48 2018 123.123.123.123:6577 Control Channel: TLSv1.2,
> cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

This log line shows you that the setup is using ECDH for this connection.

> How I can determine differences in the result of my settings, to
> evaluate the security?

If you want to enforce ECDH, you should set 'dh none', such as in your
second example config.  At the other size, set a non-ECDH cipher suite
such as TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 to verify that the
connection will fail if the other side doesn't want to do ECDH.

For ECDH-only it's probably best to set 'dh none', but not set
tls-cipher or ecdh-cipher. In recent OpenVPN versions the defaults are
sane and if you get a new, better, cooler openvpn/openssl version in the
future, your config won't restrict you from using the new, better,
cooler crypto it might offer.

-Steffan


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

Re: [Openvpn-users] TLS cipher doubts AKA sharing CA between OpenVPN and AWS IoT Things

[Steffan Karger]

Hi,

On Fri, 14 Sep 2018 at 18:46, <2...@minasithil.org> wrote:
> Would ECDHE-ECDSA-AES128-GCM-SHA256 be a good cipher for a routed VPN
> with a central server and many independent nodes?
> I have heard about ECDSA problems due to poor (P)RNG implementations
> causing key leakage, but I guess I could just pick
> ECDHE-RSA-AES128-GCM-SHA256 if that is of concern.
>
> I would like to hear your thoughts about that approach.
> Thank you.

Both are fine. Good random is indeed important ECDHE-ECDSA, but only
marginally less so for ECDHE-RSA. Both ECDHE (the ephemeral key
exchange) and the OpenVPN protocol itself need good random to generate
ephemeral keys too.

-Steffan


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

Re: [Openvpn-users] weak tls-ciphers with openvpn 2.4

[Steffan Karger]

Hi,

On 7 August 2018 at 12:29, Eike Lohmann  wrote:
> Old 3DES:
>
> TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA
> TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA
>
> openssl 1.0.2l does not support it anymore.
> openssl ciphers -v 'ALL:eNULL'|grep DES -> nothing

So this explains why these are rejected, thanks for sharing.

> but
>
> openssl ciphers -v 'ALL:eNULL'|grep DSS ->
>
> DHE-DSS-AES256-SHA  SSLv3 Kx=DH   Au=DSS  Enc=AES(256)  Mac=SHA1
> and it should be IANA"TLS-DHE-DSS-WITH-AES-256-CBC-SHA"
>
> If I set this with tls-cipher in server and client, it fails with:
>
> server side:
> Aug  7 12:27:14 rfip-ovpnbb-3.mdex.de ovpn-fixedip[14340]: 172.17.35.10:32844
> TLS error: The server has no TLS ciphersuites in common with the client. Your
> --tls-cipher setting might be too restrictive.
>
> Client side:
> nothing after "Tue Aug  7 12:27:06 2018 TLS: Initial packet from..."

Did you also change the server certificate to a DSA certificate?  The
DSS cipher suites only work with DSA server certificates.

-Steffan


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

Re: [Openvpn-users] OpenVPN cipher

[Steffan Karger]

Hi,

On 18-06-18 00:53, David Sommerseth wrote:
> On 17/06/18 23:21, Alex K wrote:
> [...snip...]
>>
>> Seems that I can use AES-256-GCM since it gives same encapsulation overhead
>> with slight decease of bandwidth compared to  AES-128-CBC I was using and it
>> will provide some extra security to avoid any surprises from the quantum
>> computers :)
> 
> Let me just correct a potential misunderstanding.  AES-256 makes it a bit
> _harder_ to attack compared to AES-128 in the post-quantum scenario.
> 
> I'm fuzzy on the details (and the crypto geeks need to correct or confirm
> this) ... but IIRC, the strength of AES-256 today is comparable to AES-128 in
> a PQ scenario.  And like wise, today's strength of AES-128 today would be
> roughly half that in a PQ world.

As rule of thumb, yes.  That's a safe way to think about it.  (In
reality, it's likely more secure than "half the exponent", because there
are all sorts of inefficiencies involved.)

> So AES-256 _does_ _not_ _protect_ you.  It just _increases_ the difficulty of
> breaking it.
Of course AES itself could be broken, but when we assume that AES128 is
sufficiently secure now, we may assume that AES256 is secure in a
post-quantum world.

That said: in the PQ scenario AES is the least of you worries.  The
(EC)DH part in TLS is.  You can use tls-crypt to work remedy that somewhat.

Bottom line: AES-256-GCM was chosen as the default because it's a safe
bet.  If you really need the extra bit of performance, using AES-128-GCM
probably fine too.

-Steffan

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

Re: [Openvpn-users] openvpn-nl ciphersuite question

[Steffan Karger]

Hi Ralf,

On 22 December 2017 at 14:37, Ralf Hildebrandt
 wrote:
> I do know that openvpn-nl is basically a slightly changed version of
> openvpn (mbed SSL & lots of insecure crypto removed).
>
> Our server-side installation of stock-openvpn already uses:
>
> cipher AES-256-CBC
> auth SHA256
>
> so I thought, we could simply replace openvpn with openvpn-nl.
> I did that, restarted the server processes and alas, most clients could 
> reconnect without a hitch.
>
> Some clients, however couldn't connect to my server running openvpn-nl:
>
> Dec 21 16:17:58 openvpn tcp[16182]: 87.173.x.y TLS_ERROR: read 
> tls_read_plaintext error: SSL - The server has no ciphersuites in common with 
> the client
>
> I then matched those client IPs to their previous successful logins
> and extracted their client versions:
>
> % fgrep -f problemclients /var/log/daemon.log.1 |fgrep IV_VER |awk '{print 
> $NF}' | sort | uniq -c | sort -n
>
>   6 IV_VER=2.4.0
>   9 IV_VER=2.3.5
>  10 IV_VER=2.3.2
>  10 IV_VER=2.3.6
>  23 IV_VER=2.3.4
>
> So it seems 2.3.2-2.3.6 and 2.4.0 can't agree to a ciphersuites in
> the control channe..
>
> Somewhere along the development of 2.3.x the ciphersuites for the
> control channel must have changed. Where?
>
> I created some stats using the current setup:
>
> # xzfgrep "Control Channel:" /var/log/daemon.log* | awk -F"Control Channel: " 
> '{print $2}' | sort | uniq -c | sort -n
>   2 TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
> 114 TLSv1.2, cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384, 2048 bit key
> 115 TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
>1617 TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA
>   17756 TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

You are likely running into the fact that OpenVPN-NL 2.4 has stricter
--tls-cipher defaults than earlier versions.  An excerpt from the
OpenVPN-NL 2.4.4-nl1 announcement[0]:

> New ciphers:
>
> The control channel now support the following cipher suites by default:
> TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
> TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
> TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
>
> The --tls-cipher option allows to also include the
> backwards-compatibility cipher suite:
> TLS-DHE-RSA-WITH-AES-256-CBC-SHA

So if you want clients that do not support TLS 1.2 to be able to
connect (could be old client, old TLS lib or restrictions such as
using --cryptoapicert), use --tls-cipher to re-enable the legacy
cipher like this: --tls-cipher
"TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA"

-Steffan

[0] https://lists.fox-it.com/pipermail/list-openvpn-nl/2017/19.html

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

Re: [Openvpn-users] feature request: multiple keys to improve config migration

[Steffan Karger]

Hi,

On 01-11-17 17:16, Jan Just Keijser wrote:
> On 29/10/17 02:49, Jason Haar wrote:
>> Best practice would be to routinely rotate secrets, to mitigate
>> configuration misuse/loss, etc.
>>
>> Due to CAs, certificates already support that concept,
>> but tls-auth/tls-auth do not.
>>
>> So wouldn't it be a good idea to allow tls-auth/tls-crypt to contain
>> multiple keys, so that the key could be rotated without an outage
>> (really like a "major upgrade"). i.e.
>>
>> 1. replace server key with one containing old + new
>> 2. replace client config, replacing old key with new one
>> 3. wait weeks/months (probably) until you know all clients are
>> reconfigured
>> 4. replace server key with just the new one
>> 5. rotation is now complete
> 
> someone else asked me a similar question just lately, so you're not the
> only one facing this issue.
> There is something to be said for such a replacement scheme, BUT to do
> this properly would require an OpenVPN protocol change, IMHO; the
> problem is that if you allow multiple tls-auth/tls-crypt keys that you
> end up unhashing EVERY packet with EVERY key to see if there is a match.
> This will kill performance; performance already takes quite a hit with
> tls-auth set.

The first byte of an openvpn packet contains an opcode that indicates
whether a packet is a control channel packet or a data channel packet.
Only control channel packets are affected by tls-auth (or tls-crypt).
Data channel performance should be impacted by tls-auth.

> The protocol change I'd envisage is to allow the use of one or multiple
> static keys for the tls-auth/tls-crypt control channel and that the
> client and server then negotiate a temporary key for the data channel.
> This temp key is then used to hash and unhash all data channel packets.
> This would require the server to be able to quickly distinguish between
> hashed control and data channel packets (we could use some sort of [src
> ip+port + dst ip+port] matching for this, but this needs more thought.

This is basically what the protocol already does, based on the opcode.
But we support only *one* tls-auth or tls-crypt key.

> The other thing that is required is a way to quickly determine whether
> an 'unhashed' packet is correct or not; this may be already present in
> current code but it becomes more important if you need to go through
> multiple keys.

That too is already done: you compute the MAC (HMAC/GMAC) based on the
packet contents, then compare your computed tag with the one in the
received packet.

Coming back to tls-crypt/tls-auth key rotation: the preferred way is
what Ilya suggested: add a new openvpn daemon which is using the new key
and is running on another port, then migrate your clients to the new
server and finally kill the old server.

Heiko and Antonio have been working on something that should make this
much easier: supporting multiple sockets.  Then you could have one
daemon accept connections with tls-auth key A on port x and connections
with tls-auth key B on port y.  That would not require defining a new IP
pool, or jumping through hoops to share the same pool over multiple
instances.

-Steffan

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

Re: [Openvpn-users] Server vs Client cert generation

[Steffan Karger]

Hi,

On 09-08-17 19:34, Gregory Sloop wrote:
> I also often need to generate certs for other things and GNU TLS's
> CertTool works pretty well.
> I'd like to use one tool to generate all the certificates I generally
> need - it's just easier to keep track of, document etc.
> 
> However when I go to generate certs for OpenVPN usage with certtool, it
> appears I have a problem with the "server" attribute.
> 
> While I have the following in the certs...
> ---
>Extensions:
>Basic Constraints (critical):
>Certificate Authority (CA): FALSE
>Subject Alternative Name (not critical):
>DNSname: abc-ovpn-server-01
>Key Purpose (not critical):
>TLS WWW Server.
>Key Usage (critical):
>Key encipherment.
>Subject Key Identifier (not critical):
>
>Authority Key Identifier (not critical):
>
> ---
> ...it doesn't appear to be identified as a "server" certificate. [At
> least in pfsense.]

I have no clue about how to use certtool, but I'll give this a shot.

Do you know what certtool means with "Key purpose"?  Is that it's own
invented name for extendedKeyUsage ?

Also, what are you using to check that this is a "server" certificate?
--remote-cert-tls? or --ns-cert-type?  or something homegrown?

In any case, this certificate seems to miss the digitalSignature
keyUsage, which is required if you want to use TLS cipher suites with
forward secrecy (DH/ECDH).  Modern OpenVPN by default only support
cipher suites by forward secrecy.  So although this has nothing to do
with "server" attributes, it is likely to cause the connection to fail.

As always, post logs and configs if you want better answers.

-Steffan

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

Re: [Openvpn-users] Clients can't connect after server reboot

[Steffan Karger]

On 08-08-17 20:34, Leonardo Rodrigues wrote:
> 
> You very likely created your certificated with MD5 hashing, which
> was disabled on newer OpenSSL versions of CentOS.
> 
> Try:
> 
> export NSS_HASH_ALG_SUPPORT=+MD5
> export OPENSSL_ENABLE_MD5_VERIFY=1
> 
> before starting your OpenVPN daemon and watch if that make clients
> connect again ...

That's great for debugging the issue, but if this works it's time to
redo your certificates with SHA2 instead.  Nobody should be using MD5
certificates anymore.

-Steffan

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

Re: [Openvpn-users] Clients can't connect after server reboot

[Steffan Karger]

On 08-08-17 20:34, Xen wrote:
> Mio Vlahović schreef op 08-08-2017 19:59:
> 
>> Can anyone assist us on this one? I have googled and found something
>> about CRL has expired error. Is it related with the upgrade of the
>> openvpn package? we use one from the epel repository.
> 
> You know a CRL is a certificate revocation list right.
> 
> Being a layman for the rest of it, it means that your configuration uses
> a CRL to begin with. A CRL is supposed to regularly issued and
> containing a list of certificates that are no longer deemed trustworthy;
> ie. client certificates that have been compromised.
> 
> So you can do two things: renew your CRL, or remove it from the
> configuration.
> 
> I will let someone answer now who actually has something useful to say ;-).

That was quite useful, and accurate too.  Of course, regularly
refreshing the CRL is more elegant than just removing it from the config.

Some context:  as of openvpn 2.4, the CRL checking logic of the crypto
library is used, instead of our own implementation.  That logic is more
strict than openvpn 2.3 was, and now rejects CRLs that have a nextUpdate
value that lies in the past.  So this is indeed related to upgrading
from openvpn 2.3.x to 2.4.x.

-Steffan

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

Re: [Openvpn-users] VPN without encryption and auth

[Steffan Karger]

Hi,

On 06-08-17 10:35, Yevgeny Kosarzhevsky wrote:
> OpenVPN without encryption or with weak encryption using '--auth none
> --no-iv --no-replay' is still great tool for tunneling traffic over UDP
> protocol. IPIP, L2TP or other known tunneling solutions may be blocked
> in certain countries. This is the reason I would vote to keep no-iv
> option in upcoming 2.5 release.

As of 2.4, OpenVPN supports the lower-overhead AES-GCM crypto modes.
Consider using these instead.

The average per-packet overhead of this solution is 20 (IP) + 8 (UDP) +
4 (average CBC padding for BF-CBC) or 8 (average CBC padding for AES) =
32 or 36 bytes.

The average per-packet overhead of the AES-128-GCM/AES-256-GCM is 20
(IP) + 8 (UDP) + 4 (GCM IV) + 16 (GCM tag) = 48 bytes.

So the difference is just 12 or 16 bytes, but gives you a huge gain in
security.  On top of that, GCM gives you a very nice hardware speedup on
modern CPUs.

(The old AES-CBC + HMAC-SHA1 would add up to 20 (IP) + 8 (UDP) + 16 (IV)
+ 4 (packet id) + 8 (avg. CBC padding) + 20 (HMAC-SHA1) = 76 bytes. Or
64 bytes for BF-CBC + HMAC-SHA1.)

-Steffan

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

Re: [Openvpn-users] Fwd: --no-iv option deprecation

[Steffan Karger]

Hi,

On 31 July 2017 at 13:19, Yevgeny Kosarzhevsky  wrote:
> For some reasons I don't need secure connection, it's enough that the
> connection isn't plain text.

I seriously doubt that.  In any case, that use case is no longer supported.

> As I understand --cipher none does not imply --no-iv one one hand, and the
> default cipher with --no-iv and --auth none gives non-plaintext connection
> and reduces packet size which is ok for my needs.

IVs are only needed when using a cipher. So --cipher none does imply --no-iv.

> This is the reason I am asking why --no-iv gets deprecated while no other
> option gives this functionality

Because it's an insecure option and you should not be using it.

-Steffan

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

Re: [Openvpn-users] Fwd: --no-iv option deprecation

[Steffan Karger]

Hi,

On 31 July 2017 at 11:00, Yevgeny Kosarzhevsky  wrote:
> On 31 July 2017 at 15:49, Gert Doering  wrote:
>>
>> Using crypto with --no-iv is only marginally better than using "--cipher
>> none"
>> - so, if you want no encryption, make it explicit with "cipher none",
>> instead of pretending to have strong crypto which it isn't.
>>
>> Why are you using --no-iv?
>
> I use it to reduce packet size on tunnels with --secret option together with
> --auth none.
> I am aware of the fact that this less secure option however I believe it's
> still provides encryption and is safe enough unless the key is revealed to
> 3rd party.
> Please correct me if I am mistaken.

You are mistaken.  CBC requires an unpredictable IV, so --no-iv breaks
the CBC security.  Using --auth none is plainly insecure against any
man-in-the-middle attacker.  Don't use either of those if you want a
secure connection.

If you want to understand why, I can recommend
https://www.coursera.org/learn/crypto.

-Steffan

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

Re: [Openvpn-users] OpenVPN with mbedTLS default TLS cipher suite list

[Steffan Karger]

Hi,

On 27-07-17 15:18, open...@keemail.me wrote:
> Thanks for the reply, but I think `--show-tls` simply prints all
> available tls-ciphers for the cipher suite,
> as stated by the manual:
> 
> Use --show-tls to see a list of TLS ciphers supported by your crypto
> library.
> 
> I'm looking for the default value of the tls-cipher, if it is not defined.

The manpage could be a bit more clear, but Magnus is right: --show-tls
prints the default cipher list, or the list resulting from your
--tls-cipher setting.  (Just try adding --tls-cipher when you do
--show-tls.)

For mbed TLS, the default is the list of all supported ciphers by the
library.  You can easily throw out a lot of bad ones by setting
--tls-version-min 1.2.

-Steffan

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

Re: [Openvpn-users] Default key length of DH/DHE/ECDH/ECDHE

[Steffan Karger]

Hi,

On 24 July 2017 at 14:20, SaAtomic  wrote:
> I'm not sure if this question is more suitable for the OpenVPN or the
> OpenSSl users list.
>
> With OpenVPN 2.4.0 and OpenSSL 1.0.2l only ECDHE and DHE are available, but
> I do not have the option to define a key length,
> so I assume OpenSSL's default key length will be used. With older versions
> of OpenVPN/OpenSSL DH and ECDH are also available if I'm not mistaken.
>
> On the OpenSSL users mailing list, I was informed, that for the EC Diffie
> Hellman, the chosen curve (e.g. NIST256, NIST384, ...) determines the key
> length.
>
> What key length does OpenVPN use for DH, DHE, ECDH and ECDHE?

For DH/DHE, the key length is determined by the parameters you provide
to the server through --dh.

For ECDH/ECDHE, thee key size is determined by the curve, and the
curve is determined by the server certificate. By default OpenVPN (1)
tries to let OpenSSL 1.0.2 and newer or mbed TLS select the curve
automatically, or for OpenSSL 1.0.1 and older uses either (2) the
curve used in the server certificate (--cert) or (3) when the server
cert is not an EC cert falls back to P-384.

-Steffan

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

Re: [Openvpn-users] push vs. client file options

[Steffan Karger]

Hi,

On 27-04-17 08:47, Gert Doering wrote:
> On Wed, Apr 26, 2017 at 05:58:19PM -0400, David Mehler wrote:
>> Same question for the auth SHA512 line which is in both the server and
>> client configuration files, if I add push "auth SHA512" can I remove
>> the auth SHA512 line from the client?
> 
> If you use GCM, the "auth" line is only used for tls-auth - and if you
> use tls-auth (or tls-crypt), this needs to be correct before a connection
> can be established at all.  So, not pushable.

One slight correction: --tls-crypt always uses HMAC-SHA-256, no matter
what you specify for --auth.  So if you are using NCP and --tls-crypt,
both the --cipher and --auth options from the config file are no longer
used.

-Steffan



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

Re: [Openvpn-users] win10, openvpn gui latest, and openvpn 2.4 server tls negotiation configuration error

[Steffan Karger]

Hi Dave,

On 17-04-17 21:03, David Mehler wrote:
> I've got a FreeBSD 10.3 server running openvpn 2.4. To that I'm trying
> to connect an external to that network win10 x64 machine running
> openvpn gui latest 2.4.
> 
> I'm getting a tls negotiation error and although google has shown this
> as common apparently I'm thinking it's a tls issue in my
> configuration. I've included my server config and client config files
> below and would appreciate it if someone can spot my tls issue.

Could you also post the (at least) --verb 4 log from a failed connection
attempt (both client and server)?  That might make it easier to spot the
issue.

-Steffan

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

Re: [Openvpn-users] OpenVPN Hardening

[Steffan Karger]

On 22-03-17 16:14, Joaquin Henriquez wrote:
>>>From the wiki I read the following:
>> Today, OpenVPN does not support TLS-ECDHE-* or more exotic cipher-suites as 
>> there is no elliptic curve support currently.
>> 
>> https://community.openvpn.net/openvpn/wiki/Hardening
>> 
>> Is this statement still true?
>> 
>> Cause I try:
>> tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
>
>
>>From 2.4:
>
> Some of the major features are AEAD (GCM) cipher and Elliptic Curve DH
key exchange support,
>
> So that answer my question.

Indeed.  If both ends are 2.4+, ECDH and ECSDA should just work.

The hardening page is somewhat outdated.  I updated the section on
--tls-cipher a bit, but the whole page could use some more love...

-Steffan

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

Re: [Openvpn-users] Security/Usage of tls-cipher with PSK KEX

[Steffan Karger]

Hi,

On 15-02-17 08:09, saato...@keemail.me wrote:
> I'm looking into the security of the offered tls-ciphers, with both
> OpenSSL and mbedTLS.
> 
> Now I've first encountered key exchanges with the use of a pre shared
> key, offered by mbedTLS.
> The PSK appears to be used either on its own or in combination with DHE,
> ECDHE or RSA.
> See the list of relevant cipher suites at the bottom of the mail:
> 
> A couple of questions there:
> How is this PSK generated and correctly deployed?
> Can someone give me a resource, explaining how this works?
> What is the security impact of the use of the PSK?
> In the cases, where only PSK is used, no additional key exchange, is the
> PSK used for the TLS encryption?

OpenVPN does not support TLS PSK.  Compared to the asymmetric key
exchanges we support, it doesn't really bring us anything, but it does
incur extra development time and maintenance cost.

The other questions you ask are quite generic TLS PSK questions, which
are probably best explained by the RFC that introduces PSK:
https://tools.ietf.org/html/rfc4279

It's just 10 pages of actual text, so should be quite digestible.

-Steffan

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

Re: [Openvpn-users] Is it safe to disable packet authentication (auth) with GCM ciphers?

[Steffan Karger]

Hi,

On 02-02-17 13:56, Dreetjeh D wrote:
> Possibly interesting read for who understands, ... i don`t :)
> "Achieving 128-bit Security against Quantum Attacks in OpenVPN"
> http://essay.utwente.nl/70677/1/2016-08-09%20MSc%20Thesis%20Simon%20de%20Vries%20final%20color.pdf
>  

Very interesting indeed.  Even more, we (Fox-IT, my employer) are
already working together with the author to get this integrated into
OpenVPN-NL, and later also OpenVPN.  (But be patient, this will take a
bit of time.)

-Steffan

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

Re: [Openvpn-users] Is it safe to disable packet authentication (auth) with GCM ciphers?

[Steffan Karger]

Hi,

On 2 February 2017 at 10:56, Dreetjeh D <dreet...@hotmail.com> wrote:
> Op 31-1-2017 om 22:31 schreef Steffan Karger:
>> On 31 January 2017 at 21:53, Karol Babioch <ka...@babioch.de> wrote:
>> <.>
>> The --auth parameter is . still used to determine the --tls-auth HMAC 
>> digest.
>
> I guess in case of --tls-crypt, --auth is not needed/doing anything?

Correct.  --tls-crypt *always* uses HMAC-SHA256 for authentication, no
matter what you specify as --auth.

-Steffan

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

Re: [Openvpn-users] Is it safe to disable packet authentication (auth) with GCM ciphers?

[Steffan Karger]

Hi,

On 31 January 2017 at 21:53, Karol Babioch  wrote:
> since OpenVPN 2.4 supports GCM ciphers I'm wondering whether it is safe
> to disable packet authentication (--auth) entirely. To my understanding
> GCM ciphers provide encryption as well as authentication.
>
> Are there any arguments to keep it enabled anyway? What arguments can be
> made for or against it? Obviously it adds some overhead, so performance
> is probably a little bit worse with explicit packet authentication. Are
> there any other things to consider?

The --auth parameter is ignored for the data channel crypto when using
GCM ciphers, so it won't make any difference there.  It is however
still used to determine the --tls-auth HMAC digest.

-Steffan

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

[Openvpn-users] [PATCH] Allow changing cipher from a ccd file

[Steffan Karger]

As described in msg  <374a7eb7-f539-5231-623b-41f208ed8...@belkam.com> on
openvpn-de...@lists.sourceforge.net, clients that are compiled with
--disable-occ (included in --enable-small) won't send an options string.
Without the options string, the 2.4 server doesn't know which cipher to
use for poor man's NCP.

This patch allows working around that issue by allowing the 'cipher'
directive to be used in --client-config-dir files.  That way, a server
admin can add ccd files to specify per-client which cipher to use.

Signed-off-by: Steffan Karger <stef...@karger.me>
---
 src/openvpn/options.c | 2 +-
 src/openvpn/options.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 4b6d720..6f89616 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -7536,7 +7536,7 @@ add_option(struct options *options,
 }
 else if (streq(p[0], "cipher") && p[1] && !p[2])
 {
-VERIFY_PERMISSION(OPT_P_NCP);
+VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
 options->ciphername = p[1];
 }
 else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index a14f2ab..f4f0226 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -628,7 +628,7 @@ struct options
 #define OPT_P_MTU (1<<14) /* TODO */
 #define OPT_P_NICE(1<<15)
 #define OPT_P_PUSH(1<<16)
-#define OPT_P_INSTANCE(1<<17)
+#define OPT_P_INSTANCE(1<<17) /**< Allow usage in ccd file */
 #define OPT_P_CONFIG  (1<<18)
 #define OPT_P_EXPLICIT_NOTIFY (1<<19)
 #define OPT_P_ECHO(1<<20)
-- 
2.7.4


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

Re: [Openvpn-users] Does EasyRsa could support to generate DSA certification by some small changes?

[Steffan Karger]

Hi,

On 30-12-16 08:56, Zhang Lei wrote:
> I just joint this mail list because I’m running into this problem as per
> title. Does anyone help?
> 
> Because I wanna using ECDHE-ECDSA-AES128-GCM-SHA256 ciphers and  I got
> this useful tool “EasyRSA”, but I need the “EasyDSA”…. So,, do we have
> any simple way of changing it into what I want? thanksJ

EasyRSA3 (despite it's name) has ECDSA support.

(ECDSA is different from DSA, and you probably want ECDSA, not DSA.)

Check

https://github.com/OpenVPN/easy-rsa/blob/master/README.quickstart.md

and

https://github.com/OpenVPN/easy-rsa/blob/master/easyrsa3/vars.example

The 'vars' file is the setting file which you have to change to you
liking to get it to use ECDSA instead of RSA.

-Steffan

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

Re: [Openvpn-users] Question about tls-crypt and port 443 firewall ducking

[Steffan Karger]

Hi,

On 20-12-16 18:01, Selva Nair wrote:
> Someone here had posted that making the VPN connection through stunnel
> works better from china. 

Exactly.  To reliably bypass good DPI, it is not sufficient to hide that
traffic is (Open)VPN traffic, but instead you'll need to make it look
like allowed traffic.  Tunneling over stunnel (which is 'plain' TLS, so
looks very similar to HTTPS) does a decent job there.

But the advice here remains unchanged:  if you want to bypass DPI, use a
tool that is designed to do just that, such as obfsproxy.

-Steffan

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

Re: [Openvpn-users] Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?

[Steffan Karger]

Hi,

On 15 December 2016 at 19:11, David Sommerseth
 wrote:
> On 15/12/16 16:35, Sebastian Rubenstein wrote:
>> Could you explain in greater detail your statement "use AES-256-GCM
>> for more efficiency on the data channel"?
>
> I'll leave this to Steffan (or JJK).

AES-GCM has a shorter authentication tag (128 bits) than HMAC-SHA256
(256 bits).  Also, AES-GCM doesn't need a unpredictable IV but rather
just a unique-per-key nonce, which mean we can transfer 8 less bytes
per packet for the IV.  This saves us a total of 24 bytes per packet
overhead compared to cipher AES-256-CBC + auth SHA256.

Furthermore, AES-GCM can maximallu leverage the AES-NI hardware
acceleration available in modern Intel CPUs, which will result is
*much* faster crypto.

-Steffan

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

Re: [Openvpn-users] Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?

[Steffan Karger]

Hi,

On 14-12-16 17:31, Sebastian Rubenstein wrote:
> I hope that some experts here will be able to tell me if my VPN provider uses 
> weak encryption standards with regards to encryption/decryption of control 
> channel authentication and data channel? Thanks.
> 
> Below is a sample of a redacted config file:
> 
> tls-client

This means you're using TLS for forward secrecy, and are refreshing you
data channel keys (at least) hourly.  That's good.

> remote-cert-tls server

You are checking that you are connecting to someone with a *server*
certificate (so not just some other client pretending to be a server).

> cipher AES-256-CBC
> auth SHA512

You are using AES-256-CBC for data channel encryption, which is very
strong, and HMAC-SHA512 for data channel authentication, which is very
strong too (frankly, overly strong.  SHA256 gives you 32 bytes per
packet overhead instead of 64, and is also very strong).

> key-direction 1
> 
> #
> # 2048 bit OpenVPN static key
> #
> -BEGIN OpenVPN Static key V1-
> 
> Large chunks of alphanumeric text
> 
> -END OpenVPN Static key V1-
> 

You're using TLS-auth to protect against mitm attacks on your TLS
connection, which is very good.  key-directing 1 means you are using
different keys for client-server and server-client traffic, which is
good too.

> Wed Dec 7 08:27:57 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 
> ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

Your private key is RSA-4096, which is plenty strong too.  You might
want to consider elliptic curve certificates to gain some connection
setup speed, but you will probably not gain any extra security by that.

So, all in all, very decent setup.  Once you move to OpenVPN 2.4 (which
is nearing release), you switch from --tls-auth to --tls-crypt for some
"poor-man's" post-quantum security, and use AES-256-GCM for more
efficiency on the data channel.

-Steffan

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

Re: [Openvpn-users] question about "WARNING: this cipher's block size is less than 128 bit"

[Steffan Karger]

Hi,

On 8 Nov 2016 12:49 a.m., "Jason Haar"  wrote:
>
>
> On Mon, Nov 7, 2016 at 10:46 PM, Gert Doering  wrote:
>>
>>  - 2.4 client talking to 2.4 server will send a special handshake
(IV_NCP=2)
>>which signals "I can do pushable cipher, and I can do AES-GCM", so the
>>server will (usually) send back "cipher AES-256-GCM" and move itself
>>to AES-256-GCM as well.
>
>
> All right, let's get this clear for me and for others :-)
>
> If I have a 2.4 server, I can set it to "cipher BF-CBC" and keep all the
2.3 clients happy. Then I can migrate the clients to 2.4 (even with "cipher
BF-CBC" too), and as they come in, they  negotiate before "cipher" matters
and go AES-256-GCM: basically "--cipher" is ignored in 2.4+ transactions?
Or I can migrate the clients to 2.4 with "cipher BF-CBC", and when they
fail to negotiate with the 2.3 server, they'll still be happy, and then
when I migrate the server to 2.4, they all auto-update to AES
>
> Is that correct? That would be perfect as then no dual infrastructure
would be required

Yes, that is correct!

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

Re: [Openvpn-users] question about "WARNING: this cipher's block size is less than 128 bit"

[Steffan Karger]

Hi,

On 04-11-16 02:03, Jason Haar wrote:
> Am I correct that to move off Blowfish cipher, we'll have to reconfigure
> the openvpn servers and clients simultaneously? The server and clients
> don't currently have "cipher" defined, but the newer clients are
> generating those "cipher" warnings. 
> 
> Also, am I correct that "cipher" cannot be used within a ""
> block? ie there's no way to migrate - it has to be a "hard" outage. 
> 
> I'm just wondering how other people do it. I can't see any way out of
> this other than bringing up entirely independent server infrastructure,
> so that the new clients can use the new servers while the old clients
> migrate.

With 2.3, yes.  OpenVPN 2.4 offers 'Negotiable Crypto Parameters', which
will (by default) negotiate AES-GCM if both client and server support
negotiation (ie, are 2.4+).  That is the more elegant migration path.

2.4 isn't stable yet, but an alpha2 preview is available for testing
[1].  The current goal is to release 2.4.0 by the end of this year.

The risks of the 64-bit block ciphers are as of 2.3.13 mitigated by
setting --reneg-bytes to 64 MB.  That is of course suboptimal, but
should be barely noticeable for most use cases.  So you might want to
consider waiting for the 2.4.0 release, or start testing 2.4 right away
and migrate as soon as you've got confidence in the 2.4 code base.  (The
2.4/master branch really is quite stable actually, and has a lot of
other nice features worth migrating for.)

-Steffan

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

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

[Openvpn-users] RFC: Pushable options and sigusr1 restarts

[Steffan Karger]

Hi,

OpenVPN (2.x) currently caches pushed options across sigusr1 restarts.
This 'allowes' a server admin to push some options that the code can't
really handle, until the client times out and performs a sigusr1
restart.  The client will then execute a number of initialisation
routines that might (or might not, depending op the option?) now
process the pushed option successfully.

This results is surprising behaviour, as discussed in trac #128 and on
the openvpn-devel mailinglist (Message-ID:
<326b8ff7-39a6-1974-c0b0-82fd2abdc...@gmail.com>).

I'd like to get rid of this behaviour, by restoring the original
options on a sigusr1 restart.  Imho, options should either be pushable
and implemented properly (without needing a sigusr1 restart at the
client side) or not pushable at all.  This code is however from well
before I got involved into OpenVPN. So what I'm wondering about though
is:

Does anyone think this behaviour is intended and/or does anyone rely
on this behaviour?

-Steffan

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

Re: [Openvpn-users] 2.3.10 work 2.3.11 throws TLS error

[Steffan Karger]

Hi,

On 22 August 2016 at 13:27, debbie10t  wrote:
> I wonder if anybody can shed some light on this problem:
> https://forums.openvpn.net/viewtopic.php?f=6=22290

Yes, Mikrotik didn't support modern cipher suites, which OpenVPN
2.3.11 wants to use.  See
https://community.openvpn.net/openvpn/ticket/685.

-Sreffan

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

Re: [Openvpn-users] [Openvpn-devel] use of --cipher with no arguments?

[Steffan Karger]

Hi,

On Mon, Jul 25, 2016 at 10:04 PM, Gert Doering  wrote:
> has anyone ever used "--cipher" without an argument?  If yes, what is the
> intended usage?  It sort of "tells openvpn we want crypto!" but does not
> go into detail about it...
>
> Normally, this would just be a random weird option, but I ran across
>
>   --cipher none --cipher
>
> which first tells openvpn "nah, we do not want anything!" and sets
> a pointer to NULL, and then tells openvpn "but please *do* use the
> ciphers already setup!", which core dumps.
>
> This is not remotely exploitable, so not a *security* issue, but a bit
> stupid nonetheless - so I propose we just throw out "--cipher" with
> no arguments (--cipher none, or --cipher bf-cbc would, of course,
> continue to work).
>
> Anyone having a good argument against it?  JJK, do you happen to know
> what this is about?

As the patch I just sent suggests, I don't believe this can be useful at all.

Using just --cipher is a no-op if anything but '--cipher none' is used
(o->ciphername_defined is already set to true), and crashes OpenVPN
otherwise.  Probably just a leftover 'from the old days'.

-Steffan

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] tls-cipher

[Steffan Karger]

Hi,

On Mon, Jul 25, 2016 at 1:46 AM, Yevgeny Kosarzhevsky  wrote:
> whenever I enable 'tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384' on
> client and server I get the following error:
>
> TLS_ERROR: BIO read tls_read_plaintext error: error:1408A0C1:SSL
> routines:SSL3_GET_CLIENT_HELLO:no shared cipher
>
> Is there something I missed?
> I have also 'tls-min-version 1.2' on both sides.

This is likely due to the ECDHE part - this is not supported for
OpenVPN 2.3 with OpenSSL (it is for PolarSSL).  Use DHE instead, or
switch to the OpenVPN master branch.  The master branch does have
ECDH(E) support for OpenSSL too.

-Steffan

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] ECDH / ECDSA support?

[Steffan Karger]

Hi Scott,

On Wed, Jul 6, 2016 at 9:18 PM, Scott Crooks  wrote:
> I saw this file in the OpenVPN codebase:
> https://github.com/OpenVPN/openvpn/blob/master/README.ec
>
> Which claims that support for elliptic curve certificates will be enabled in
> OpenVPN 2.4.0. Just wanting to make sure there wasn't another way to enable
> it in version 2.3.10?

Yes, use an mbed TLS build.  That will automatically support ECDSA and
ECDH.  I *think* (can't test right now) that ECDSA also works fine
with 2.3.10 + modern OpenSSL (1.0.1+, iirc).  ECDH might also work
with OpenSSL 1.0.2+.

But, by far the easiest way is to just use the master branch.  It is
quite stable, and has full EC support, for both mbed TLS and OpenSSL.

-Steffan

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] [Openvpn-devel] SSL handshake and OpenVPN config cipher none

[Steffan Karger]

Hi,

On Thu, May 5, 2016 at 12:26 PM, Shubham Chauhan
 wrote:
> I had a doubt about the cipher none config in OpenVPN.
> I realized that OpenVPN initiates an SSL handshake, even if I choose not to
> use any encryption-decryption operations through the cipher none config. It
> chooses a particular cipher in the handshake as well.
>
> Is it supposed to happen this way?

Yes.

> If yes then why does this exactly happen?

OpenVPN uses TLS to create the 'control channel', over which keys for
the data channel are negotiated and network configuration is pushed to
clients.

> What is the significance of the SSL/TLS handshake and negotiating a session,
> if I am not using any encryption?

Disabling crypto is possible, but not what OpenVPN was designed for.
Also, disabling encryption (using --cipher) does not disable
authentication (--auth) too. If you want to control the TLS crypto,
use --tls-cipher.  Note however that the TLS control channel is only
used for configuration, so disabling the crypto there won't give you a
faster VPN connection.

-Steffan

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Detecting client certificate CN during connection

[Steffan Karger]

Hi,

On 28 Apr 2016 7:27 p.m., "Ryan Whelan"  wrote:
>
> To make sure i'm not completely confused; the current state of this
functionality as it exists in OpenVPN, it is possible to get keying info
out of a server connected to a client (via a shared object plugin).
However, there currently exists no way to use this information to move a
clients connection to a new server.  Am I understanding properly?

No, the key material that can be exported is derived from the master key in
such a way that it is irreversible.  You can not import it to retrieve the
original master key.

See RFC 5707 for more info on what this is meant for.

-Steffan
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] want to confirm: verify-x509-name for cert DNS check

[Steffan Karger]

Hi Jason,

On 13-12-15 05:25, Jason Haar wrote:
> So am I correct in saying that if a client is configured to only use
> "verify-x509-name . name" to validate server, so as long as the
> server cert contains "." as one of it's "Subject alternative
> names", the client is happy

No, verify-x509-name does not do anything with Subject alt names. It 
validates the peer certificate subject (or a specific part of the 
subject, if you use the 'name' or 'name-prefix' types).  I think the man 
page explains this quite accurately:

  --verify-x509-name name type
 Accept connections only if a host's X.509 name is equal to name.
 The remote host must also pass all other tests of verification.

 Which  X.509  name is compared to name depends on the setting of
 type.  type can be "subject" to match the  complete  subject  DN
 (default),  "name"  to  match  a subject RDN or "name-prefix" to
 match a subject RDN prefix.   Which  RDN  is  verified  as  name
 depends  on the --x509-username-field option. But it defaults to
 the common name (CN), e.g.  a  certificate  with  a  subject  DN
 "C=KG, ST=NA, L=Bishkek, CN=Server-1" would be matched by:

 --verify-x509-name 'C=KG, ST=NA, L=Bishkek, CN=Server-1' and
 --verify-x509-name Server-1 name or you could use --verify-
 x509-name Server- name-prefix if you want a client to only
 accept connections to "Server-1", "Server-2", etc.

> So... I could configure the client to connect to the servers IP address,
> or some entirely unrelated "." DNS alias - and it would be
> happy, because the server cert contains "." as one of it's name
> options? ie there's no need for the other DNS aliases to be part of the
> server cert?

Yes (but see above).  In OpenVPN, the address of a server is not taken 
into account for certificate validation, so you can happily change it's 
address and/or ip, update your client config, but keep your certificates.

-Steffan


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

Re: [Openvpn-users] OpenVPN architecture questions

[Steffan Karger]

On Mon, Nov 30, 2015 at 9:54 AM, Jason Haar <jason_h...@trimble.com> wrote:
> On 29/11/15 22:56, Steffan Karger wrote:
>> OpenVPN makes a distinction between control traffic (key/config
>> exchange, etc) and data traffic (actual vpn network packets).  For
>> control packets, OpenVPN has a reliability layer that ACKs packets,
>> retransmits, etc.  For data packets, OpenVPN does not do any of that.
>> (But, when you're using TCP mode, TCP does that, ofc.)
> ...Then why does it work so well over UDP?
>
> I almost exclusively use openvpn over UDP and I would have thought the
> lack of error checking on the data channel would hurt, so why doesn't it?
>
> eg, if there's no UDP error checking built into openvpn, then shouldn't
> DNS lookups (ie udp inside a udp openvpn tunnel) fail a lot? Or is the
> Internet generally so reliable that it doesn't matter? (eg 1% packet
> loss on Internet leads to 1% packet loss inside openvpn tunnel?)

You're tunnelling IP over UDP.  IP assumes no reliable transport.
Either you run a protocol over IP that provides the reliability (e.g.
TCP), or you design your application such that it does not assume
reliable transport (e.g. DNS).  DNS over UDP-OpenVPN over Internet
will experience (almost) the same packet loss, out-of-order
transmissions and whatnot behaviour as UDP-over-Internet on the same
route would.

Because the assumptions IP makes on the underlying transport are
similar to the behaviour of UDP tunnelling, UDP tunnelling generally
works well.  TCP tunnelling however can cause problems with
TCP-over-TCP, because the two layers of reliability features can cause
strange interactions.

So yes, 1% packet loss on the underlying transport will cause 1%
packet loss on your UDP-OpenVPN tunnel. And that's (generally) a good
thing ;)

-Steffan

(Disclaimer: I'm really not a networking expert, so I might not use
the correct terms, be imprecise or even incorrect.  Please correct me
if that is the case.)

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] OpenVPN architecture questions

[Steffan Karger]

Hi Leroy,

On Mon, Nov 30, 2015 at 5:21 AM, Leroy Tennison
 wrote:
> Thank you for your reply, I appreciate it (and the technical
> distinctions concerning reliability).  Do you have a pointer to a source
> for additional information about what is retained in OpenVPN's "state"?
> I don't mind doing the reading if I just knew where to look (even a
> well-labeled C struct would be fine, I just don't know how extensive the
> source code is).

I'm afraid there isn't a clear piece of documentation describing the
internal state.  However, 'struct context' in openvpn.h should give
you a good starting point when you start digging in the code:
https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/openvpn.h#L508

What we do have, and what might help you, is looking at the generated
doxygen documentation.  Either run 'doxygen
doc/doxygen/openvpn.doxyfile' from the source root, or look at the
doxygen I regularly generate for git-master:
https://delft.syzzer.nl/openvpn-doxygen/  (no guarantees on this one,
if it breaks it might take me a while to notice and/or fix).

-Steffan

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Recommended ciphers in openvpn = 2.3.6

[Steffan Karger]

On 16-06-15 23:17, Jan Just Keijser wrote:
 On 16/06/15 16:40, Ralf Hildebrandt wrote:
 I'd recommend

 cipher AES-256-CBC
 auth SHA256

Agreed.

 The main reason to use AES-256 is if you're using machines that are
 optimized for AES (e.g. AES-NI capable CPU's). AES-256 is faster than
 Blowfish on such CPU's.

If speed is an issue, you might also consider AES-128-CBC, which is 
perfectly fine too by today's standards.

 Increasing the auth (hash) size to 512 is not likely to increase
 security, unless you are also issuing certificates signed using SHA512:
 the control channel hashing algo is almost always the same as the algo
 used to sign the certificates.
 By using 'auth sha512' you could end up making the data channel more
 securely hashed/signed (and a lot slower) than the control channel,
 which does add a lot of extra security.

Also, SHA256 can be hardware accelerated on a lot of modern hardware. 
SHA512 mostly can not. And SHA512 adds 64 bytes per packet, while SHA256 
adds just 32 bytes. Especially for connections with lots of small 
packets (games, voip, video streams) that is a significant overhead.

-Steffan

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

Re: [Openvpn-users] Logjam: new tls/dh attack

[Steffan Karger]

On Sat, May 23, 2015 at 4:07 PM, Bonno Bloksma b.blok...@tio.nl wrote:
 Just a heads up on this new attack
 https://weakdh.org/

 the short gist of this attack is:  upgrade your DH param file to 2048
 bits or more otherwise you're vulnerable :)

 This is true, but in the case of OpenVPN the case is less horrible, because:

 1) OpenVPN encourages users to generate their own DH-group using 'openssl 
 dhparam',
 instead of using common groups. The man page / examples used to provide 1024 
 bits
 DH keys (updated to 2048 recently),

 Are you sure? I just looked at my setup which I generated many years ago and 
 it has a dh4096.pem file
 I think I generated this using default parameters because I did not 
 understand much about openvpn and keys at that time. But then again, maybe I 
 did increase it myself.

Yes, I'm sure. It was this commit where I updated the sample dh params
from 1024 to 2048 bits:
https://github.com/OpenVPN/openvpn/commit/b77c27a

-Steffan

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] push client network to server

[Steffan Karger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 21-05-15 14:45, Gert Doering wrote:
 On Thu, May 21, 2015 at 02:37:36PM +0200, David Sommerseth wrote:
 It's not that easy, unfortunately.  And you've already been down
 that path once already.
 
 To switch to TLS mode, you need to use --ca, --cert and --key.
 In addition on the server side you need --dh as well.  This means
 you need to have a CA where you issue certificates.
 
 In addition, you're back to the need to use --client-config-dir
 and - --iroute as well to make LAN-to-LAN-over-VPN work.
 
 And then you can add --tls-auth as well, on top of all of this.
 
 I seem to remember that there is a way to do peer-to-peer (so, not
 call --server and --client) but still do TLS - by having the
 TLS server configured with --ca, --cert, --key and
 --tls-server, and the peer with --tls-client.

That is correct, and we use it all the time in our 'make check' tests.
For an example, look at the loopback config files for inspiration:
https://github.com/OpenVPN/openvpn/blob/master/sample/sample-config-files/loopback-server
https://github.com/OpenVPN/openvpn/blob/master/sample/sample-config-files/loopback-client

Do note that the networking bits of these configs are *not* usable in
the real world.  But the crypto bits (tls-{client,server}, dh, ca,
key, cert, tls-auth) show how to get a point-to-point tls connection
going.

- -Steffan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVXl3BAAoJEJgCyj0AftKI9p8H/jHSF4+s7ET5LiGleURJ3YB6
8ef1TJaz62lQr8okF5KnEKz8IX/GuyRY1bwF31rGmpSfIZcs73i/pfbOMVc2uTYA
MmgJUR8RxiKfjeEGp9RnLjnCxs1MpM5vaSsr81BQtzyxyiyZEh3+TBzXjbsLPdVa
RZIeDv4z8m7wF3GBPESrgfAXXGhKBu2I+uhGxcUHGD13eHeT1PYS3XtCNSVUKuIc
MMFrOiZyHzIP7raBcbAZ2CXoQXdqJl2RTWmxFRkhJjM8cIMJ/nvm6EwBMLngXq/f
/7Hvr3JuidHkBlnG6wkAeSrz0Xp7gHRb0WW9gfdjTpOr+LdKHoPyyzDczzPwTFQ=
=kBKG
-END PGP SIGNATURE-

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Testing with large keys

[Steffan Karger]

On 22-04-15 20:11, jack seth wrote:
 Ok I have been doing some experiments and I can connect using 1 bit DH 
 parameters.  Any bigger than that up to at least 13824 I get the following 
 'modulus too large' error on the client log:

 TLS_ERROR: BIO read tls_read_plaintext error: error:05066067:Diffie-Hellman 
 routines:COMPUTE_KEY:modulus too large: error:14098005:SSL 
 routines:SSL3_SEND_CLIENT_KEY_EXCHANGE:DH lib
 Wed Apr 22 07:08:58 2015 TLS Error: TLS object - incoming plaintext read 
 error
 Wed Apr 22 07:08:58 2015 TLS Error: TLS handshake failed

 Something interesting/weird also happened.  I tried to test 10001, 10002, and 
 10004 bit DH to find the exact place I would get the 'modulus too large' 
 error.  But the server log reported the DH parameters being 10008 instead.  I 
 did a test at 15104 that gave the same error but then I tried two more times 
 and the client just sat at the 'initial packet point' like it does with the 
 16384 bit parameters.  So somewhere between 13824 and 16384 it switches 
 between the error above and just sitting there 'frozen'.

 Questions: 1. Can the modulus error be cured?  2. Do you think the same 
 modulus error is going on when the client appears to freeze with parameters 
 larger than 13824 or is something else going (i.e. why does it freeze instead 
 of giving the 'modulus error')?  3. Why does the server log report 10001, 
 10002, 10004 bit DH as 10008?

All OpenVPN does here is pass along the DH parameters to OpenSSL. What 
you're seeing here are OpenSSL errors and OpenSSL behaviour. You can 
verify the behaviour wrt DH parameter handling using the openssl command 
line tools s_server and s_client:

$ openssl s_server -cert server.crt -key server.key -dhparam dh2048.pem

$ openssl s_client

Assuming that using the openssl command line tools renders the same 
results: unless anyone on this list has fiddled around with this in the 
same way, you will probably get better answers when asking your 
questions on the openssl list.

-Steffan

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Disconnects, maybe from Bad source address messages after connection

[Steffan Karger]

On 23-04-15 08:58, Gert Doering wrote:
 On Wed, Apr 22, 2015 at 05:25:54PM -0700, blz wrote:
 The server will just update its what IP/port is the client on? table
 entry, without restarting anything.

 What I'm wondering is how secure that is, such as how easily one could
 fake such a reconnect to get in on someone else's session, where they
 wouldn't even need a key? I hope this is just good ol' fashion paranoia
 on my part, but it would be nice to know. Thanks.

 The server updates its table entry only if the packet's HMAC validates,
 read the client knows the key material for that particular session.

It is even better: the server checks both the HMAC /and/ replay 
protection before updating its table entry. This means that an attacker 
also can't use older, previously valid, packets to mount a 
denial-of-service attack.

-Steffan

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] FreeBSD+cryptodev testers wanted

[Steffan Karger]

Hi,

See https://community.openvpn.net/openvpn/ticket/480

A bug was reported when using openvpn in daemon mode (--daemon), in 
combination with the OpenSSL cryptodev engine on FreeBSD.  The 
originally proposed patch is reported to fix the problem, but caused a 
change in the interpretation of config files, so was NAK'ed.  I proposed 
an alternative patch, which I believe will fix the issue without 
changing config file interpretation, but I do not have a set up to 
verify this.

So, is there anyone with a FreeBSD machine with cryptodev engine 
available who is willing to test the patch?

Thanks,
-Steffan

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] What size DH parameters for AES256?

[Steffan Karger]

On 28-03-15 20:05, jack seth wrote:
 I think I read somewhere that keys should be around 15K bit to match the
 security of AES256.  Do DH parameters need to be just as large? 
 Easy-RSA makes the keys and DH parameters the same bit size.

That was probably NIST SP 800-57, section 6.5.1 [1], which states
15360-bit DH or RSA has the same security level as AES256.  Both finite
field problems (such as DH) and integer factorization (such as RSA) are
placed in the same league.  So yes, to achieve an equal security level,
you should choose your DH group the same size as your RSA modulus.

On a practical note though, AES256 gives reasonable performance, but 15K
RSA/DH is _very_ slow.  If you don't care about the time it takes to set
up a connection (and generate DH group parameters) that is not a
problem, but for most real-world setups the performance hit is not
reasonable.

Also note that the reason to use AES256 is not that a 128-bits search
space is not enough, but because if powerful quantum computers ever
become reality, one can use Grover's algorithm [2] to reduce the search
space to 128 bit.  But, if powerful quantum computers do became reality,
both RSA and DH are completely broken [3].  Which makes it from my point
of view very reasonable to choose a security level similar to AES-128
for your DH parameters or RSA modulus.

-Steffan

[1]
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf

[2] https://en.wikipedia.org/wiki/Grover%27s_algorithm

[3] http://arxiv.org/abs/quant-ph/9508027

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] OpenSSL Security Advisory [19 Mar 2015]

[Steffan Karger]

On 21-03-15 02:31, Jason Haar wrote:
 Do any of them affect openvpn if it's set to use tls-auth (as recommended)?

 ie is openvpn immune from these if the bad guys don't have copies of
 your tls-auth file

Ah, sorry I forgot to mention tls-auth this time.  Yes, for all of these 
tls-auth protects against a mitm attacker without the tls-auth key.

-Steffan

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Remove support for key-method 1 from master/2.4

[Steffan Karger]

On 14-03-15 20:58, Richard Doyle wrote:
 On 03/14/2015 12:18 PM, Gert Doering wrote:
 On Sat, Mar 14, 2015 at 08:57:12AM -0700, Richard Doyle wrote:
 I still use key method 1 
 Why?  Genuine curiousity.

 (There has to be some benefit, otherwise it's not programmer lifetime
 well spent maintaining)
 Inertia (works for me).
 
 It was the standard method used when I setup my OpenVPN infrastructure.
 I'll migrate to method 2 when method 1 is gone.

Thanks for answering. This makes it a chicken-egg thing, because what I
propose is to make method 1 be gone. Apart from the proposed removal,
'method 2' is a stronger mechanism and I would strongly encourage you to
migrate.

-Steffan

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] New OpenVPN 2.3.6 Windows installers released - FREAK

[Steffan Karger]

On 06-03-15 17:42, debbie...@gmail.com wrote:
 Server Config:
 tls-cipher
 TLS-DHE-RSA-WITH-AES-256-CBC-SHA:DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA

 Just use tls-cipher DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA,
 TLS-DHE-RSA-WITH-AES-256-CBC-SHA is ready part of DEFAULT.

 Specifying the actual cipher I want to use means that no other cipher
 can be selected.
 This is my desired configuration. I have full control of server and
 clients.

 As for determining which desgnation each cipher currently is assigned,
 IE: !LOW (not low):!PSK etc
 I presume I can search the source for a reasonably simple assignment list.
 Will try later ..

 However, for clarification, which item takes precedence ?
 IE: DES-CFB1 64 bit default key (fixed) ... Verses ... !LOW
 If a contradiction is itroduced is it reported and how is it resolved ?

If you know what you want, specifying a single cipher is fine too. In 
that case there is no need to add the DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA 
part, as that will add more cipher suites to the list of allowed cipher 
suites. Next to specifying ciphers, OpenSSL support groups like 
'DEFAULT' or 'LOW'. OpenVPN just forwards this list to OpenSSL, so take 
a look at their documentation for details:
https://www.openssl.org/docs/apps/ciphers.html

This page might not tell you everything you want to know, the full 
'documentation' can be found here:
https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/ssl_ciph.c#L1457

-Steffan

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] New OpenVPN 2.3.6 Windows installers released - FREAK

[Steffan Karger]

Hi,

On Fri, Mar 6, 2015 at 12:32 PM,  debbie...@gmail.com wrote:
 Can somebody please explain this:

 Adding !EXP to the server side tls-cipher is enough to mitigate attacks. The
 suggested tls-cipher string is DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA. This
 disallows export ciphers, weak ciphers (e.g. DES), and RSA key exchange
 (note: not RSA authentication), but allows any future, stronger cipher
 suites.
 Clients who wish to rule out this attack on clients prior to 2.3.6-I002/I603
 can add !kRSA to their tls-cipher string
 ref:
 https://community.openvpn.net/openvpn/wiki/SecurityAnnouncement-FREAK

 This is what I get following these instructions:

 Server Config:
 tls-cipher
 TLS-DHE-RSA-WITH-AES-256-CBC-SHA:DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA

Just use tls-cipher DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA,
TLS-DHE-RSA-WITH-AES-256-CBC-SHA is ready part of DEFAULT.

 Server log:
 Fri Mar  6 11:24:00 2015 us=862202 OpenVPN 2.3_git
 [git:master/669f898b8fcaf7a8+] i686-pc-linux-gnu [SSL (OpenSSL)]
  [LZO] [LZ4] [EPOLL] [MH] [IPv6] built on Mar  3 2015
 Fri Mar  6 11:24:01 2015 us=427277 No valid translation found for TLS cipher
 '!EXP'
 Fri Mar  6 11:24:01 2015 us=427463 No valid translation found for TLS cipher
 '!LOW'
 Fri Mar  6 11:24:01 2015 us=427544 No valid translation found for TLS cipher
 '!PSK'
 Fri Mar  6 11:24:01 2015 us=427617 No valid translation found for TLS cipher
 '!SRP'
 Fri Mar  6 11:24:01 2015 us=427688 No valid translation found for TLS cipher
 '!kRSA'

These warnings are harmless (but annoying and confusing). I'll work up
a patch to get rid of these.

 Client Config:
 tls-cipher !kRSA

 Client log:
 Fri Mar 06 11:17:09 2015 us=390625 OpenVPN 2.3.6 i686-w64-mingw32 [SSL
 (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Mar 4 2015
 Fri Mar 06 11:17:10 2015 us=265625 No valid translation found for TLS cipher
 '!kRSA'
 Fri Mar 06 11:17:10 2015 us=281250 MANAGEMENT: Client disconnected
 Fri Mar 06 11:17:10 2015 us=281250 Failed to set restricted TLS cipher list:
 !kRSA: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match
 Fri Mar 06 11:17:10 2015 us=281250 Exiting due to fatal error

This results in an empty list, as this says empty, but no RSA key
exchange. That is what OpenSSL is complaining about. Just use
tls-cipher DEFAULT:!EXP:!LOW:!PSK:!SRP:!kRSA.

As you've noticed, getting tls-cipher right can be tricky. Not
specifically to you, but in general: tls-cipher really is an advanced
feature for people who know what they're doing. If you don't
understand *exactly* what you're doing, you might very well be causing
more harm than good. Please please please do not use it unless you
understand the consequences completely.

-Steffan

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] CN maximum length

[Steffan Karger]

Hi Jorge,

On 19-01-15 23:47, Jorge Luiz Silva Peixoto wrote:
 Is the comparison between strlen ((char *)buf) and size correct?
 Shouldn't be less equal?

That check is correct, since strlen() excludes the NULL-character, and
we rely on the string begin NULL-terminated.

 I'll do some tests, e.g. changing TLS_USERNAME_LEN from 64 to 65.

At first glance this seems to be the right fix, but keep in mind that
you'll have to change the warning messages using the value too, to keep
them displaying '64'.

 PS: According to rfc5280, common name maximum length is 64.

Yes, and that is where this errors stems from. The strings used by
rfc5280 are not NULL-terminated, whereas C strings are.

Please feel free to send your patch to
openvpn-de...@lists.sourceforge.net if you decide to do a patch for
this. (and please use git format-patch to create such a patch).

-Steffan

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] The Cryptographic Doom Principle

[Steffan Karger]

On 10-01-15 18:51, Jonathan K. Bullard wrote:
 I just noticed an old (December 2011) blog post by Moxie Marlinspike,
 The Cryptographic Doom Principle
 http://www.thoughtcrime.org/blog/the-cryptographic-doom-principle/? 
 mentioned
 recently on Hacker News https://news.ycombinator.com/, and wondered
 how the OpenVPN protocol works: in particular, does it encrypt then
 authenticate?

For the control channel it does whatever your TLS cipher suite does
(usually mac-then-encrypt, but with an up-to-date version of your crypto
library and having TLS-version negotiation enabled at both ends possibly
aead or encrypt-then-mac).

For the data channel, which is the most interesting since it is the
easiest to influence its traffic as an attacker, OpenVPN uses it's own
protocol, which does encrypt-then-mac. So as far as OpenVPN's own crypto
goes, we're good. Still, if TLS breaks, everything breaks (okay, there
is TLS-auth as a bonus, but that won't always save you either).

-Steffan

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] How can I use ECDSA keys for OpenVPN?

[Steffan Karger]

Hi,

On 22-12-14 12:35, Jan Just Keijser wrote:
 but do keep in mind that it is currently not possible to use SHA2 signed
 ECDSA certificates , unless a patch is applied.

That is true for OpenVPN 2.3 (and possibly easy-rsa 2, I'm not sure),
but both openvpn git master (which will some day become OpenVPN 2.4) and
easy-rsa git master (which will some day become easy-rsa 3) do support
ECDSA with SHA2.

-Steffan

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Assertion failed at multi.h:411 - now 409

[Steffan Karger]

Hi Eike,

On 21-11-14 17:07, Eike Lohmann wrote:
 Hi, today we got the same error, after a kill client via the management 
 interface.
 
 Nov 21 15:43:08 myserver ovpn[1945]: MANAGEMENT: CMD 'kill client'
 Nov 21 15:43:08 myserver ovpn[1945]: client/1.2.3.4:3271 SIGTERM[soft,] 
 received, client-instance exiting
 Nov 21 15:43:08 myserver ovpn[1945]: PLUGIN_CALL: POST 
 /usr/lib/openvpn/radiusplugin.so/PLUGIN_CLIENT_DISCONNECT status=0
 Nov 21 15:43:08 myserver ovpn[1945]: MANAGEMENT: Client disconnected
 Nov 21 15:43:08 myserver ovpn[1945]: Assertion failed at multi.h:409
 Nov 21 15:43:08 myserver ovpn[1945]: Exiting
 Nov 21 15:43:08 myserver ovpn[1945]: Closing TUN/TAP interface
 Nov 21 15:43:08 myserver ovpn[1945]: /sbin/ifconfig tun0 0.0.0.0
 
 Debian wheezy:
 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3
 
 openvpn:
 Architecture: amd64
 Version: 2.2.1-8+deb7u2
 
 Any Ideas or need more information?

Sorry, no immediate ideas here. Did you see this error more often? Or
can you perhaps even reproduce it at will? If you can, please test
whether this is still present in 2.3 (there are debian packages of 2.3
available: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos).

If this is still present in 2.3, please specify how you can reproduce
the error, including the (anonymized) server config and a log at --verb
4 or higher.

-Steffan

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Help me figure out how to use tls-cipher

[Steffan Karger]

Hi,

On Fri, Oct 17, 2014 at 5:13 AM, jack seth bird_...@hotmail.com wrote:

 I have the following command in both the server and client configs
 'tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA256'.  The server starts up
 fine with this so I think the server side is good.  Both are running
 Openvpn 2.3.4.  Server is linux on my router, client is on a Windows 7
 Ultimate laptop.  Running the --show-tls command on the server and the
 client show the cipher as available.  My client config connects fine with
 the 'tls-cipher' command commented out.  Here is a portion of the client
 log:

 Thu Oct 16 22:10:09 2014 TLS_ERROR: BIO read tls_read_plaintext error:
 error:140830B5:SSL routines:SSL3_CLIENT_HELLO:no ciphers available
 Thu Oct 16 22:10:09 2014 TLS Error: TLS object - incoming plaintext read
 error
 Thu Oct 16 22:10:09 2014 TLS Error: TLS handshake failed


SHA256 digests are only supported by TLSv1.2, whereas OpenVPN by default
only does TLSv1.0 (because quite some corner cases break when enabling 1.2,
work-in-progress). To enable TLSv1.2, add 'tls-version-min 1.0' to both
server and client config file.

On a final note, tls-cipher is an expert feature for people who really know
what their doing and how OpenSSL reacts to specifying tls ciphers. Not
properly understanding what it does might result in a *less* secure
connection. Note that OpenVPN does not 'fall back' to insecure TLS/SSL
versions when the connection fails, like browser do, and thus is not
vulnerable to typical TLS/SSL fallback attacks. Furthermore, protecting
your TLS handshake using tls-auth (see man page) protects you against
attacks on the TLS implementation. Given these facts, is is almost always
wiser to let OpenSSL decide on the tls cipher to use.

-Steffan
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] multiple clients with same cert leads to problems

[Steffan Karger]

Hi Jason,

On 07-10-14 21:59, Jason Haar wrote:
 One thing we're doing is allowing duplicate-cn, but using our NAC test
 to reject clients using the same cert (get better logging of the
 offenders that way). Anyway, I have a Mac and Windows box set up to use
 the same cert to test this, and it causes an interesting situation...
 
 First client connects, second client connects, NAC script notices the
 same cert in use and kills the first connection. Second client later
 hangs up. If I then look at the first client hours later, it still
 thinks it's logged in! There is no error, it still has the tun interface
 up, but no traffic flows. The server shows no connection via either
 client (I use the management api to confirm that)
 
 We use --ping, and tcpdump confirms the  first client and server are
 still exchanging packets - but the server does not classify the client
 as being connected. But as the openvpn pings are still working, the
 client doesn't know it's actually disconnected. A simple kill -HUP on
 the client fixes everything as it forces a full restart
 
 So I have two questions:
 
 1. The client uses explicit-exit-notify - but it looks like using the
 kill management command on the server does not tell the client it is
 hanging up? Wouldn't that be a good idea?

Sounds like a reasonable plan to me, yes. Then again, I'm not very
familiar the networking bits of openvpn.

 2. The fact that ping is still working makes me think that means ping
 must be *separate* from session management? Isn't that a bad idea?

In OpenVPN each connection actually consists of two. One 'control' and
one 'data' channel. The control channel is actually the TLS connection,
which is set up by the TLS/SSL library. The ping packets are sent over
the control channel, indicating that the TLS connection is still fully
functional. Seems like OpenVPN is shutting down the data channel, but
not (successfully) shutting down the control channel. Sounds like a bug
to me.

-Steffan

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] OpenVPN log format changes when tls-auth is enabled

[Steffan Karger]

Hi,

On 29-09-14 15:50, Stephan Alz wrote:
 I had my ovpn servers in verb 3 mode. I didn't upgrade them just turned on 
 the tls-auth feature and surprisingly it stopped logging a lot of events.
 Instead of an output like this:
 
 Tue Jan 27 09:53:41 2009 119.137.85.240:2114 VERIFY OK: depth=1, 
 /C=DK/ST=CPH/L=COPENHAGEN/O=CTcash_Limited/OU=IT/CN=server/emailAddress=o...@awtoc.net
 Tue Jan 27 09:53:41 2009 119.137.85.240:2114 VERIFY OK: depth=0, 
 /C=DK/ST=CPH/O=CTcash_Limited/OU=IT/CN=client-1/emailAddress=o...@awtoc.net
 Tue Jan 27 09:53:42 2009 119.137.85.240:2114 Data Channel Encrypt: Cipher 
 ‘BF-CBC’ initialized with 128 bit key
 Tue Jan 27 09:53:42 2009 119.137.85.240:2114 Data Channel Encrypt: Using 160 
 bit message hash ‘SHA1′ for HMAC authentication
 Tue Jan 27 09:53:42 2009 119.137.85.240:2114 Data Channel Decrypt: Cipher 
 ‘BF-CBC’ initialized with 128 bit key
 Tue Jan 27 09:53:42 2009 119.137.85.240:2114 Data Channel Decrypt: Using 160 
 bit message hash ‘SHA1′ for HMAC authentication
 Tue Jan 27 09:53:42 2009 119.137.85.240:2114 Control Channel: TLSv1, cipher 
 TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
 Tue Jan 27 09:53:42 2009 119.137.85.240:2114 [client-1] Peer Connection 
 Initiated with 119.137.85.240:2114
 Tue Jan 27 09:53:42 2009 client-1/119.137.85.240:2114 OPTIONS IMPORT: reading 
 client specific options from: ccd/client-1
 Tue Jan 27 09:53:42 2009 client-1/119.137.85.240:2114 MULTI: Learn: 10.8.0.6 
 - client-1/119.137.85.240:2114
 Tue Jan 27 09:53:42 2009 client-1/119.137.85.240:2114 MULTI: primary virtual 
 IP for client-1/119.137.85.240:2114: 10.8.0.6
 Tue Jan 27 09:53:42 2009 client-1/119.137.85.240:2114 MULTI: internal route 
 10.10.1.0/24 - client-1/119.137.85.240:2114
 Tue Jan 27 09:53:42 2009 client-1/119.137.85.240:2114 MULTI: Learn: 
 10.10.1.0/24 - client-1/119.137.85.240:2114
 Tue Jan 27 09:53:43 2009 client-1/119.137.85.240:2114 PUSH: Received control 
 message: ‘PUSH_REQUEST’
 Tue Jan 27 09:53:43 2009 client-1/119.137.85.240:2114 SENT CONTROL 
 [client-1]: ‘PUSH_REPLY,route 192.168.1.0/24 255.255.255.0,dhcp-option DNS 
 10.8.0.1,redirect-gateway def1,route 10.8.0.1,ping 10,ping-restart 
 120,ifconfig 10.8.0.6 10.8.0.5′ (status=1)
 
 I only get 1 line in the logs:
 OPTIONS IMPORT: reading client specific options from: ...
 
 I did try verb mode 4 as well, it's the same. I don't want to go over that to 
 get raw packet info to the logfiles. Why is this happening? Tls-auth setting 
 should not affect the logging. I get the same result if I log into a separate 
 logfile or to syslog.

I tried, but am not able to reproduce this. I tested with both 2.3 and
git-master. Both keep logging all the output just fine with tls-auth
enabled. Are you sure you did not change anything else? Permissions on
log files perhaps? Or just different log file? (Just some wild guesses)

-Steffan

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Is there a reason that ciphers can't be specified within connection stanzas?

[Steffan Karger]

Hi,

On 04-10-14 13:22, Gert Doering wrote:
 On Thu, Oct 02, 2014 at 11:39:29AM -0400, Joe Patterson wrote:
 I was considering the possibility of changing my cipher, and was trying to
 figure out the logistics of it, and it seems like I'm probably stuck with
 change everything all at once across all clients and servers, which is
 kind of painful.
 
 Yes, this is how it is today.

A possible 'transition plan' is to run a second OpenVPN server on a
different port or ip with a new cipher setting, and then migrate clients
one by one to the new server. Far from perfect, but at least a bit
better than 'change everything all at once'.

 We've started talking about pushable cipher settings, and potentially 
 full client-server cipher negotiations inside the TLS handshake, but
 this did not result in any code yet.

Also, the current code assumes on quite some places that the same cipher
mode is used for all data channel connections. It needs to be decoupled
before we can start with cipher negotiation.

-Steffan

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[Steffan Karger]

On 26 Sep 2014 07:37, Doug Lytle supp...@drdos.info wrote:

  Well my problem with this additional tls-auth method is that the droid
version does not support it yet:

 I don't have any problems with tls-auth using Feat-VPN on my Droid.

 http://www.featvpn.com/

Or use the original open source 'OpenVPN for Android' app, which is
maintained by one of the openvpn core developers. Works just fine with
tls-auth for me.

-Steffan
--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Openvpn security on VPS-es

[Steffan Karger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 24-09-14 11:21, David Sommerseth wrote:
 On 24/09/14 10:26, David Sommerseth wrote:
 On 24/09/14 10:15, Gert Doering wrote:
 But to get to the point, that if I setup openvpn on my
 droplet and let's say an evil admin sniffing my traffic for 3
 months with tcpdump then decides to decrypt that traffic what
 tools does he have (if any to do this). At this point he has
 a pcap file and the openvpn server certificates and keys.
 
 Now that is easy - OpenVPN does PFS, so the stored keys won't 
 help decrypt sniffed session traffic.
 
 If an attacker have sniffed the complete handshake and is in 
 possession of the keys, I believe it is a theoretical
 possibility to compromise the key exchange handshake.  Which
 again gives you the access to the tunnel data.  If the attacker
 in addition have access to client keys, then this process goes
 even faster.  But it is correct that you don't get the raw key
 out of the handshake.
 
 Gert and I have had a private discussion regarding if it is
 possible or not to break the session key.  We both agree that it's
 not an easy task, and capturing data + having they key material
 alone isn't enough to break the session key.

I agree, OpenVPN does offer forward secrecy. At least when the setup
uses TLS-mode (like the howto of digitalocean the OP referred to).

Let me elaborate a bit. OpenVPN can run in two modes:
1. Static key mode (using '--secret file'). This uses a pre-shared
static key, which is not rotated at all. An attacker with that key and
a pcap can decrypt all traffic since the last time you (manually)
rotated the key. Unless you know what you're doing and have good
reasons to use it, do not use this mode.

2. Dynamic key mode. This uses TLS to set up a secure channel over
which the actual data encryption keys are exchanged. This mode
protects you as much as TLS does. By default, OpenVPN connections use
a dynamic key exchange, like (Ephemeral) Diffie-Hellman or - for older
versions - Ephemeral RSA. The TLS session keys will then exist at most
(1) between two session negotiations for ephemeral DH, (2) for an
OpenVPN connection for non-ephemeral DH or (3) for the OpenVPN process
lifetime for ephemeral RSA.

For a scenario like the OP describes (pcap + current memory dump), the
attacker can only decrypt traffic for which the current in-memory key
has been used (see above).

Note that this scenario restricts the attacker to be passive (i.e.
just traffic / memory dumps). An active attacker could use a
man-in-the-middle position to attack the cryptographic handshake or
implementation, like David describes. That however does not enable her
to 'go back in time' further then the validity of the keys used during
the attack. Traditionally, we recommend to use OpenVPN's tls-auth
feature as an extra layer of protection against man-in-the-middle
attacks. In this scenario however, the attack already has access to
the tls-auth keys, so that won't help you here. (Still, use tls-auth,
it protects you from a lot of other bad stuff.)

This ended up as more text than I intended. I hope it clarifies more
than it confuses ;)

- -Steffan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUI4j9AAoJEJgCyj0AftKIBCoIAMLpmfGlnZ0rXcuw6yP7f62/
2TRxLSXtRJx/Z211F+s0+y7WOiFe18bkCfNXQI14RJJTLuX1JEZGNNTq4xI6Uhfo
p54q3VzfuYHbx7RwXe5oNxZGaFywiBL70AKT6Icjoqc4EzuYTJVy7N0NpeHV2CCq
TC0RiH3B6s4dhhauqc6ldeNv7Ltld36Lk5vgD5d/wfSJ/EaUOZnF/cgJbz1vzAhL
Xc/jF8+1OjhAAIPhz8M2eU+KKt7txfGJ8+Al4EiUGx2lC9LSgn2MdCNyAQL6W2eu
vohQqq9wBql83zNRaboMMtOg3DD8mADKF2SFYUFqP0c9COrAAe4GuUCY5lBTZnQ=
=b1aU
-END PGP SIGNATURE-

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] is it safe to let all clients negotiate tls-ciphers?

[Steffan Karger]

Hi,

On Mon, Sep 1, 2014 at 4:15 PM, Jan Just Keijser janj...@nikhef.nl wrote:
 On 01/09/14 00:55, Jason Haar wrote:
 So am I correct in
 saying that an openvpn network using tls-auth plus client certs should
 be effectively immune to MiTM attacks, thereby making it OK to leave as
 much decision making as possible to the server?
 the 'tls-cipher' negotiation is the first part of any OpenVPN
 connection. It is used to initialize the contol channel authentication.
 The control channel init phase can be strengthened with the 'tls-auth'
 option, which causes openvpn to drop any packets that are not signed
 with the right key.

Indeed. This means that tls-auth protects you against mitm attacks on
the TLS handshake and the TLS implementation. It does not protect you
when the TLS handshake can be broken passively (e.g. when the peers
autonomously decide to use a weak cipher suite).

 In my opinion the *clients* do not need to specify a stronger list of
 tls-ciphers, but the server should. If the openvpn server only offers
 strong ciphers for negotiating the control channel setup then any
 clients that want to use weak ciphers are automatically excluded.

I agree. Layered security is nice, but in this case it is probably not
worth the management burden. Though if you are only in control of the
client, you can still choose to ensure strong cipher suites if you
really want to. But if you don't trust the server to choose a proper
cipher, you probably should not trust it with your plaintext either...

 If a weak tls-cipher is chosen then a MitM attack is theoretically
 possible , or at least someone might be able to decipher the control
 channel part too quickly.  The data channel part is not affected by this.

I don't agree here. The data channel keys are exchanged over the
control channel. If the control channel is compromised, an attacker
could obtain of influence the keys for the data channel. Hence, the
control channel security is crucial to the data channel security.

-Steffan

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] How to call Static OpenSSL Libraries?

[Steffan Karger]

Hi Peter,

On 13-08-14 15:11, pbar...@netprotec.com wrote:
 I have compiled OpenSSL libraries statically and now have libssl.a and
 libcrypto.a.  When I run ./configure it never finds ssl_ctx_new.  I have
 tried many variations on the ./configure, here is my latest one:
 
 ./configure --disable-shared OPENSSL_SSL_LIBS=-L/usr/local/ssl/lib/
 -lssl OPENSSL_CRYPTO_LIBS=-L/usr/local/ssl/lib/
 -lcryptoOPESSL_SSL_CFLAGS=-I/usr/local/ssl/include/
 OPENSSL_CRYPTO_CFLAGS=-I/usr/local/ssl/include/
 
 Any help with setting the static library would be appreciated.

I use the following flags to successfully compile OpenVPN against my own
(static) OpenSSL build:

OPENSSL_SSL_LIBS=-Wl,--no-as-needed -L$(pwd)/../openssl -lssl \
OPENSSL_SSL_CFLAGS=-I$(pwd)/../openssl/include \
OPENSSL_CRYPTO_LIBS=-L$(pwd)/../openssl -lcrypto -ldl \
OPENSSL_CRYPTO_CFLAGS=-I$(pwd)/../openssl/include \
./configure --disable-shared

Make sure to not have any openssl development system packages installed,
because pkg-config will then override your OPENSSL CFLAGS/LIBS variables
(I think that's a bug in the OpenVPN build system, patches are welcome).

-Steffan

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

Re: [Openvpn-users] OpenVPN and Multi-Core processor

[Steffan Karger]

Hi,

On Wed, Aug 6, 2014 at 3:20 PM, Gert Doering g...@greenie.muc.de wrote:
 On Wed, Aug 06, 2014 at 02:12:12PM +0200, David Sommerseth wrote:
 The encryption and decryption using symmetric keys are really fast.

 fast, but used very very often...

Yes, and less difficult to separate. That is why I would tackle this
one first too.

 My rough idea was something like

  - one control thread doing the IP routing and client connection maintenance
  - one group of threads to do decrypt incoming packet
  - one group of threads to do encrypt outgoing packet and send away

 and of course the control thread could split off the asymmetric crypto
 to yet another thread...  this should be sufficient to at least utilize
 a few more cores, until we get to bottlenecks in the central thread.

More or less what I had in mind too. If possible, I would try to do
just the control/data decision in a thread different from the
connection maintenance. That would prevent the data channels from
choking up during connection attempts.

-Steffan

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] OpenVPN and Multi-Core processor

[Steffan Karger]

Hi Joe,

On Wed, Aug 6, 2014 at 10:06 PM, Joe Patterson j.m.patter...@gmail.com wrote:
 The only disadvantage I see is that it does
 prevent a single client from being able to be serviced by multiple cores,
 but if I'm not wrong that's going to be a problem whether it's threaded or
 multi-process, unless you're using ecb or ctr ciphers (and I don't see any
 ctr ciphers in my openssl, and wouldn't suggest using an ecb one), so I
 suspect that problem will be endemic.

For the typical road-warrior scenario (one server, many clients) you
are probably right that a single user won't benefit much from
data-channel threading. However, in a high-capacity site-to-site link,
many concurrent connection by many users are handled by a single
connection instance. In this case threading would enable processing
multiple network packets concurrently. Though that does not speed up
processing of a single packet, it will speed up the total connection
almost linear to the number of cores.

-Steffan

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Has our dear friend Samuli revoked his public signing key?

[Steffan Karger]

Hi,

On Mon, Jul 21, 2014 at 11:33 AM, Lisa Minogue lmino...@mail.be wrote:
 Oh no!

 Has someone hacked into the server and replaced or altered the certificate? 
 Have software hosted on the server been compromised or infected with malware 
 and backdoors?

Works for me:
=
wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg | apt-key add -
--2014-07-21 13:38:23--  https://swupdate.openvpn.net/repos/repo-public.gpg
Resolving swupdate.openvpn.net (swupdate.openvpn.net)... 173.192.224.173
Connecting to swupdate.openvpn.net
(swupdate.openvpn.net)|173.192.224.173|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1780 (1.7K) [application/octet-stream]
Saving to: ‘STDOUT’

100%[==] 1,780   --.-K/s   in 0s

2014-07-21 13:38:24 (364 MB/s) - written to stdout [1780/1780]

OK
=

Do you perhaps not have the Starfield Class 2 Certification Authority
certificate in you local trust store?

-Steffan

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users