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

    More secure Diffie - Hellman groups, why not?

    Scheduled Pinned Locked Moved IPsec
    8 Posts 3 Posters 8.7k Views
    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.
    • D
      dusan
      last edited by

      I'm not a programmer. This is a six-year old and already answered question. But I'm sorry I don't think it's resolved:

      http://forum.pfsense.org/index.php/topic,2937.0.html

      The question is: why pfSense doesn't support more secure Diffie - Hellman groups?

      For example, group 14 (modp 2048) and group 15 (modp 3072) which provide 112-bit and 128-bit security, respectively.

      I'm aware of this KAME document

      http://www.kame.net/racoon/racoon.conf.5

      which states that racoon supports only groups 1, 2 and 5.

      That [very old] document is clearly obsolete. Nowaday ipsec-tools v.0.8 (in pfSense v.2) supports many RFC3526 groups, including groups 14 and 15. Besides the new documentation, another convincing argument is the file dhgroup.h from the source code /usr/ports/security/ipsec-tools.

      It's my understanding that ipsec-tools performs all public-key crypto stuffs, including Diffie-Hellman key exchange, by itself. It requires no special kernel services. AFAIK the IPsec-enabled kernel performs only secret-key crypto stuffs. With built-in AES, the kernel is ready for 128-bit security. We just need a proper [symmetric] 112- or 128-bit key derived by racoon,

      and a Web UI with more DH group options, generating the proper racoon.conf.

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        If it's supported by racoon, then there may not be anything holding it back. Open a feature request ticket at http://redmine.pfsense.org/ and we can look into it.

        The problem may just be inertia - it works as-is, and nobody has tried to change it, so it's stayed the same. While we're at it, we could add in sha256, sha384, and sha512 rather than just MD5/SHA1.

        Looks like the racoon.conf man page is a bit more up-to-date than what you saw.

        For P1:

        proposal { sub-substatements }
                            encryption_algorithm algorithm;
                                    Specifies the encryption algorithm used for the
                                    phase 1 negotiation.  This directive must be
                                    defined.  algorithm is one of following: des,
                                    3des, blowfish, cast128, aes, camellia
        for Oak-
                                    ley.  For other transforms, this statement should
                                    not be used.
                            hash_algorithm algorithm;
                                    Defines the hash algorithm used for the phase 1
                                    negotiation.  This directive must be defined.
                                    algorithm is one of following: md5, sha1, sha256,
                                    sha384, sha512
        for Oakley.
                            authentication_method type;
                                    Defines the authentication method used for the
                                    phase 1 negotiation.  This directive must be
                                    defined.  type is one of: pre_shared_key, rsasig
                                    (for plain RSA authentication), gssapi_krb,
                                    hybrid_rsa_server, hybrid_rsa_client,
                                    xauth_rsa_server, xauth_rsa_client,
                                    xauth_psk_server or xauth_psk_client.
                            dh_group group;
                                    Defines the group used for the Diffie-Hellman
                                    exponentiations.  This directive must be defined.
                                    group is one of following: modp768, modp1024,
                                    modp1536, modp2048, modp3072, modp4096, modp6144,
                                    modp8192.  Or you can define 1, 2, 5, 14, 15, 16,
                                    17, or 18 as the DH group number.
         When you want
                                    to use aggressive mode, you must define the same
                                    DH group in each proposal.

        And for P2:

        encryption_algorithm algorithms;
                            des, 3des, des_iv64, des_iv32, rc5, rc4, idea, 3idea,
                            cast128, blowfish, null_enc, twofish, rijndael, aes,
                            camellia
        (used with ESP)
                    authentication_algorithm algorithms;
                            des, 3des, des_iv64, des_iv32, hmac_md5, hmac_sha1,
                            hmac_sha256, hmac_sha384, hmac_sha512, non_auth
        (used
                            with ESP authentication and AH)

        So the GUI options could be expanded quite a bit, assuming those all work.

        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
        • jimpJ
          jimp Rebel Alliance Developer Netgate
          last edited by

          https://github.com/bsdperimeter/pfsense/commit/665340db1142980ca40d49b9dddf1b07e07da3b8

          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
          • D
            dusan
            last edited by

            Great.

            I've applied your patch in a 2.0.1-RELEASE (i386) installation and tested it against a Shrew Soft VPN Client v.2.1.7. A phase 2 tunnel using PFS DH group 15 was established. It works.

            More results will follow soon.

            Many thanks for your good job.

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              Be sure to read my notes on the commit I linked about using that on 2.0.x. The DH groups should be safe though.

              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
              • T
                Timpscan
                last edited by

                So this will not work on 2.1?

                1 Reply Last reply Reply Quote 0
                • jimpJ
                  jimp Rebel Alliance Developer Netgate
                  last edited by

                  It will work on 2.1, and it does work on 2.1.

                  You just couldn't mix them between 2.0.x and 2.1 for SHA256-512, which is why I left it out of 2.0.x and don't encourage people to use the patches on 2.0.x.

                  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
                  • D
                    dusan
                    last edited by

                    I use it, for the whole year, in a production VPN with 2.0.1-RELEASE devices and Fortinet FortiOS v.4.x devices. All IKE sessions use DH group 14 (the maximum supported by FortiOS standard edition) without any problem.

                    Many thanks.

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