Page 1 of 6

OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 11:17 am
by dariusz
As starting with 2.4 elliptic crypto is supported I decided to give it a try. After some digging and researching I manage to make it work. Please note that you will need 2.4 capable server and client together with latest crypto libraries. In my case I used raspberry pi with raspbian jessie as a server and macOS with the latest tunnelblick beta 3.6.10beta06 (only this one supports OpenVPN 2.4 at the moment) as a client.

On my pi I have installed the latest openssl 1.0.1j (needed for easy-rsa and some manual operations) and mbedTLS 2.4.0 for OpenVPN server:

*** openssl
https://www.openssl.org/source/openssl-1.0.2j.tar.gz
tar xvf openssl-1.0.2j.tar.gz
cd openssl-1.0.2j
./config
make
sudo install

*** mbedtls
wget https://tls.mbed.org/download/mbedtls-2.4.0-gpl.tgz
tar xvf mbedtls-2.4.0-gpl.tgz
cd mbedtls-2.4.0/
make
sudo make install

Then I have built the latest OpenVPN 2.4
wget https://swupdate.openvpn.org/community/ ... 4.0.tar.gz
tar xvf openvpn-2.4.0.tar.gz
cd openvpn-2.4.0
./configure --with-crypto-library=mbedtls
make
sudo make install


As manual installation does not replace openvpn software which comes with raspberry pi please be careful which version you run. For testing I would recommend just run it from command like openvpn --config server_ecc.conf

When you are happy with results you can tinker with systemd or initd to make 2.4 your default autostart option.

Now time to generate our EC keys. The easiest way is to use easy-rsa

cd ~

mkdir OPENVPN

cd OPENVPN

git clone git://github.com/OpenVPN/easy-rsa
cd easy-rsa/easyrsa3
cp vars.example vars

# edit vars - see my example file below. Make sure you point openssl to the latest one


# my vars file BEGIN ------------
set_var EASYRSA "$PWD"
# make sure that it points to your latest openssl file
set_var EASYRSA_OPENSSL "/usr/local/openssl/bin/openssl"
set_var EASYRSA_PKI "$EASYRSA/pki"

set_var EASYRSA_DN org
set_var EASYRSA_REQ_COUNTRY "US"
set_var EASYRSA_REQ_PROVINCE "California"
set_var EASYRSA_REQ_CITY "San Francisco"
set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
set_var EASYRSA_REQ_EMAIL "me@example.net"
set_var EASYRSA_REQ_OU "My Organizational Unit"

# !!! going elliptic crypto mode. Yipie
set_var EASYRSA_ALGO ec

# Define the named curve - choose what you like and what is supported - openvpn --show-curves
set_var EASYRSA_CURVE secp521r1

# In how many days should the root CA key expire?
set_var EASYRSA_CA_EXPIRE 3650

# In how many days should certificates expire?
set_var EASYRSA_CERT_EXPIRE 3650

# How many days until the next CRL publish date? Please note that 2.4 takes seriously next crl publish date and dont run if it expires. If you use setup from 2.3 you might have to recreate crl files. you can check your crl with openssl crl -in crl.pem -noout -text
set_var EASYRSA_CRL_DAYS 3650
# my vars file END ------------

# create new PKI
./easyrsa init-pki
# build CA

./easyrsa build-ca

# create server cert
./easyrsa gen-req myECserver nopass

# sign server cert
./easyrsa sign-req server myECserver

#create user cert
./easyrsa gen-req ECClient1

# sign user cert
./easyrsa sign-req client ECClient1


go to ./pki/private folder and 3DES encrypt your private key. again - make sure you are using the latest openssl. I am not 100% sure if this step is required for all clients.

/usr/local/ssl/bin/openssl ec -in ECClient1.key -des3 -out ECClient1.3des.key


Now you have all server files.
./pki/ca.crt
./pki/issued/myECserver.crt
./pki/private/myECserver.key
Copy them to your openvpn server config folder. I put them in separate folder /etc/openvpn/ECCkeys

and use these client files to create ovpn file:
./pki/ca.crt - use for <ca> value in your ovpn file
./pki/issued/ECClient1.crt - use for <cert> value (only part between BEGIN and END)
./pki/private/ECClient1.3des.key - use for <key> value

Please see below my ovpn example file. This is an example with real data - of course I don't use it any more so don't waste time cracking it:) I have commented out all non essential parameters. If you make it working you can uncomment whatever you think is useful for you. But why to complicate things from the start...
client
client
dev tun
remote myserver.com 1194 udp

#float
#resolv-retry infinite
#nobind
#persist-key
#persist-tun
#mute-replay-warnings

#cipher AES-256-GCM
#auth SHA512

#key-direction 1
#reneg-sec 0
#compress lz4
#verb 3
#mute 20

