search

opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.36k stars 753 forks source link

Feature request: AES256 encryption for HTTPS "webConfigurator" #1301

Closed shezzski closed 7 years ago

shezzski commented 7 years ago

OPNsense 16.7.10 supports AES128 encryption for the HTTPS web management interface, otherwise known as the "webConfigurator".

I think the web server (lighhtpd) configuration file is located at /var/etc/lighty-webConfigurator.conf. OPNsense (twitter) advised that you can manually change the ssl ciphers list within the web server configuration to force AES256 with the line:

ssl.cipher-list = "AES256+EECDH:AES256+EDH:!aNULL:!eNULL"

While I am unable to get this working, it would be ideal to be able to set the ciphers within the WebConfigurator itself. This would enable OPNsense to be used in environments that have requirements for AES256 encryption, or for someone who is security conscious.

fichtner commented 7 years ago

Thanks!

The line in question that needs modification is:

https://github.com/opnsense/core/blob/master/src/etc/inc/system.inc#L1280

located at /usr/local/etc/inc/system.inc

This should make it work locally for now. :)

Cheers, Franco

fabianfrz commented 7 years ago

@shezzski it is always a bad idea to be limited to one cipher. If it gets broken, you do not have a chance to keep it secure. I prefer to have always at least two of them available. This is why I prefer to have CAMELLIA as an option available. However there is a huge difference in the supported ciphers between OpenSSL and LibreSSL. Keep in mind that not all TLS implementations support all cipher suits. So you should only prefer some but you should not reject secure cipher suits if possible.

mschilt commented 7 years ago

Depends on the situation. If all of the connecting clients are in your control then only using one cipher can perfectly make sense. IMHO AES128 is 'sufficiently secure' and about 40% faster than AES256. Block ciphers are most often not attacked. Using a 'better' key exchange would be more important since you are probably using NIST P-curves with ECDHE which pose some risks (see djb safecurves, rigidity). I would rather go for x25519 curve or Poly1305.

shezzski commented 7 years ago

Thanks @fichtner for the fix and @fabianfrz for the tips. I guess while I was exclusively asking for AES256 support, I think it would be good if OPNsense would support the selection of ciphers in the GUI by the OPNsense administrator so all can be happy.

fabianfrz commented 7 years ago

@mschilt As far as I can remember, curve 25519 and Poly 1305 etc. will come with TLS 1.3.

mschilt commented 7 years ago

Making the cipher string configurable would enable everyone to freely choose from what is available. Displaying the available ciphers (listed with "openssl ciphers -v") would be great.

@fabianfrz Nope. Not really. These primitives are already available today with TLS 1.2. Google Chrome and Firefox are shipping some of them already. Go visit https://www.ssllabs.com/ssltest/viewMyClient.html and check the ciphers. You should at least see TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 with both browsers and x25519 with chrome.

AdSchellevis commented 7 years ago

I've implemented the idea of @mschilt , if anyone likes to try it before it's in a release, use the following commands:

opnsense-patch 99dac4ab7
chmod 700 /usr/local/opnsense/scripts/system/ssl_ciphers.py
service configd restart