Increasing default SSL key size
-
I just happened to notice that the self-signed certificate created by default and used by lighttpd for the pfSense webGUI is using deprecated crypto (RSA-1024 and SHA1).
Consider bumping it up to RSA-2048, whereas the more security conscious among us might want to use RSA-4096 and sha256.
PS: Check http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
-
Some related info http://www.nsa.gov/business/programs/elliptic_curve.shtml
-
The auto-generated self-signed certificate is merely for convenience. Anyone who wants any real security either needs to create a cert off a CA their system(s) trust, or buy a cert from a trusted public CA, as is true with every such system.
-
There is security conscious – and then their is tinfoil hat ville ;)
The web gui is designed to be accessed via your local private lan, You could debate the need for ssl at all. But you feel that 1024 is not enough?
-
The web gui is designed to be accessed via your local private lan, You could debate the need for ssl at all.
I guess with that mentality one could also debate the need for SSH, why not use plain telnet in your local private lan?
Anyway, this was not a bug report (or I would have submitted it via redmine), it was just a quick heads up and my original suggestion to bump it up to 2048 can be implemented by simply changing one line in /etc/inc/system.inc
-
It's a simple change, it would increase security and I can't think of any problems with changing it rather than waiting for a few more minutes for the creation of the key on embedded systems… so why not?
-
Agreed on a private network, ssh vs telnet could be debated yes.
"it would increase security"
It would also increase overhead. Maybe my info or memory is bad, but I thought there was around a 5x hit for using 2048 vs 1024.. Why would you want that when 1024 is secure!!edit
https://devcentral.f5.com/weblogs/macvittie/archive/2010/09/10/f5-friday-the-2048-bit-keys-to-the-kingdom.aspx
The decrease in performance as key sizes increase is not linear, but more on the lines of exponential. For example, though the key size is shifting by a factor of two, F5 internal testing indicates that such a shift results in approximately a 5x reduction in performance (as measured by TPS – Transactions per Second). This reduction in performance has also been seen by others in the space, as indicated by a recent Citrix announcement of a 5x increase in performance of its cryptographic processing. This decrease in TPS is due primarily to heavy use of the key during the handshaking process. -
So, just to be clear, you're saying that NIST, VeriSign, GeoTrust, Entrust, Godaddy, Microsoft, Red Hat and Mozilla (among many others) are wrong? This change is happening, why would pfSense ingore it and stay with an obsolete key lenght?
Agreed on a private network, ssh vs telnet could be debated yes.
"it would increase security"
It would also increase overhead. Maybe my info or memory is bad, but I thought there was around a 5x hit for using 2048 vs 1024.. Why would you want that when 1024 is secure!!edit
https://devcentral.f5.com/weblogs/macvittie/archive/2010/09/10/f5-friday-the-2048-bit-keys-to-the-kingdom.aspx
The decrease in performance as key sizes increase is not linear, but more on the lines of exponential. For example, though the key size is shifting by a factor of two, F5 internal testing indicates that such a shift results in approximately a 5x reduction in performance (as measured by TPS – Transactions per Second). This reduction in performance has also been seen by others in the space, as indicated by a recent Citrix announcement of a 5x increase in performance of its cryptographic processing. This decrease in TPS is due primarily to heavy use of the key during the handshaking process. -
If you were going to do anything about security for the https connection, how about enable TLS 1.2 – TLS 1.0 is not really secure anymore now is it.
If it is such an issue, why is google still only using 1024? Why do sites still use RC4?
What I am saying is its a private network connection, you could debate the use of SSL on your private in the first place. If you want to use a 4096 cert, go for it! All you have to do is install your own vs using the default one.
There is more to your Secure connection then the length of the key. If you really think that 2048 is more secure on your private network, its quite easy to change it out.
But I for sure don't have a problem with a 1024 bit default length. 512 would be fine with me ;)
It took a couple of clicks to get a new 4096 cert btw
-
What I am saying is its a private network connection, you could debate the use of SSL on your private network in the first place.
I can think of many scenarios where the people with the greatest incentive to reconfigure your firewall are on the LAN side already. In a web cafe for example. I guess I wouldn't really say class it as a 'private' network in that case.
Steve
-
"Private" / "Local" network does not mean that the owner(s) / operator(s) / administrator(s) are the only ones with access / connected to the network, and have direct control over everyone who does 24x7.
Some corporate policies require all network traffic to be encrypted. Better than oops, how come that wasn't encrypted and got out. Encrypt everything and be done with it rather than having to make decision for each item and end up missing something.
As for the level of encryption. The strongest available that is "usable".
-
The decrease in performance as key sizes increase is not linear, but more on the lines of exponential. For example, though the key size is shifting by a factor of two, F5 internal testing indicates that such a shift results in approximately a 5x reduction in performance (as measured by TPS – Transactions per Second). This reduction in performance has also been seen by others in the space, as indicated by a recent Citrix announcement of a 5x increase in performance of its cryptographic processing. This decrease in TPS is due primarily to heavy use of the key during the handshaking process.
Well, I doubt TPS is an issue when it comes to the web interface of pfSense…
...it's not like this is a high-transaction thing.If you were going to do anything about security for the https connection, how about enable TLS 1.2 – TLS 1.0 is not really secure anymore now is it.
If it is such an issue, why is google still only using 1024? Why do sites still use RC4?
Because for some things it doesn't matter, for some things the companies are more concerned about performance than about customer's privacy, and for some things, I bet, things are kept intentionally vulnerable such that certain three-letter-agencies can rumage through the data if they so desire.
I mean, nobody here actually believes that cloud services keep their data confidential, do they?
-
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
