FEATURE: Infinite TLS-Crypt-V2 Client keys per Server key #104

TinCanTech · 2020-12-15T04:36:17Z

Easy-TLS can act as a fine-grain control of a single client X509 cert for multiple client nodes.

Something along the lines of:

--sub-cert-node=A3 build-tls-crypt-v2-client s01 c01 tct ab0123456789
This would create a TLS Crypt V2 key called: c01-A3-tls-crypt-v2.key

The text was updated successfully, but these errors were encountered:

TinCanTech · 2020-12-16T02:23:36Z

For those of you who understand such things, this is not commonly known as "a key array"

TinCanTech · 2020-12-26T20:37:12Z

This is more tricky than it looked at first - inline_index_serial_to_common_name will return multiple records because the X509 Client cert is the serial number to key on and that number is used for all sub-cert keys.

TinCanTech · 2020-12-26T21:31:33Z

Not so bad after all ;-)

Rebuilding the easytls inline index does not work because rebuilding does not detect --sub-cert-name .. yet ..

TinCanTech · 2020-12-28T03:07:28Z

@houmie this would allow you have multiple TLS CV2 keys per x509 Cert .. interested ?

houmie · 2020-12-28T08:18:17Z

Hi @TinCanTech
That sounds exciting. How does this affect the overall outcome?

This could mean that several OpenVPN servers should share the same X.509 certificate. Correct? If correct, it would allow more flexibility. Do you have any real life examples of how this could be beneficial?
Could this have any effect on hiding the footprint even better from deep packet inspections? (As the current version already does)
Is there any other advantage I couldn't think of?

TinCanTech · 2020-12-28T14:28:26Z

The main benefit which I can see is that you can have multiple VPN profiles all using different TLS CV2 Keys but all using the same x509 cert. So if one key gets matched by DPI another may not ;-)

houmie · 2020-12-28T23:51:13Z

Ah yes, makes sense. Sounds intriguing. :-) I'm happy to put some time aside and test this next week, if this is ready. Is there any documentation how this is setup compared to the classic way?

TinCanTech · 2020-12-29T00:27:39Z

There is no documentation, other than this issue.

Essentially, you would do this:

Complete your EasyRSA PKI, with all your required certs.
Use easytls to create Server TLS Crypt V2 key and Inline Server details.
Use easytls to create Client TLS crypt V2 keys and sub-certificate keys.
Note: These are not subordinate keys in any way but that is the word I chose for now.
Use easytls to create Inline files for your each of your Client keys and sub-certificate keys.

As a Client you would have something like:

houmie x509 cert x1, key x1
houmie TLS Crypt V2 key x1 - Inlined with X509 above.
houmie TLS Crypt V2 sub-key-1 x1 - Inlined with X509 above.
houmie TLS Crypt V2 sub-key-2 x1 - Inlined with X509 above.
etc ..

Each Inline file would have your client x509 details plus one sub-key. You would then plug these into an OpenVPN config file compatible with your server and voila!
Each TLS Crypt V2 key would have metadata based on your single x509 client.

Travellers may find they can use different keys if they are blocked by DPI.

There would also be details for other clients of yours and they can all have sub-keys.

One unfortunate flaw though is, users cannot remotely create their own TLS Crypt V2 key.
(Edit: Although it is very risky, there is a way for clients to remotely create a new client key)

TinCanTech · 2020-12-30T21:21:27Z

#110

houmie · 2020-12-30T21:26:06Z

Awesome. I will get to this 100% and test it. I'm away this week but return on Sunday. I definitely get it done. 👍🏼

TinCanTech · 2020-12-30T21:43:34Z

I am in the process of reviewing the new code for this. It is quite a large change but overall I am quite pleased with it. In the process of writing this I had to extend my test suite and also really drill down into the lower functions to ensure the correct data is returned. It can still be improved but it is getting sweeter ;-) It will be ready for 2021 !

TinCanTech · 2020-12-30T23:29:59Z

