OPNsense Forum
English Forums => Hardware and Performance => Topic started by: Werner Fischer on May 02, 2017, 12:01:24 pm
-
Hi everyone,
I just noticed that "pfSense Community Edition version 2.5" will depend on a Intel CPU with AES-NI support:
https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html
Are there any plans at OPNsense, to remove support for non-AES-NI CPUs in the future, too?
Best regards,
Werner
-
Hi Werner,
There is no reason to depend on AESNI for anything to work other than performance. In the case of this news piece it means locking down the potential hardware pool available to users to be able to sell more. This is not new, if you remember 2.4 removing i386 and NanoBSD systems. Less hardware support is only a partly motivation for more momentum for development and progress. And while i386 dropping makes some sense to argue that automated build servers are free to do other things, locking down the CPU instruction set in the same architecture is an arbitrary restriction that comes at no cost for the authors, potentially coercing users to buying new hardware. :)
We can't keep up with the release cycle outlined there any longer as it has and likely always will be confusing. There's "3.0" (announced in 2015 based on a PHP-less API rework and DPDK, not available yet), 2.4 (announced in 2016 with FreeBSD 11 and no NanoBSD and i386, not available yet), 2.5 (announced in 2.5 with FreeBSD 12, not available yet).
Judging by the news that 2.5 is based on FreeBSD 12.0 that could easily mean 2019 or later as outlined by FreeBSD recently:
http://marc.info/?l=freebsd-current&m=148709717032570&w=2
"FreeBSD 12.0-RELEASE, available in couple of years"
Expect all of this to change, any day, for any reason. As I said, it's hard to keep up with what is real and what is not.
Also note that OPNsense 17.1 is production-ready on FreeBSD 11 and we have vowed to keep i386 running for as long as we are on 11. This also goes for parallel OpenSSL/LibreSSL tracks and with it the ability to run on any hardware that boots the underlying FreeBSD version.
In short: no, we do and will not restrict our releases to certain CPU requirements other than phasing out all of i386 in the long run (maybe around FreeBSD 12, but it's still negotiable).
I hope this helps.
Cheers,
Franco
-
Hi Franco,
thanks for your friendly and helpful answer. I'm happy that you will continue to support all the hardware that boots the underlying FreeBSD version :)
Thank you very much,
best regards,
Werner
-
I just signed up to the forums and I'm considering switching to OPNSense due in small part to the AES-NI situation with pfSense 2.5 but mainly due to the way they conduct themselves on HN and Reddit regarding the change.
I noticed also that they're not longer supporting 32-bit in 2.4 but made an exception for their own ARM SG1000 (32-bit ARM CPU) it also doesn't feature AES-NI (it has its own cryptographic hardware that implements AES in hardware) but it too will get release 2.5.
But of course if we (the community) wish to use 2.4 on 32-bit we're not allowed, nor can we use cryptographic accelerators or architectures that have their own crypto hardware which isn't AES-NI.
So I have to agree that this whole situation feels like planned obsolescence to get community members to purchase branded hardware.
And that is why I'm here really, I don't like the way things are going there and I've woken up to the realities that they're moving away from openness to make money.
Regardless though I'm happy to be here and learning about OPNSense.
-
InstaNoodle, welcome to the forums.
Franco, thanks for your honest and transparent answer.
-
Hi guys,
You are welcome. There's no reason to change our approach to our work now or ever. ;)
We've concluded in 2014 that we see where the other road leads eventually, so we want to be ready for those changes when they impact a larger body of users. So here's OPNsense, being polished and modernised for over two years and anyone can take it or leave it. We forked to retain 2-Clause BSD licensing like it ever was in FreeBSD, M0n0wall and the pfSense days of yonder. We don't regret it. We stand by this choice.
What I find astonishing is that the "general knowledge" that we are "evil and vile" lives on in 2017 inside the microcosm of pfSense, but people need to realise that without this view inside pfSense there's no reason for pfSense if there are projects out there based on the same code just as good as any.
I'm leaving it to the avid reader and tinkerer to check the facts and figures, see how firmware updates go and how we try to keep innovating. Spoiler alert: it's not for everybody. :D
We love the spirit of what pfSense used to be and we want to retain it. Not more, not less.
Cheers,
Franco
-
Franco thanks for your continued work. I too use OPNsense on a non-AES NI accelerated system. It is nice to know that I can keep using this without a forced upgrade.
For me, the main benefits to OPNsense have been the increased, modernized features that your team has added. For instance, the NetFlow Insight feature and the ability to use FQ_CODEL. Those two features alone are worth the upgrade over pfSense. OPNsense also fixes numerous, nagging issues that pfSense never seems to resolve. For instance, pfSense constantly restarts the DNS Resolver service when registering DHCP leases in the resolver. OPNsense does not do this and therefore it doesn't lose DNS caching. Simple things like this make OPNsense a much smoother, faster experience for the average user.
I used pfSense for the last 10 years. I ran OPNsense in a VM for over a year before deciding to switch out to it in full and run it on dedicated hardware. I consider it to be quite the upgrade over pfSense, especially the 17.1 release! Keep up the great work!
-
Franco,
I saw AESNI post for pfSense and I was really happy I use OPNsense for my hardware. There is new blog post providing good reasons for AESNI. You said AESNI is for performance, not security. It appears to be wrong. Please advise.
https://www.netgate.com/blog/more-on-aes-ni.html
-
We’re leveraging AES-GCM inside TLS as the transport layer, because RFC 7525 REQUIRES it, and the RESTCONF standard, RFC 8040, says RFC 7525 is a SHOULD.
One should also mention RFC 2119 which explains what "SHOULD" means.
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
https://www.ietf.org/rfc/rfc2119.txt
A valid reason is the use of this cloud-based central management technology in particular, not a run-time requirement for an operating system / distribution on a particular hardware. Extrapolating on this, you will have no choice but to run this technology on your free community edition potentially plugging into a foreign US company network even if you don't want this.
Disclaimer: This may not be true, but then the argument link using "SHOULD" becomes the exception to that terminology. So: it's either true and you're always connected to that management platform, or it's not true and you are just arbitrarily restricted in what hardware you are allowed to use.
And besides playing in this this-because-of-that game. RFC 8040 is an arbitrary choice in the scope of REST and API, it feels like a weakly linked argumentation to validate something that does not need to be true. Nobody forces RFC 8040 but Netgate, so the choice to require AES-NI is theirs alone.
Cheers,
Franco
-
Something struck me as peculiar except the usual boilerplate of "we are going to have the best of all of this soon":
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.
Do you think this C code will be open source? Do you think that pfSense as an open source project will thrive from the switching of PHP to something that cannot be easily edited and improved by the vast majority of the community contributors? Do you feel like all questions have been duly answered and we can all go back to work?
Doesn't feel like it... :)
Cheers,
Franco
-
Oh, one more thing from RFC 8040:
A RESTCONF server MUST support the Transport Layer Security (TLS) protocol [RFC5246] and SHOULD adhere to [RFC7525].
The RFC does not state wether this recommendation for RFC 7525 is being made for connections connecting to the service remotely or locally. One must assume that it talks about connections in general, so the recommendation makes sense to secure all possible connections. However, "valid reasons in particular circumstances" are easily given by assuming that the API is providing a local frontend to the GUI running on the same server making local connections, unless the GUI is rewritten as a client-side JS application at the same time.
At this point, we'd be looking at a rewrite of pfSense in all general areas, something that was advertised in 2015, advertised again now. I'll say what I said back then: it looks like a huge pile of work and even more work to get it right. We wish them all the best in their continuing endeavour. :)
Cheers,
Franco
-
I for one was running pfSsense in an ESXi VM on my Supermicro server. It's dual CPU's supported AES-NI, so when decided to separate my firewall/gateway/etc.. off my ESXi server (mostly so that I didn't bring down the internet every time I needed to tinker/reboot) I wanted a CPU with AES-NI (which for Intel Gen 3 meant at least an I5). If I was still running pfSense the AES-NI requirement would not affect me but it would still rub me the wrong way. Either way I'm pretty happy where I'm at now, with really only one item that I really miss from my pfSense days
-
with really only one item that I really miss
Which one is that? :)
-
Hi Franco,
Yes, kepp up the great work!
cheers till
-
Franco,
I read all you write. I don't understand what you talk about. Why is that that important? I asked about AESNI.
-
AES-NI is a set of CPU instructions on x86 architectures. It exists to increase the performance of AES operations on those CPUs. For security, it is irrelevant if it is done in software or in hardware. The same plain text with the same key must result in the same cipher text.
-
AES-NI is a set of CPU instructions on x86 architectures. It exists to increase the performance of AES operations on those CPUs. For security, it is irrelevant if it is done in software or in hardware. The same plain text with the same key must result in the same cipher text.
Note that I'm not a cryptographer and am not currently an authoritative source to talk in-depth about cryptography. Take what I'm about to say with that in mind.
AES-NI can help resolve concerns surrounding a number of side channel attacks, thus improving the security of sensitive data. You'll also usually notice a performance increase in cryptographic operations with a good hardware crypto accelerator, which AES-NI is considered. In short, vetted hardware cryptographic accelerators provide enhanced security and performance.
AES-NI is a welcomed and well-used feature. However, for an open source project which aims to be deployable to a wide range of devices, OPNsense may decide not to force use of AES-NI. Indeed, OPNsense already supports and encourages AES-NI and other crypto accelerators, though use of them is not mandatory.
edit[0]: grammar and encouragement
-
I read all you write. I don't understand what you talk about. Why is that that important? I asked about AESNI.
Why is what important? I don't understand either. You'll have to be more specific.
Cheers,
Franco
-
I just signed up to the forums and I'm considering switching to OPNSense due in small part to the AES-NI situation with pfSense 2.5 but mainly due to the way they conduct themselves on HN and Reddit regarding the change.
I noticed also that they're not longer supporting 32-bit in 2.4 but made an exception for their own ARM SG1000 (32-bit ARM CPU) it also doesn't feature AES-NI (it has its own cryptographic hardware that implements AES in hardware) but it too will get release 2.5.
But of course if we (the community) wish to use 2.4 on 32-bit we're not allowed, nor can we use cryptographic accelerators or architectures that have their own crypto hardware which isn't AES-NI.
So I have to agree that this whole situation feels like planned obsolescence to get community members to purchase branded hardware.
And that is why I'm here really, I don't like the way things are going there and I've woken up to the realities that they're moving away from openness to make money.
Regardless though I'm happy to be here and learning about OPNSense.
Me too. I'm using a Supermicro j1900 motherboard for mine. No AES-NI. No plan to toss it out either since the home router cost nearly $400 at the time I built it. Supermicro isn't cheap but it's supposed to be ultra reliable.
Going to try to convert first on a spare laptop and use a usb lan cable for the 2nd lan outlet. After I get it to work as I like, I'll install on the Supermicro and load the config from the laptop experiment.
If the laptop experiment fizzles I'll do the same but on Hyper-V.
-
I read all you write. I don't understand what you talk about. Why is that that important? I asked about AESNI.
Why is what important? I don't understand either. You'll have to be more specific.
Cheers,
Franco
Hi Franco,
I asked for explanation about AESNI use for performance only. You replied in three posts talking about pfSense but did not explain why you think AESNI is only for performance. It's important because I use OPNsense for security. Please advise.
-
Hi mkolenc,
I asked for explanation about AESNI use for performance only. You replied in three posts talking about pfSense but did not explain why you think AESNI is only for performance. It's important because I use OPNsense for security. Please advise.
I'm sorry for not making this clearer. Of course AES-NI is about performance and security. Between the two, right now, performance is the more prevalent reason to rely on AES-NI. Security for constant-time may be of more use in the future; we are talking about 2 year window of implementation here where attacks will be carried out with growing computation time and sophistication. Yet between now and 2 years, who knows if the security argument is still true or AES-NI will have been compromised in some way? And there is more to this...
It should be of note that AES-NI is automatic. When you have it, OpenSSL and LibreSSL use it, so you get all the benefits by direct choice, performance, security and otherwise. This was and is true for pfSense, OPNsense, FreeBSD, BSD in general, Linux and so on and so forth.
This is not a matter of leaving you less protected when AES-NI is not a hard required. You already get all the benefits of what is being implied here that will maybe hit in 2 years about something that you already have. It's your choice, right now.
Let's get to the juicy part, a paper from 2013 that is used to argue AES-NI in 2017 for maybe 2019. :)
http://sites.nyuad.nyu.edu/moma/pdfs/moma-project-cache-timing-attacks-on-aes.pdf
Emphasis in bold letters.
Cache-timing attacks were first introduced by Bernstein
in 2005, who showed how to complete an AES key recovery
from known-plaintext timings of a network server on another
computer. He used a Pentium III as targeted server and
conjectured that the same attack could be carried out against
software running on many other CPUs. In the last part of his
paper, he encourages future work by applying the same attack
to other CPUs and other severs. He implies that with the
difficulty of writing constant-time high speed AES software, it
would be surprising if any AES-based server were immune.
It should be of note that OpenBSD is right now building a constant time AES into their OS now which is based on the BearSSL implementation, which mimics the benefit of what AES-NI offers in terms of discussed security:
http://openbsd-archive.7691.n7.nabble.com/PATCH-01-04-Constant-time-AES-implementation-td317046.html
The BearSSL take on this is also worth a read:
https://www.bearssl.org/constanttime.html#aes
In the long run this constant-time will seep into LibreSSL (as it is maintained by OpenBSD) as well so AES-NI is either about "performance only" or the argument is bogus altogether, because software in the future will exist that satisfies the heightened security properties that AES-NI offers now, or did back in 2013 anyway.
So we have:
1. An argument based on an arbitrary choice to use RESTCONF which recommends the use of AES-GCM by proxy as discussed previously (RFC 7525), and now also
2. An argument from 2013 favouring AES-NI rejecting the state of constant-time crypto security algorithm state now or in 2019 (nobody knows).
These two can be put to together to present a narrative, but it's muss less work and discussion if we don't. ;)
Cheers,
Franco
-
I too will be moving to OPNsense due to future AES requirements on pfSense. I have an i3 that has the instruction set, but I bought an asrock j1900d2y with embedded passive CPU and fanless PSU for a nice quiet router/firewall. It's awesome.
I have 3 users, to think I need hardware AES is a gross exaggeration. If need be I was going to install Debian on my old toaster oven, since that's about all I would need resource wise.
I prefer BSD for my networking needs and when I posted my concerns on a pfSense forum, the responses were rude and that hardware AES is needed. So, I said (sarcastically) under their logic why don't they go ahead and require ECC RAM and ZFS for the file system and lo and behold, I got responses supporting that and it digressed into a blowhard description of what the future of technology would be and that too would be required in 2.5, but I am sure it is not. troll prolly. UGH! There was no acknowledgment for understanding how things work, it was throwing resources where they need not be.
It used to be that if you desired an enterprise like firewall on commodity hardware, pfSense was a solid go to solution and was a "selling" point. I called out Netgate on the AES thing, but I guess they have to do what they have to do. Just don't feed me that a router needs ZFS and 3 hard drives. I mean, what in the world?
Side note first router was in 99 OS/2 old AT mobo and we screwed it to the framing in the wash room.
Thank you OPNsense for understanding the scope of things.
-
This is exactly what I came here to have answered.
My plan is now to migrate to OPNsense when pfSense obsoletes my hardware. This is about "sending them a message" so that, hopefully, others can see that when you plan obsolescence, users just migrate to some other project.
I have been using various projects since around the early 00s, and I have certain standards that, when met, I will buy swag, send donations, etc (I have a pfSense sticker on my enclosure), so I like to think I'm the kind of user projects prefer to retain.