PfSense 2.5 will only work with AES-NI capable CPUs
-
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. -
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.
That's (roughly) what pfSense does today. pfSense uses OpenSSL as its underlying crypto library. OpenSSL will use AES-NI when its available, but it falls back on a side-channel-resistant version when SSE3 is available (which is almost everywhere).
So, why do the pfSense devs want to require AES-NI? It's not completely clear, but their blog posts described their worry over cache timing attacks on an upcoming remote management interface that will be in future versions of pfSense. Cache timing attacks are sophisticated attacks that attempt to steal secret AES keys by looking at the time it take a target system to perform encryption operations. It suffices to say that AES operations performed in hardware- as is the case with AES-NI- should not be vulnerable to such attacks. But software implementations may be.
That should sound bad- and it is- but its important to remember a few things: 1) cache timing attacks are extremely difficult to mount in practice, due to the what the attacker needs to be able to observe, 2) OpenSSL already includes an implementation resistant to these attacks, and 3) there's no issue at all if don't use Netgate's upcoming cloud management solution.
@BlueKobold:
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.No, AES-NI will be used for encryption. It's not useful for anything other than performing AES round functions. The blog posts indicated that the pfSense devs plan to use AES to encrypt the management interface between the webGUI and the pfSense device itself. Note that the webGUI itself will be running on the pfSense device itself if you do not use Netgate's upcoming cloud management solution. Encryption probably isn't necessary in the case of local management, since the traffic is staying fully inside the pfSense router itself, but they seem to be doing it primarily for standards compliance.
@BlueKobold:
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.Because OpenSSL already includes software AES implementations, the pfSense devs will have to go out of their way to prevent systems that do not support AES-NI from being used with pfSense 2.5. The easiest and simplest path would simply be to continue doing what they do today: use AES-NI when its available, and allow OpenSSL to fallback to software when it's not.
-
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.
