PfSense 2.5 will only work with AES-NI capable CPUs
-
Back in 2006 when i first used FreeNas (Opensource software based on FreeBSD to turn a old pc in to a NAS, a fork of mOnOwall),
it worked on the oldest hardware you could think of, like Pentium II or III and even on Thin Clients.
Arround 5 years later, the software became so "heavy" that the minimum requirements where :
Multicore 64Bit cpu,
8Gb minimum bootdrive
8Gb RAM !!!
When i first read the article about pfSense 2.5 and only work with AES-NI capable cpu's, i get a "deja vu".
What started out as a lightweight software is now turning to become a bulldozer which demands
for faster and faster (and newer) hardware.
So am i the only one that think it's like "it's all about the benjamins" ?Grtz
DeLoreanAES-NI is not exclusive to Netgate hardware. AES-NI has been around for many years, it's not considered as a "heavy" requirement. It may be about the benjamins, but not on our end.
-
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 NWho cares when you bought. Intel released that CPU 6 years ago.
http://ark.intel.com/products/59683/Intel-Atom-Processor-D2700-1M-Cache-2_13-GHz
Research your hardware before you buy it…
-
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 NWho cares when you bought. Intel released that CPU 6 years ago.
http://ark.intel.com/products/59683/Intel-Atom-Processor-D2700-1M-Cache-2_13-GHz
Research your hardware before you buy it…
Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
And, I'll note you don't need to go back to 2011 to find new Intel processors released without AES-NI. DAVe3283 provided a nice link to a list of current CPUs without AES-NI:
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. -
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 NWho cares when you bought. Intel released that CPU 6 years ago.
http://ark.intel.com/products/59683/Intel-Atom-Processor-D2700-1M-Cache-2_13-GHz
Research your hardware before you buy it…
Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
And, I'll note you don't need to go back to 2011 to find new Intel processors released without AES-NI. DAVe3283 provided a nice link to a list of current CPUs without AES-NI:
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.For anyone actually purchasing hardware and not just repurposing old hardware, I would hope the desire to have a remotely future proof purchase would've prompted someone to care about AES-NI. VPN, especially in the US, is becoming much more commonly needed and so are faster internet connections. At this point it's not possible to have any sort of efficient encryption capability without it. Sure, you can get functional encryption without it right now, but not efficient. Again, if you're spending money, even last week before this announcement, it's something that should be considered, period.
EDIT: and that list of CPUs is terrible. I think we can safely exclude atom's meant for cell phones and Xeon Phi's from contention for possible PFSense duty…
EDIT2: the only way to make that CPU list not terrible, is to at least add Intel64 (x86-64) to the filter, as it's another relevant feature that might be worthwhile to have for future proof purchases in 2017.... add that little gem to the filter and they've literally only released 1 CPU since q2 2015 (basically the last 2 years) without AES-NI. And if you look at quad cores, it's only 1 CPU released without since Q3 2014...
Quit whining about your terrible purchase...
-
Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
We talked about the importance of having AES-NI for a lot longer than that. You can find many "will this work" threads on our forums and /r/PFSENSE where others point out AES-NI importance as well.
And, I'll note you don't need to go back to 2011 to find new Intel processors released without AES-NI. DAVe3283 provided a nice link to a list of current CPUs without AES-NI:
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.We are aware not all CPU's from 2011 onwards have AES-NI, that's why the heads-up is over a year in advance.
-
We talked about the importance of having AES-NI for a lot longer than that. You can find many "will this work" threads on our forums and /r/PFSENSE where others point out AES-NI importance as well.
While I believe you, this announcement was the first time I ever saw the importance of AES-NI referenced outside of VPN. Heck, I'm even having trouble searching for examples where it came up on reddit (again, outside of VPN). I'm sure examples exist, but I don't think it was very common.
We are aware not all CPU's from 2011 onwards have AES-NI, that's why the heads-up is over a year in advance.
For systems that don't get refreshed very often, but are rather important to patch for security updates, one year doesn't seem all that long. While 2.4 will presumably be supported for one year, I imagine packages may see the end of support before then. And even if that doesn't happen, two years doesn't seem all that long, either.
And, as you know, you're literally going to have to go out of your way to prevent systems that don't support AES-NI from working. You're using OpenSSL, which automatically falls back to the fabled bit-sliced AES implementation. Presumably you're going to have to add a check on boot to prevent pfSense from starting on non-AES-NI systems.
While it sounds well-intentioned, it seems pretty unnecessary. Users of Netgate hardware will use AES-NI regardless. Home users of the Community Edition might end up using software crypto, but those users are unlikely to use the cloud management functionality, which is, as far as I can tell, the only place where could plausibly be a problem. And even in those cases, those users would fall back to a bit-sliced AES implementation if they have a CPU that supports SSE3. And that's to say nothing of the difficult attack models necessary for cache timing attacks.
-
We talked about the importance of having AES-NI for a lot longer than that. You can find many "will this work" threads on our forums and /r/PFSENSE where others point out AES-NI importance as well.
While I believe you, this announcement was the first time I ever saw the importance of AES-NI referenced outside of VPN. Heck, I'm even having trouble searching for examples where it came up on reddit (again, outside of VPN). I'm sure examples exist, but I don't think it was very common.
We are aware not all CPU's from 2011 onwards have AES-NI, that's why the heads-up is over a year in advance.
For systems that don't get refreshed very often, but are rather important to patch for security updates, one year doesn't seem all that long. While 2.4 will presumably be supported for one year, I imagine packages may see the end of support before then. And even if that doesn't happen, two years doesn't seem all that long, either.
And, as you know, you're literally going to have to go out of your way to prevent systems that don't support AES-NI from working. You're using OpenSSL, which automatically falls back to the fabled bit-sliced AES implementation. Presumably you're going to have to add a check on boot to prevent pfSense from starting on non-AES-NI systems.
While it sounds well-intentioned, it seems pretty unnecessary. Users of Netgate hardware will use AES-NI regardless. Home users of the Community Edition might end up using software crypto, but those users are unlikely to use the cloud management functionality, which is, as far as I can tell, the only place where could plausibly be a problem. And even in those cases, those users would fall back to a bit-sliced AES implementation if they have a CPU that supports SSE3. And that's to say nothing of the difficult attack models necessary for cache timing attacks.
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
-
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
-
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
I don't see how that question is relevant for this topic as well as to what I just told you. Let's not go into off-topic, please.
-
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
I don't see how that question is relevant for this topic as well as to what I just told you. Let's not go into off-topic, please.
It's absolutely relevant to whether one-year notice is sufficient. You're taking about a change that will go out of its way to break compatibility with systems that are only a few years old.
-
Dude just buy a new cpu in a couple years. You aren't going to change anyone's mind throwing a fit on the internet.
-
For systems that don't get refreshed very often, but are rather important to patch for security updates, one year doesn't seem all that long.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
"rather important" or SMB/SOHO/home - make up your mind. ;)
In a "rather important" install I don't care about a few hundred [currency], really. And I wouldn't buy stuff today that does not support the latest and greatest shit, including AES-NI. And I'd swap-out hardware every two years so I'm always covered with warranty (plus support contracts).
For SMB/SOHO/home it is totally sufficient to run 2.4.xyz until hardware dies or use-pattern changes. I can live without AES-NI or a possible downtime due to hardware failures there.
-
For anyone actually purchasing hardware and not just repurposing old hardware, I would hope the desire to have a remotely future proof purchase would've prompted someone to care about AES-NI. VPN, especially in the US, is becoming much more commonly needed and so are faster internet connections. At this point it's not possible to have any sort of efficient encryption capability without it. Sure, you can get functional encryption without it right now, but not efficient. Again, if you're spending money, even last week before this announcement, it's something that should be considered, period.
EDIT: and that list of CPUs is terrible. I think we can safely exclude atom's meant for cell phones and Xeon Phi's from contention for possible PFSense duty…
EDIT2: the only way to make that CPU list not terrible, is to at least add Intel64 (x86-64) to the filter, as it's another relevant feature that might be worthwhile to have for future proof purchases in 2017.... add that little gem to the filter and they've literally only released 1 CPU since q2 2015 (basically the last 2 years) without AES-NI. And if you look at quad cores, it's only 1 CPU released without since Q3 2014...
Quit whining about your terrible purchase...
The point of the list was to show that Intel is actively selling and supporting a number of processors that don't have AES-NI. Even if Intel hasn't designed a new CPU since Q1 2016 without AES-NI, they are still selling & supporting a bunch.
And excluding Atoms is deliberately missing the point. Many people have / buy small NAS boxes or fanless systems that have an Atom, and if you don't use a VPN, the lack of AES-NI isn't going to be a performance penalty. The Atom will cover the needs of a lot of home users, unless you are lucky enough to be getting Gigabit Internet in your area in the next couple years. Were we all so lucky!
In my case, there are 2 things that bother me:
-
I just bought several embedded fanless systems without AES-NI (all with currently supported Intel Celeron processors). Sucks to be me, I'll have to shell out $600 or so to replace them in another couple years even if they are working perfect.
-
The reason they need to be replaced is purely arbitrary. And simply not updating pfSense after they drop 2.4 support is a FAR worse security risk than using software AES… and it will only need AES if you use their cloud management or a VPN!
-
-
Hi!
I don't mind having to update my hardware once in a while if I want to have the latest, greatest version and maintained version.
My current hardware does support AES-NI though but my backup one (in case there is a problem) won't. Unless by the time 2.5 is out I have replaced it, I will be running on it the latest version which supported a CPU without AES-NI…
(Keep in mind that this is my backup machine, which will only be activated if the main one has problem and be deactivated once they are fixed...)
(…)
"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.
It's more concerns like this
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.
And this which concern me…
I am absolutely not interested in having this manageable from the cloud, this is absolutely the last thing I would like to be manageable from the cloud… We are talking of a device that manages the security of a network, I don't want to make it remotely configurable...
Will it be possible to totally disable remote administration with no possibility of ever activating it but from the firewall itself?
Have a nice day!
Nick
-
Back in 2006 when i first used FreeNas (Opensource software based on FreeBSD to turn a old pc in to a NAS, a fork of mOnOwall),
it worked on the oldest hardware you could think of, like Pentium II or III and even on Thin Clients.
Arround 5 years later, the software became so "heavy" that the minimum requirements where :
Multicore 64Bit cpu,
8Gb minimum bootdrive
8Gb RAM !!!And if you have or own a Microsoft MS Server let us say 2003/2008 and you will install now Server 2012/2016
you will even getting more or less in trouble if no new hardware will be there in usage! But no one is complaining
they all buy new Hardware for their servers.When i first read the article about pfSense 2.5 and only work with AES-NI capable cpu's, i get a "deja vu".
This is perhaps owed to the circumstance that there will be even one or more angle points where things are changing
and often to a higher stage where stronger hardware will be a need and "must be" and not only a "can be" option.Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
Then please read the second blog post about AES-NI and its need, it is not pointed to building VPNs only.
Perhaps it might be also not even and everywhere a need for software development or code writing, but
if a developer was deciding to use something that uses AES-NI it will be not or only be used for building VPNs
then, then it must be a AES-NI capable CPU inside.What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
That is not really précises asked for! If you are talking about pure routers that are not firewalls, plastic devices
from AVM, TP-Link, ASUS or Buffalo you might be happy with ~$200 - ~$300 hardware for each Internet connection
speed available. They are cheap and ASIC/FPGA based and tuned working. But pfSense is a software based x_86
firewall that will perhaps also for nearly $200 available, but with installing many packets until pfSense is a rich featured
and fully featured UTM device for VLANs, QoS, HTTP-Proxy, AV Scan and IDS for 1 GBit/s at the WAN and the most able
to get throughput for VPN must be there, you will failing with $200 that's it. But is you spend more money let us say
around $500 - $1000 you will be perhaps able to let it run many years like 5 - 7 years, have a look at the APU2C4
if you need it for a 100/20 Internet account and connection speed it will be for nearly ~$250 with mSATA and WiFi
a all-in-one box for many years.For anyone actually purchasing hardware and not just repurposing old hardware, I would hope the desire to have a remotely future proof purchase would've prompted someone to care about AES-NI. VPN, especially in the US, is becoming much more commonly needed and so are faster internet connections. At this point it's not possible to have any sort of efficient encryption capability without it. Sure, you can get functional encryption without it right now, but not efficient. Again, if you're spending money, even last week before this announcement, it's something that should be considered, period.
And if Windows 10 is needing new hardware I will be able to be angry about, because I pay for it, by using OpenSource
software where I don´t spend money or pay for it I could only ask for something but not really complaining about it. -
@BlueKobold:
Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
Then please read the second blog post about AES-NI and its need, it is not pointed to building VPNs only.
Perhaps it might be also not even and everywhere a need for software development or code writing, but
if a developer was deciding to use something that uses AES-NI it will be not or only be used for building VPNs
then, then it must be a AES-NI capable CPU inside.I couldn't follow the second sentence there. Can you rephrase?
As for the first sentence, if you look at my post, I did preface my statement with "until last week." I looked back at references to AES-NI on on this forum and on reddit, and I didn't see any posts highlighting a need for AES-NI except when referring to VPN performance (save for one odd post talking about webGUI performance, which doesn't make a ton of sense).
Also, before all this came up, I was well aware of the cache timing vulnerabilities in some AES implementations. But as has been discussed in this thread, the library pfSense uses, OpenSSL, already has a software implementation that is resistant to such attacks. It's not entirely clear that the pfSense devs realize that. They pointed to a class project report that suggested that it does not, but they may have missed the statement about compiling OpenSSL without SSE3 support (which disables the more secure and efficient AES implementation).
@BlueKobold:
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
That is not really précises asked for! If you are talking about pure routers that are not firewalls, plastic devices
from AVM, TP-Link, ASUS or Buffalo you might be happy with ~$200 - ~$300 hardware for each Internet connection
speed available. They are cheap and ASIC/FPGA based and tuned working. But pfSense is a software based x_86
firewall that will perhaps also for nearly $200 available, but with installing many packets until pfSense is a rich featured
and fully featured UTM device for VLANs, QoS, HTTP-Proxy, AV Scan and IDS for 1 GBit/s at the WAN and the most able
to get throughput for VPN must be there, you will failing with $200 that's it. But is you spend more money let us say
around $500 - $1000 you will be perhaps able to let it run many years like 5 - 7 years, have a look at the APU2C4
if you need it for a 100/20 Internet account and connection speed it will be for nearly ~$250 with mSATA and WiFi
a all-in-one box for many years.In context, it should have been clear that I was asking what someone should expect is a reasonable hardware refresh cycle for a router running pfSense. It sounds like you agree that someone would reasonably expect to use the same hardware for "many years," perhaps as many as 5-7 years. Given that, one-year notice of a fairly arbitrary new hardware requirement, simply to maintain existing functionality with updated builds, seems rather short.
As for the rest of that paragraph, I'm not entirely sure what you meant.
-
Will this "‘back-end’ (written in ‘C’)" be open source?
@ivor: would be nice if you or someone from netgate had an answer.
-
And this which concern me…
I am absolutely not interested in having this manageable from the cloud, this is absolutely the last thing I would like to be manageable from the cloud… We are talking of a device that manages the security of a network, I don't want to make it remotely configurable...
Will it be possible to totally disable remote administration with no possibility of ever activating it but from the firewall itself?
Have a nice day!
Nick
+1
-
I find this thread very interesting. Can someone explain me why doesn't pfsense doesn't make AES-NI optional and load the AES-NI module dynamically when the box starts up. (See Reference below)
Can someone send a link where I can read why making AES-NI mandatory is the best outcome. Obviously there must be a rationale behind it.
Reference:
https://manuth.life/enable-aes-ni-freebsd/ -
It sounds like you agree that someone would reasonably expect to use the same hardware for "many years,"
Yes that should be a fine thing for many of us, or? I personally prefer to use one build (hardware) for many years, over
going all two years buying new hardware. pfSense is my firewall and not my hobby!perhaps as many as 5-7 years.
In former days it was said likes "You get what you pay for!" but as today many peoples will change all things in
the same order like they change their smartphone, but not me! I prefer to get and pays for one machine more
money and use it then as long as I am able to do! If Supermicro starts their production in 2017 of the third range
of Xeon D-1500 mainboards, that is supporting then AES-NI, QAT and SPDK & DPDK I would fairly wait until the end
of 2017 or the beginning of 2018 to buy new hardware, but then this rig must be running for 5 - 7 years for sure.Other may love it more to spend $200 for each appliance but they are buying then all 2 years new hardware.
To support the project I would go more to buy a small device such SG-1000 or one of the next ones such the R1
to play with or to try out things at first.Given that, one-year notice of a fairly arbitrary new hardware requirement, simply to maintain existing functionality with updated builds, seems rather short.
For sure if one thing is changing it can be nasty, but if many things are turning around or a bigger change is their
then the most peoples would not believe it or trust it, or plain the are disagree with that, but I am fairly believing
and pretty sure about, that the pfSense developers are not doing something to harm us or bother with us.
Version 2.2.6 - version 2.3 - version 2.3 - version 2.4 and from 2.4 to 2.5 even and even more new things
will be floating in that project and version 3.0 is perhaps fully new written and more smooth and liquid acting
then the software now, why should I am angry about that? Actual my pfSense firewall is fulfilling all conditions
from that software and I am really lucky about that.I find this thread very interesting. Can someone explain me why doesn't pfsense doesn't make AES-NI optional and load the AES-NI module dynamically when the box starts up. (See Reference below)
I think this could be easily done. As I have understood that both blog posts from Netgate AES-NI can be used for encryption
but it can be also used by the code to do other things. And there were three different methods able to use for the
developers and their were choosing the one how works together with AES-NI and that not only for the VPN encryption part.Reference:
https://manuth.life/enable-aes-ni-freebsd/Nice, but only for FreeBSD, that is fairly said, the so called basis underlying of pfSense, but nothing more.
And as today I think the fully new written pfSense system will be very hard edited from of the original
FreeBSD OS based on all changed things and code.Can someone send a link where I can read why making AES-NI mandatory is the best outcome. Obviously there must be a rationale behind it.
There are two blog posts with statements from Netgate about it as I am right informed.
pfSense 2.5 and AES-NI
More on AES-NIAs for the first sentence, if you look at my post, I did preface my statement with "until last week." I looked back at references to AES-NI on on this forum and on reddit, and I didn't see any posts highlighting a need for AES-NI except when referring to VPN performance (save for one odd post talking about webGUI performance, which doesn't make a ton of sense).
I think, and this is only my opinion nothing else, that there was a problem with many something +500 VLANs and the status
page renew interval that was "eating" the whole CPU performance until the box freezes totally and now they (the developers)
are changing this by writing a new frontend & backend by using C and phyton. And this frontend will be able to manage from
a cloud account (many pfSense installations) but also able to connect from the CLI or local WebGui.And now the second part!
AES-NI will not be only used anymore for VPN encryption alone, but also used more from another piece of software
or code that will be based on one of three available methods. And the developers were choosing the one, that is using
AES-NI instruction set of the CPU too, but for other things or to secure the entire system more then using it for VPN alone.
