PfSense 2.5 will only work with AES-NI capable CPUs
-
Funny english language. I wrote:
I bet all your shoeboxes that can't do AES-NI will be obsolete anyway by that time.
I meant that hardware that doesn't have an AES-NI capable CPU by the time 2.5 is released is likely to be obsolete at the time.
-
@kpa:
Funny english language. I wrote:
I bet all your shoeboxes that can't do AES-NI will be obsolete anyway by that time.
I meant that hardware that doesn't have an AES-NI capable CPU by the time 2.5 is released is likely to be obsolete at the time.
Oh yes, sorry. I will edit that part ;)
-
So when AES-NI is found to be a defective all users will be affected, instead of a subset of users.
Look at Intel ME experience for example. Is that what were going for? All racked servers affected.
Homogeneity is bad for security.
-
So when AES-NI is found to be a defective all users will be affected, instead of a subset of users.
Look at Intel ME experience for example. Is that what were going for? All racked servers affected.
Homogeneity is bad for security.
https://en.wikipedia.org/wiki/AES_instruction_set
-
After all I had read, OPNsense is not really an alternative if you want honest software developed by trustworthy people,
I think you need to chill. You're welcome to use any kind of software you want, but don't claim we are dishonest or not trustworthy.
There's a "not" in my sentence, and I stand by it. So yes, I do think pfSense is better than it's fork (at least as of <2.5).
On another note though, proclaiming 2 year old hardware obsolete in 1 years time - not my cup of tea. I have servers here that are more than 5 years old and there is no need to replace them. I don't see any reason to replace our APUs which are running our AES256 OpenVPN traffic just fine without hardware acceleration at less than 10% load only because suddenly AES-NI becomes a requirement.
Stefan
-
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!
-
@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. Is it not common knowledge that most hardware is designed with planned obsolescence? This isn't a slap in the face to anyone IMO.
-
After all I had read, OPNsense is not really an alternative if you want honest software developed by trustworthy people,
I think you need to chill. You're welcome to use any kind of software you want, but don't claim we are dishonest or not trustworthy.
There's a "not" in my sentence, and I stand by it. So yes, I do think pfSense is better than it's fork (at least as of <2.5).
On another note though, proclaiming 2 year old hardware obsolete in 1 years time - not my cup of tea. I have servers here that are more than 5 years old and there is no need to replace them. I don't see any reason to replace our APUs which are running our AES256 OpenVPN traffic just fine without hardware acceleration at less than 10% load only because suddenly AES-NI becomes a requirement.
Stefan
Now I feel stupid. I am sorry as I have misread your initial comment. I have fixed it. Please note that we will be supporting pfSense 2.4 for around a year once 2.5 is out. 2.5 won't be out for over a year (really depends from FreeBSD 12 release date).
-
Come on, just because a new version is out sometime in the future it doesn't mean the version you currently run (or that will be released in the foreseeable future, aka 2.3.4) is rendered useless.
Same with 32bit hardware and v2.4 in the future. Just keep using 2.3.x on that.The goal of each and every pfSense installation I have out there is to do its job. And it does exactly that, otherwise I would have chosen a different solution. That won't change with a new release.
My job is not to update all systems just because a new version is available. Is yours?Only if you want to run the latest version with all new bells and whistles you'll need moderatly new hardware for that. So what?
This discussion reminds me of a crying kid whom you've taken away the favorite toy. With the exception that it is only an announcement due in 12+ months to get you prepared (with a new toy).
So you're mourning a year or so in advance. Really? -
I have pfSense running in SOHO environment using ATOM (Cedarview), with VPN, and no resource constraints
whatsoeverunder light to moderate load. I've recommended the platform to others who've used it for ICS, and through AWS. I won't be able to, in good conscience, recommend the product with these restrictions. I won't be upgrading my hardware. I find AES-NI requirement more of a security weakness than enhancement, and will likely begin going with plain old *BSD.Bullrun aside, a 7 year old critical remote exploit was just disclosed in Intel's AMT. The CVE was published today: https://nvd.nist.gov/vuln/detail/CVE-2017-5689
You guys chose a hell of a week to announce a baked in Intel requirement!
-
Some additional info:
https://www.reddit.com/r/PFSENSE/comments/68nd6y/pfsense_25_and_aesni/dh0qi53/ -
Now I feel stupid. I am sorry as I have misread your initial comment. I have fixed it. Please note that we will be supporting pfSense 2.4 for around a year once 2.5 is out. 2.5 won't be out for over a year (really depends from FreeBSD 12 release date).
Actually, if this ~2 year timeline on 2.4 viability is even close, this announcement should be very well taken by everyone. 24 months is a professional notice time period.
Maybe some could use to think about this for a moment before jumping in and venting in a negative manner.
-
Wow, that (full) reddit post kind of threw me of my chair ::)
Amazed by the anger/frustration. If they put equal effort in coding as they do in trying to clarifying their motivations, hats off…
Interesting read of Gonzo's post though, that's probably the best part (for me) as I learned new things.So I just got an actual legit reason to go looking for a new home router in the near future -> life is good ;D
-
@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.
-
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
-
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 ?
-
@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.