#remote-cert-tls server
#remote-cert-eku "TLS Web Server Authentication"
#verify-x509-name DB-OpenVPN-Server name
<ca>
-----BEGIN CERTIFICATE-----
MIIEDzCCA3CgAwIBAgIJAPExRQl9wMeRMAoGCCqGSM49BAMCMIGyMQswCQYDVQQG
EwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNj
bzEgMB4GA1UECgwXQ29weWxlZnQgQ2VydGlmaWNhdGUgQ28xHzAdBgNVBAsMFk15
IE9yZ2FuaXphdGlvbmFsIFVuaXQxFDASBgNVBAMMC0Vhc3ktUlNBIENBMR0wGwYJ
KoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldDAeFw0xNzAxMTYwOTE0MDJaFw0yNzAx
MTQwOTE0MDJaMIGyMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEW
MBQGA1UEBwwNU2FuIEZyYW5jaXNjbzEgMB4GA1UECgwXQ29weWxlZnQgQ2VydGlm
aWNhdGUgQ28xHzAdBgNVBAsMFk15IE9yZ2FuaXphdGlvbmFsIFVuaXQxFDASBgNV
BAMMC0Vhc3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldDCB
mzAQBgcqhkjOPQIBBgUrgQQAIwOBhgAEAWGwh3oYzUzpVX7qyqO4A0ygo834d4eZ
2ZPHOYoxZRdBieQv51pCY6hZl/6/qlcUl8pKqn7mDWH9ySIIiqz0X8QTAM6XSH8H
at/thQPZt5o6sRrJqrBCuX0h8lZs0QWIRs4od0442NQIJ7spu5MIYXCoycuoZm+b
RGocerRG6Mmt0G3Mo4IBKDCCASQwHQYDVR0OBBYEFEo9zHVMOGgBkSyHb64NgSeC
ERbSMIHnBgNVHSMEgd8wgdyAFEo9zHVMOGgBkSyHb64NgSeCERbSoYG4pIG1MIGy
MQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2Fu
IEZyYW5jaXNjbzEgMB4GA1UECgwXQ29weWxlZnQgQ2VydGlmaWNhdGUgQ28xHzAd
BgNVBAsMFk15IE9yZ2FuaXphdGlvbmFsIFVuaXQxFDASBgNVBAMMC0Vhc3ktUlNB
IENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAPExRQl9wMeRMAwG
A1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMAoGCCqGSM49BAMCA4GMADCBiAJCAKWu
xGrpBfNnKpTOSCG0P9veO1SO86HUuRubTYtf66RNjH+K4PV1DT2z65FwN42VvAK/
M3by41KiHGDxZvupOtNCAkIBbXJkDU6NHNcX7fMwD0TpjThi8Iim0PKATuT32CcK
nM5BwY5HsNhnomYNWo74hZ9oUUJi+upkaqSzYtNJJboPzZ0=
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
MIIEGDCCA3mgAwIBAgIBATAKBggqhkjOPQQDAjCBsjELMAkGA1UEBhMCVVMxEzAR
BgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xIDAeBgNV
BAoMF0NvcHlsZWZ0IENlcnRpZmljYXRlIENvMR8wHQYDVQQLDBZNeSBPcmdhbml6
YXRpb25hbCBVbml0MRQwEgYDVQQDDAtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJ
ARYObWVAZXhhbXBsZS5uZXQwHhcNMTcwMTE2MDkxNDMyWhcNMjcwMTE0MDkxNDMy
WjCBsTELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcM
DVNhbiBGcmFuY2lzY28xIDAeBgNVBAoMF0NvcHlsZWZ0IENlcnRpZmljYXRlIENv
MR8wHQYDVQQLDBZNeSBPcmdhbml6YXRpb25hbCBVbml0MRMwEQYDVQQDDApteUVD
c2VydmVyMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldDCBmzAQBgcqhkjO
PQIBBgUrgQQAIwOBhgAEAWwv2UTxAuqsKkOXqwLCw76trsk+1yFI8TX+9FRfuH2P
T1jWk3Pe8a+TYTW+dnHOjXoXRbrnHFKdEfqWBQKR1nrYADaA/OpnESuFzxTYVfMa
wkNVGMTWsDEdjBSSBSGCEql4UzS8y5v9Vy6u6GenMCoH+WHcbleZMOj3AFrx1PFO
uBb6o4IBOjCCATYwCQYDVR0TBAIwADAdBgNVHQ4EFgQUqBpL9NRgSpBzJqO+ZEQy
tldFvMswgecGA1UdIwSB3zCB3IAUSj3MdUw4aAGRLIdvrg2BJ4IRFtKhgbikgbUw
gbIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1T
YW4gRnJhbmNpc2NvMSAwHgYDVQQKDBdDb3B5bGVmdCBDZXJ0aWZpY2F0ZSBDbzEf
MB0GA1UECwwWTXkgT3JnYW5pemF0aW9uYWwgVW5pdDEUMBIGA1UEAwwLRWFzeS1S
U0EgQ0ExHTAbBgkqhkiG9w0BCQEWDm1lQGV4YW1wbGUubmV0ggkA8TFFCX3Ax5Ew
EwYDVR0lBAwwCgYIKwYBBQUHAwEwCwYDVR0PBAQDAgWgMAoGCCqGSM49BAMCA4GM
ADCBiAJCAezxL0fJ03jQENU6xmv9UccdZHRBXUpKfv3zpYMZLtW4szFhrGgIzLVH
eUnicoAx6l9cwcfMDHnfqsuTpR2GWiTfAkIBgHCsyvZ1tAYWABgvyOLi10gQZILf
qNhDc3y4S5rt1aKW9spsQOmNJSBubjjiJjXolX7qMzegw6WujI5iyTfNNAA=
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6778BFA39150BF9E