#64 #110

Opt: Use TBD Signed-off-by: Richard Bonhomme <[email protected]>

Signed-off-by: Richard Bonhomme <[email protected]>

…file Signed-off-by: Richard Bonhomme <[email protected]>

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech · 2021-01-01T21:46:48Z

Please let me know if you experience any problems. Please post your logs.
First thing to try is: ./easytls --verbose status

houmie · 2021-01-01T23:46:17Z

Hello. Happy new year, mate.
Yes, I should be back by Sunday (day after tomorrow) and can get started. I keep you in the loop. Thanks

houmie · 2021-01-03T10:09:31Z

Alrighty, as promised I'm back.

I have setup a fresh server with OpenVPN 2.5.0 installed.

I thought I double check the steps with you.

git clone https://github.com/TinCanTech/easy-tls
cp ./easy-tls/easytls /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
./easytls init-tls
cd /etc/openvpn/easy-rsa/pki/issued/
SERVER=$(basename server*.crt .crt)
cd ~
CLIENT=$(basename client*.ovpn .ovpn)
cd /etc/openvpn/easy-rsa
./easytls --openvpn=/usr/sbin/openvpn build-tls-crypt-v2-server $SERVER

In the old way I would continue creating the client like this:

./easytls --openvpn=/usr/sbin/openvpn build-tls-crypt-v2-client $SERVER $CLIENT

But I think now instead of that, I should be creating sub-certificate keys straight away?

./easytls --help doesn't really make it clear how to do it.

May you provide more details, please?

houmie · 2021-01-04T07:15:56Z

Good morning, Yes that's fine, I'm happy to create the config files for OpenVPN by myself. I just need to understand it better so I can automate it and test them on my end.

So that I understand this correctly. OpenVPN is injecting by default <tls-crypt> into the client.ovpn. So you recommend not to replace that with <tls-crypt-v2>, but instead insert only the inline into the server config file (or alternatively via argument)?
Do I then just remove <tls-crypt>...</tls-crypt> entirely from the client config files in this case?
Can a server config list multiple inlines from different clients? How is the <tag> defined that needs to go into server config? Is it still <tls-crypt-v2> Content of Inline key </tls-crypt-v2> or something else?

Thanks

TinCanTech · 2021-01-04T16:20:52Z

Whatever you choose to use on the server, you must also use on the client.

--tls-auth and --tls-crypt are simple pre-shared keys. The same key must be used at both ends. --tls-auth also requires --key-direction: Server uses 0, client uses 1.

--tls-crypt-v2 uses a server specific key and a client specific key. These are not a pre-shared key. The client key can only be used to connect to the server key which was used to create it.

At both ends, instead of specifying --ca, --cert, --key and --tls-*, you can simply use --config /etc/openvpn/easy-rsa/pki/easytls/vpn-node-01.inline.

Or copy/paste the Inline file into your config file. If you paste it in at the very end of the file then the settings you paste in will over-ride any previous setting. But it makes sense to remove the old settings from your config to keep it tidy.

Automating the use of the Inline files seems like over-kill to me.

Signed-off-by: Richard Bonhomme <[email protected]>

houmie · 2021-01-04T19:08:50Z

Good evening mate,

I see. Of course, sorry I should have looked into the inline file to see it for myself. It simply includes all four below, which no longer will be required in the server config.

tls-crypt-v2 tls-crypt-v2.key 0
key server_vSpTuNo38WJBclg2.key
cert server_vSpTuNo38WJBclg2.crt
ca ca.crt

So far so good. This will not change anything with client.ovpn, correct? In there everything stays the same way.

Now to the next test. You mentioned that multiple VPN profiles can now all be using different TLS CV2 Keys but all using the same x509 cert. How can I create a second client ovpn that can do that?

That means it will have the same verify-x509-name server_vSpTuNo38WJBclg2 name, same ca, same cert and same key, different tls-crypt-v2 and still be able to connect to the server?

