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

    PfSense 2.5 will only work with AES-NI capable CPUs

    Scheduled Pinned Locked Moved General pfSense Questions
    169 Posts 46 Posters 88.8k 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.
    • C
      ChefRayB
      last edited by

      Yeah, if you are rooted in the same box it goes without saying :)

      I was thinking more in the lines of an attacker rooting another systems running on the same VM box…
      There are also ways without being root to access the cache memory and figure out the "secret keys"  (e.g. VM, cross VM, shared hugepage, adjacent process running in same native OS, etc... ) There are countermeasures to reduce the risk (e.g. disabling hugepage sharing, disabling L3 shared cross VM, etc...)

      As you've stated earlier, OpenSSL has it fixed :)

      Reference:
      OpenSSL vulnerabilities fixes
      https://www.openssl.org/news/vulnerabilities.html

      Page 10, B. The Cross-Core Cross-VM Attack
      http://users.wpi.edu/~teisenbarth/pdf/SharedCacheAttackSnP2015.pdf

      University writing tools to exploit time cache attacks....
      https://ts.data61.csiro.au/projects/TS/cachebleed/

      1 Reply Last reply Reply Quote 0
      • ?
        Guest
        last edited by

        But ARM? Is the project now wanting to compete with lower end offering like Netgear/Asus/TP-Link/D-Link routers and Ubiquity EdgeRouters?

        Many users were asking for it, now they got it!

        To everyone whining about this here, stop complaining about your mistakes here. The appropriate way to handle this is to put in a feature request for 2.5 to support non-AES-NI systems (possibly getting the SSE3 OpenSSL build included) and maybe the devs will consider it. They sure as heck aren't going wade through a few whiny forum posts and decide to change direction because of them.

        Things often changing fast, but good to know on what they are actual working.

        From my perspective, I see this as a issue stemming from a lack of roadmap more than anything. A roadmap helps me in understanding where the focus is, and where/when "major" architectural changes like this will be taking place. It also helps me in determining when a project/product is taking a direction is a direction that is focused on  solutions that don't benefit me or help me solve the issues I'm trying to solve.

        I see this blog more as a way they want to go and what we can expect from the next version, or what feature or
        option will be inside of the next version, and for sure which known issues are there or are solved out. This might
        be not the same as the most users will be expect, or something like a 100% right and matching way they are walking.

        I'm having a hard time understanding where the project direction is now: High-end high-throughput systems that would compete with CISCO/Checkpoint/Palo Alto? Centrally managed - again competing with higher end commercial offerings? Doesn't fit within my needs, but ok, I see many others demonstrating a desire for it in the forums (fastest residential Internet offeriing in my area is 500/50).

        The most questions were running in that direction, 1 GBit/s on WAN, turning the firewall in a real UTM, getting
        out the maximum of VPN throughput. This is more or less what the most peoples were asking so perhaps it
        comes from that side a bit and you may seeing only the Netgate or pfSense developers side, can this perhaps be?

        Cisco is playing in many more playgrounds and is a NASDAQ notated company so what x_86 hardware can compete
        against or plays in the same league likes the Cisco CRS-3 for 470.000 Euros?

        And PaloAlto is producing NG Firewalls, that are ASIC/FPGA supported and the greater models will starting at
        80.000 Euros.Also not the same range where pfSense is actual operating.

        I'm really confused where PFSense's focus/direction is now. I could be wrong, but I didn't think there was enough development resources to support this many major initiatives.

        This might be not alone pending on the pfSense team because FreeBSD is the base of it. And yes, also FreeBSD is
        widely used as a Server OS in many companies and in private Networks, Linux and Windows servers are supporting
        actual the QAT perhaps it comes from there, can this be?

        It's not a surprise to see the underlying BSD OS supporting ARM and hence giving PFSense the ability support ARM. It doesn't necessarily equate to trying to compete with the consumer, lower end offering like Netgear/Asus/TP-Link/D-Link routers.

        Many users were asking for a cheaper device then the SG-2220 unit and mostly used only for pure firewall tasks.

        Also, I wouldn't put Ubiquity EdgeRouters in the same boat as those consumer offerings, they're definitely Enterprise gear. Maybe the low end of Enterprise, but definitely not consumer oriented.

        They produce WISP gear from the lower bottom to the higher end for sure, useable for all sections, from the end user
        at home to get a good CPE or the WISP that will serve to that clients.

        No, it's the opposite of a roadmap. They very specifically have no intention of telling people what their plans are.

        Dropping some lines what is actual going on might be better then getting nothing to hear until it is out! Other may think
        different on this but I would be love to informed from time to time what is actual going on.

        1 Reply Last reply Reply Quote 0
        • A
          Agshlee
          last edited by

          @athurdent:

          @athurdent:

          Will this "‘back-end’ (written in ‘C’)" be open source?

          @ivor: would be nice if you or someone from netgate had an answer.

          @ivor: still very interested to hear the answer to this question!

          1 Reply Last reply Reply Quote 0
          • D
            DeLorean
            last edited by

            @Knight:

            The webGUI will be present either on our cloud service or on-device, both talking to the ‘back-end’ (written in ‘C’) on the device via a RESTCONF interface. This is just as I said back in February 2015.

            And this which concern me…

            I am absolutely not interested in having this manageable from the cloud, this is absolutely the last thing I would like to be manageable from the cloud… We are talking of a device that manages the security of a network, I don't want to make it remotely configurable...

            Will it be possible to totally disable remote administration with no possibility of ever activating it but from the firewall itself?

            Have a nice day!

            Nick

            I am also not interested in having the manageable part of MY firewall in the cloud.
            If this ever gets hacked, many users are sitting ducks and are exposed to all kinds of things.
            When there is a rollout of a bad update of the manageable part in the cloud, many users are envolved.
            And last, what about a closed network like a lab for testing purposes etc…. what doesn't have / require internet access,
            that cannot be configured ?
            Firewalls managed from the cloud is like driving a shoppingcart by pulling a few ropes on a parking lot,
            untill someone cuts the ropes, your shoppingcart rolls down the street and bangs a parked car.

            Grtz
            DeLorean

            1 Reply Last reply Reply Quote 0
            • A
              ashes00
              last edited by

              @Bismarck:

              @Knight:

              And this which concern me…

              I am absolutely not interested in having this manageable from the cloud, this is absolutely the last thing I would like to be manageable from the cloud… We are talking of a device that manages the security of a network, I don't want to make it remotely configurable...

              Will it be possible to totally disable remote administration with no possibility of ever activating it but from the firewall itself?

              Have a nice day!

              Nick

              +1

              +1 here as well!

              1 Reply Last reply Reply Quote 0
              • A
                Agshlee
                last edited by

                @athurdent:

                Will this "‘back-end’ (written in ‘C’)" be open source?

                I'll just quote this again! ::) Any response to this question ivor?

                1 Reply Last reply Reply Quote 0
                • A
                  athurdent
                  last edited by

                  @Agshlee:

                  @athurdent:

                  Will this "‘back-end’ (written in ‘C’)" be open source?

                  I'll just quote this again! ::) Any response to this question ivor?

                  No answer is also an answer.

                  1 Reply Last reply Reply Quote 0
                  • ivorI
                    ivor
                    last edited by

                    @athurdent:

                    @Agshlee:

                    @athurdent:

                    Will this "‘back-end’ (written in ‘C’)" be open source?

                    I'll just quote this again! ::) Any response to this question ivor?

                    No answer is also an answer.

                    @Agshlee:

                    @athurdent:

                    Will this "‘back-end’ (written in ‘C’)" be open source?

                    I'll just quote this again! ::) Any response to this question ivor?

                    Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.

                    Need help fast? Our support is available 24/7 https://www.netgate.com/support/

                    1 Reply Last reply Reply Quote 0
                    • A
                      athurdent
                      last edited by

                      @ivor:

                      Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions.

                      Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons. Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
                      Anyway, thank you for taking the time to respond.

                      1 Reply Last reply Reply Quote 0
                      • ivorI
                        ivor
                        last edited by

                        @athurdent:

                        Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons.

                        Then you should not make assumptions like: "No answer is also an answer."

                        @athurdent:

                        Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
                        Anyway, thank you for taking the time to respond.

                        There's no need for passive-aggressive remarks. Thanks.

                        Need help fast? Our support is available 24/7 https://www.netgate.com/support/

                        1 Reply Last reply Reply Quote 0
                        • A
                          ashes00
                          last edited by

                          @athurdent:

                          @ivor:

                          Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions.

                          Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons. Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
                          Anyway, thank you for taking the time to respond.

                          I too find Ivor's an interesting moderator.  I will leave it at that!

                          1 Reply Last reply Reply Quote 0
                          • ivorI
                            ivor
                            last edited by

                            @ashes00:

                            @athurdent:

                            @ivor:

                            Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions.

                            Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons. Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
                            Anyway, thank you for taking the time to respond.

                            I too find Ivor's an interesting moderator.  I will leave it at that!

                            I don't see what the problem is. Thread went off-topic, it's still here and you're welcome to discuss further. Just don't demand or try to force me to respond to your off-topic questions.

                            Need help fast? Our support is available 24/7 https://www.netgate.com/support/

                            1 Reply Last reply Reply Quote 0
                            • R
                              reggie14
                              last edited by

                              @ivor:

                              Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.

                              Are you willing or able to comment on what the developers have decided was unacceptable with Mike Hamburg's constant-time (and cache-timing-resistant) AES implementation already in OpenSSL?

                              That question seems directly applicable to the original post.

                              1 Reply Last reply Reply Quote 0
                              • ivorI
                                ivor
                                last edited by

                                @reggie14:

                                @ivor:

                                Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.

                                Are you willing or able to comment on what the developers have decided was unacceptable with Mike Hamburg's constant-time (and cache-timing-resistant) AES implementation already in OpenSSL?

                                That question seems directly applicable to the original post.

                                Our developers have not made such decision. I suggest you read the blog posts again. It appears you have missed this part:

                                Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.

                                It's worth to point out that you've made a lot of assumptions on this thread.

                                Thanks.

                                Need help fast? Our support is available 24/7 https://www.netgate.com/support/

                                1 Reply Last reply Reply Quote 0
                                • R
                                  reggie14
                                  last edited by

                                  @ivor:

                                  @reggie14:

                                  @ivor:

                                  Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.

                                  Are you willing or able to comment on what the developers have decided was unacceptable with Mike Hamburg's constant-time (and cache-timing-resistant) AES implementation already in OpenSSL?

                                  That question seems directly applicable to the original post.

                                  Our developers have not made such decision. I suggest you read the blog posts again. It appears you have missed this part:

                                  Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.

                                  It's worth to point out that you've made a lot of assumptions on this thread.

                                  Thanks.

                                  I'm confused.  Are you saying now that the Netgate team hasn't decided to require AES-NI now, and are still considering whether to include bit-sliced software implementations?  That seems to contradict the blog posts.

                                  The first blog post specifically said AES-NI (or other hardware accelerators) would be required:

                                  pfSense Community Edition version 2.5 will include a requirement that the CPU supports AES-NI.

                                  The second blog post reiterated this, seemingly further emphasizing that AES-NI would be required, and rejecting bit-sliced implementations:

                                  With AES you either design, test, and verify a bitslice software implementation, (giving up a lot of performance in the process), leverage hardware offloads, or leave the resulting system open to several known attacks. We have selected the “leverage hardware offloads” path. The other two options are either unthinkable, or involve a lot of effort for diminishing returns.

                                  So to me, it definitely sounds like you've already decided to require AES-NI, and for some reason you don't like the existing bit-sliced implementation in the crypto library you already use.

                                  If I've made any incorrect or unfounded assumptions, I've love to know what they were.

                                  1 Reply Last reply Reply Quote 0
                                  • ivorI
                                    ivor
                                    last edited by

                                    @reggie14:

                                    I'm confused.

                                    Yes, you appear to be confused. I think I was very clear I cannot provide more comments or details other than what was revealed in the blog posts.

                                    Need help fast? Our support is available 24/7 https://www.netgate.com/support/

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      reggie14
                                      last edited by

                                      @ivor:

                                      @reggie14:

                                      I'm confused.

                                      Yes, you appear to be confused. I think I was very clear I cannot provide more comments or details other than what was revealed in the blog posts.

                                      I'm not trying to be difficult here.  And I'll even understand if there are certain things that you're not at liberty to say.  But now I'm trying to understand what you meant when you said:

                                      @ivor:

                                      Our developers have not made such decision. I suggest you read the blog posts again.

                                      The blog posts said AES-NI would be required in pfSense 2.5.  Your post from earlier today said that the developers have not decided that the VPAES implementation is unacceptable.  Does that mean they're considering to to allow the use of the VPAES implementation (which does not use AES-NI) in pfSense 2.5?  Are you suggesting that there may not be a requirement for AES-NI after all?

                                      1 Reply Last reply Reply Quote 0
                                      • ivorI
                                        ivor
                                        last edited by

                                        @reggie14:

                                        @ivor:

                                        @reggie14:

                                        I'm confused.

                                        Yes, you appear to be confused. I think I was very clear I cannot provide more comments or details other than what was revealed in the blog posts.

                                        I'm not trying to be difficult here.  And I'll even understand if there are certain things that you're not at liberty to say.  But now I'm trying to understand what you meant when you said:

                                        @ivor:

                                        Our developers have not made such decision. I suggest you read the blog posts again.

                                        The blog posts said AES-NI would be required in pfSense 2.5.  Your post from earlier today said that the developers have not decided that the VPAES implementation is unacceptable.  Does that mean they're considering to to allow the use of the VPAES implementation (which does not use AES-NI) in pfSense 2.5?

                                        AES-NI is required for pfSense 2.5. I think you misunderstood my post from earlier today.

                                        Need help fast? Our support is available 24/7 https://www.netgate.com/support/

                                        1 Reply Last reply Reply Quote 0
                                        • R
                                          reggie14
                                          last edited by

                                          @ivor:

                                          It's worth to point out that you've made a lot of assumptions on this thread.

                                          Seriously, I’d really like to know where I’ve run off with unfounded assumptions.  I looked through my earlier posts in this threads, and it seems like everything is based closely on statements in the blog posts with limited inferences based on other material.

                                          I’ll try to summarize the major points in my posts and I’d honestly appreciate feedback on items that are incorrect.

                                          • AES-NI (or other hardware accelerations) will be REQUIRED in pfSense 2.5. (reference)

                                          • Netgate is motivated by concerns over cache-timing attacks on AES. (reference)

                                          • Future versions of pfSense will use a RESTCONF API for management between a cloud or local hosted webGUI and the pfSense router.  This will use TLS with an AES-GCM cipher suite. (reference)

                                          • I deduce that Netgate is worried about cache-timing attacks allowing recovery of the AES-GCM key used in RESTCONF sessions (seemingly clear from above).

                                          • Cache-timing attacks are a legitimate threat, but are can be difficult to mount under realistic attack scenarios (reference)  An attack scenario involving the RESTCONF interface hasn’t been laid out by anyone yet.

                                          • pfSense developers are not implementing their own crypto, but are instead using  OpenSSL (reference)

                                          • OpenSSL already includes a constant-time, cache-timing-resistant AES implementation (reference: VPAES). While obviously not as fast as AES-NI, it still offers strong performance for a software implementation (reference).

                                          • OpenSSL v1.0.1s (which is running on my pfSense v2.3.3 box) and OpenSSL v1.0.2j (which I see referenced in the source tree) both include VPAES.

                                          • When referring to concerns over cache timing attacks on AES (reference), Netgate pointed to an NYU class project that would have disabled VPAES by disabling use of SSE3. (reference, page 5)

                                          • A requirement for AES-NI logically implies that the VPAES implementation was deemed unacceptable (or that its existence was unknown, or that it wasn't considered at all).

                                          1 Reply Last reply Reply Quote 0
                                          • ivorI
                                            ivor
                                            last edited by

                                            @reggie14:

                                            @ivor:

                                            It's worth to point out that you've made a lot of assumptions on this thread.

                                            Seriously, I’d really like to know where I’ve run off with unfounded assumptions.  I looked through my earlier posts in this threads, and it seems like everything is based closely on statements in the blog posts with limited inferences based on other material.

                                            I’ll try to summarize the major points in my posts and I’d honestly appreciate feedback on items that are incorrect.

                                            • AES-NI (or other hardware accelerations) will be REQUIRED in pfSense 2.5. (reference)

                                            • Netgate is motivated by concerns over cache-timing attacks on AES. (reference)

                                            • Future versions of pfSense will use a RESTCONF API for management between a cloud or local hosted webGUI and the pfSense router.  This will use TLS with an AES-GCM cipher suite. (reference)

                                            • I deduce that Netgate is worried about cache-timing attacks allowing recovery of the AES-GCM key used in RESTCONF sessions (seemingly clear from above).

                                            • Cache-timing attacks are a legitimate threat, but are can be difficult to mount under realistic attack scenarios (reference)  An attack scenario involving the RESTCONF interface hasn’t been laid out by anyone yet.

                                            • pfSense developers are not implementing their own crypto, but are instead using  OpenSSL (reference)

                                            • OpenSSL already includes a constant-time, cache-timing-resistant AES implementation (reference: VPAES). While obviously not as fast as AES-NI, it still offers strong performance for a software implementation (reference).

                                            • OpenSSL v1.0.1s (which is running on my pfSense v2.3.3 box) and OpenSSL v1.0.2j (which I see referenced in the source tree) both include VPAES.

                                            • When referring to concerns over cache timing attacks on AES (reference), Netgate pointed to an NYU class project that would have disabled VPAES by disabling use of SSE3. (reference, page 5)

                                            • A requirement for AES-NI logically implies that the VPAES implementation was deemed unacceptable (or that its existence was unknown, or that it wasn't considered at all).

                                            I will quote myself:

                                            I think I was very clear I cannot provide more comments or details other than what was revealed in the blog posts.

                                            Need help fast? Our support is available 24/7 https://www.netgate.com/support/

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