UkkHCq3x6FsWPbW14hFtag+Qc2+iA6bK9teY0uCENWmJFb4UTnJQeW8silkLvUE5
bJ8C7Jxb2vVgufF4zx8BQkVYZipKyUZyjA42Ktjm0GQ6QVJ3mbMYmow4GzWmPbxI
fK2Q6C4ZizzYixBqYzq2/fsenkc8Pe9ZRZ5j4ynm5n5H3cLP3hM6fJ+NfzH8v41e
FHMXeO38SFvuaHs99E//kU0ClZjIG2oRADBF69BlTtrMpYdgQS7FTOeiqQ3QgVzN
rzme9Q7HC7OYmO6b8r0OFq+vSTwNxG6xYAthplrO4h0=
-----END EC PRIVATE KEY-----
</key>

now let's create server config. The same principle as before - I comment out all what is not essential. Less things to troubleshoot. In my working setup I have both files uncommented but before you play with it I really recommend to make sure that you setup works with minimum set of options.
server
# "dev tun" will create a routed IP tunnel, TCP or UDP server, which port
dev tun
proto udp
port 1194

# SSL/TLS root certificate (ca), certificate (cert), private key (key) and Diffie Hellman parameters (dh)
tls-server
ca /etc/openvpn/ECCkeys/ca.crt
cert /etc/openvpn/ECCkeys/myECserver.crt
key /etc/openvpn/ECCkeys/myECserver.crt.key

# as we want to go pure EC we don't need DH anymore
dh none

# Data channel - it will be negotiated with client. Later you can ucomment to enforce your own policies
#ncp-ciphers AES-256-GCM
#cipher AES-256-GCM
#auth SHA512

# Control channel (TLS) - also negotiated with client.
#tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
#tls-version-min 1.2

# new in 2.4. does similar job like tls-auth in 2.3 but apparently better
#tls-crypt /etc/openvpn/ECCkeys/tc.key 0
#key-direction 0

# Ensure that remote machine has client cert
#remote-cert-eku "TLS Web Client Authentication"

# replace this section with whatever config you are using
server 10.88.90.0 255.255.255.0
ifconfig 10.88.90.1 10.88.90.2
push "route 10.88.90.1 255.255.255.255"
push "route 10.88.90.0 255.255.255.0"
push "dhcp-option DNS 84.200.69.80"
push "dhcp-option DNS 84.200.70.40"
push "redirect-gateway def1 bypass-dhcp"

#Block IPv6
#push "block-ipv6"

# Uncomment this directive to allow different clients to be able to "see" each other.
#client-to-client

# Uncomment this directive if multiple clients might connect with the same certificate/key
#duplicate-cn

# The keepalive. Ping every 10 seconds, assume that remote peer is down if no ping received during a 120 second
#keepalive 10 120

# Enable compression on the VPN link. Enable the same for client
#compress lz4

# don't run server as root
user nobody
group nogroup

# The persist options will try to avoid accessing certain resources on restart
# that may no longer be accessible because of the privilege downgrade.
#persist-key
#persist-tun
#persist-local-ip
#persist-remote-ip

# Output a short status file showing current connections, truncated
# and rewritten every minute.
status /var/log/openvpn-status_ecc.log 20

# Lof file
log /var/log/openvpn_ecc.log
#verb 4
#mute-replay-warnings

