Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upFigure out best options for a custom build of strongSwan #12
Comments
This comment has been minimized.
This comment has been minimized.
So, one concrete issue that is resolved by building from source is that we get AES-NI support. AESNI is supported on DigitalOcean by default. It helps extremely low performance VPS providers avoid getting overwhelmed in CPU usage. |
This comment has been minimized.
This comment has been minimized.
Enabling the aesni plugin (which I guess is what you are referring to) only has an effect on IKE traffic, of which there isn't a lot. So unless you use the kernel-libipsec plugin (userland IPsec stack) you need a kernel that supports AES-NI. Some notes on the other options you listed there:
Not needed if the openssl plugin is enabled and the installed OpenSSL version supports AES-GCM.
Only useful if the CPU actually supports it (similar to AES-NI).
This is a special testing framework that is of no use in production environments.
This only has an effect if tests are enabled (charon.crypto_test options in
Not really a cipher, but if it's not used, disabling it sure makes sense.
These are also provided by the openssl plugin (unless they are disabled in the OpenSSL library against which it is built, or specific |
This comment has been minimized.
This comment has been minimized.
Thanks for the tips @tobiasbrunner! My goal is to support only the features that Algo uses and none others. I will ultimately use this to make a PPA specifically for Algo in #194. Here are my notes so far.
Here is what I trimmed the Debian CONFIGUREARGS down to.
This results in the following build configuration:
Finally, the following entries need to be deleted from files in the
Suggestions to trim this down further are welcome! |
This comment has been minimized.
This comment has been minimized.
You might want to consider using |
After we get everything working, we should try to trim down the StrongSwan binaries as much as possible by compiling from source and disabling everything we don't use. As a side benefit, this makes it a more unique target for exploitation and ensures that we're using the latest version.
Here my initial review of Autoconf options:
Enable new good features:
--enable-chapoly
--enable-gcm
--enable-openssl
--enable-rdrand
Enable testing support
--enable-conftest
--enable-integrity-test
--enable-test-vectors
Disable legacy ciphers
--disable-cmac
--disable-des
--disable-ikev1
--disable-md5
--disable-rc2
--disable-sha1
--disable-xcbc
Disable unused features
--disable-attr
--disable-dnskey
--disable-pgp
--disable-pkcs1
--disable-pkcs7
--disable-pkcs8
--disable-resolve
--disable-scepclient
--disable-sshkey
--disable-xauth-generic
We'll also need to figure out package signing and write a script to automate this somehow:
We may be able to limit the privileges of the strongSwan daemon even further by running StrongSwan as a non-root user and then limiting it to
cap_net_admin
.cap_new_raw
may be required if we useconnmark
since it's required by the iptables library that plugin uses.