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 up
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 testing support
Disable legacy ciphers
Disable unused features
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
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
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!