# check revoked certs
#crl-verify /etc/openvpn/ECCkeys/crl.pem
Everything put together and here we are. Working EC encrypted OpenVPN session:
#server starts:
Mon Jan 16 11:14:44 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 16 2017
Mon Jan 16 11:14:44 2017 library versions: mbed TLS 2.4.0, LZO 2.09
Mon Jan 16 11:14:44 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 16 11:14:44 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 16 11:14:44 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 16 11:14:44 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 16 11:14:44 2017 ROUTE_GATEWAY 192.168.142.1/255.255.255.0 IFACE=wlan0 HWADDR=f4:f2:6d:0f:68:9b
Mon Jan 16 11:14:44 2017 TUN/TAP device tun2 opened
Mon Jan 16 11:14:44 2017 TUN/TAP TX queue length set to 100
Mon Jan 16 11:14:44 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Jan 16 11:14:44 2017 /sbin/ifconfig tun2 10.88.90.1 pointopoint 10.88.90.2 mtu 1500
Mon Jan 16 11:14:44 2017 /sbin/route add -net 10.88.90.0 netmask 255.255.255.0 gw 10.88.90.2
Mon Jan 16 11:14:44 2017 Could not determine IPv4/IPv6 protocol. Using AF_INET
Mon Jan 16 11:14:44 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Mon Jan 16 11:14:44 2017 UDPv4 link local (bound): [AF_INET][undef]:1194
Mon Jan 16 11:14:44 2017 UDPv4 link remote: [AF_UNSPEC]
Mon Jan 16 11:14:44 2017 GID set to nogroup
Mon Jan 16 11:14:44 2017 UID set to openvpn_server
Mon Jan 16 11:14:44 2017 MULTI: multi_init called, r=256 v=256
Mon Jan 16 11:14:44 2017 IFCONFIG POOL: base=10.88.90.4 size=62, ipv6=0
Mon Jan 16 11:14:44 2017 Initialization Sequence Completed

#client connects:
Mon Jan 16 11:15:28 2017 81.109.233.126:51479 TLS: Initial packet from [AF_INET]81.109.233.126:51479, sid=369005aa f97df4d9
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 VERIFY OK: depth=1, C=US, ST=California, L=San Francisco, O=Copyleft Certificate Co, OU=My Organizational Unit, CN=EasyRSA-DB, emailAddress=me@example.net
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 Validating certificate extended key usage
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 VERIFY EKU OK
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 VERIFY OK: depth=0, C=US, ST=California, L=San Francisco, O=Copyleft Certificate Co, OU=My Organizational Unit, CN=clientname1, emailAddress=me@example.net
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_VER=2.4.0
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_PLAT=mac
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_PROTO=2
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_NCP=2
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_LZ4=1
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_LZ4v2=1
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_LZO=1
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_COMP_STUB=1
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_COMP_STUBv2=1
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 peer info: IV_TCPNL=1
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 Control Channel: TLSv1.2, cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, 521 bit key
Mon Jan 16 11:15:29 2017 81.109.233.126:51479 [clientname1] Peer Connection Initiated with [AF_INET]81.109.233.126:51479
Mon Jan 16 11:15:29 2017 clientname1/81.109.233.126:51479 MULTI_sva: pool returned IPv4=10.88.90.6, IPv6=(Not enabled)
Mon Jan 16 11:15:29 2017 clientname1/81.109.233.126:51479 MULTI: Learn: 10.88.90.6 -> clientname1/81.109.233.126:51479
Mon Jan 16 11:15:29 2017 clientname1/81.109.233.126:51479 MULTI: primary virtual IP for clientname1/81.109.233.126:51479: 10.88.90.6
Mon Jan 16 11:15:30 2017 clientname1/81.109.233.126:51479 PUSH: Received control message: 'PUSH_REQUEST'
Mon Jan 16 11:15:30 2017 clientname1/81.109.233.126:51479 SENT CONTROL [clientname1]: 'PUSH_REPLY,route 10.88.90.1 255.255.255.255,route 10.88.90.0 255.255.255.0,dhcp-option DNS 84.200.69.80,dhcp-option DNS 84.200.70.40,redirect-gateway def1 bypass-dhcp,block-ipv6,route 10.88.90.1,topology net30,ping 300,ping-restart 1200,ifconfig 10.88.90.6 10.88.90.5,peer-id 0,cipher AES-256-GCM' (status=1)
Mon Jan 16 11:15:30 2017 clientname1/81.109.233.126:51479 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Jan 16 11:15:30 2017 clientname1/81.109.233.126:51479 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 11:22 am
by dariusz
As all details of my client config has been stripped out I include unedited version here for your reference:

client
dev tun
remote myserver.com 1194 udp

#float
#resolv-retry infinite
#nobind
#persist-key
#persist-tun
#mute-replay-warnings

#key-direction 1
#reneg-sec 0
#compress lz4
#verb 3
#mute 20

#remote-cert-tls server
#remote-cert-eku "TLS Web Server Authentication"
#verify-x509-name DB-OpenVPN-Server name