or could you explain the use case, please ?

TinCanTech · 2021-01-04T19:40:38Z

I see. Of course, sorry I should have looked into the inline file to see it for myself. It simply includes all four below, which no longer will be required in the server config.
tls-crypt-v2 tls-crypt-v2.key 0
key server_vSpTuNo38WJBclg2.key
cert server_vSpTuNo38WJBclg2.crt
ca ca.crt
So far so good.

That sounds correct. (Except, you do not require the direction parameter 0 or 1 for any --tls-crypt* key)

This will not change anything with client.ovpn, correct? In there everything stays the same way.

Not sure I understand. Your client must use the correct credentials ..

TinCanTech · 2021-01-04T20:01:22Z

That means it will have the same verify-x509-name server_vSpTuNo38WJBclg2 name, same ca, same cert and same key, different tls-crypt-v2 and still be able to connect to the server?

Yes, that is the idea.

or could you explain the use case, please ?

Sure,

The server side is fairly straight forward, you only have the one --tls-crypt-v2 server key.
The client is similar if you only have one --tls-crypt-v2 key.

The client is slightly different when using the --sub-key-name option.

Think of it like this:

* X509 CA =
          |
          |- X509 Server01 Cert/Key = 
          |                         |- TLS-Crypt-V2 Server key - Inline file Server01
          |
          |- X509 Client01 Cert/key = 
          |                         |- TLS-Crypt-V2 Client key 01 - Inline file Client01-subkey01
          |                         |- TLS-Crypt-V2 Client key 02 - Inline file Client01-subkey02
          |

TinCanTech · 2021-01-04T20:08:53Z

In order to create multiple subkeys do this:

./easytls --sub-key-name=test01 --custom-group=tincantech build-tls-crypt-v2-client SERVER01 client01 abdcef012345 aabbccddeeff
./easytls --sub-key-name=test02 --custom-group=tincantech build-tls-crypt-v2-client SERVER01 client01 abdcef012345 aabbccddeeff
./easytls --sub-key-name=test01 inline-tls-crypt-v2 client01
./easytls --sub-key-name=test02 inline-tls-crypt-v2 client01

You can have unlimited client keys per server key.

All client keys for any specific server key must use the same --custom-group (Default is EASYTLS)

--sub-key-name is upto you and Hardware addresses are basically unlimited up to the line length or metadata limit.

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech · 2021-01-04T21:34:40Z

I first named this option --sub-cert-key=NAME but decided that --sub-key-name=NAME was simpler. However, I am not convinced this name is the right one yet.. Suggestions welcome.

houmie · 2021-01-04T23:06:17Z

Ah very nice. It is now coming together in my head. Allow me to sleep over this and I'll continue tomorrow.

I think --sub-key-name is the better name. Because cert and key are usually describing two different things and it would get confusing if you went with --sub-cert-key. So you chose the better name already, I would say.

TinCanTech · 2021-01-05T00:06:34Z

Updated help: https://github.com/TinCanTech/easy-tls/wiki/15-=-Multiple-TLS-Crypt-V2-Keys-per-X509-Certificate

TinCanTech · 2021-01-05T01:11:20Z

Ah very nice. It is now coming together in my head. Allow me to sleep over this and I'll continue tomorrow.

Many thanks for taking time to help me.

I think --sub-key-name is the better name. Because cert and key are usually describing two different things and it would get confusing if you went with --sub-cert-key. So you chose the better name already, I would say.

I agree because of confusing cert and key in one option.

But technically, it is a key which is used in a sub certificate fashion ;-)
One cert -> many keys .. I could call it --icing-sugar 🍬

houmie · 2021-01-05T18:48:58Z

Many thanks for taking time to help me.

No problem. My pleasure.

But technically, it is a key which is used in a sub certificate fashion ;-)
One cert -> many keys .. I could call it --icing-sugar 🍬

ha. :-)

