PfSense 2.5 will only work with AES-NI capable CPUs
-
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!
See, here's the problem. You're complaining about a purchase of bare hardware from a separate 3rd party on which you intend to run free software. That hardware was not sold for any particular purpose and does not have any kind of warranty guaranteeing to support future versions of anything. When you make purchases like that, it's on you to accept any and all repercussions of the free software you run on it. AND you're complaining about a change to free software that's most likely 2 years down the road. If you want on-going support you need to purchase task specific hardware/appliances. Buy PFSense hardware directly from Netgate if that's what you're looking for. That's just how the world works.
Don't get me wrong, I can understand your plight. You probably didn't buy those systems for yourself and you probably have to explain to someone, a customer or a boss, that they now have an expiration date you didn't anticipate. But again, that's on you because there are fanless embedded systems with AES-NI and you chose to purchase ones without it.
To everyone whining about this here, stop complaining about your mistakes here. The appropriate way to handle this is to put in a feature request for 2.5 to support non-AES-NI systems (possibly getting the SSE3 OpenSSL build included) and maybe the devs will consider it. They sure as heck aren't going wade through a few whiny forum posts and decide to change direction because of them.
-
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything. A roadmap helps me in understanding where the focus is, and where/when "major" architectural changes like this will be taking place. It also helps me in determining when a project/product is taking a direction is a direction that is focused on solutions that don't benefit me or help me solve the issues I'm trying to solve.
Two years ago (2015), I was reading posts focused around high throughput leveraging Intel QuickAssist (there was also mention that it may not be delivered in the Community edition, but only the commercial edition). 2.4 announce (a welcome in my opinion) change is underlying filesystem, but it also announced a focus with ARM based systems. Now, with 2.5 I am hearing a move to cloud management with a requirement for AES-NI offload.
I'm having a hard time understanding where the project direction is now: High-end high-throughput systems that would compete with CISCO/Checkpoint/Palo Alto? Centrally managed - again competing with higher end commercial offerings? Doesn't fit within my needs, but ok, I see many others demonstrating a desire for it in the forums (fastest residential Internet offeriing in my area is 500/50).
But ARM? Is the project now wanting to compete with lower end offering like Netgear/Asus/TP-Link/D-Link routers and Ubiquity EdgeRouters?
I'm really confused where PFSense's focus/direction is now. I could be wrong, but I didn't think there was enough development resources to support this many major initiatives.
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything.
While I get it's a blog post, but I think notice about a change to a version 2 major point versions and probably 2 years away is about as good as a roadmap as you can expect.
I'm having a hard time understanding where the project direction is now
(…)
But ARM? Is the project now wanting to compete with lower end offering like Netgear/Asus/TP-Link/D-Link routers and Ubiquity EdgeRouters?
I think they've been molding PFSense in an Enterprise direction for quite a while. Cloud (internal and 3rd party) is very much being embraced in the Enterprise. And ARM is making in roads into the Enterprise/datacenter space as well. ARM has been around in network devices for a while as well as storage devices. Full blown servers based on ARM are becoming a thing too and they already have the encryption offload capabilities built into very efficient hardware. It's not a surprise to see the underlying BSD OS supporting ARM and hence giving PFSense the ability support ARM. It doesn't necessarily equate to trying to compete with the consumer, lower end offering like Netgear/Asus/TP-Link/D-Link routers. Also, I wouldn't put Ubiquity EdgeRouters in the same boat as those consumer offerings, they're definitely Enterprise gear. Maybe the low end of Enterprise, but definitely not consumer oriented.
-
In the sense of fairness I have to report something interesting.
I had planned to test out some alternate software with an old laptop and a usb lan port. One that I had selected had issues with creating the usb installer.
Then I decided to see if the laptop supported AES-NI (amd a6-1450) Yes. The laptop is underpowered and was in a closet, too good to toss out but not good enough for much of anything.
I have a pair usb lan adapters. Just for grins I plugged one in a usb2 port and another in a usb3, attacted the WAN to the usb2 port adapter and LAN to the usb3 port adapter. Then I put pfSense on the usb installer and fired it up. After a few issues with the initial keyboard / screen defaults it fired right up. I'm using it as my home router at this moment.
It's not going to be my home router for long, but it's interesting that it worked at all.
Going to keep an open mind about these changes.
-
You can also use laptops/single NIC computers paired with a VLAN capable switch by putting WAN and LAN on VLANs.
-
I am trying to be impartial….but I think users shouldn't be complaining too much especially when it's free software that can run on many boxes.... If you buy Netgate, they have AES-NI. Don't get me wrong, I do feel for the non AES-NI users. The pfsense team can change direction, can change their mind and will implement what they believe is the best for the long term, perhaps they might get it wrong, perhaps they might get it right.... who knows what is the real trend in the next 5 years....
After quickly reading the links, sometime in the future (e.g. version3) pfsense might want to host the WebGUI on the cloud. In order to communicate between the WebGUI on the cloud and the pfsense box, the pfsense box needs to implement RESTCONF (RFC 8040) which is basically a REST API via HTTP which needs to be compliant with transport layer RFC 7525 which works with either 128bit or 256bit flavor of AES GCM. (See Reference for RFC, cool stuff)
At a quick glance (quickly googling), AES-NI (especially 128bit) seems to perform extremely well for AES GCM with the exception of small cpu like the Atom ( See Reference below) Using AES-NI will mitigate the risk of cache timing attack....
I don't know how the cache timing attack works and I won't be reading it, I've written and read enough exploits in my early days...
The point is that if pfsense believes it can be exposed to an attack, it wants to protect itself and pfsense believes to solve the problem by making AES-NI mandatory on the box running RESTCONF. Makes pfsense ?The question I would ask myself is assuming pfsense support a non-cloud based WebGUI, does the cache timing attack still applies ? Anybody that understand the cache timing attack can elaborate....
If yes, then it makes somewhat pfsense to make AES-NI mandatory…
If no, then pfsense could allow RESTCONF to run on a box without AES-NI ? possible ?I do feel for the users that don't have AES-NI and always wanting to stretch hardware to its maximum potential… perhaps users should just ask if pfsense to add a flag to support non AES-NI ( SSE3 OpenSSL) and accept button or red warning on GUI at the bottom saying you are exposed to a cache timing attack.
Anyways.... life is too short...
Reference:
AES-NI seems to be kicking ass when machines needs to perform AES-GCM-128 and AES-GCM-256
https://calomel.org/aesni_ssl_performance.htmlRFC 8040
https://tools.ietf.org/html/rfc8040#page-15
RFC 7525
https://tools.ietf.org/html/rfc7525#page-11 -
I don't know how the cache timing attack works and I won't be reading it, I've written and read enough exploits in my early days…
The point is that if pfsense believes it can be exposed to an attack, it wants to protect itself and pfsense believes to solve the problem by making AES-NI mandatory on the box running RESTCONF. Makes pfsense ?Perhaps, but is it throwing the baby out with the bathwater, given OpenSSL already includes a software AES implementation resistant to cache timing attacks?
The question I would ask myself is assuming pfsense support a non-cloud based WebGUI, does the cache timing attack still applies ? Anybody that understand the cache timing attack can elaborate….
If yes, then it makes somewhat pfsense to make AES-NI mandatory…
If no, then pfsense could allow RESTCONF to run on a box without AES-NI ? possible ?The short answer is no. In the local webGUI case, the RESTCONF interface is entirely contained with the pfSense box. It's just an internal communications path. It will apparently be encrypted, but it's not exposed. Anything in a position to mount a cache timing attack on the pfSense box itself is already in a position to do much worse things.
Cache timing attacks, in theory, allow an attacker to learn a secret AES key after seeing a large number of samples showing fairly precise encryption times on mostly random data. If you get bored, here's a paper describing a possible mostly-passive remote cache timing attack. The specific attacks vary, but they're usually some form a known-plaintext attack requiring several gigabytes of data to be encrypted with the target key.
In the case of pfSense, the concern appears to be that an attacker may target the AES-GCM session key used within the HTTPS/TLS protocol encrypting the RESTCONF messages. To mount this attack (assuming a vulnerable AES implementation), an attacker would need to somehow get the victim to send a large amount of data over RESTCONF interface. And it can't just by any traffic from the victim- that traffic specifically has to go over the same HTTPS session. And the attacker has to see precise timings for the crypto operations themselves, which is hard to observe remotely when the victim is doing things other than just immediately responding to requests to encrypt data.
An attacker isn't going to be able to see traffic going over the local communications path. And if it could, it must already be in control of the pfSense box, which means the attacker has already won.
-
Thanks for the clarification ! Btw I won't be reading it, I promised the wife no more 24/7 coding and taking over the world with my army of gazillions of botnets…. I am no longer a Lord.... It's about balanced life...a bit of IT geeky stuff.... cooking.... exercise... go outside take a bit of air.... talk with humans.... :-[
[quote author=reggie14 link=topic=129842.msg717627#msg717627 date=1494354184]
The short answer is no. In the local webGUI case, the RESTCONF interface is entirely contained with the pfSense box. It's just an internal communications path. It will apparently be encrypted, but it's not exposed. Anything in a position to mount a cache timing attack on the pfSense box itself is already in a position to do much worse things.
There is some hope for the non AES-NI community :)
In the case of pfSense, the concern appears to be that an attacker may target the AES-GCM session key used within the HTTPS/TLS protocol encrypting the RESTCONF messages. To mount this attack (assuming a vulnerable AES implementation), an attacker would need to somehow get the victim to send a large amount of data over RESTCONF interface. And it can't just by any traffic from the victim- that traffic specifically has to go over the same HTTPS session. And the attacker has to see precise timings for the crypto operations themselves, which is hard to observe remotely when the victim is doing things other than just immediately responding to requests to encrypt data.
An attacker isn't going to be able to see traffic going over the local communications path. And if it could, it must already be in control of the pfSense box, which means the attacker has already won.
Interesting. I guess pfsense wants to be 100% air tight, even if an attacker is in your network the attacker won't be able to cause damage to pfsense). I guess a script kiddie won't be able to run a "cache timing attack" quickly on rooted box….
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything.
While I get it's a blog post, but I think notice about a change to a version 2 major point versions and probably 2 years away is about as good as a roadmap as you can expect.
No, it's the opposite of a roadmap. They very specifically have no intention of telling people what their plans are.
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything.
While I get it's a blog post, but I think notice about a change to a version 2 major point versions and probably 2 years away is about as good as a roadmap as you can expect.
No, it's the opposite of a roadmap. They very specifically have no intention of telling people what their plans are.
So you don't understand words apparently. They very specifically explained a requirement of a future version of the product and explained how they intend to architect the underlying components of configuration interface in that version. That version being multiple versions and years in the future. I'm not an English major, but I'm pretty sure that's very roadmap-esque. Definitely not the opposite of a roadmap.
-
So you don't understand words apparently.
I'm not an English major, but I'm pretty sure that's very roadmap-esque. Definitely not the opposite of a roadmap.
A bit harsh…go easy, some people have a lot of passion, have certain expectation of pfsense open source and it's roadmap... the expectation doesn't always align with reality 8)
If there enough critical mass (e.g. thousands and thousands of people that really want pfsense without AES-NI or other features that pfsense doesn't want to do ) well there can always be a spin off.... " pfsenseLite based on pfsense but some features tweaked in order to support more hardware and sometimes comprise on security"
Life is short...
-
Interesting. I guess pfsense wants to be 100% air tight, even if an attacker is in your network the attacker won't be able to cause damage to pfsense). I guess a script kiddie won't be able to run a "cache timing attack" quickly on rooted box….
Let's suppose they could. Why would they, though? With root it would be easier to simply read through memory looking for an AES key.
But then again, why even do that? If you already have root, how would getting an AES session key help you in any way? You already control the box at that point.
-
Yeah, if you are rooted in the same box it goes without saying :)
I was thinking more in the lines of an attacker rooting another systems running on the same VM box…
There are also ways without being root to access the cache memory and figure out the "secret keys" (e.g. VM, cross VM, shared hugepage, adjacent process running in same native OS, etc... ) There are countermeasures to reduce the risk (e.g. disabling hugepage sharing, disabling L3 shared cross VM, etc...)As you've stated earlier, OpenSSL has it fixed :)
Reference:
OpenSSL vulnerabilities fixes
https://www.openssl.org/news/vulnerabilities.htmlPage 10, B. The Cross-Core Cross-VM Attack
http://users.wpi.edu/~teisenbarth/pdf/SharedCacheAttackSnP2015.pdfUniversity writing tools to exploit time cache attacks....
https://ts.data61.csiro.au/projects/TS/cachebleed/ -
But ARM? Is the project now wanting to compete with lower end offering like Netgear/Asus/TP-Link/D-Link routers and Ubiquity EdgeRouters?
Many users were asking for it, now they got it!
To everyone whining about this here, stop complaining about your mistakes here. The appropriate way to handle this is to put in a feature request for 2.5 to support non-AES-NI systems (possibly getting the SSE3 OpenSSL build included) and maybe the devs will consider it. They sure as heck aren't going wade through a few whiny forum posts and decide to change direction because of them.
Things often changing fast, but good to know on what they are actual working.
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything. A roadmap helps me in understanding where the focus is, and where/when "major" architectural changes like this will be taking place. It also helps me in determining when a project/product is taking a direction is a direction that is focused on solutions that don't benefit me or help me solve the issues I'm trying to solve.
I see this blog more as a way they want to go and what we can expect from the next version, or what feature or
option will be inside of the next version, and for sure which known issues are there or are solved out. This might
be not the same as the most users will be expect, or something like a 100% right and matching way they are walking.I'm having a hard time understanding where the project direction is now: High-end high-throughput systems that would compete with CISCO/Checkpoint/Palo Alto? Centrally managed - again competing with higher end commercial offerings? Doesn't fit within my needs, but ok, I see many others demonstrating a desire for it in the forums (fastest residential Internet offeriing in my area is 500/50).
The most questions were running in that direction, 1 GBit/s on WAN, turning the firewall in a real UTM, getting
out the maximum of VPN throughput. This is more or less what the most peoples were asking so perhaps it
comes from that side a bit and you may seeing only the Netgate or pfSense developers side, can this perhaps be?Cisco is playing in many more playgrounds and is a NASDAQ notated company so what x_86 hardware can compete
against or plays in the same league likes the Cisco CRS-3 for 470.000 Euros?And PaloAlto is producing NG Firewalls, that are ASIC/FPGA supported and the greater models will starting at
80.000 Euros.Also not the same range where pfSense is actual operating.I'm really confused where PFSense's focus/direction is now. I could be wrong, but I didn't think there was enough development resources to support this many major initiatives.
This might be not alone pending on the pfSense team because FreeBSD is the base of it. And yes, also FreeBSD is
widely used as a Server OS in many companies and in private Networks, Linux and Windows servers are supporting
actual the QAT perhaps it comes from there, can this be?It's not a surprise to see the underlying BSD OS supporting ARM and hence giving PFSense the ability support ARM. It doesn't necessarily equate to trying to compete with the consumer, lower end offering like Netgear/Asus/TP-Link/D-Link routers.
Many users were asking for a cheaper device then the SG-2220 unit and mostly used only for pure firewall tasks.
Also, I wouldn't put Ubiquity EdgeRouters in the same boat as those consumer offerings, they're definitely Enterprise gear. Maybe the low end of Enterprise, but definitely not consumer oriented.
They produce WISP gear from the lower bottom to the higher end for sure, useable for all sections, from the end user
at home to get a good CPE or the WISP that will serve to that clients.No, it's the opposite of a roadmap. They very specifically have no intention of telling people what their plans are.
Dropping some lines what is actual going on might be better then getting nothing to hear until it is out! Other may think
different on this but I would be love to informed from time to time what is actual going on. -
-
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
I am also not interested in having the manageable part of MY firewall in the cloud.
If this ever gets hacked, many users are sitting ducks and are exposed to all kinds of things.
When there is a rollout of a bad update of the manageable part in the cloud, many users are envolved.
And last, what about a closed network like a lab for testing purposes etc…. what doesn't have / require internet access,
that cannot be configured ?
Firewalls managed from the cloud is like driving a shoppingcart by pulling a few ropes on a parking lot,
untill someone cuts the ropes, your shoppingcart rolls down the street and bangs a parked car.Grtz
DeLorean -
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
+1 here as well!
-
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
-
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
No answer is also an answer.
-
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
No answer is also an answer.
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.