#cipher AES-256-GCM
#auth SHA512
<ca>
-----BEGIN CERTIFICATE-----
MIIEDzCCA3CgAwIBAgIJAPExRQl9wMeRMAoGCCqGSM49BAMCMIGyMQswCQYDVQQG
EwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNj
bzEgMB4GA1UECgwXQ29weWxlZnQgQ2VydGlmaWNhdGUgQ28xHzAdBgNVBAsMFk15
IE9yZ2FuaXphdGlvbmFsIFVuaXQxFDASBgNVBAMMC0Vhc3ktUlNBIENBMR0wGwYJ
KoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldDAeFw0xNzAxMTYwOTE0MDJaFw0yNzAx
MTQwOTE0MDJaMIGyMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEW
MBQGA1UEBwwNU2FuIEZyYW5jaXNjbzEgMB4GA1UECgwXQ29weWxlZnQgQ2VydGlm
aWNhdGUgQ28xHzAdBgNVBAsMFk15IE9yZ2FuaXphdGlvbmFsIFVuaXQxFDASBgNV
BAMMC0Vhc3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldDCB
mzAQBgcqhkjOPQIBBgUrgQQAIwOBhgAEAWGwh3oYzUzpVX7qyqO4A0ygo834d4eZ
2ZPHOYoxZRdBieQv51pCY6hZl/6/qlcUl8pKqn7mDWH9ySIIiqz0X8QTAM6XSH8H
at/thQPZt5o6sRrJqrBCuX0h8lZs0QWIRs4od0442NQIJ7spu5MIYXCoycuoZm+b
RGocerRG6Mmt0G3Mo4IBKDCCASQwHQYDVR0OBBYEFEo9zHVMOGgBkSyHb64NgSeC
ERbSMIHnBgNVHSMEgd8wgdyAFEo9zHVMOGgBkSyHb64NgSeCERbSoYG4pIG1MIGy
MQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2Fu
IEZyYW5jaXNjbzEgMB4GA1UECgwXQ29weWxlZnQgQ2VydGlmaWNhdGUgQ28xHzAd
BgNVBAsMFk15IE9yZ2FuaXphdGlvbmFsIFVuaXQxFDASBgNVBAMMC0Vhc3ktUlNB
IENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAPExRQl9wMeRMAwG
A1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMAoGCCqGSM49BAMCA4GMADCBiAJCAKWu
xGrpBfNnKpTOSCG0P9veO1SO86HUuRubTYtf66RNjH+K4PV1DT2z65FwN42VvAK/
M3by41KiHGDxZvupOtNCAkIBbXJkDU6NHNcX7fMwD0TpjThi8Iim0PKATuT32CcK
nM5BwY5HsNhnomYNWo74hZ9oUUJi+upkaqSzYtNJJboPzZ0=
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
MIIEGDCCA3mgAwIBAgIBATAKBggqhkjOPQQDAjCBsjELMAkGA1UEBhMCVVMxEzAR
BgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBGcmFuY2lzY28xIDAeBgNV
BAoMF0NvcHlsZWZ0IENlcnRpZmljYXRlIENvMR8wHQYDVQQLDBZNeSBPcmdhbml6
YXRpb25hbCBVbml0MRQwEgYDVQQDDAtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJ
ARYObWVAZXhhbXBsZS5uZXQwHhcNMTcwMTE2MDkxNDMyWhcNMjcwMTE0MDkxNDMy
WjCBsTELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcM
DVNhbiBGcmFuY2lzY28xIDAeBgNVBAoMF0NvcHlsZWZ0IENlcnRpZmljYXRlIENv
MR8wHQYDVQQLDBZNeSBPcmdhbml6YXRpb25hbCBVbml0MRMwEQYDVQQDDApteUVD
c2VydmVyMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldDCBmzAQBgcqhkjO
PQIBBgUrgQQAIwOBhgAEAWwv2UTxAuqsKkOXqwLCw76trsk+1yFI8TX+9FRfuH2P
T1jWk3Pe8a+TYTW+dnHOjXoXRbrnHFKdEfqWBQKR1nrYADaA/OpnESuFzxTYVfMa
wkNVGMTWsDEdjBSSBSGCEql4UzS8y5v9Vy6u6GenMCoH+WHcbleZMOj3AFrx1PFO
uBb6o4IBOjCCATYwCQYDVR0TBAIwADAdBgNVHQ4EFgQUqBpL9NRgSpBzJqO+ZEQy
tldFvMswgecGA1UdIwSB3zCB3IAUSj3MdUw4aAGRLIdvrg2BJ4IRFtKhgbikgbUw
gbIxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1T
YW4gRnJhbmNpc2NvMSAwHgYDVQQKDBdDb3B5bGVmdCBDZXJ0aWZpY2F0ZSBDbzEf
MB0GA1UECwwWTXkgT3JnYW5pemF0aW9uYWwgVW5pdDEUMBIGA1UEAwwLRWFzeS1S
U0EgQ0ExHTAbBgkqhkiG9w0BCQEWDm1lQGV4YW1wbGUubmV0ggkA8TFFCX3Ax5Ew
EwYDVR0lBAwwCgYIKwYBBQUHAwEwCwYDVR0PBAQDAgWgMAoGCCqGSM49BAMCA4GM
ADCBiAJCAezxL0fJ03jQENU6xmv9UccdZHRBXUpKfv3zpYMZLtW4szFhrGgIzLVH
eUnicoAx6l9cwcfMDHnfqsuTpR2GWiTfAkIBgHCsyvZ1tAYWABgvyOLi10gQZILf
qNhDc3y4S5rt1aKW9spsQOmNJSBubjjiJjXolX7qMzegw6WujI5iyTfNNAA=
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6778BFA39150BF9E

