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

[Sebastian Rubenstein]

Hi,

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:

remote-random
remote somevpn.com 443
proto tcp-client
tls-client
dev tun
persist-tun
persist-key
nobind
pull
redirect-gateway def1
route-delay 3
auth-user-pass password.txt
verb 3
remote-cert-tls server
key-direction 1
cipher AES-256-CBC
auth SHA512
mute-replay-warnings
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
<ca>
-----BEGIN CERTIFICATE-----

Large chunks of alphanumeric text

-----END CERTIFICATE-----
</ca>
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----

Large chunks of alphanumeric text

-----END OpenVPN Static key V1-----
</tls-auth>


Below is the client-side log when my machine is trying to connect to one of the VPN servers. It has been redacted for clarity:


Wed Dec 7 08:27:54 2016 OpenVPN 2.3.14 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Dec 7 2016
Wed Dec 7 08:27:54 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08
Wed Dec 7 08:27:54 2016 WARNING: file 'password.txt' is group or others accessible
Wed Dec 7 08:27:54 2016 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Wed Dec 7 08:27:54 2016 Control Channel Authentication: tls-auth using INLINE static key file
Wed Dec 7 08:27:54 2016 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Dec 7 08:27:54 2016 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

(redacted for clarity)

Wed Dec 7 08:27:56 2016 Validating certificate key usage
Wed Dec 7 08:27:56 2016 ++ Certificate has key usage 00a0, expects 00a0
Wed Dec 7 08:27:56 2016 VERIFY KU OK
Wed Dec 7 08:27:56 2016 Validating certificate extended key usage
Wed Dec 7 08:27:56 2016 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Dec 7 08:27:56 2016 VERIFY EKU OK
Wed Dec 7 08:27:56 2016 VERIFY OK: depth=0, CN=de1-4096
Wed Dec 7 08:27:57 2016 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Dec 7 08:27:57 2016 Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Dec 7 08:27:57 2016 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Wed Dec 7 08:27:57 2016 Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Dec 7 08:27:57 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA

[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
> <tls-auth>
> #
> # 2048 bit OpenVPN static key
> #
> -----BEGIN OpenVPN Static key V1-----
>
> Large chunks of alphanumeric text
>
> -----END OpenVPN Static key V1-----
> </tls-auth>

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

[Jan Just Keijser]

Hi,

I fully agree with Steffan. An extra check you can throw in is to check
the client and server side certificates, as well as the CA certificate.
The server certificate may be signed using RSA4096 but if other
certificates in the chain are weaker then this offers little
protection. You can check the cipher strength of the CA certificate by
writing the CA blob

<ca>
-----BEGIN CERTIFICATE-----

Large chunks of alphanumeric text

-----END CERTIFICATE-----
</ca>

to a file and then run
openssl x509 -text -noout -in cert.pem | grep 'Public'

If you see a 1024 public key in the chain then I'd worry; 2048 bit certificates are fine.

JM2CW,

JJK

On 14/12/16 21:06, Steffan Karger wrote:
> 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
>> <tls-auth>
>> #
>> # 2048 bit OpenVPN static key
>> #
>> -----BEGIN OpenVPN Static key V1-----
>>
>> Large chunks of alphanumeric text
>>
>> -----END OpenVPN Static key V1-----
>> </tls-auth>
> 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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Sebastian Rubenstein]

Hi Jan,

Thanks for your tip.

> You can check the cipher strength of the CA certificate by
> writing the CA blob
>
> <ca>
> -----BEGIN CERTIFICATE-----
>
> Large chunks of alphanumeric text
>
> -----END CERTIFICATE-----
> </ca>
>
> to a file and then run
> openssl x509 -text -noout -in cert.pem | grep 'Public'

The name of the file must be cert.pem, right?

[David Sommerseth]

On 15/12/16 16:08, Sebastian Rubenstein wrote:
> Hi Jan,
>
> Thanks for your tip.
>
>> You can check the cipher strength of the CA certificate by
>> writing the CA blob
>>
>> <ca>
>> -----BEGIN CERTIFICATE-----
>>
>> Large chunks of alphanumeric text
>>
>> -----END CERTIFICATE-----
>> </ca>
>>
>> to a file and then run
>> openssl x509 -text -noout -in cert.pem | grep 'Public'
>
> The name of the file must be cert.pem, right?

Nope. openssl isn't picky about filenames at all. Call it
flying_pink_unicorn.coolness ... and it'll still work.

The important detail is that the "---------BEGIN CERTIFICATE------"
header and the corresponding footer is intact, as well as the "random"
characters in between.

