PfSense 2.5 will only work with AES-NI capable CPUs
-
:'(
sad day for the home users.Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
-
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
First, the "sad day for home users" comment is presumably a reference to the announcement that the pfSense devs would rather leave behind home users who may have fairly recently bought Atom/Celeron (and even early i3) systems that lack AES-NI, than simply continue to let OpenSSL run with its existing bit-sliced AES implementation. Even if there was a good reason for AES-NI, it still sucks to leave those users behind (at least, from their perspective) instead of implementing some other solution. So, I don't really see the speculation there.
Second, did you see the second blog post? It's fairly detailed about the explanation. I personally don't think it justifies the decision, but it doesn't seem like there are big unknowns.
-
If all peoples, users and customers are spending $2 per year we could have all things we want!
-
(…)
"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.
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
They specifically associated the rationale with "tens of thousands" of hits on a cloud back end. (Which isn't really that much–so it isn't clear why chacha20 is out, except maybe this is a way to screw with a certain hardware vendor that netgate has made no effort to hide their hostility towards, and who sells a lot of j1900 kit.)
-
They specifically associated the rationale with "tens of thousands" of hits on a cloud back end.
As someone stated on reddit, wouldn't that only the require the cloud server to have AES-NI? Why does the box at the remote location need it, it's not like it's getting hit with tens of thousands of requests.
-
Lol, is it really? Maybe, but no one knows what this even means. This is all just speculation, chill out.
Huh? How is an announcement from the developers "just speculation"? What are you saying isn't known?
What isn't known is the reason behind their decision to require AES-NI.
So, saying that any of this is a "sad day for home users" is speculation. This is just a bunch of people on the internets freaking out over something they can't fully understand yet…
They specifically associated the rationale with "tens of thousands" of hits on a cloud back end. (Which isn't really that much–so it isn't clear why chacha20 is out, except maybe this is a way to screw with a certain hardware vendor that netgate has made no effort to hide their hostility towards, and who sells a lot of j1900 kit.)
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.
And, AES still has a performance advantage over ChaCha20 when using AES-NI.
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.
-
I dig how this "controversy" has started some lively dialogue. They should do this more often.
-
I dig how this "controversy" has started some lively dialogue. They should do this more often.
Yes, it's very good to see the wheels turning. There's a lot of smart people out there.
-
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.