UkkHCq3x6FsWPbW14hFtag+Qc2+iA6bK9teY0uCENWmJFb4UTnJQeW8silkLvUE5
bJ8C7Jxb2vVgufF4zx8BQkVYZipKyUZyjA42Ktjm0GQ6QVJ3mbMYmow4GzWmPbxI
fK2Q6C4ZizzYixBqYzq2/fsenkc8Pe9ZRZ5j4ynm5n5H3cLP3hM6fJ+NfzH8v41e
FHMXeO38SFvuaHs99E//kU0ClZjIG2oRADBF69BlTtrMpYdgQS7FTOeiqQ3QgVzN
rzme9Q7HC7OYmO6b8r0OFq+vSTwNxG6xYAthplrO4h0=
-----END EC PRIVATE KEY-----
</key>

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 11:35 am
by dariusz
So the latest and greatest what OpenVPN has to offer works perfectly:

TLS channel uses elliptic curve diffie-hellmann key exchange (ECDH) with elliptic curve digital signature algorithm (ECDSA)- TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384, 521 bit key

and data channel the latest AEAD (GCM) cipher AES-256-GCM

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 1:30 pm
by TinCanTech
dariusz wrote:As all details of my client config has been stripped out
The details are all still in your post .. press the View Original button to see them.

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 1:36 pm
by dariusz
not all. I wanted to make sure that difference with RSA keys is shown here. not sure if it matters, but if yes than better to have it all

for EC keys:
<key>
-----BEGIN EC PRIVATE KEY-----

for RSA keys:
<key>
-----BEGIN RSA PRIVATE KEY-----

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 5:57 pm
by peter_sm
Thanks for the guide, I will try this in the weekend

Just some questions

Can this be used instead for server / client

Code: Select all

build-client-full client_1 nopass
build-server-full server nopass
And ta.key with tls-auth or tls-crypt with EC ?

Will this settings be useful for the server config file ?

Code: Select all

ecdh-curve sect571r1
BR
Peter

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 6:05 pm
by dariusz
build-client-full or build-server-full should do the trick as well but I have not tried myself

in terms of of ecdh-curve as per man pages this:

" --ecdh-curve name
Specify the curve to use for elliptic curve Diffie Hellman. Available curves can be listed with --show-curves. The specified curve will only be used for ECDH TLS-ciphers.
This option is not supported in mbed TLS builds of OpenVPN."

You can build openvpn 2.4 with openssl as well than it will work.

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 6:27 pm
by peter_sm
Hi,
Some more Q
I would like to see how dh key could be used with EC :-) is it ecdh ? I have not found how do that?

So try to find a a way to use ta.key and dh.key with EC then this guide is completed :-) :-)

I'm on a Slackware system (unRAID)

//Peter

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 6:42 pm
by dariusz
you can use either ta.key (--tls-auth) like in 2.3 or new tc.key (--tls-crypt) - unfortunately they are mutually exclusive. it can be actually the same key but you have to decide its use. you generate it like always openvpn --genkey --secret tls.key. If you look at raw version of my configs you will see that I use --tls-crypt (then you have also add it to client config)

DH - if you wish you can generate DH key and use for tls like TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384. It is entirely up to you. Such key exchange would be slower and less secure. You can only use up to 4096 RSA when 521 elliptic key is equivalent of 15000 something RSA. Check with openvpn --show-tls - the keys are sorted according to their strength.

My objective here was to go full elliptic:) strongest possible crypto OpenVPN can offer. There are many other options how to configure it. But again - I just wanted to see pure elliptic in action.

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 6:47 pm
by dariusz
actually i might be a bit wrong about my DH usage explanation. you have to do your own research.

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Mon Jan 16, 2017 7:05 pm
by dariusz

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Tue Jan 17, 2017 2:48 pm
by dariusz
@Peter

DH parameter does not have any use when EC keys are in action. There are no tls ciphers available where key exchange would happen using DHE (this is when you need DH parameters) instead of ECDHE when EC keys are used.

