Webconfig cipher suite?

fabrizziop

Hey, I have the latest pfsense amd64 snapshot running, and I noticed several things:

Why are we preferring Camellia over AES?. After all, AES is the block cipher used everywhere and is probably held up to more scrutiny than Camellia.
The DH parameters used in the web server are only 1024-bit according to SSL Labs. Why bother with Camellia-256 and 4096-bit RSA if you only use a 1024-bit key exchange?.

I think that the webconfigurator interface should either let you choose your DH parameters from a list of pre-generated ones (1024, 2048, 4096 bit) or automatically select them based on your RSA modulus length.

If not, saner values should be used, like AES-128 and Camellia-128, because the weakest link there will be the DH key exchange.

I assume you're not using ECDSA and ECDHE because it has compatibility issues with an accelerator card, that's plain speculation right there, but they're way faster than RSA and DH. If you don't use them because you're scared of the NSA, then you should be more scared of 1024-bit DH.

As usual, sorry for the weird english.

The cipher suite in the latest snapshot is:


DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:CAMELLIA128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:!aNULL:!eNULL:!3DES:@STRENGTH

meteotest

i would be interested in that choice too (also why is AESGCM excluded specifically)?

at the moment this is one of the most robust encrytion suites:

ECDH+AESGCM:DH+AESGCM:AES256+EECDH:AES256+EDH

crappy/old browsers/OSes not supported. it would be nice if add a hardened encryption option would be added in the GUI (ofc with warning, not to enable for certain hardware/browser combos) or better yet rename migitate BEAST to something more suited.

as it stands, i'm hacking up /etc/inc/system.inc as follows:

diff -u system.inc.orig system.inc
--- system.inc.orig     2015-01-14 10:05:16.860689145 +0100
+++ system.inc  2015-01-14 10:06:04.628213144 +0100
@@ -1337,7 +1337,7 @@

                if (isset($config['system']['webgui']['beast_protection'])) {
                        $lighty_config .= "ssl.honor-cipher-order = \"enable\"\n";
-                       $lighty_config .= "ssl.cipher-list = \"ECDHE-RSA-AES256-SHA384:AES256-SHA256:HIGH:!MD5:!aNULL:!EDH:!AESGCM\"\n";
+                       $lighty_config .= "ssl.cipher-list = \"ECDH+AESGCM:DH+AESGCM:AES256+EECDH:AES256+EDH\"\n";
                } else {
                        $lighty_config .= "ssl.cipher-list = \"DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:CAMELLIA128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:!aNULL:!eNULL:!3DES:@STRENGTH\"\n";
                }

firewalluser

Some info on camellia taken from:
http://www.mitsubishielectric.com/news/2013/0326-b_print.html
"An encryption algorithm is proven to be secure when it has resisted multiple deciphering attacks over a long period of time. Camellia's security has been continuously tested over a decade by the cryptography research community. Meanwhile, its ability to withstand newly-found attack techniques, including related-key, biclique-based meet-in-the-middle, and rebound attacks, was investigated, but no successful attack has been reported so far. Camellia's level of security therefore surpasses that of AES, which was subject to successful (but impractical) related-key attacks reported on its 192- and 256-bit versions."

"at the moment this is one of the most robust encrytion suites:"
Any encryption built on a chip can not be inspected, but you can can inspect code which is part of the appeal of opensource software.

meteotest

The question was not directed at the 2nd Ciphersuite. But why AESGCM was specifically excluded in the first.

The reason i ask, is that the specific Ciphersuite uses SHA-1 (which is broken https://www.schneier.com/blog/archives/2005/02/sha1_broken.html ) as MAC, whereas the one i replace it with uses SHA256 AEAD GCM.

As it turns out, the same can be achieved in lighttpd with this Suite:

AES128+EECDH:AES128+EDH

If you want to read up on the reasoning behind: https://cipherli.st/ (not my site, but a great resource).

The reason i was so intrigued is this post https://forum.pfsense.org/index.php?topic=81107.msg442731 which specifically mentions AESGCM. So if it's good and desirable for VPN, it should be good enough for WebGUI security, no?

Also, notice the tagline "This is how you open source" ;)

kejianshi

The US government loves to promote AES - So, I don't trust it…

I actually trust blowfish at 128 more than AES at 256... But I'm weird like that.

meteotest

It's not that weird. Actually you should trust AES more at 128 than at 256 aswell…

Still the original question remains. And it's mainly directed at the devs.

firewalluser

ECB is easier to crack.

A clue as to why can be seen here.

https://pthree.org/2012/02/17/ecb-vs-cbc-encryption/

fabrizziop

@meteotest:

The question was not directed at the 2nd Ciphersuite. But why AESGCM was specifically excluded in the first.

The reason i ask, is that the specific Ciphersuite uses SHA-1 (which is broken https://www.schneier.com/blog/archives/2005/02/sha1_broken.html ) as MAC, whereas the one i replace it with uses SHA256 AEAD GCM.

As it turns out, the same can be achieved in lighttpd with this Suite:
AES128+EECDH:AES128+EDH
If you want to read up on the reasoning behind: https://cipherli.st/ (not my site, but a great resource).

The reason i was so intrigued is this post https://forum.pfsense.org/index.php?topic=81107.msg442731 which specifically mentions AESGCM. So if it's good and desirable for VPN, it should be good enough for WebGUI security, no?

Also, notice the tagline "This is how you open source" ;)

HMAC-SHA1 isn't broken. Cipher suites like AES128-SHA256 and AES256-SHA384 are useless and only add more overhead.

If you're scared of AES, then use Camellia, but first worry about larger DH parameters. 1024-bit DH is probably trivial to crack by the NSA. It's like 80-bit equivalent security. The constants used in the curves commonly used for ECDH are created from a hash of a "random" seed chosen "randomly" by NIST/NSA, so avoid those elliptic curves if possible, just by precaution.

I made a pull request about a month ago, fixing the issue, but got totally ignored.
https://github.com/pfsense/pfsense/pull/1390
https://github.com/fabrizziop/pfsense/commit/136df3243bad20380b796160f3e53636a8eb55f0

cmb

@fabrizziop:

I made a pull request about a month ago, fixing the issue, but got totally ignored.

Not ignored at all, that was just too late in the release cycle for making that kind of a change. Cipher changes seem innocuous, but when you have to support a wide range of devices, with a variety of other pieces potentially interfering (such as hardware crypto cards), that's not the kind of change you make late in a release cycle. It's something we'll get merged for 2.2.1 and newer releases.