--
kind regards,

David Sommerseth

[Sebastian Rubenstein]

Hi Steffan

Thanks for taking the time to explain to me the salient features of a good encryption/decryption VPN.

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

Is "forward secrecy" the same as "Perfect Forward Secrecy"? I have come across the latter on some websites.

How can you tell the data channel keys are refreshed at regular intervals?

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

Should I be worried if some VPN providers do NOT use "tls-auth" or "key-directing 1"? The reason for asking is I have been using commercial VPN providers for many years and some of them do NOT provide "tls-auth" or "key-directing 1".


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

You said that my VPN provider is using 4096 bit RSA based on the above statement. What about "ECDHE-RSA-AES256-GCM-SHA384"?

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

Could you explain in greater detail your statement "use AES-256-GCM for more efficiency on the data channel"?

My VPN provider is already using AES-256-GCM but its technical staff had told me that I needed to use their version of OpenVPN software because the community-version 2.3.14 does not offer AES-256-GCM. To be safe, I declined their offer.

Regards.

Sebastian

[David Sommerseth]

On 15/12/16 16:35, Sebastian Rubenstein wrote:
> Hi Steffan
>
> Thanks for taking the time to explain to me the salient features of
> a good encryption/decryption VPN.
>
>>> tls-client
>>
>> This means you're using TLS for forward secrecy, and are refreshing you
>> data channel keys (at least) hourly. That's good.
>
> Is "forward secrecy" the same as "Perfect Forward Secrecy"? I have
> come across the latter on some websites.

Yes.

> How can you tell the data channel keys are refreshed at regular intervals?

You will see "Data Channel Encrypt: Cipher ....." lines appearing at
regular intervals in the log file, at least with --verb 3.

It can also be irregular intervals as well, if --reneg-bytes or
--reneg-pkts are used. But the key point is that you see more of those
"Data Channel Encrypt: " lines in your logs with the same process ID.

>> 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.
>
> Should I be worried if some VPN providers do NOT use "tls-auth" or
> "key-directing 1"? The reason for asking is I have been using
> commercial VPN providers for many years and some of them do NOT
> provide "tls-auth" or "key-directing 1".

Probably no need to be overly concerned, at least when thinking about
the client side security. The server side though can benefit more from
this feature.

But --tls-auth makes it far harder to inject packets, as
both client and server will just throw away packets with an unexpected
HMAC signature. However, commercial public VPN providers will need to
provide the same key to all its users, so if the packet injection comes
from a user who managed to get a copy of that --tls-auth key, the
protection isn't effective any more.

>>> Wed Dec 7 08:27:57 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
>>
>
> You said that my VPN provider is using 4096 bit RSA based on the
> above statement. What about "ECDHE-RSA-AES256-GCM-SHA384"?

ECDHE - Elliptic Curve with Diffie Hellman key exchange
RSA - using RSA keys
AES256 - encryption using AES 256 bit key
GCM - with GHASH authentication
SHA384 - SHA2 384 bits hashing algorithm

This is all good.

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

> My VPN provider is already using AES-256-GCM but its technical staff
> had told me that I needed to use their version of OpenVPN software
> because the community-version 2.3.14 does not offer AES-256-GCM. To
> be safe, I declined their offer.

We're getting really close releasing v2.4. I'll probably wrap up the
2.4_rc2 later today - ready for a public release during tomorrow, and
the final v2.4.0 release is scheduled for Dec 28th [1] unless something
really odd and unexpected is showing up. But it has to be a real
blocker issue, not a silly uncritical issue

So if the VPN provider uses a proper community based version and not
their own AES-GCM implementation, this should work quite fine out of the
box with v2.4.


[1] <https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn24>


--
kind regards,

David Sommerseth

[Steffan Karger]

Hi,

On 15 December 2016 at 19:11, David Sommerseth
<***@sf.lists.topphemmelig.net> 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

[Dreetjeh D]

Hi,

Thanks for the explanations.

Pippin

----------
Op 15-12-2016 om 23:05 schreef Steffan Karger:

Op 15-12-2016 om 21:10 schreef David Sommerseth:

[Sebastian Rubenstein]

Thanks Steffan for your explanation but....

> Sent: Friday, December 16, 2016 at 6:05 AM
> From: "Steffan Karger" <***@karger.me>
> To: "openvpn-***@lists.sourceforge.net" <openvpn-***@lists.sourceforge.net>
> Subject: Re: [Openvpn-users] Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?
>
>
> 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.

in terms of cryptographic strength, AES-256-GCM is comparable to HMAC-SHA256?

Regards.

Sebastian