The documentation that you just added made it super clear. So I could have one server and three clients for different devices, such as iPhone, Laptop and Android phone. If one of the devices get caught by DPI in future, the other devices will still work.

Another scenario is that I could write a native phone app and integrate OpenVPN in it. Then I could include three sub-keys in the same app. The user could then switch between the sub keys on the same phone. So when one of the sub-keys is caught, switching to another sub-key will make it work again. Correct?

TinCanTech · 2021-01-05T19:10:07Z

That is the idea.. but beware, it may work, not it will work again.

This is the problem with DPI; they have all the power and no matter what we do, it is still possible that this trick can be blocked. But it is quite a nice trick on our side, for a change.

houmie · 2021-01-06T19:55:30Z

Hey buddy,

Sorry I'm a bit struggling with time. I will finish the testing by this weekend.

My plan is to create two sub keys for two separate clients and connect to the same server to see if it all works smoothly.
Thanks

TinCanTech · 2021-01-06T20:18:27Z

There is no rush. You have already helped me a lot and I am grateful for your time.

TinCanTech · 2021-01-06T20:30:19Z

I would only ask that you make sure to use git/master for your test. 🍬 🍫 🍹 🍻

TinCanTech · 2021-01-07T01:13:12Z

@houmie I cannot thank you enough for the help and effort you have already made.

I have only one further request, please use option --verbose all the time, in future.

🍰

EG: ./easytls --verbose init-tls

TinCanTech · 2021-01-08T22:25:52Z

I am thinking, this command could have a x10 keys function .. ?
Automatically create 10 keys and inline files.

houmie · 2021-01-11T22:26:49Z

Hi buddy,

I've been testing everything on master via verbose flag. Everything looks solid. But the VPN connection test is still outstanding. I hope to get that done tomorrow morning my time.

I have one question:

If I create two sub-key-clients:

clientDeTestM2-mySubKey1-tls-crypt-v2.key
clientDeTestM2-mySubKey2-tls-crypt-v2.key

The server should recognise and accept either one of them.
The subKeys above could be used, each on a separate device with a separate OPENVPN client.

Or

the same device could import two OpenVPN profiles one with mySubKey1 included and the other profile with mySubKey2.
That way the same device could switch between them every other day to change the foot print and therefore hide better from DPI.

Have I understood it correctly?
Thanks

TinCanTech · 2021-01-11T23:11:09Z

You have understood correctly. Both of your methods above are valid.

All TLS-Cryp-V2 Client keys, regardless of --sub-key-name, can be used by the Server key which created them. (Just be careful if you start using hardware-lockdown.. )

houmie · 2021-01-12T12:38:30Z

I am thinking, this command could have a x10 keys function .. ?
Automatically create 10 keys and inline files.

Yes, I think this would be useful. 👍🏼

TinCanTech · 2021-02-02T06:18:30Z

Closing in favour of interactive menus

TinCanTech added help wanted Extra attention is needed Feature request Additional new feature labels Dec 15, 2020

TinCanTech self-assigned this Dec 26, 2020

TinCanTech added this to the First Official Release v1.27 milestone Dec 30, 2020

TinCanTech referenced this issue Jan 1, 2021

Add metadata fields: --sub-cert-key & Opt

c9a1508

Opt: Use TBD Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 1, 2021

Add help for --sub-cert-key=name (NFC)

72537a1

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 1, 2021

Major over haul to improve inline index, status and search functions

389b680

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 1, 2021

Add function: inline_crt_common_name() # Get common_name from inline …

66f9435

…file Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 1, 2021

Rename EASYTLS_TLSCV2_SCN to EASYTLS_TLSCV2_SUBKNAME

cd19278

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 1, 2021

Rewrite inline_index_rebuild ()

4bdec8f

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 1, 2021

Final corrections to --sub-key-name feature

0907c21

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 1, 2021

Add user confirmation for TLS-Crypt-V2 metadata: --sub-key-name

904a5c6

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech added Solution applied This issue has been solved Testing welcome labels Jan 1, 2021