I have tried to exclude ECDHE from accepted tls-cipher and then connection fails with: "TLS_ERROR: read tls_read_plaintext error: SSL - The server has no ciphersuites in common with the client" when on client side I allow all available ones.

For example when running openvpn --show-tls with openssl library results are:
TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384
TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
TLS-DHE-RSA-WITH-AES-256-CBC-SHA256
TLS-DHE-RSA-WITH-AES-256-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA
TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256
TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA
TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA256
TLS-DHE-RSA-WITH-AES-128-CBC-SHA
TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA

as you can see it is now much more stricter than 2.3

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Tue Jan 17, 2017 4:05 pm
by bird333
Thanks for this post because I wanted to do the same thing. All crypto at least equal to the strength of 256-bit AES with EC. Question though are you saying that now it is NOT necessary to generate DH keys? Also, can I use my old ta.key for --tls-crypt or should I generate a new one?

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Tue Jan 17, 2017 4:16 pm
by dariusz
bird333 wrote:Thanks for this post because I wanted to do the same thing. All crypto at least equal to the strength of 256-bit AES with EC. Question though are you saying that now it is NOT necessary to generate DH keys? Also, can I use my old ta.key for --tls-crypt or should I generate a new one?
There is no need for DH parameter. This is the reason why "dh none" option has been introduced. To be on the safe side limit number of ciphers e.g. myself I use only one:

tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
tls-version-min 1.2

Tls crypt - yes this is the same file. you can use existing ta.key. I have tried it.

tls-crypt is much better as not only encrypts packets but also includes authentication, and thereby makes --tls-auth redundant. As per 2.4 documentation:

Encrypting (and authenticating) control channel packets:

· provides more privacy by hiding the certificate used for the TLS connection,

· makes it harder to identify OpenVPN traffic as such,

· provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy).

In contrast to --tls-auth, --tls-crypt does *not* require the user to set --key-direction.

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Tue Jan 17, 2017 5:16 pm
by bird333
First let me say I am a total newbie at this stuff. I read that you want a 'prime curve' and preferably a NON-NIST curve because of NSA backdoor concerns. Do any of the available curves fit the criteria of being prime, non-NIST, and equal to or greater than 256-bit AES?

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Tue Jan 17, 2017 5:23 pm
by dariusz
This is entirely different subject:) when you have your system running end to end with EC you can experiment with other curves. Which ones? It depends on your server and client support. On the server run openvpn --show-curves to see what is available.

Yes indeed there are speculations that some curbs are not perfect.. but if NSA is after you than not sure if openvpn will help you.

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Thu Jan 19, 2017 6:42 am
by peter_sm
Here is my new settings for EC !
Please feedback if something is wrong or good :-)

Server

Code: Select all

server 10.33.0.0 255.255.255.0
local 192.168.0.190
dev tun
port 1199
proto udp
dh none
ca /mnt/appdata/myVPNserver_newEC_1/ca.crt
cert /mnt/appdata/myVPNserver_newEC_1/server.crt
key /mnt/appdata/myVPNserver_newEC_1/server.key
ifconfig-pool-persist /boot/config/plugins/openvpnserver/ipp.txt
push "dhcp-option DNS 192.168.0.1"
tls-server
verb 3
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384
tls-crypt /mnt/appdata/myVPNserver_newEC_1/ta.key
persist-key
persist-tun
keepalive 10 120
user nobody
group users
cipher AES-256-GCM
ncp-ciphers AES-256-GCM
auth sha512
compress lz4-v2
push "compress lz4-v2"
push "route 192.168.0.0 255.255.255.0"
push "resolv-retry infinite"
status /var/log/openvpnserver-status.log 5
log-append /var/log/openvpnserver.log
status-version 2
# Notify the client that when the server restarts so it
# can automatically reconnect.
explicit-exit-notify 0
Client

Code: Select all

remote my.server.com
cipher AES-256-GCM
auth sha512
client
dev tun
proto udp
port 1199
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server

verb 3
route-delay 2
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,9787972C44DCCDE8
-----END EC PRIVATE KEY-----
</key>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-crypt>
Client log

Code: Select all

