PfSense 2.5 will only work with AES-NI capable CPUs
-
You guys chose a hell of a week to announce a baked in Intel requirement!
The timing was indeed unfortunate! However AES-NI is not exclusive to Intel:
https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture
Steve
That's a good point. Also some good points in the Reddit post.
For most users, hardware, and companies, this requirement will probably go by practically unnoticed. And if Intel's (or AMD's) implementation of AES-NI is flawed, unintentionally or otherwise, it's going to affect more than just pfSense.
Regardless of whether or not I trust the code in Intel's chips, I do have confidence that Netgate is making the decision for good reasons. The advanced notice is appreciated too.
-
@thehammer86:
Push the AES-NI requirement to pfSense 3.0 roadmap.
Lots of people here have re-purposed older hardware which they have under-volted and under-clocked with the plan to dial it up as needs arise..
Dropping 32-bit support recently was understandable but this is ludicrous!
Is it? Or is it ludicrous to be running any internet facing hardware that is 6 years after EOL.
The first one.
Well you could always go back to carrier pigeon, they don't have any of those ludicrous hardware acceleration instruction sets.
-
@thehammer86:
Push the AES-NI requirement to pfSense 3.0 roadmap.
Lots of people here have re-purposed older hardware which they have under-volted and under-clocked with the plan to dial it up as needs arise..
Dropping 32-bit support recently was understandable but this is ludicrous!
Is it? Or is it ludicrous to be running any internet facing hardware that is 6 years after EOL.
The first one.
Well you could always go back to carrier pigeon, they don't have any of those ludicrous hardware acceleration instruction sets.
I see you've gone from the ludicrous to the absurd. The strength of your argument is clear.
-
@thehammer86:
Push the AES-NI requirement to pfSense 3.0 roadmap.
Lots of people here have re-purposed older hardware which they have under-volted and under-clocked with the plan to dial it up as needs arise..
Dropping 32-bit support recently was understandable but this is ludicrous!
Is it? Or is it ludicrous to be running any internet facing hardware that is 6 years after EOL.
The first one.
Well you could always go back to carrier pigeon, they don't have any of those ludicrous hardware acceleration instruction sets.
I see you've gone from the ludicrous to the absurd. The strength of your argument is clear.
We may as well be walking on the Sun, right?
You guys thinking of forking off here at 2.4? Ya'll can call it PFsenseless. ;D
-
YAY !!!!
Excuse for me to buy more kit to "test" :D
Seriously though, 2 years notice? I'll take that.
My wife bought me an APU2C4 for Christmas to run pfSense, I'll start speccing new hardware in 12 - 16 months time, ready for Christmas.
-
Well, feel terribly sorry for you… :)
CPU: AMD Embedded G series GX-412TC, 1 GHz quad Jaguar core with 64 bit and AES-NI
-
YAY !!!!
Excuse for me to buy more kit to "test" :D
Seriously though, 2 years notice? I'll take that.
My wife bought me an APU2C4 for Christmas to run pfSense, I'll start speccing new hardware in 12 - 16 months time, ready for Christmas.
APU2C4 has AES-NI
-
A bit more on AES-NI https://www.netgate.com/blog/more-on-aes-ni.html
-
YAY !!!!
Excuse for me to buy more kit to "test" :D
Seriously though, 2 years notice? I'll take that.
My wife bought me an APU2C4 for Christmas to run pfSense, I'll start speccing new hardware in 12 - 16 months time, ready for Christmas.
APU2C4 has AES-NI
I know - don't tell the wife though ;)
-
Hmmm… This
the new, pure JS GUI (client) architected as a single page web application.
seems much more disturbing than the AES-NI requirement. (Just recovering from a complete JS fiasco experience, only a couple of days old.)
-
JS (on the GUI, not the backend like Ubuquiti attempted via NodeBB) compared to PHP?
I'll take JS, every time.
p.s. false equivalence, dude.
-
Hmmm… This
the new, pure JS GUI (client) architected as a single page web application.
seems much more disturbing than the AES-NI requirement. (Just recovering from a complete JS fiasco experience, only a couple of days old.)
No fear when Dok is part of the testing team!! :P
-
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 ?
