OpenVPN Support Forum

Posted: **Tue Jan 17, 2017 5:23 pm**

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.

Posted: **Thu Jan 19, 2017 6:42 am**

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

Posted: **Thu Jan 26, 2017 8:39 am**

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 ?

Posted: **Thu Jan 26, 2017 9:31 am**

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.

Posted: **Thu Jan 26, 2017 11:09 am**

If you transfer a file over an insecure channel and somebody captures it,
a brute force attack will eventually crack it.

Posted: **Tue Jan 31, 2017 10:20 am**

If anybody is interested I have found out that compiling OpenVPN 2.4 with the latest LibreSSL 2.5.0 library allows me to use ECDHE-ECDSA-CHACHA20-POLY1305 for control channel - potentially it should be faster, lighter for mobile devices with CPU without AES instructions support. Why to use ChaCha?

See https://blog.cloudflare.com/do-the-chac ... ptography/
Different context but principle remains the same - the relatively new kid on the crypto block has some advantages.

Compilation instruction for my Raspberry Pi:

1) LibreSSL

./configure --prefix=/opt/libressl-2.5.0
make -j 4 && sudo make install

2) OpenVPN

./configure --enable-systemd --with-crypto-library=openssl OPENSSL_SSL_LIBS="-L/opt/libressl-2.5.0/lib/ -lssl" OPENSSL_SSL_CFLAGS="-I/opt/libressl-2.5.0/include/" OPENSSL_CRYPTO_LIBS="-L/opt/libressl-2.5.0/lib/ -lcrypto" OPENSSL_CRYPTO_CFLAGS="-I/opt/libressl-2.5.0/include/" LDFLAGS="-L/opt/libressl-2.5.0/lib/"
make -j 4 && sudo make install

Result openvpn --version
OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 27 2017
library versions: LibreSSL 2.5.0, LZO 2.09

Now small change to server.config (do the same on client side if you use tls-cipher directive):

tls-cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256

And now when using macOS using latest (3.7.0) tunnelblick with OpenVPN version set to 2.4 with LibreSSL 2.5.0 it nicely connects with latest crypto:

Tue Jan 31 09:32:59 2017 12.210.44.77:59459 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-CHACHA20-POLY1305

Please note that at the moment iOS OpenVPN client does not support 2.4 yet... so it only works from desktop. Let's hope that it will change soon.

Posted: **Sun Feb 05, 2017 11:03 am**

does iOS OpenVPN Connect able to cope with these settings?

Posted: **Sun Feb 05, 2017 11:06 am**

Nope.

iOS OpenVPN Connect does not support ec at the moment.

Posted: **Wed Feb 08, 2017 11:15 am**

Hi all,

I've attempted (successfully, as far as I can tell) a similar setup using all-ECC keys, all at 521-bit length (because overkill is cheap, so why not?).

All appears to be working fine, with the client log showing "Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384" as expected.

I've also explicitly put "ecdh-curve secp521r1" in the server configuration.

I have the following questions:
1. In the absence of "ecdh-curve" being declared, what curve is used for ECDHE? I would expect the server to use the same curve as the server certificate (e.g. if the server uses secp384r1, the key exchange would use secp384r1, while if the server uses secp521r1, the key exchange would use secp521r1, and so on), but it'd be nice to confirm this.

2. Is there some way of verifying that the key exchange uses secp521r1 as expected? Even with verbosity turned up to 7 there's no indication of which curve is used for the key exchange.

3. Is there any particular reason to prefer tls-auth vs. tls-crypt? Any downsides of one versus the other? In my case, there's a very limited number of users (myself and a few family members) all using systems I administer, so widespread compatibility with the public is not necessary.

Thanks.

Posted: **Wed Feb 08, 2017 1:51 pm**

heypete wrote: 1. In the absence of "ecdh-curve" being declared, what curve is used for ECDHE? I would expect the server to use the same curve as the server certificate (e.g. if the server uses secp384r1, the key exchange would use secp384r1, while if the server uses secp521r1, the key exchange would use secp521r1, and so on), but it'd be nice to confirm this.

As per man pages:
--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.

If no ecdh-curve is provided than at least my OpenVPN server (compiled with the latest LibreSSL and all my certs using brainpoolP512r1) will use secp384r1. My openvpn.log (Initialization Sequence details)

without ecdh-curve at all
Wed Feb 8 13:27:14 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:27:14 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:27:14 2017 Failed to extract curve from certificate (UNDEF), using secp384r1 instead.
Wed Feb 8 13:27:14 2017 ECDH curve secp384r1 added
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

with "ecdh-curve brainpoolP512r1"
Wed Feb 8 13:29:04 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:29:04 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:29:04 2017 ECDH curve brainpoolP512r1 added
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

heypete wrote: 2. Is there some way of verifying that the key exchange uses secp521r1 as expected? Even with verbosity turned up to 7 there's no indication of which curve is used for the key exchange.

check your server log after restart - as in previous point it should list what curve has been selected.

heypete wrote: 3. Is there any particular reason to prefer tls-auth vs. tls-crypt? Any downsides of one versus the other? In my case, there's a very limited number of users (myself and a few family members) all using systems I administer, so widespread compatibility with the public is not necessary.

Actually tls-crypt introduced in 2.4 is better. It does not only authenticate (like tls-auth) , but also encrypt the TLS control channel.

As per man pages:

--tls-crypt keyfile

Encrypt and authenticate all control channel packets with the key from keyfile. (See --tls-auth for more background.)

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

Posted: **Wed Feb 08, 2017 11:26 pm**

