Security issue in OpenVPN when Server Mode is "Remote Access (SSL/TLS)"

[albgen]

hi,

i have setup an OpenVPN server with the Server Mode as "Remote Access (SSL/TLS)".
Using client export package, i extracted the config and tested on a client machine.
Everything is working normally but the issue is that if i change the key file(maybe some letters on it and save it), it will connect anyway and it is working normally!!!

Is this behavior normal or am i missing something for this kind of setup?

pfSense 64 bit 2.4.2-RELEASE-p1

[Derelict]

Change what key file where and when? Please be more specific.

[albgen]

The TLS key on the client

[Pippin]

Need more info.
Exactly how is the setup, screenshots of server config, client config file and logs of server and client @ verb 4.

[johnpoz]

What exactly did you change?

I moved a line around and get this error when trying to connect…

Sun Jan 21 05:47:39 2018 us=615403 TLS: Initial packet from [AF_INET]64.53.xxx.xxx:1194, sid=bc91f4c8 763844f7
Sun Jan 21 05:47:39 2018 us=615403 tls-crypt unwrap error: packet authentication failed
Sun Jan 21 05:47:39 2018 us=615403 TLS Error: tls-crypt unwrapping failed from [AF_INET]64.53.xxx.xxx:1194

edit:
example the yellow and red lines reversed - see attached

[albgen]

hi all,

attached my server config.

What i changed for example is the firt letter of the tls.key file on the client.

2048 bit OpenVPN static key

–---BEGIN OpenVPN Static key V1-----
afddf...

TO

2048 bit OpenVPN static key

-----BEGIN OpenVPN Static key V1-----
bfddf...


[albgen]

@johnpoz:

What exactly did you change?

I moved a line around and get this error when trying to connect…

Sun Jan 21 05:47:39 2018 us=615403 TLS: Initial packet from [AF_INET]64.53.xxx.xxx:1194, sid=bc91f4c8 763844f7
Sun Jan 21 05:47:39 2018 us=615403 tls-crypt unwrap error: packet authentication failed
Sun Jan 21 05:47:39 2018 us=615403 TLS Error: tls-crypt unwrapping failed from [AF_INET]64.53.xxx.xxx:1194

edit:
example the yellow and red lines reversed - see attached

i have changed half of the key file with random numbers and than i get the following error which actually is different from you error:

Sun Jan 21 15:44:33 2018 TLS Error: local/remote TLS keys are out of sync:…

The problem is that being a key, even a change one single bit should give errors instead it is not.
No idea whats happening but it is concerning me a lot

[johnpoz]

I am not an expert but I do believe there is padding on the front and end of the key as presented, I don' think changing the first character is going to mess it up… Change a character in the middle.

So I changed a 3 in the middle of the presented "key" to a 2 and get this error

Sun Jan 21 09:20:38 2018 us=256706 TLS Error: local/remote TLS keys are out of sync: [AF_INET]64.53.xxx.xxx:1194
Sun Jan 21 09:20:48 2018 us=886641 TLS Error: local/remote TLS keys are out of sync: [AF_INET]64.53.xxx.xxx:1194

Maybe someone with more indepth understanding of the makeup of the key as presented can chime in.. Guess I could hunt down the rfc on the makeup, etc..  But I do know there is padding put in that could account for your changing of a character or beginning or end might not really cause an issue with the actual key being used.

edit:  Take a look here
http://lapo.it/asn1js/

So the "key" is not that full thing - its encoded in that block of text… So messing up a character would change the encoding of something sure but maybe not the actual "key" part..  You could play around with a parser of the encoding and decoding above..  to see what I am talking about.

[albgen]

@johnpoz:

I am not an expert but I do believe there is padding on the front and end of the key as presented, I don' think changing the first character is going to mess it up… Change a character in the middle.

So I changed a 3 in the middle of the presented "key" to a 2 and get this error

Sun Jan 21 09:20:38 2018 us=256706 TLS Error: local/remote TLS keys are out of sync: [AF_INET]64.53.xxx.xxx:1194
Sun Jan 21 09:20:48 2018 us=886641 TLS Error: local/remote TLS keys are out of sync: [AF_INET]64.53.xxx.xxx:1194

Maybe someone with more indepth understanding of the makeup of the key as presented can chime in.. Guess I could hunt down the rfc on the makeup, etc..  But I do know there is padding put in that could account for your changing of a character or beginning or end might not really cause an issue with the actual key being used.

edit:  Take a look here
http://lapo.it/asn1js/

So the "key" is not that full thing - its encoded in that block of text… So messing up a character would change the encoding of something sure but maybe not the actual "key" part..  You could play around with a parser of the encoding and decoding above..  to see what I am talking about.

padding has nothing to do. Being a key, as said previously, even if you change a single bit it must not work because means it's another key. I have changed one char which means 4 bit! There is something else.

[johnpoz]

"padding has nothing to do. Being a key, "

Like I said I do not believe that the list of characters given are the actual key.. So changing a couple of characters depending on their location may or may not change the actual key as it is decoded from string of text..  ie padding..

Maybe someone with better understanding how the key is encoded and decoded from that can explain it too you better.

[albgen]

@johnpoz:

"padding has nothing to do. Being a key, "

Like I said I do not believe that the list of characters given are the actual key.. So changing a couple of characters depending on their location may or may not change the actual key as it is decoded from string of text..  ie padding..

Maybe someone with better understanding how the key is encoded and decoded from that can explain it too you better.

There is no encoding on the key, no padding and nothing else! It is a KEY!
Read online what does that "2048 bit OpenVPN static key" means!

