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





  • 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.


  • Rebel Alliance Global Moderator

    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?


  • Rebel Alliance Global Moderator

    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?

    @johnpoz:

    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.


  • Rebel Alliance Global Moderator

    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



  • Netgate Administrator

    @johnpoz:

    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".



  • @johnpoz:

    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.

    @johnpoz:

    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."


  • Rebel Alliance Global Moderator

    "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.



  • @johnpoz:

    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!



  • @johnpoz:

    "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.1

    @johnpoz:

    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.

    Yeah with that in mind you probably shouldn't use a computer at all… or a cellphone... or a tv... not even an ipod :)

    @johnpoz:

    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.


  • Rebel Alliance Developer Netgate

    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.


  • Netgate Administrator

    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.


Locked