Increasing default SSL key size
-
We are talking about a network equipment with lots of exploitable capabilities. Not about generic “some thing”. Certainly hope pfSense developers don’t have philosophy that it is just “some thing” that security doesn’t matter.
Companies being more concerned about performance than customer privacy are the reason so many breaches occur. That should be the example of the wrong security philosophy, not used as an example that everybody else does it like this so that must mean it’s okay and the way for us too.
If some intentionally have feeble security to allow snooping that is their business. But it is not a justification for others to do the same.
I don’t put stuff up in the cloud that I wouldn’t be willing to post publicly. Not even if encrypted. In a few short years todays encryption will be trivial to crack. And once uploaded it is there to stay. Nothing can truly be deleted from the web/cloud. Once the cat is out of the bag it cannot be put back in.
Oh by the way. Put a 4096 length cert on a pfSense box Web GUI Configurator. Don’t notice it being any slower. Overkill you say. Maybe. But it doesn’t seem to have any significant down side so why not.
-
TLS/SSL negotiation uses two different ciphers over time. The RSA key (which can be 512,1024,2048, or 4096 bit) is only used for the first few packets of the connection, which are used to exchange keys (56,64,128 or 256 bit) for the second symmetric cipher only.
Once RSA key has been exchanged, both ends switch to a symmetric cipher (e.g. RC4 in the case of Google/Amazon/etc, or AES, or sometimes others e.g. Camellia based on what I see when connecting to pfsense) to exchange actual data, and your RSA key length is completely irrelevant.
According to http://en.wikipedia.org/wiki/Key_size Cryptography professor Arjen Lenstra […] when asked whether 1024-bit RSA keys are dead, said: "The answer to that question is an unqualified yes."
-
"when asked whether 1024-bit RSA keys are dead, said: "The answer to that question is an unqualified yes."
And so is TLS 1.0 – so why are you not complaining pfsense https gui does not support 1.2?
The DEFAULT SSL key is not something anyone that is really worried about security would be using in the first place.. How do you know the developers of pfsense don't have the private side? How do you know someone that submits code for pfsense did not setup something to get the private key? So shouldn't you be using a key that your sure of.
I would be more interested in that, than what the "default" key length is set too.
From what security standpoint are you going to say that a "default" should be used? So do you leave the default password? Do you leave the default SSH key?
My point being from your OP
"whereas the more security conscious among us might want to use RSA-4096 and sha256."Then do so! What does that have to do with the "default" key length? Default is Never a good thing in the security world, so what does it matter what the default key length is.. To be honest if anything they should set it to 512 ;) Faster to create and less overhead during that first connection where you then change it to what you want to use.
-
To be honest if anything they should set it to 512 ;)
Then do so, and while you're at it, make sure to replace SSH with plaintext telnet, as you suggested a few posts ago.
Sorry I don't have the time to deal with Internet trolls!
-
"when asked whether 1024-bit RSA keys are dead, said: "The answer to that question is an unqualified yes."
And so is TLS 1.0 – so why are you not complaining pfsense https gui does not support 1.2?
First of all, he wasn't complaining. If you care to read the OP again, you'll see it's simply a suggestion.
And second, they should update the OpenSSL package as soon as possible to support at least TLS 1.1The DEFAULT SSL key is not something anyone that is really worried about security would be using in the first place.. How do you know the developers of pfsense don't have the private side? How do you know someone that submits code for pfsense did not setup something to get the private key? So shouldn't you be using a key that your sure of.
Yeah with that in mind you probably shouldn't use a computer at all… or a cellphone... or a tv... not even an ipod :)
I would be more interested in that, than what the "default" key length is set too.
From what security standpoint are you going to say that a "default" should be used? So do you leave the default password? Do you leave the default SSH key?
My point being from your OP
"whereas the more security conscious among us might want to use RSA-4096 and sha256."Then do so! What does that have to do with the "default" key length? Default is Never a good thing in the security world, so what does it matter what the default key length is.. To be honest if anything they should set it to 512 ;) Faster to create and less overhead during that first connection where you then change it to what you want to use.
Have you ever heard of the words "secure by default"?
When you first install a firewall (any decent firewall) the ports on the WAN interface are always closed, the default protocol for web administration is HTTPS (not HTTP) and for console administration is SSH (not telnet); also the administration is only allowed from the LAN. That's the idea of being "secure by default", you only have to start opening ports and allowing the things you want.
The default key lenght of the certificate for HTTPS connections is just a part of this, and they should keep it by default at at least the minimum lenght which is considered secure by today's standards. That's of course just my opinion. -
Lowering the key size isn't exactly akin to completely removing encryption, so that's not a fair comparison at all (ssh vs telnet).
1024 should be OK for a default on the GUI. If someone wants more, they can make one. We have to keep the performance in mind of old/slow devices as well when it comes to default values, and every cycle counts on some units, so the defaults have to strike a balance.
If everything was speedy/fast, sure, increasing the defaults would be fine. But as it stands, for most people, it isn't necessary.
You should be locking out GUI access on networks you don't trust anyhow, as we do by default.
-
I did some tests in my Alix 2C3 using ab from one of my servers and using key lengths of 1024 and 2048bits on the firewall (2.0.1). Here are the results in case anyone is interested:
1024bit:
root@test:~# ab -n100 -c2 -f TLS1 https://alix.lan/firewall_rules.php This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking alix.lan (be patient).....done Server Software: lighttpd/1.4.29 Server Hostname: alix.lan Server Port: 443 SSL/TLS Protocol: TLSv1/SSLv3,DHE-RSA-AES256-SHA,1024,256 Document Path: /firewall_rules.php Document Length: 6422 bytes Concurrency Level: 2 Time taken for tests: 32.338 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 684078 bytes HTML transferred: 642200 bytes Requests per second: 3.09 [#/sec] (mean) Time per request: 646.763 [ms] (mean) Time per request: 323.381 [ms] (mean, across all concurrent requests) Transfer rate: 20.66 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 114 333 110.9 323 1084 Processing: 251 311 25.3 311 549 Waiting: 242 309 25.6 307 549 Total: 386 644 110.2 630 1390 Percentage of the requests served within a certain time (ms) 50% 630 66% 631 75% 631 80% 632 90% 638 95% 650 98% 1390 99% 1390 100% 1390 (longest request)2048bit:
root@test:~# ab -n100 -c2 -f TLS1 https://alix.lan/firewall_rules.php This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking alix.lan (be patient).....done Server Software: lighttpd/1.4.29 Server Hostname: alix.lan Server Port: 443 SSL/TLS Protocol: TLSv1/SSLv3,DHE-RSA-AES256-SHA,2048,256 Document Path: /firewall_rules.php Document Length: 6422 bytes Concurrency Level: 2 Time taken for tests: 45.552 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 684100 bytes HTML transferred: 642200 bytes Requests per second: 2.20 [#/sec] (mean) Time per request: 911.032 [ms] (mean) Time per request: 455.516 [ms] (mean, across all concurrent requests) Transfer rate: 14.67 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 400 411 7.9 415 437 Processing: 492 500 6.6 504 520 Waiting: 489 497 6.7 501 516 Total: 904 911 6.5 909 944 Percentage of the requests served within a certain time (ms) 50% 909 66% 909 75% 909 80% 910 90% 915 95% 929 98% 943 99% 944 100% 944 (longest request)Overall I'm seeing an additional latency of about 300ms (remember this is the initial ssl handshake), but on the other hand a much lower standard deviation on latency. My guess is because I'm using 2 lighttpd processes and the 2048bit key length gives me about 2 requests per second, while the 1024bit key length gives me about 3 requests per second so it may get unsynced.
Subjectively, it feels perfectly usable so far and not different performance-wise than using a 1024bit key length. And after the initial connection I can't even notice any difference with a regular unencrypted HTTP connection. But I just switched so this is just an initial impression. -
Real numbers, nice. :)
Steve
-
For those working at least in the United States in certain regulated industries, the NIST SP800-131A document's regulations are extremely important. Being able to answer an auditor with a flat "No, we have never had a certificate on the network or on the premises that does not meet NIST SP800-131A requirements" is valuable; you don't have to waste time explaining the exceptions, "Well, it was a default configuration on a new firewall, and we changed it immediately. Yes, it was plugged into the core switch. No, no-one else got into it. Yes, here's a copy of the logs from the time we turned it on until the time the certificate was changed. Yes, here's the documentation of the approval."
As others have said, upgrading OpenSSL to 1.0.x and getting TLS 1.1/1.2 available would also be very welcome.
-
Yup. There is really no good reason for rolling out version after version of down rev’d and out of date product.
If people can't deal with upgrading then they can stay on the previous existing rev they are currently running. Placating lowest common denominator at the expense of everyone is it just bad dogma.