[johnpoz]

"There is no encoding on the key, no padding and nothing else! It is a KEY!"

Where did you read that at exactly???

An OpenVPN static key file contains enough entropy to key both a 512 bit cipher key and a 512 bit HMAC key for authentication.

Here
https://openvpn.net/index.php/open-source/faq/77-server/327-changed-hex-bytes-in-the-static-key-the-key-still-connects-to-a-remote-peer-using-the-original-key.html

[albgen]

@johnpoz:

"There is no encoding on the key, no padding and nothing else! It is a KEY!"

Where did you read that at exactly???

An OpenVPN static key file contains enough entropy to key both a 512 bit cipher key and a 512 bit HMAC key for authentication.

Here
https://openvpn.net/index.php/open-source/faq/77-server/327-changed-hex-bytes-in-the-static-key-the-key-still-connects-to-a-remote-peer-using-the-original-key.html

On the same page that you posted. First line is the cipher. i'm changing the first char on the first line so it is a different cipher and the difference is 4 bit. How come that if i change the cipher, still works?!?
This has something to do with how it is implemented on OpenVPN or a bug or maybe a feature :P.

[johnpoz]

are you using auth or crypt.. Did you check it with the commands given?  If your using auth your using a key direction, etc.

So if you read that how is it stated its the KEY ;)  and there is not padding, etc.. When clearly that faq shows what I was talking about.

[albgen]

@johnpoz:

are you using auth or crypt.. Did you check it with the commands given?  If your using auth your using a key direction, etc.

So if you read that how is it stated its the KEY ;)  and there is not padding, etc.. When clearly that faq shows what I was talking about.

yes of course it is like you said and in fact you posted a javascript decoder :D

[johnpoz]

Here I created this key and started openvpn with higher verb to see the stuff in the log..

2048 bit OpenVPN static key

–---BEGIN OpenVPN Static key V1-----
0c744bab82db8b9005594629e0d3dc20
e5385b10371707b97b2fd143bfbfea48
3f066d2e336ba72df5271b2ae9397ecf
9024093516b0b8592dd2f71db4030384
b62e13935ac94d5939051f110c23022a
8400eb7acf7e118a3a48e37fd778e3e4
f051edb02b693938f86d456462556b71
dd352e3ed0bd6a28a9204f836828db7a
5881431ee57d0a513a7eb2d933af1872
43338f9d7af296a3b0e903833c18499c
78f0eaef9d53512ee5261e222d217e8c
dfea6434d126a004ccf38886bdc58d78
4ed4cd50ccf87237913121e9592a36c8
8d3b0a0efbed91270b4fd0df37314550
b9f39f6166784bde212d5048ff262452
89013f096d5a96bc722952f48daaad34
–---END OpenVPN Static key V1-----

Jan 21 11:55:52 openvpn 18141 Incoming Control Channel Encryption: HMAC size=32 block_size=32
Jan 21 11:55:52 openvpn 18141 Incoming Control Channel Encryption: HMAC KEY: 4ed4cd50 ccf87237 913121e9 592a36c8 8d3b0a0e fbed9127 0b4fd0df 37314550
Jan 21 11:55:52 openvpn 18141 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 21 11:55:52 openvpn 18141 Incoming Control Channel Encryption: CIPHER block_size=16 iv_size=16
Jan 21 11:55:52 openvpn 18141 Incoming Control Channel Encryption: CIPHER KEY: 5881431e e57d0a51 3a7eb2d9 33af1872 43338f9d 7af296a3 b0e90383 3c18499c
Jan 21 11:55:52 openvpn 18141 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 21 11:55:52 openvpn 18141 Outgoing Control Channel Encryption: HMAC size=32 block_size=32
Jan 21 11:55:52 openvpn 18141 Outgoing Control Channel Encryption: HMAC KEY: b62e1393 5ac94d59 39051f11 0c23022a 8400eb7a cf7e118a 3a48e37f d778e3e4
Jan 21 11:55:52 openvpn 18141 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 21 11:55:52 openvpn 18141 Outgoing Control Channel Encryption: CIPHER block_size=16 iv_size=16
Jan 21 11:55:52 openvpn 18141 Outgoing Control Channel Encryption: CIPHER KEY: 0c744bab 82db8b90 05594629 e0d3dc20 e5385b10 371707b9 7b2fd143 bfbfea48
Jan 21 11:55:52 openvpn 18141 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key

Looks like the incoming is not the first part of the block, that is outgoing..

So are you using just auth or crypt.. With auth cipher is not even used only the HMAC would be used, etc.

[Pippin]

Edit:
Deleted, I should pay attention  :o

[johnpoz]

No that is not actually true Pippin, with tls-crypt the key is used… While I agree with you that with NCP the cipher will will be negotiated.  That does not remove the part about using tls-crypt and using the correct key from the ta.key file, etc.

Working out which exact key from the block of info that makes up the actual key block is the part that is a bit tricky..  I knew that block was not the whole key, etc.  I knew the hmac was in there as well... I worded as padding, which might of been a bit off..

The link I posted shows the details of what I was trying to get across..

I use NCP... But if I mess with the portion of that shared key file that is actually being used then you can not get in, etc.

And I end up using 128 GCM connection.. Which is what I wanted and is top of the list in the ncp settings, etc.

[Pippin]

Ah, in between posts  :)

I see he uses SHA1 160 bit.
So if he edit the file and changes the not used bits, it will still connect.

[pwood999]

Does this help ?  https://openmaniak.com/openvpn_static.php