PfSense 2.5 will only work with AES-NI capable CPUs
-
The additional clarification from the developers was nice, but I still have some lingering concerns.
First, it appears that the AES side-channel attack (or any other attacks on AES) only matter if you use their cloud management or a VPN. I absolutely understand them wanting to secure their cloud management, so making AES-NI a requirement for that is fine. However, many people would be willing to accept the risk when running a VPN, and many more don't use the VPN at all.
For local management, the only way to see the encrypted data in transit is to be on the local machine, and at that point, you are attacking yourself. Rather than blanket require AES-NI, I think it should only be required for the cloud management (and maybe for VPN usage), since most home use, and even many small businesses, will not be using AES aside from the loopback iface for management.
My other issue is AES-NI is not nearly as common on embedded systems as people here are saying. Sure, if you are using desktop or server hardware for pfSense, you probably already have AES-NI, but if you are using embedded systems for a fanless low-power remote office setup (I have 3 remote sites like this), then AES-NI is not a given.
By way of example, this is the list of Intel processors currently being sold with at least 2 cores and that DON'T have AES-NI: https://ark.intel.com/Search/FeatureFilter?productType=processors&CoreCountMin=2&AESTech=false&FilterCurrentProducts=true
At this time, there are 233 processors on that list. If you restrict yourself to 4+ core processors, there are still 59 actively sold processors without AES-NI! Several of them were launched Q4 of last year, so we aren't just talking old stock laying around.This has hit me particularly, because I very recently purchased Qotom fanless PCs with both the Intel J1900 (4 core, Q4'13) and the Intel 3215U (2 core, Q2'15); both CPU designs are much newer than the AES-NI. Yet, none of my remote sites will be able to upgrade to pfSense 2.5 without new hardware. Since all the remote sites have sub-100Mbps internet, going to a newer CPU will provide no tangible benefit to the users, since I have no plans to use the cloud management features.
I would implore the developers to only require AES-NI if you plan to use one of the features that actually exposes an AES encrypted channel to the internet, such as cloud management or a VPN. And for the VPN, only our security is on the line, so IMO that should be a warning, not a requirement.
-
Didn't they say somewhere on here or on the blog that the reason to require AES-NI was because the workload of implementing future pfSense features was too high of they had to support non AES-NI platforms as well? Or d something along those lines.
Sounds like a smart move to me. I'd rather they make realistic goals that they can continue delivering a solid product on than try to accomplish something they already determined was improbable.
I'm sure a handful of users will leave over this but ultimately it seems like a sound decision based in reality.
-
Didn't they say somewhere on here or on the blog that the reason to require AES-NI was because the workload of implementing future pfSense features was too high of they had to support non AES-NI platforms as well? Or d something along those lines.
Unfortunately, nobody has any clue what that means because they also said they're not rolling their own crypto, and existing crypto libraries already implement a number of different algorithms with side channel resistance. All they've said so far is that that only want to use one particular algorithm out of the set of algorithms available, and they don't want to say more because reasons, which just leaves everyone to speculate. My speculation is that it has something to do with their cloud strategy (though even that doesn't make much sense), but we'll see.
I personally think enabling only one crypto mode with no fallback available to anything else is nuts, but it's not my sandbox.
-
Didn't they say somewhere on here or on the blog that the reason to require AES-NI was because the workload of implementing future pfSense features was too high of they had to support non AES-NI platforms as well? Or d something along those lines.
What they said was this:
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.
You might reasonably interpret these sentences as implying that if pfSense didn't simply use AES-NI (and other hardware implementations, like Marvell's CESA), then the pfSense developers would need to implement their own bit-sliced AES implementation.
But, that's not what it means. pfSense should already be running a bit-sliced AES implementation on any CPU that supports SSE3. Why? Because pfSense uses OpenSSL, and OpenSSL uses such an implementation when AES-NI isn't available, but SSE3 is.
That is, unless the pfSense devs disabled it when they built OpenSSL.
-
:'(
sad day for the home users. -
:'(
sad day for the home users.Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
-
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
First, the "sad day for home users" comment is presumably a reference to the announcement that the pfSense devs would rather leave behind home users who may have fairly recently bought Atom/Celeron (and even early i3) systems that lack AES-NI, than simply continue to let OpenSSL run with its existing bit-sliced AES implementation. Even if there was a good reason for AES-NI, it still sucks to leave those users behind (at least, from their perspective) instead of implementing some other solution. So, I don't really see the speculation there.
Second, did you see the second blog post? It's fairly detailed about the explanation. I personally don't think it justifies the decision, but it doesn't seem like there are big unknowns.
-
If all peoples, users and customers are spending $2 per year we could have all things we want!
-
(…)
"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."Will this "‘back-end’ (written in ‘C’)" be open source?
I would be interested to know this as well.
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
They specifically associated the rationale with "tens of thousands" of hits on a cloud back end. (Which isn't really that much–so it isn't clear why chacha20 is out, except maybe this is a way to screw with a certain hardware vendor that netgate has made no effort to hide their hostility towards, and who sells a lot of j1900 kit.)
-
They specifically associated the rationale with "tens of thousands" of hits on a cloud back end.
As someone stated on reddit, wouldn't that only the require the cloud server to have AES-NI? Why does the box at the remote location need it, it's not like it's getting hit with tens of thousands of requests.
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
They specifically associated the rationale with "tens of thousands" of hits on a cloud back end. (Which isn't really that much–so it isn't clear why chacha20 is out, except maybe this is a way to screw with a certain hardware vendor that netgate has made no effort to hide their hostility towards, and who sells a lot of j1900 kit.)
ChaCha20 is a marginally-standardized algorithm. It's specified in a purely optional extension to TLS v1.2, and I don't think the algorithm is recognized in any standards outside of IETF. It's a nice algorithm. It doesn't have anything approaching the analysis that's gone into AES, but it's a solid design is almost certainly safe to use. But corporate customers might want to stick to things more broadly accepted.
And, AES still has a performance advantage over ChaCha20 when using AES-NI.
Anyways, performance doesn't appear to be the motivating factor here. Performance considerations may drive them to use AES-NI on Netgate's cloud systems, but I can't imagine that RESTCONF is so chatty that there would be performance issues on the local pfSense boxes (and if it is, then we have bigger problems).
The blog post really focuses on the cache timing attacks.
-
I dig how this "controversy" has started some lively dialogue. They should do this more often.
-
I dig how this "controversy" has started some lively dialogue. They should do this more often.
Yes, it's very good to see the wheels turning. There's a lot of smart people out there.
-
The blog post really focuses on the cache timing attacks.
I have a limited understanding of the subject, but wouldn't that require the attacker to have access to the machine? If they have access, can't you assume that all security has gone out the window anyways?
-
Regarding cache timing attacks, aren't they only a problem for VMs? I do have a few virtualized pfSenses (and those are all on AES-NI-capable hardware), but the majority of mine are on dedicated low-power boxes.
-
ChaCha20 is a marginally-standardized algorithm. It's specified in a purely optional extension to TLS v1.2, and I don't think the algorithm is recognized in any standards outside of IETF. It's a nice algorithm. It doesn't have anything approaching the analysis that's gone into AES, but it's a solid design is almost certainly safe to use. But corporate customers might want to stick to things more broadly accepted.
So those customers can use AES-GCM, right?
And, AES still has a performance advantage over ChaCha20 when using AES-NI.
And ChaCha20 has the advantage in a pure software implementation, and it's still being improved with AVX512 et al.
Anyways, performance doesn't appear to be the motivating factor here. Performance considerations may drive them to use AES-NI on Netgate's cloud systems, but I can't imagine that RESTCONF is so chatty that there would be performance issues on the local pfSense boxes (and if it is, then we have bigger problems).
The blog post really focuses on the cache timing attacks.
And the cache timing attacks are also pretty irrelevant to a purely local instance. Back to square one.
Anyway, the reason I pointed out ChaCha20 in particular is that ChaCha20-Poly1305 is that it's an AEAD mode like AES-GCM. Having more than one option means that in the event of a catastrophic protocol weakness you have the ability to quickly fall back to an alternative. The other options are to continue to provide AES-CBC and/or look forward to AES-CCM.
At any rate, the fundamental argument "RFC 7525 REQUIRES [AES-GCM]" is bogus, the RFC says no such thing. There are good reasons to implement multiple algorithms/modes, and all this handwaving is just confusing.
-
and all this handwaving is just confusing.
Meh, It's Netgate. you get used to it. At least it's still free
