Feature #4230
closed
Prefer SSL Perfect Forward Secrecy ciphers in UI
Added by Phil Koller almost 10 years ago.
Updated over 9 years ago.
Description
Perfect Forward Secrecy (PFS) ciphers should be preferred in the admin interface to further harden the admin web server.
Suggested changed/added settings to the webConfigurator configuration:
ssl.use-compression = "disable"
ssl.honor-cipher-order = "enable"
ssl.cipher-list = "AES128+EECDH:AES128+EDH:AES128-SHA:!aNULL:!eNULL:!DSS"
This configuration explicitly disables TLS compression and defines the correct cipher order. AES128-SHA is added as a fallback, DSS ciphers should not be used.
The result of
openssl ciphers -v 'AES128+EECDH:AES128+EDH:AES128-SHA:!aNULL:!eNULL:!DSS'
will be:
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
Background:
https://raymii.org/s/tutorials/Strong_SSL_Security_On_lighttpd.html
- Project changed from pfSense Packages to pfSense
- Category set to Web Interface
- Target version set to 2.2.1
- Affected Version deleted (
2.2)
this is something I'd noted for 2.2.1 but don't think we have a ticket on it.
Any specific reason to disable AES256 ones?
As stated in the background paper:
"AES128 is preferred to AES256. There have been discussions on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks."
Another discussion on the topic:
http://security.stackexchange.com/questions/14068/why-most-people-use-256-bit-encryption-instead-of-128-bit
In case this isn't convincing, AES256 can be added again. Just make sure EECDH is always used first, e.g.
ssl.use-compression = "disable"
ssl.honor-cipher-order = "enable"
ssl.cipher-list = "AES256+EECDH:AES128+EECDH:AES256+EDH:AES128+EDH:AES256-SHA:AES128-SHA:!aNULL:!eNULL:!DSS"
- Assignee set to Chris Buechler
- % Done changed from 0 to 80
It looks like the best compromise is enabling both 128 and 256, and preferring 128, which is the change I just committed. With that, it scores an A on ssllabs.com. Its only complaint is considering TLS_DHE_RSA_WITH_AES_* options "weak." But, disabling those breaks several clients/browsers. The config as committed only breaks with IE on Windows XP (which is fine, and already known broken by 2.2's list).
AES 256 doesn't break with glxsb, including where only AES256 is in the cipher-list. So that's not a concern. Also no issue with AES-NI, but didn't expect any problems there.
Only thing remaining to test with hifn card, which I'll do in the morning. If someone else has a hifn and can help test, it'd be appreciated. Depending on the result of that, we may be able to get rid of the BEAST option.
- % Done changed from 80 to 90
Fine with hifn cards too. Renato's removing the BEAST option since it's no longer necessary then this will be complete.
- Status changed from New to Feedback
- % Done changed from 90 to 100
- Status changed from Feedback to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by