How to force Hardware AES De-/Encryption?

[limone]

Hi guys,

I've got a KVM server whos host doesn't pass the aes flag to the vm.
So my server is hardware aes capable, but openssl doesn't know that without specifically telling it to do so.

Code: Select all

# openssl speed -elapsed -evp aes-128-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      61211.46k    60594.33k    60892.50k   163162.11k   182031.70k

Code: Select all

# OPENSSL_ia32cap="+0x200000200000000" openssl speed -elapsed -evp aes-128-cbc
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     461871.00k   484265.41k   510874.11k   504460.29k   544361.13k

So, anyone got an idea how to do that?

[dazo]

Have you tried adding the OPENSSL_ia32cap variable before starting the OpenVPN process? If you're using a systemd based distro, you can do that with systemctl edit openvpn-{client,serve}@CONFIGNAME .... then add:

Code: Select all

[Service]
Environment="OPENSSL_ia32cap='+0x200000200000000'"

Then do a systemctl restart openvpn-{client,server}@CONFIGNAME

[limone]

dazo

better late then never

i enabled my openvpn config with this:

Code: Select all

systemctl enable openvpn@clientxyz.service

so i did

Code: Select all

systemctl edit openvpn@clientxyz.service

and added

Code: Select all

[Service]
Environment="OPENSSL_ia32cap='+0x200000200000000'"

there, but after a restart the flag isn't set, the openvpn connection is still ~80mbit/s max, to the server directly (without openvpn) it is ~400 mbit/s, i even rebooted the whole vm.

i know the encyption slows it down a bit, but with that flag it should be faster than without it, right?

can i set that flag globally in /etc/default/openvpn anyhow?

[TinCanTech]

after a restart the flag isn't set

Dazo and I tried this and (although we did not test the performance) the flag can and does persist into the openvpn environment .. so maybe your solution has not been executed correctly.

[dazo]

Something is definitely wrong in your unit files, if this doesn't work. By doing 'ps faxuwwe | grep openvpn' you should see the complete environment table for the openvpn processes as well. Or if you have the PID for the openvpn process, you can also do this: "cat /proc/$PID/environ | tr '\0' '\n'"

That said, I see you use openvpn@.service. Please do move over to the openvpn-{client,server}@.service unit files instead. They should be managed by the upstream OpenVPN community, and should be similar across all Linux distros (even though Debian have managed mess this up too). Regardless, the latest unit files are available here: https://github.com/OpenVPN/openvpn/tree ... ro/systemd (they will require OpenVPN 2.4 to be installed, as they are tuned to an improved systemd integration in v2.4). The README.systemd file should provide more details.

[limone]

Ok, doing cat /proc/758/environ | tr '\0' '\n' does list the flag, even with my openvpn@clientxyz.service config..
So aes may not be the bottleneck? Do you have any idea what it could be then?

btw i use debian 9

[dazo]

As long as you see it the environment variable ... the OpenSSL library should be able to pick it up. Why it doesn't is out-of-scope for OpenVPN, so I have no idea. The only thing I can imagine might be an issue (as I don't see your configs) is that you use --chroot, and the OpenSSL tries to load some support libraries/dependencies after OpenVPN have done the chroot() call. But this is just a wild guess. Perhaps try some OpenSSL support forums, mailing lists or similar?

Just a sanity check ... Have you tried start OpenVPN from the command line, outside of systemctl?

Code: Select all

 # OPENSSL_ia32cap='+0x200000200000000' openvpn --config /path/to/config.conf 

What happens then? If it is still the same, then I am completely out of ideas.

[limone]

Still the same (80-100mbit/s)

thanks for your help guys, but i think it's just a shitty vm.

may you see a mistake here in my configs, but if there's nothing wrong i wont put any more effort into this, and get a better machine next time..

Code: Select all

port 12345
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
topology subnet
server 10.*.*.0 255.255.255.0
ifconfig-pool-persist ipp.txt
script-security 2
keepalive 10 30
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
tls-version-min 1.2
auth SHA512
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 0
user openvpn
group openvpn
client-config-dir /etc/openvpn/ccd
up "/bin/bash /etc/openvpn/routes.sh add"
down "/bin/bash /etc/openvpn/routes.sh del"

Code: Select all

client
dev tun
proto udp
remote 1.2.3.4 12345
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
key-direction 1
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
tls-version-min 1.2
cipher AES-128-CBC
auth SHA512
comp-lzo
verb 0
explicit-exit-notify
script-security 2
<ca>
*
</ca>
<cert>
*
</cert>
<key>
*
</key>
<tls-auth>
*
</tls-auth>

[dazo]

Code: Select all

auth SHA512

This kills performance dramatically, for no gain even. The --auth option changes the HMAC algorithm. And even MD5 is considered fairly safe to use with HMAC. The default is SHA1, though, which is a fairly sane.

The reason is that each packet gets an overhead of these authentication packets. SHA1 gives 20 bytes overhead on each packet. SHA256 increases that to 32 bytes (+12 bytes). With SHA512 the overhead is 64 bytes (+44 bytes per packet, compared to SHA1).

And if you have OpenVPN 2.4 (or OpenVPN 3 based clients) which can tackle AES-GCM algorithms, this overhead drops to 0, as the authentication is built into the GCM part. By default, if OpenVPN 2.4 servers detects a client which supports AES-GCM, it will upgrade --cipher automatically for you to AES-256-GCM.

I would also drop the --tls-cipher lines, if you're on a recent release of OpenVPN. The defaults here are usually more than sane enough as well. We're trying to push the defaults to be the sanest possible, without users needing to tweak these options. They're present mostly for those who really need a specific cipher.

[limone]

My server and clients are 2.4.*, so my auth and cipher options are kinda useless?
I'll try dropping the tls part.

Drop the tls part changes nothing
changing auth to sha1 changes nothing
setting the cipher to aes-256-gcm (in case the server does not detect it) changes nothing

what do you think about comp-lzo?

[limone]

Update: I was able to get 28 mbit/s instead of 20mbit/s with the settings you provided on another machine

[dazo]

Just to clarify a bad statement from my side

And if you have OpenVPN 2.4 (or OpenVPN 3 based clients) which can tackle AES-GCM algorithms, this overhead drops to 0, as the authentication is built into the GCM part.

This is somewhat incorrect. The packet overhead does not drop to 0. The packet size is reduced with 8 bytes compared to CBC with --auth SHA1. But the CPU overhead is removed, as the authentication and decryption happens in the same crypto operation. With CBC with --auth, the decryption and authentication are two more or less independent operations.

what do you think about comp-lzo?

Generally, compression and encryption are questionable. It makes the encrypted data stream a more viable target for compression oracle attacks. If you are concerned about others detecting the contents of the data you transfer, disable compression. If you're more concerned about throughput than security, compression might give an advantage if the contents being transported is compressible. If you mostly transport data already compressed (video, audio, etc), the compression will have little effect but adding more CPU load.

That said, if you want to use compression - move to the newer --compress option instead of --comp-lzo.