[Jan Just Keijser]

Hi,


On 16/12/16 13:27, Sebastian Rubenstein wrote:
> Can I take your above statement into consideration when I shop for a
commercial VPN provider? For example, before I buy a subscription plan,
I will ask if they use tls-auth ta.key. If they do, it means they trust
their customers, yes?

Not really - it means they use tls-auth to protect their servers against
DDoS attacks. I'd not trust the tls-auth key file provided by a large
VPN provider at all, as almost *anybody* will have access to that file.


On 16/12/16 13:31, Sebastian Rubenstein wrote:

> 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.
> in terms of cryptographic strength, AES-256-GCM is comparable to HMAC-SHA256?
>
>

AES-256-GCM is an alternative for AES-256 + SHA2 and is , as Steffan
wrote, much faster due to a very nicely optimized implementation in the
underlying OpenSSL libs.
Most https:// connections nowadays are based on AES-256-GCM so they can
be considered trusted+secure.

HTH,

JJK

[Sebastian Rubenstein]

> Sent: Friday, December 16, 2016 at 2:31 PM
> From: "Jan Just Keijser" <***@nikhef.nl>
> To: "Sebastian Rubenstein" <***@gmx.com>, openvpn-***@lists.sourceforge.net
> Subject: Re: [Openvpn-users] Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?

Hello Jan, thanks for your reply.

I have learnt something new from you. I was under the impression that tls-auth is used to protect customers while in actual fact, it is used to protect the VPN provider's servers. How ignorant of me!
>
>
> Not really - it means they use tls-auth to protect their servers against
> DDoS attacks. I'd not trust the tls-auth key file provided by a large
> VPN provider at all, as almost *anybody* will have access to that file.
>
>
Having said that, what alternatives would you propose that a large VPN provider could use, since *every customer* will have access to tls-auth key file?

Regards.

Sebastian

[Jan Just Keijser]

Hi,

On 16/12/16 16:34, Sebastian Rubenstein wrote:
>> Sent: Friday, December 16, 2016 at 2:31 PM
>> From: "Jan Just Keijser" <***@nikhef.nl>
>> To: "Sebastian Rubenstein" <***@gmx.com>, openvpn-***@lists.sourceforge.net
>> Subject: Re: [Openvpn-users] Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?
> Hello Jan, thanks for your reply.
>
> I have learnt something new from you. I was under the impression that tls-auth is used to protect customers while in actual fact, it is used to protect the VPN provider's servers. How ignorant of me!
>>
>> Not really - it means they use tls-auth to protect their servers against
>> DDoS attacks. I'd not trust the tls-auth key file provided by a large
>> VPN provider at all, as almost *anybody* will have access to that file.
>>
>>
> Having said that, what alternatives would you propose that a large VPN provider could use, since *every customer* will have access to tls-auth key file?
>
>
well, it's not 100% black and white: current VPN providers will use
tls-auth mostly to protect their own servers, but it *does* protect the
clients a little bit as well - it prevents DDoS attacks on the VPN
client as well (but those hardly ever occur in the first place) and it
actually makes it slightly harder for the NSA to decrypt the traffic ;)

With the upcoming 2.4 release and/or the new tls-crypt option security
*is* improved for the clients, as it will become harder to sniff any
part of the initial control channel negotiation. That doesn't mean that
*without* tls-crypt your connection is not secure, it just means that
with tls-crypt your connection is 0.5% more secure.

JJK

[Sebastian Rubenstein]

Hello Jan

> Sent: Friday, December 16, 2016 at 4:41 PM
> From: "Jan Just Keijser" <***@nikhef.nl>
> To: "Sebastian Rubenstein" <***@gmx.com>, openvpn-***@lists.sourceforge.net
> Subject: Re: [Openvpn-users] Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?
>
> With the upcoming 2.4 release and/or the new tls-crypt option security
> *is* improved for the clients, as it will become harder to sniff any
> part of the initial control channel negotiation. That doesn't mean that
> *without* tls-crypt your connection is not secure, it just means that
> with tls-crypt your connection is 0.5% more secure.
>
Thanks for your reply.

OpenVPN should thank you for extolling and evangelizing the benefits of upgrading to 2.4 :)

Regards.

Sebastian

[Gert Doering]

Hi,

On Fri, Dec 16, 2016 at 04:53:34PM +0100, Sebastian Rubenstein wrote:
> OpenVPN should thank you for extolling and evangelizing the benefits of upgrading to 2.4 :)

Since Jan-Just is "part of OpenVPN", he's in this with the rest of us :-)

gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ***@greenie.muc.de
fax: [phone] ***@net.informatik.tu-muenchen.de

[Sebastian Rubenstein]

Hello David,

Thanks for the time that you spent on explaining basic concepts to me.

> Sent: Friday, December 16, 2016 at 2:11 AM
> From: "David Sommerseth" <***@sf.lists.topphemmelig.net>
> To: "Sebastian Rubenstein" <***@gmx.com>, openvpn-***@lists.sourceforge.net
> Subject: Re: [Openvpn-users] Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?
>
> But --tls-auth makes it far harder to inject packets, as
> both client and server will just throw away packets with an unexpected
> HMAC signature. However, commercial public VPN providers will need to
> provide the same key to all its users, so if the packet injection comes
> from a user who managed to get a copy of that --tls-auth key, the
> protection isn't effective any more.

Thanks David for highlighting the above. When you wrote --tls-auth key, you were referring to the server-side --tls-auth key, which is owned and kept by the VPN provider, yes?

>
> So if the VPN provider uses a proper community based version and not
> their own AES-GCM implementation, this should work quite fine out of the
> box with v2.4.

My VPN provider has its own AES-GCM implementation and has even offered me the source code to check for security risks. As I am no expert in OpenVPN technologies and cryptography, I declined to use their software.

Regards.

Sebastian

[Dreetjeh D]

Sorry, i forgot cc


Hi,

I have a question about this:

Op 14-12-2016 om 21:06 schreef Steffan Karger:


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.



key-direction also works when ta.key is the same on both sides.

It is intended that no warning/info message appears in logs when using the same key?


Thanks Pippin.

[David Sommerseth]

On 15/12/16 20:55, Dreetjeh D wrote:
>
> Sorry, i forgot cc
>
> Hi,
>
> I have a question about this:
>
> Op 14-12-2016 om 21:06 schreef Steffan Karger:
>>
>> 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.
>>
> key-direction also works when ta.key is the same on both sides.
>
> It is intended that no warning/info message appears in logs when using
> the same key?

You can use

(1) --tls-auth ta.key

or

(2) --tls-auth ta.key {0,1}


In (1) you will get a connection, and I believe both sides will use the
same subkey in ta.key (haven't checked the code yet, so don't trust me
fully yet).

In (2) client and server must use different values, otherwise you will
see "packet HMAC authentication failed" errors in the log. If server
uses 0, the client must use 1 ... or vice versa. In this mode, the
client and server uses different sub-keys from ta.key.


--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

[Dreetjeh D]

Hi,

So in (2), parts of the one ta.key are used.....

I had a hunch when looking at the log`s stating:

>TLS: Initial packet from [AF_INET]............:1194, sid=XXXXXXXX
XXXXXXXX<

Where the X`s represent the subkey`s?

Thinking loud, the opposite side uses two different subkey`s, then four
subkey`s are derived.

If so, then one cannot use two different ta.key`s in same way one can
use client-CA and server-CA.


Thank you,

Pippin


Op 15-12-2016 om 21:10 schreef David Sommerseth:
> On 15/12/16 20:55, Dreetjeh D wrote:
>> Sorry, i forgot cc
>>
>> Hi,
>>
>> I have a question about this:
>>
>> Op 14-12-2016 om 21:06 schreef Steffan Karger:
>>> 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.
>>>
>> key-direction also works when ta.key is the same on both sides.
>>
>> It is intended that no warning/info message appears in logs when using
>> the same key?
> You can use
>
> (1) --tls-auth ta.key
>
> or
>
> (2) --tls-auth ta.key {0,1}
>
>
> In (1) you will get a connection, and I believe both sides will use the
> same subkey in ta.key (haven't checked the code yet, so don't trust me
> fully yet).
>
> In (2) client and server must use different values, otherwise you will
> see "packet HMAC authentication failed" errors in the log. If server
> uses 0, the client must use 1 ... or vice versa. In this mode, the
> client and server uses different sub-keys from ta.key.
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Technologies, Inc
>
>

[Steffan Karger]

Hi,

On 15 December 2016 at 21:35, Dreetjeh D <***@hotmail.com> wrote:
> So in (2), parts of the one ta.key are used.....
>
> I had a hunch when looking at the log`s stating:
>
> >TLS: Initial packet from [AF_INET]............:1194, sid=XXXXXXXX
> XXXXXXXX<
>
> Where the X`s represent the subkey`s?

No, that's just a random session identifier.

> Thinking loud, the opposite side uses two different subkey`s, then four
> subkey`s are derived.
>
> If so, then one cannot use two different ta.key`s in same way one can
> use client-CA and server-CA.