TinCanTech pinned this issue Jan 1, 2021

TinCanTech referenced this issue Jan 4, 2021

Make status --sub-key-name aware

f974178

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech referenced this issue Jan 4, 2021

Make inline-expire --sub-key-name aware

9f75bfc

Signed-off-by: Richard Bonhomme <[email protected]>

TinCanTech removed the help wanted Extra attention is needed label Jan 6, 2021

TinCanTech mentioned this issue Jan 11, 2021

A disabled key is not detected when no sub-key is used in easytls-cryptv2-verify.sh #128

Closed

TinCanTech added the documentation Improvements or additions to documentation label Jan 12, 2021

TinCanTech added Feature Unique and removed Feature request Additional new feature labels Jan 22, 2021

TinCanTech closed this as completed Feb 2, 2021

TinCanTech changed the title ~~Sub X509 certificate mode: allow X509 to have multiple TLS-Crypt-V2 keys~~ FEATURE: Infinite TLS-Crypt-V2 Client keys per Server key Mar 18, 2021

FEATURE: Infinite TLS-Crypt-V2 Client keys per Server key #104

FEATURE: Infinite TLS-Crypt-V2 Client keys per Server key #104

Comments

TinCanTech commented Dec 15, 2020 • edited Loading

TinCanTech commented Dec 16, 2020

TinCanTech commented Dec 26, 2020

TinCanTech commented Dec 26, 2020 • edited Loading

TinCanTech commented Dec 28, 2020

houmie commented Dec 28, 2020

TinCanTech commented Dec 28, 2020

houmie commented Dec 28, 2020

TinCanTech commented Dec 29, 2020 • edited Loading

TinCanTech commented Dec 30, 2020

houmie commented Dec 30, 2020

TinCanTech commented Dec 30, 2020 • edited Loading

TinCanTech commented Dec 30, 2020 • edited Loading

TinCanTech commented Jan 1, 2021 • edited Loading

houmie commented Jan 1, 2021

houmie commented Jan 3, 2021

houmie commented Jan 4, 2021 • edited Loading

TinCanTech commented Jan 4, 2021 • edited Loading

houmie commented Jan 4, 2021

TinCanTech commented Jan 4, 2021

TinCanTech commented Jan 4, 2021

TinCanTech commented Jan 4, 2021 • edited Loading

TinCanTech commented Jan 4, 2021

houmie commented Jan 4, 2021

TinCanTech commented Jan 5, 2021 • edited Loading

TinCanTech commented Jan 5, 2021

houmie commented Jan 5, 2021

TinCanTech commented Jan 5, 2021

houmie commented Jan 6, 2021

TinCanTech commented Jan 6, 2021

TinCanTech commented Jan 6, 2021 • edited Loading

TinCanTech commented Jan 7, 2021 • edited Loading

TinCanTech commented Jan 8, 2021

houmie commented Jan 11, 2021 • edited Loading

TinCanTech commented Jan 11, 2021

houmie commented Jan 12, 2021

TinCanTech commented Feb 2, 2021

TinCanTech commented Dec 15, 2020 •

edited

Loading

TinCanTech commented Dec 26, 2020 •

edited

Loading

TinCanTech commented Dec 29, 2020 •

edited

Loading

TinCanTech commented Dec 30, 2020 •

edited

Loading

TinCanTech commented Dec 30, 2020 •

edited

Loading

TinCanTech commented Jan 1, 2021 •

edited

Loading

houmie commented Jan 4, 2021 •

edited

Loading

TinCanTech commented Jan 4, 2021 •

edited

Loading

TinCanTech commented Jan 4, 2021 •

edited

Loading

TinCanTech commented Jan 5, 2021 •

edited

Loading

TinCanTech commented Jan 6, 2021 •

edited

Loading

TinCanTech commented Jan 7, 2021 •

edited

Loading

houmie commented Jan 11, 2021 •

edited

Loading