• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Increasing default SSL key size

2.1 Snapshot Feedback and Problems - RETIRED
9
22
8.1k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J
    johnpoz LAYER 8 Global Moderator
    last edited by Jun 10, 2012, 4:27 PM Jun 10, 2012, 4:09 PM

    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

    newcert.jpg
    newcert.jpg_thumb

    An intelligent man is sometimes forced to be drunk to spend time with his fools
    If you get confused: Listen to the Music Play
    Please don't Chat/PM me for help, unless mod related
    SG-4860 24.11 | Lab VMs 2.7.2, 24.11

    1 Reply Last reply Reply Quote 0
    • S
      stephenw10 Netgate Administrator
      last edited by Jun 10, 2012, 9:20 PM

      @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

      1 Reply Last reply Reply Quote 0
      • N
        NOYB
        last edited by Jun 10, 2012, 10:10 PM

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

        1 Reply Last reply Reply Quote 0
        • R
          rcfa
          last edited by Jun 11, 2012, 12:10 AM

          @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?

          1 Reply Last reply Reply Quote 0
          • N
            NOYB
            last edited by Jun 11, 2012, 1:09 AM Jun 11, 2012, 1:04 AM

            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.

            1 Reply Last reply Reply Quote 0
            • D
              dhatz
              last edited by Jun 11, 2012, 7:38 AM

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

              1 Reply Last reply Reply Quote 0
              • J
                johnpoz LAYER 8 Global Moderator
                last edited by Jun 11, 2012, 11:19 AM Jun 11, 2012, 11:14 AM

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

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                1 Reply Last reply Reply Quote 0
                • D
                  dhatz
                  last edited by Jun 11, 2012, 12:04 PM

                  @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!

                  1 Reply Last reply Reply Quote 0
                  • F
                    feadin
                    last edited by Jun 11, 2012, 2:34 PM

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

                    1 Reply Last reply Reply Quote 0
                    • J
                      jimp Rebel Alliance Developer Netgate
                      last edited by Jun 11, 2012, 2:38 PM

                      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.

                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

                      1 Reply Last reply Reply Quote 0
                      • F
                        feadin
                        last edited by Jun 11, 2012, 4:18 PM Jun 11, 2012, 4:14 PM

                        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.

                        1 Reply Last reply Reply Quote 0
                        • S
                          stephenw10 Netgate Administrator
                          last edited by Jun 11, 2012, 4:27 PM

                          Real numbers, nice.  :)

                          Steve

                          1 Reply Last reply Reply Quote 0
                          • N
                            Nadrek
                            last edited by Jun 15, 2012, 3:00 AM

                            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.

                            1 Reply Last reply Reply Quote 0
                            • N
                              NOYB
                              last edited by Jun 15, 2012, 5:07 AM

                              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.

                              1 Reply Last reply Reply Quote 0
                              18 out of 22
                              • First post
                                18/22
                                Last post
                              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.