PfSense 2.5 will only work with AES-NI capable CPUs
-
So requiring hardware AES-NI is to alleviate the concern of software AES timing side-channel attacks within TLS.
From Bernstein's original Pentium III tests it appears to take coordination between the attacker and server to calculate the correlations. Wouldn't this require nefarious code to be installed on pfSense to coordinate with the attacker to perform a timing side-channel attack ? If yes, wouldn't installing nefarious code be game-over in the pfSense case long before trying some tedious side-channel attack ?
Additionally multi-core CPU's seems to reduce the effectiveness of such an attack.
From a practical standpoint, is requiring AES-NI really a gotta-have ? Or would a suitable one-time warning at installation or runtime for multi-core, non-AES-NI hardware be sufficient for all practical purposes ?
-
@lra:
From Bernstein's original Pentium III tests it appears to take coordination between the attacker and server to calculate the correlations. Wouldn't this require nefarious code to be installed on pfSense to coordinate with the attacker to perform a timing side-channel attack ? If yes, wouldn't installing nefarious code be game-over in the pfSense case long before trying some tedious side-channel attack ?
+1
Heck, even allowing a contrived attack model that lets the attacker run code on the victim's computer, and targeting single core Atom machine, the UCSD researchers still couldn't construct anything approaching a realistic attack, concluding:
Therefore, we posit that any data-cache timing attack against x86 processors that does not somehow subvert the prefetcher, physical indexing, and massive memory requirements of modern programs is doomed to fail, to say nothing of the difficulties imposed by multicore processors and hardware AES implementations.
-
pfsense is seriously wants their userbase go hell way down now arent they?
in reality, most users who use pfsense use it because they can be installed in almost any hardware that has 2 or more nics, now after 2.5, you cant do that shit anymore. kthxbye.
can they just create a pfsense 2.5 AES-NI edition (and non aes-ni edition) or something along those line and everyone will be fine?
-
pfsense is seriously wants their userbase go hell way down now arent they?
in reality, most users who use pfsense use it because they can be installed in almost any hardware that has 2 or more nics, now after 2.5, you cant do that shit anymore. kthxbye.
can they just create a pfsense 2.5 AES-NI edition (and non aes-ni edition) or something along those line and everyone will be fine?
You can ebay a used dell/hp xeon 6 core 3.33ghz for like $300.
-
pfsense is seriously wants their userbase go hell way down now arent they?
in reality, most users who use pfsense use it because they can be installed in almost any hardware that has 2 or more nics, now after 2.5, you cant do that shit anymore. kthxbye.
can they just create a pfsense 2.5 AES-NI edition (and non aes-ni edition) or something along those line and everyone will be fine?
Please do not be rude or exaggerate. We are giving everyone a heads up for almost two years in advance, they will require a CPU from 2011 or newer. When pfSense 2.5 is released, pfSense 2.4 will be supported for another year or so.
-
We are giving everyone a heads up for almost two years in advance, they will require a CPU from 2011 or newer. When pfSense 2.5 is released, pfSense 2.4 will be supported for another year or so.
To be fair, not all chips released in/after 2011 included AES-NI. The low-power Celerons come to mind.
-
…can be installed in almost any hardware
that has 2 or more nics, now after 2.5, …CTFU
(clarified that for you) -
I wonder what old notebook I'll have laying around in a couple of years and if it'll have AES-NI. A colleague gave me an old 64 bit Dell notebook last year that may see pfSense 2.4 when the time comes. In the meantime just been using it as a dual boot x86 Android Silicon Dust media center test/POC machine. Not sure of the proc it has but it has Windows Vista sticker on it.
:-\ -
A bit more on AES-NI https://www.netgate.com/blog/more-on-aes-ni.html
So, does "cloud management platform" refer to a public cloud only system or can we install a private cloud instance on-premise?
I believe there are quite a few companies that will not trust any cloud service when it comes to firewall management.
To be honest, as a paranoid German ( :) ) I would not use or recommend a public cloud firewall management system, even for my home devices. -
I would not use or recommend a public cloud firewall management system, even for my home devices.
+1
As a matter of security policy many businesses won't either. Show stopper for those who know better.
-
A bit more on AES-NI https://www.netgate.com/blog/more-on-aes-ni.html
And another question:
"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?
-
So, does "cloud management platform" refer to a public cloud only system or can we install a private cloud instance on-premise?
"The webGUI will be present either on our cloud service or on-device, both talking to the ‘back-end’ on the device…
You answered yourself, the on-premise version is on-device.
If it can be used to control multiple local installations we'll see when it's available. Too much can change until then to make an educated guess today. -
This is a fairly annoying news, since I deployed several pfSense routers on HP MicroServer Gen8 hardware in the last few months, which are based on Celeron G1610T, which does not support AES-NI.
-
I don't think that makes any more sense. Changing the interface isn't a good reason to drop devices without AES-NI.
It's not because they're changing the interface, it's because of how they want to implement their cloud service. It's up to you to decide how well your priorities converge with that.
I'm just considering to get a QOTOM-Q355G4 Core i5 unit , to get starting w. pfSense.
Now i'm a bit worried … Will the new GUI require some kind of access to a "cloud" ?
Did i misunderstand something ??There's no way i'll ever let some external connection (Cloud or other) to be a requirement for running my firewall.
It has to run 100% normal wo. any connections to the internet.Else i just have to continue with my Linux Firewall Builder project , or get a
PIX-506ASA-5506.I dropped the FW-Builder due to pfSense having a nice solution for "It ALL" , FW , IDS ,DHCP etc.
But not for a "Cloud Service" or requirement.REST API's could be cool as SDN will be the future.
Thanx for any info
/Bingo
-
Now i'm a bit worried … Will the new GUI require some kind of access to a "cloud" ?
Did i misunderstand something ??There's no way i'll ever let some external connection (Cloud or other) to be a requirement for running my firewall.
It has to run 100% normal wo. any connections to the internet.From the blog post:
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.
So no, you shouldn't need need to use the cloud management option. You can instead use the webGUI hosted on the pfSense box itself, just like you do now.
-
We are giving everyone a heads up for almost two years in advance, they will require a CPU from 2011 or newer. When pfSense 2.5 is released, pfSense 2.4 will be supported for another year or so.
To be fair, not all chips released in/after 2011 included AES-NI. The low-power Celerons come to mind.
And some ATOM processors… :-\
Sales Order Date: 1/11/2015 11:46:56 AM
JetWay JNF9B-2700 Intel Atom D2700 2.13GHz Intel N -
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.