dariusz wrote:If no ecdh-curve is provided than at least my OpenVPN server (compiled with the latest LibreSSL and all my certs using brainpoolP512r1) will use secp384r1. My openvpn.log (Initialization Sequence details)

without ecdh-curve at all
Wed Feb 8 13:27:14 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:27:14 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:27:14 2017 Failed to extract curve from certificate (UNDEF), using secp384r1 instead.
Wed Feb 8 13:27:14 2017 ECDH curve secp384r1 added
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

with "ecdh-curve brainpoolP512r1"
Wed Feb 8 13:29:04 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:29:04 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:29:04 2017 ECDH curve brainpoolP512r1 added
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Excellent. It does indeed show up in the server log, and the secp521r1 curve shows as being added correctly. Thanks!

Actually tls-crypt introduced in 2.4 is better. It does not only authenticate (like tls-auth) , but also encrypt the TLS control channel.

Right. I read the man page and understand the "Why tls-crypt is a good thing." concept. The major advantage is encrypting the control channel, which is handy. Other than compatibility issues with older clients (which don't apply in my case), are there any downsides? tls-crypt uses AES-256-CTR which is fast, and not much data gets sent over the control channel anyway, so there shouldn't be an meaningful performance impact. Still, it's nice to get confirmation.

Thanks for the prompt and detailed response.

Posted: **Thu Feb 09, 2017 9:32 am**

I think that the must is to use either of two parameters because they limit attack vector. as only authenticated packets are processed it makes it impossible for non valid user to try to DDoS your OpenVPN server as their non signed packets would be simply discarded before processing. From practical perspective I don't see massive advantage of neither of them. tls-crypt obfuscate OpenVPN traffic even more by static key encryption but as long as solid crypto is used I don't think it makes much difference from security perspective. Does it protect traffic from being detected as VPN? I doubt this claim. In places where it matters e.g. China, sophistication of their detection technology requires more clever tools anyway.

That said I decided to to use tls-crypt. Simply as you said because overkill is cheap:) Only cost I see is battery power - more complex crypto requires more processing. Depends on your usage pattern when on the move - vpn always on or just used for sensitive apps like banking. Unfortunately there is no iOS client yet supporting OpenVPN 2.4 new features so at least for me it is academic. Moving forward I will definitely switch all my VPN setup to elliptic crypto (mobile devices being the main reason).

Posted: **Mon May 22, 2017 3:06 pm**

dariusz wrote: 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

Where does that cipher and hash come from? I don't have either of those in my config files but they show up in the logs. I have AES-256-CBC and SHA512 in my config.

Posted: **Mon May 22, 2017 3:19 pm**

Can you please post your confit?

Posted: **Mon May 22, 2017 5:49 pm**

I will but your config doesn't seem to have this but you get this output too. Is it the TLS negotiation?

Posted: **Mon May 22, 2017 7:09 pm**

@bird333
See manual 2.4 --ncp.....

Posted: **Mon May 22, 2017 7:13 pm**

Crypto parameters negotiation is automatic unless explicitly disabled as per 2.4 manual

Posted: **Mon May 22, 2017 11:36 pm**

The control channel encryption still shows AES-256-CTR and SHA256 with 'ncp-disable' added to the server and client configs. The client log does show that AES-256-CBC and SHA512 for the 'data channel' which it didn't before I added 'ncp-disable'. See below.

Client log

Code: Select all

Mon May 22 18:07:35 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon May 22 18:07:35 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon May 22 18:07:35 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon May 22 18:07:35 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication




Mon May 22 18:07:35 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384
Mon May 22 18:07:35 2017 [server] Peer Connection Initiated with [AF_INET]*.*.*.*:1194
Mon May 22 18:07:35 2017 Key [AF_INET]*.*.*.*:1194 [0] not initialized (yet), dropping packet.
Mon May 22 18:07:35 2017 Key [AF_INET]*.*.*.*:1194 [0] not initialized (yet), dropping packet.
Mon May 22 18:07:36 2017 Key [AF_INET]*.*.*.*:1194 [0] not initialized (yet), dropping packet.
Mon May 22 18:07:36 2017 MANAGEMENT: >STATE:1495494456,GET_CONFIG,,,,,,
Mon May 22 18:07:36 2017 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon May 22 18:07:36 2017 PUSH: Received control message: 'PUSH_REPLY,ping 15,ping-restart 60,peer-id 1'
Mon May 22 18:07:36 2017 OPTIONS IMPORT: timers and/or timeouts modified
Mon May 22 18:07:36 2017 OPTIONS IMPORT: peer-id set
Mon May 22 18:07:36 2017 OPTIONS IMPORT: adjusting link_mtu to 1657
Mon May 22 18:07:36 2017 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon May 22 18:07:36 2017 Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Mon May 22 18:07:36 2017 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon May 22 18:07:36 2017 Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication

Posted: **Tue May 23, 2017 1:57 pm**

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

Above lines in server log indicate that you have tls-crypt enabled and it initiated control channel packets encryption. tls-crypt is not mandatory but adds extra layer of security. It is used in addition to control channel cipher which is either negotiated or explicitly specified by your configuration e.g. in your case ECDHE-ECDSA-AES256-GCM-SHA384 with HMAC - SHA512

Posted: **Tue May 23, 2017 8:30 pm**

I guess my question was why does it not match what's in the config? I suspect that 'tls-crypt' defaults to AES-256-CTR and SHA256 and there is no way to change it.

OpenVPN Support Forum

OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup

Re: OpenVPN 2.4 and pure elliptic curve crypto setup