The tls-auth key is symmetic key, shared amongst all servers and
client that need to be able to connect to each other. It is 2048 bit
long, and divided into 4 512-bit subkeys. 2 for server-to-client
crypt/auth and two for client-to-server crypt/auth. Tls-auth uses
just the auth parts of these keys, and as David already described,
either the same subkey is used for both directions (if no
key-direction is specified), or different subkeys are used (if
key-direction is specified).

The reason why you won't see much VPN providers use the tls-auth key
is that it doesn't work that well with their model: they can't really
trust their clients, but have to give all clients the same tls-auth
key. This model works much better for company or private VPNs, where
the clients can be trusted to some extend. (I'm working on adding
support for client-specific tls-auth/tls-crypt keys to fix this, you
can expect a proposal on the openvpn-devel list early next year.)

-Steffan

[Sebastian Rubenstein]

Hello

> Sent: Friday, December 16, 2016 at 6:14 AM
> From: "Steffan Karger" <***@karger.me>
> To: "Dreetjeh D" <***@hotmail.com>
> Cc: "openvpn-***@lists.sourceforge.net" <openvpn-***@lists.sourceforge.net>
> Subject: Re: [Openvpn-users] Fwd: Re: Experts' opinions needed: Is my VPN provider using weak or strong encryption algorithms?
>
>
> The reason why you won't see much VPN providers use the tls-auth key
> is that it doesn't work that well with their model: they can't really
> trust their clients, but have to give all clients the same tls-auth
> key. This model works much better for company or private VPNs, where
> the clients can be trusted to some extend.

Can I take your above statement into consideration when I shop for a commercial VPN provider? For example, before I buy a subscription plan, I will ask if they use tls-auth ta.key. If they do, it means they trust their customers, yes?

> (I'm working on adding
> support for client-specific tls-auth/tls-crypt keys to fix this, you
> can expect a proposal on the openvpn-devel list early next year.)

That's good news, Steffan. I wonder why your proposed feature was not included in earlier versions of OpenVPN? Was it because of time constraints? complexity in coding?

Regards.

Sebastian

[David Sommerseth]

On 15/12/16 21:35, Dreetjeh D wrote:
> Hi,
>
> So in (2), parts of the one ta.key are used.....
>
> I had a hunch when looking at the log`s stating:
>
> >TLS: Initial packet from [AF_INET]............:1194, sid=XXXXXXXX
> XXXXXXXX<
>
> Where the X`s represent the subkey`s?
>
> Thinking loud, the opposite side uses two different subkey`s, then four
> subkey`s are derived.
>
> If so, then one cannot use two different ta.key`s in same way one can
> use client-CA and server-CA.

That is correct. --tls-auth (and --tls-crypt in v2.4) requires that the
provided key (ta.key in my example below, as you top-post) is shared
among all clients and server.

This is _by design_, as it is not possible to derive a shared secret
this early in the packet processing. This check happens before the SSL
library really get a chance to look at the TLS packet, which is using
the client/server keys and certificates), even before OpenVPN checks if
this packet is a data channel or control channel packet.

This HMAC check even happen so early that if you use UDP as transport on
your server, the UDP port will seem to be closed by port scanners. If
the HMAC signature in the UDP packet doesn't make sense, the packet is
dropped instantly.

(With TCP as transport, it is different as the SYN/ACK handshake needs
to complete before you can start to send packets over the wire)


--
kind regards,

David Sommerseth
OpenVPN Technologies, Inc

> Op 15-12-2016 om 21:10 schreef David Sommerseth:
>> On 15/12/16 20:55, Dreetjeh D wrote:
>>> Sorry, i forgot cc
>>>
>>> Hi,
>>>
>>> I have a question about this:
>>>
>>> Op 14-12-2016 om 21:06 schreef Steffan Karger:
>>>> 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.
>>>>
>>> key-direction also works when ta.key is the same on both sides.
>>>
>>> It is intended that no warning/info message appears in logs when using
>>> the same key?
>> You can use
>>
>> (1) --tls-auth ta.key
>>
>> or
>>
>> (2) --tls-auth ta.key {0,1}
>>
>>
>> In (1) you will get a connection, and I believe both sides will use the
>> same subkey in ta.key (haven't checked the code yet, so don't trust me
>> fully yet).
>>
>> In (2) client and server must use different values, otherwise you will
>> see "packet HMAC authentication failed" errors in the log. If server
>> uses 0, the client must use 1 ... or vice versa. In this mode, the
>> client and server uses different sub-keys from ta.key.
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>> OpenVPN Technologies, Inc