PfSense 2.5 will only work with AES-NI capable CPUs
-
The blog post really focuses on the cache timing attacks.
I have a limited understanding of the subject, but wouldn't that require the attacker to have access to the machine? If they have access, can't you assume that all security has gone out the window anyways?
-
Regarding cache timing attacks, aren't they only a problem for VMs? I do have a few virtualized pfSenses (and those are all on AES-NI-capable hardware), but the majority of mine are on dedicated low-power boxes.
-
ChaCha20 is a marginally-standardized algorithm. It's specified in a purely optional extension to TLS v1.2, and I don't think the algorithm is recognized in any standards outside of IETF. It's a nice algorithm. It doesn't have anything approaching the analysis that's gone into AES, but it's a solid design is almost certainly safe to use. But corporate customers might want to stick to things more broadly accepted.
So those customers can use AES-GCM, right?
And, AES still has a performance advantage over ChaCha20 when using AES-NI.
And ChaCha20 has the advantage in a pure software implementation, and it's still being improved with AVX512 et al.
Anyways, performance doesn't appear to be the motivating factor here. Performance considerations may drive them to use AES-NI on Netgate's cloud systems, but I can't imagine that RESTCONF is so chatty that there would be performance issues on the local pfSense boxes (and if it is, then we have bigger problems).
The blog post really focuses on the cache timing attacks.
And the cache timing attacks are also pretty irrelevant to a purely local instance. Back to square one.
Anyway, the reason I pointed out ChaCha20 in particular is that ChaCha20-Poly1305 is that it's an AEAD mode like AES-GCM. Having more than one option means that in the event of a catastrophic protocol weakness you have the ability to quickly fall back to an alternative. The other options are to continue to provide AES-CBC and/or look forward to AES-CCM.
At any rate, the fundamental argument "RFC 7525 REQUIRES [AES-GCM]" is bogus, the RFC says no such thing. There are good reasons to implement multiple algorithms/modes, and all this handwaving is just confusing.
-
and all this handwaving is just confusing.
Meh, It's Netgate. you get used to it. At least it's still free
-
Some complained that, since they don’t use VPN, they don’t need AES-NI. While I wasn’t quite ready to say more about the “3.0” effort, it is the reason for the new requirement for pfSense 2.5 and beyond.
What should be wrong or unknown with that comment? It only says the same as over the end of NanoBSD and
32Bit system support under or since version 2.4. And since version 2.5 you will need a AES-NI capable CPU and
that not only for the VPN stuff.With AES you either design, test, and verify a bitslice software implementation, (giving up a lot of performance in the process), leverage hardware offloads, or leave the resulting system open to several known attacks. We have selected the “leverage hardware offloads” path. The other two options are either unthinkable, or involve a lot of effort for diminishing returns.
There are three ways to go and they (the developers) were choosing that way that needs AES-NI and nothing more.
There is a paper from NYU, published in 2013 titled, “Cache-timing Attacks on AES”. You can read the paper for background on timing attacks, but I would like to draw attention to two statements in the paper.
Only a point to be clarifying and explaining that point.
We want pfSense software to be safe for everyone.
To be able to offer a safe system or not is perhaps more exiting for a firewall then other stuff.
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.
There will be two options for the webgui;
- via Cloud service
many pfSense installations easier to handle and administer for the admin, perhaps plus settings backup method - local on the device
As it is and for local or less many pfSense installations
Backend is the underlying part of the software (what you don´t see) and the frontend visible and overlaying
part of the software (what you see) can be chosen by us as offered by the cloud services or local as it is now.So the choice is either to design, engineer and release a less-than-strong product, or require AES-NI or other offloads.
Better strong and secure together with using AES-NI!
The entire PHP layer is being eliminated in the “3.0” effort, and we’re simply too small to continue to maintain both the current, organically-grown PHP layer (100K lines of PHP in 200 files) and the new, pure JS GUI (client) architected as a single page web application.
Is pointed to an earlier circumstance, that together with +500 VLANs the reaction or respond time will be very long
till the system will never responding or able to get information's from (freezing). So with the new one we all
get rid of this problem that the nearly entire CPU power will be "eaten" by showing up the VLANs acting.So there is an excellent chance that pfSense 2.5 will use the new webGUI, talking to our RESTCONF back-end.
Only that the new WebGui will be earlier as we could imagine it present and ready to use.
As should be obvious by now, this isn’t about VPN.
So it (AES-NI) is not really and only for the VPN usage.
- via Cloud service
-
So those customers can use AES-GCM, right?
I don't disagree. I'm merely saying if you were going to pick one, AES-GCM is still the natural choice.
And the cache timing attacks are also pretty irrelevant to a purely local instance. Back to square one.
Agreed. While I appreciate their desire to get the crypto right, I don't think it's necessary to prevent systems that lack AES-NI from running pfSense 2.5.
-
Local instances of RESTCONF aren't vulnerable at all.
-
pfSense's crypto library, OpenSSL, already includes a bitsliced AES implementation that provides resistance to cache timing attacks
-
OpenSSL will prefer AES-NI, when available, for customers that are concerned.
-
Mounting a successful cache timing attack under a realistic attack scenario would be extremely difficult.
-
And, ChaCha20-Poly1305 is a viable alternative.
At any rate, the fundamental argument "RFC 7525 REQUIRES [AES-GCM]" is bogus, the RFC says no such thing. There are good reasons to implement multiple algorithms/modes, and all this handwaving is just confusing.
Indeed. RFC 7525 recommends the AES-GCM cipher suites, but does not require them. And beyond that recommendation, ChaCha20-Poly1305 isn't any less RFC compliant than AES-GCM. ChaCha20-Poly1305 is specified in RFC 7905, and AES-GCM isn't a mandatory-to-implement TLS 1.2 cipher suite, either. Software support for ChaCha is a bit more limited, but Netgate controls the software on both endpoints anyway.
-
-
I didn't read all 6 pages but ….
I use pfSense on a j1900 Supermicro based home built router. I like pfSense because it supports multiple simultaneous OpenVPN instances.
Just in case my J1900 no longer works at a later time, are there any other router implementations (ipfire, sophos, etc.) that support multiple OpenVPN instances. I know all don't but some might.
Thanks.
-
I didn't read all 6 pages but ….
I use pfSense on a j1900 Supermicro based home built router. I like pfSense because it supports multiple simultaneous OpenVPN instances.
Just in case my J1900 no longer works at a later time, are there any other router implementations (ipfire, sophos, etc.) that support multiple OpenVPN instances. I know all don't but some might.
Thanks.
This forum is about pfSense hardware. You should try the General Discussion or better yet the respective forums of other distributions.
-
I didn't read all 6 pages but ….
I use pfSense on a j1900 Supermicro based home built router. I like pfSense because it supports multiple simultaneous OpenVPN instances.
Just in case my J1900 no longer works at a later time, are there any other router implementations (ipfire, sophos, etc.) that support multiple OpenVPN instances. I know all don't but some might.
Thanks.
This forum is about pfSense hardware. You should try the General Discussion or better yet the respective forums of other distributions.
Thanks, but it's relevant here in this thread.
pfSense says it won't support my motherboard in a couple of years. What are the options given my needs? Had pfSense not stated this change, you would be somewhat correct. The forum police are some of the most annoying people on earth. I'll figure out which ones support the J1900. I don't feel like downloading and experimenting with 10 - 20 other firewalls just to see how openvpn works on it.
-
Thanks, but it's relevant here in this thread.
pfSense says it won't support my motherboard in a couple of years. What are the options given my needs? Had pfSense not stated this change, you would be somewhat correct. The forum police are some of the most annoying people on earth. I'll figure out which ones support the J1900. I don't feel like downloading and experimenting with 10 - 20 other firewalls just to see how openvpn works on it.
Sorry but it's not relevant. I removed the off-topic comments. You are welcome to discuss 3rd party solutions on their forums.
-
I didn't read all 6 pages but ….
I use pfSense on a j1900 Supermicro based home built router. I like pfSense because it supports multiple simultaneous OpenVPN instances.
Just in case my J1900 no longer works at a later time, are there any other router implementations (ipfire, sophos, etc.) that support multiple OpenVPN instances. I know all don't but some might.
Thanks.
This forum is about pfSense hardware. You should try the General Discussion or better yet the respective forums of other distributions.
Thanks, but it's relevant here in this thread.
pfSense says it won't support my motherboard in a couple of years. What are the options given my needs? Had pfSense not stated this change, you would be somewhat correct. The forum police are some of the most annoying people on earth. I'll figure out which ones support the J1900. I don't feel like downloading and experimenting with 10 - 20 other firewalls just to see how openvpn works on it.
How about in two years you pickup a j3355 off eBay for $15 and save yourself the hassle.
-
I didn't read all 6 pages but ….
I use pfSense on a j1900 Supermicro based home built router. I like pfSense because it supports multiple simultaneous OpenVPN instances.
Just in case my J1900 no longer works at a later time, are there any other router implementations (ipfire, sophos, etc.) that support multiple OpenVPN instances. I know all don't but some might.
Thanks.
This forum is about pfSense hardware. You should try the General Discussion or better yet the respective forums of other distributions.
Thanks, but it's relevant here in this thread.
pfSense says it won't support my motherboard in a couple of years. What are the options given my needs? Had pfSense not stated this change, you would be somewhat correct. The forum police are some of the most annoying people on earth. I'll figure out which ones support the J1900. I don't feel like downloading and experimenting with 10 - 20 other firewalls just to see how openvpn works on it.
How about in two years you pickup a j3355 off eBay for $15 and save yourself the hassle.
Thanks. Nice idea but I have another plan. Moderators prevent me from describing it.
-
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
DeLorean -
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.