2017-01-19 07:37:32 OpenVPN 2.4.0 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Jan 14 2017
2017-01-19 07:37:32 library versions: OpenSSL 1.0.2j  26 Sep 2016, LZO 2.09
2017-01-19 07:37:32 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337
2017-01-19 07:37:32 Need hold release from management interface, waiting...
2017-01-19 07:37:32 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337
2017-01-19 07:37:32 MANAGEMENT: CMD 'pid'
2017-01-19 07:37:32 MANAGEMENT: CMD 'state on'
2017-01-19 07:37:32 MANAGEMENT: CMD 'state'
2017-01-19 07:37:32 MANAGEMENT: CMD 'bytecount 1'
2017-01-19 07:37:32 MANAGEMENT: CMD 'hold release'
2017-01-19 07:37:32 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2017-01-19 07:37:32 *Tunnelblick: openvpnstart starting OpenVPN
2017-01-19 07:37:32 *Tunnelblick: Established communication with OpenVPN
2017-01-19 07:37:42 MANAGEMENT: CMD 'password [...]'
2017-01-19 07:37:42 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2017-01-19 07:37:42 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2017-01-19 07:37:42 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2017-01-19 07:37:42 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
2017-01-19 07:37:42 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
2017-01-19 07:37:42 MANAGEMENT: >STATE:1484807862,RESOLVE,,,,,,
2017-01-19 07:37:42 TCP/UDP: Preserving recently used remote address: [AF_INET]78.72.210.82:1199
2017-01-19 07:37:42 Socket Buffers: R=[196724->196724] S=[9216->9216]
2017-01-19 07:37:42 UDP link local: (not bound)
2017-01-19 07:37:42 UDP link remote: [AF_INET]78.72.210.82:1199
2017-01-19 07:37:42 MANAGEMENT: >STATE:1484807862,WAIT,,,,,,
2017-01-19 07:37:42 MANAGEMENT: >STATE:1484807862,AUTH,,,,,,
2017-01-19 07:37:42 TLS: Initial packet from [AF_INET]78.72.210.82:1199, sid=d614c816 61351060
2017-01-19 07:37:42 VERIFY OK: depth=1, CN=Easy-RSA CA
2017-01-19 07:37:42 Validating certificate key usage
2017-01-19 07:37:42 ++ Certificate has key usage  00a0, expects 00a0
2017-01-19 07:37:42 VERIFY KU OK
2017-01-19 07:37:42 Validating certificate extended key usage
2017-01-19 07:37:42 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2017-01-19 07:37:42 VERIFY EKU OK
2017-01-19 07:37:42 VERIFY OK: depth=0, CN=server
2017-01-19 07:37:42 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1549', remote='link-mtu 1550'
2017-01-19 07:37:42 WARNING: 'comp-lzo' is present in remote config but missing in local config, remote='comp-lzo'
2017-01-19 07:37:42 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384
2017-01-19 07:37:42 [server] Peer Connection Initiated with [AF_INET]78.72.210.82:1199
2017-01-19 07:37:44 MANAGEMENT: >STATE:1484807864,GET_CONFIG,,,,,,
2017-01-19 07:37:44 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2017-01-19 07:37:44 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 192.168.0.1,compress lz4-v2,route 192.168.0.0 255.255.255.0,resolv-retry infinite,route 10.33.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.33.0.22 10.33.0.21,peer-id 0,cipher AES-256-GCM'
2017-01-19 07:37:44 Options error: option 'resolv-retry' cannot be used in this context ([PUSH-OPTIONS])
2017-01-19 07:37:44 OPTIONS IMPORT: timers and/or timeouts modified
2017-01-19 07:37:44 OPTIONS IMPORT: compression parms modified
2017-01-19 07:37:44 OPTIONS IMPORT: --ifconfig/up options modified
2017-01-19 07:37:44 OPTIONS IMPORT: route options modified
2017-01-19 07:37:44 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2017-01-19 07:37:44 OPTIONS IMPORT: peer-id set
2017-01-19 07:37:44 OPTIONS IMPORT: adjusting link_mtu to 1624
2017-01-19 07:37:44 OPTIONS IMPORT: data channel crypto options modified
2017-01-19 07:37:44 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
2017-01-19 07:37:44 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
2017-01-19 07:37:44 Opening utun (connect(AF_SYS_CONTROL)): Resource busy
2017-01-19 07:37:44 Opened utun device utun1
2017-01-19 07:37:44 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
2017-01-19 07:37:44 MANAGEMENT: >STATE:1484807864,ASSIGN_IP,,10.33.0.22,,,,

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Thu Jan 26, 2017 8:39 am
by peter_sm
dariusz wrote: go to ./pki/private folder and 3DES encrypt your private key. again - make sure you are using the latest openssl. I am not 100% sure if this step is required for all clients.

/usr/local/ssl/bin/openssl ec -in ECClient1.key -des3 -out ECClient1.3des.key
Can this be done without that the user need to enter password when import the file in the client software ?
Or can this step be ignored for all clients ?

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Thu Jan 26, 2017 9:31 am
by dariusz
Only purpose is to strengthen private key encryption when transferred to client over insecure channel e.g. email. By default private key is encrypted with nowadays considered weak DES encryption. 3DES is much stronger and can be further improved by choosing even better crypto e.g. AES256.

It is not mandatory - you can generate client key without any password and omit this step all together. It is entirely up to you.

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Posted: Thu Jan 26, 2017 11:09 am
by TinCanTech
If you transfer a file over an insecure channel and somebody captures it,
a brute force attack will eventually crack it.