PfSense 2.5 will only work with AES-NI capable CPUs
-
A bit more on AES-NI https://www.netgate.com/blog/more-on-aes-ni.html
I don't think that makes any more sense. Changing the interface isn't a good reason to drop devices without AES-NI.
I'm definitely not happy, as I just bought a nice box 6 months ago without AES-NI support that works great. I was hoping to get a second for HA, and then have these for 4ish years. That's not going to happen now.
If this was coming in 3.0 which would be 3-4 years out, I'd understand. But not a year out. I was planning to buy pfSense Gold, but not now.
-
I was planning to buy pfSense Gold, but not now.
Is that supposed to make us feel bad? You are using our product for free. You don't have to use it. I understand you are not happy but don't be disrespectful, please.
-
I was hoping to get a second for HA, and then have these for 4ish years.
If your goal is to have an HA cluster then go for it now.
If your goal is to mainly fiddle with a piece of software then maybe not.You don't have to update a system once a new version is available, you know. "High availability" systems don't need to run the latest release, they need to perform without interruption. No doubt, you can have that with the current release already. For free.
-
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 also fascinated that other algorithms are completely unacceptable because reasons. Clearly the pfsense cloud needs more security than google's or amazon's.
-
… how they want to implement their cloud service ...
That's only a part of it.
Basically the whole SDN is moving to RFC defined APIs and pfSense is moving along. If I understood it correctly, that is. -
… how they want to implement their cloud service ...
That's only a part of it.
Basically the whole SDN is moving to RFC defined APIs and pfSense is moving along. If I understood it correctly, that is.I'm sure that is also tremendously important to home users with standalone firewalls.
-
… how they want to implement their cloud service ...
That's only a part of it.
Basically the whole SDN is moving to RFC defined APIs and pfSense is moving along. If I understood it correctly, that is.I'm sure that is also tremendously important to home users with standalone firewalls.
well there's already a tremendous amount of less-than router products on the market. What exactly got you to use pfsense in the first place? Was it because it was generic like all the other solutions or because it has a modular package system with bells and whistles out the yin yang?
-
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.
