PfSense 2.5 will only work with AES-NI capable CPUs
-
I'm confused.
Yes, you appear to be confused. I think I was very clear I cannot provide more comments or details other than what was revealed in the blog posts.
I'm not trying to be difficult here. And I'll even understand if there are certain things that you're not at liberty to say. But now I'm trying to understand what you meant when you said:
Our developers have not made such decision. I suggest you read the blog posts again.
The blog posts said AES-NI would be required in pfSense 2.5. Your post from earlier today said that the developers have not decided that the VPAES implementation is unacceptable. Does that mean they're considering to to allow the use of the VPAES implementation (which does not use AES-NI) in pfSense 2.5? Are you suggesting that there may not be a requirement for AES-NI after all?
-
I'm confused.
Yes, you appear to be confused. I think I was very clear I cannot provide more comments or details other than what was revealed in the blog posts.
I'm not trying to be difficult here. And I'll even understand if there are certain things that you're not at liberty to say. But now I'm trying to understand what you meant when you said:
Our developers have not made such decision. I suggest you read the blog posts again.
The blog posts said AES-NI would be required in pfSense 2.5. Your post from earlier today said that the developers have not decided that the VPAES implementation is unacceptable. Does that mean they're considering to to allow the use of the VPAES implementation (which does not use AES-NI) in pfSense 2.5?
AES-NI is required for pfSense 2.5. I think you misunderstood my post from earlier today.
-
It's worth to point out that you've made a lot of assumptions on this thread.
Seriously, I’d really like to know where I’ve run off with unfounded assumptions. I looked through my earlier posts in this threads, and it seems like everything is based closely on statements in the blog posts with limited inferences based on other material.
I’ll try to summarize the major points in my posts and I’d honestly appreciate feedback on items that are incorrect.
-
AES-NI (or other hardware accelerations) will be REQUIRED in pfSense 2.5. (reference)
-
Netgate is motivated by concerns over cache-timing attacks on AES. (reference)
-
Future versions of pfSense will use a RESTCONF API for management between a cloud or local hosted webGUI and the pfSense router. This will use TLS with an AES-GCM cipher suite. (reference)
-
I deduce that Netgate is worried about cache-timing attacks allowing recovery of the AES-GCM key used in RESTCONF sessions (seemingly clear from above).
-
Cache-timing attacks are a legitimate threat, but are can be difficult to mount under realistic attack scenarios (reference) An attack scenario involving the RESTCONF interface hasn’t been laid out by anyone yet.
-
pfSense developers are not implementing their own crypto, but are instead using OpenSSL (reference)
-
OpenSSL already includes a constant-time, cache-timing-resistant AES implementation (reference: VPAES). While obviously not as fast as AES-NI, it still offers strong performance for a software implementation (reference).
-
OpenSSL v1.0.1s (which is running on my pfSense v2.3.3 box) and OpenSSL v1.0.2j (which I see referenced in the source tree) both include VPAES.
-
When referring to concerns over cache timing attacks on AES (reference), Netgate pointed to an NYU class project that would have disabled VPAES by disabling use of SSE3. (reference, page 5)
-
A requirement for AES-NI logically implies that the VPAES implementation was deemed unacceptable (or that its existence was unknown, or that it wasn't considered at all).
-
-
It's worth to point out that you've made a lot of assumptions on this thread.
Seriously, I’d really like to know where I’ve run off with unfounded assumptions. I looked through my earlier posts in this threads, and it seems like everything is based closely on statements in the blog posts with limited inferences based on other material.
I’ll try to summarize the major points in my posts and I’d honestly appreciate feedback on items that are incorrect.
-
AES-NI (or other hardware accelerations) will be REQUIRED in pfSense 2.5. (reference)
-
Netgate is motivated by concerns over cache-timing attacks on AES. (reference)
-
Future versions of pfSense will use a RESTCONF API for management between a cloud or local hosted webGUI and the pfSense router. This will use TLS with an AES-GCM cipher suite. (reference)
-
I deduce that Netgate is worried about cache-timing attacks allowing recovery of the AES-GCM key used in RESTCONF sessions (seemingly clear from above).
-
Cache-timing attacks are a legitimate threat, but are can be difficult to mount under realistic attack scenarios (reference) An attack scenario involving the RESTCONF interface hasn’t been laid out by anyone yet.
-
pfSense developers are not implementing their own crypto, but are instead using OpenSSL (reference)
-
OpenSSL already includes a constant-time, cache-timing-resistant AES implementation (reference: VPAES). While obviously not as fast as AES-NI, it still offers strong performance for a software implementation (reference).
-
OpenSSL v1.0.1s (which is running on my pfSense v2.3.3 box) and OpenSSL v1.0.2j (which I see referenced in the source tree) both include VPAES.
-
When referring to concerns over cache timing attacks on AES (reference), Netgate pointed to an NYU class project that would have disabled VPAES by disabling use of SSE3. (reference, page 5)
-
A requirement for AES-NI logically implies that the VPAES implementation was deemed unacceptable (or that its existence was unknown, or that it wasn't considered at all).
I will quote myself:
I think I was very clear I cannot provide more comments or details other than what was revealed in the blog posts.
-
-
Everyone who is upset with the pending change … chill. I WAS upset but came back to Earth after some investigation and thinking. In reality, 2.5 won't be out for years and 2.4 will be supported for a year beyond that date. 2.4 will still work afterward, it just won't update. Given the pfSense rate of change, this is several years down the road.
After this time has passed, nice hardware from today will be considered surplus by then and will support AES-NI. Junk and surplus hardware in use today will look ridiculous as a router by then.
I have an old laptop with a couple of spare usb lan adapters. The old laptop supports AES-NI. It WILL work as a router today with pfSense. I tried it a couple of days ago and it supported my entire house.
My custom J1900 based router will work for several years. Then, at that time, I'll look into different circumstances. Maybe. Even if I don't my router will still work.
I tried a few router distributions on the above mentioned laptop. One had an installer defect. Others were decent routers but none were as concise and/or complete as pfSense with regard to my needs (IPS/IDS, geoblocking with misc list blocking, openvpn with multiple servers and users with individual certificates, and a little more. One was close but it required a licence renewal every three years. I didn't want to indirectly put others in that position.).
Note to pfSense ... look into SoftEther with or instead of openvpn ... on the surface it's amazing.
-
Everyone who is upset with the pending change … chill. I WAS upset but came back to Earth after some investigation and thinking. In reality, 2.5 won't be out for years and 2.4 will be supported for a year beyond that date. 2.4 will still work afterward, it just won't update. Given the pfSense rate of change, this is several years down the road.
After this time has passed, nice hardware from today will be considered surplus by then and will support AES-NI. Junk and surplus hardware in use today will look ridiculous as a router by then.
I have an old laptop with a couple of spare usb lan adapters. The old laptop supports AES-NI. It WILL work as a router today with pfSense. I tried it a couple of days ago and it supported my entire house.
My custom J1900 based router will work for several years. Then, at that time, I'll look into different circumstances. Maybe. Even if I don't my router will still work.
I tried a few router distributions on the above mentioned laptop. One had an installer defect. Others were decent routers but none were as concise and/or complete as pfSense with regard to my needs (IPS/IDS, geoblocking with misc list blocking, openvpn with multiple servers and users with individual certificates, and a little more).
Note to pfSense ... look into SoftEther with or instead on openvpn ... on the surface it's amazing.
Glad to have you back! Regarding SoftEther, if there is someone willing to contribute the package let us know! We currently do not have enough of development resources for it.
-
Everyone who is upset with the pending change … chill. I WAS upset but came back to Earth after some investigation and thinking. In reality, 2.5 won't be out for years and 2.4 will be supported for a year beyond that date. 2.4 will still work afterward, it just won't update. Given the pfSense rate of change, this is several years down the road.
I don't care about new features (well, not as much, but I understand new features may require new hardware). I care about security patches- both for pfSense itself and for packages. If patching (as an major element support security) isn't important to you, then I'm at a loss why you'd be using something like pfSense.
As you said, what we're heard is that is pfSense 2.5 is likely about a year away, and they'll probably support it for about a year beyond that. At face value, that means two year notice that you won't be able to receive security patches if you're running something that lacks AES-NI.
It might be better than that- realistically I don't expect pfSense 2.5-final in a year, for instance. But it also might be worse. What's going to happen to pfSense v2.4 packages after v2.5 is out? How many of them will still receive updates- particularly the ones developed by people in the community outside of Netgate? I think many of them will stop being patched well before pfSense v2.4 falls out of support.
After this time has passed, nice hardware from today will be considered surplus by then and will support AES-NI. Junk and surplus hardware in use today will look ridiculous as a router by then.
I think it's more complicated than that. Most home users don't need a powerful box to run pfSense. The Celeron/Atom systems in use today are popular because they're small, cheap, and low-power. Yes, a lot of people might end up with spare hardware between now and then, but do you really want to replace a 10W J1900 mini-ITX system with a 65W Core i5 ATX system?
-
Why in the world would anyonehave to replace a j1900 with an if ATX system?
I'm pretty sure every single CPU in the Apollo lake lineup supports AES-NI all the way down to the n series Celerons.
Apollo lake SoC are already cheap (~$55), in a few years you'll be able to pick them up for like $20 or less on eBay.
-
So you, ivor, don't respond to direct and yes relevant questions and then chastise people for making assumptions about those questions and what silence says.
Whatever.
-
So you, ivor, don't respond to direct and yes relevant questions and then chastise people for making assumptions about those questions and what silence says.
Whatever.
Open source projects are a mixed blessing. The people doing the work are constantly getting bitched at by users they often see as technically inept free-loaders. Users get confused by poorly thought out public messages that throw into doubt what they thought they knew about the project. Raw attitudes and antagonistic cultures are just about inevitable. Unfortunately pfSense is no exception.
-
So you, ivor, don't respond to direct and yes relevant questions and then chastise people for making assumptions about those questions and what silence says.
Whatever.
I have no idea what you are talking about. I suggest you cool down.
-
So you, ivor, don't respond to direct and yes relevant questions and then chastise people for making assumptions about those questions and what silence says.
Whatever.
Open source projects are a mixed blessing. The people doing the work are constantly getting bitched at by users they often see as technically inept free-loaders. Users get confused by poorly thought out public messages that throw into doubt what they thought they knew about the project. Raw attitudes and antagonistic cultures are just about inevitable. Unfortunately pfSense is no exception.
pfSense is free, we don't see our users like that. I had to respond to a couple of assumptions or it would end up as a "drama". I cannot respond to every comment. Some are refusing to comprehend that I'm not allowed to share more information and they continue to demand answers by dragging me into further discussion. I can't do much if NOYB doesn't see that.
Let's stay on topic.
-
This is going to hurt me.
I manage about 40 sites which are mainly using re-purposed Dell small form factor desktops and APU devices with the AMD G-T40E CPU. None of them use VPN (except me to log in to them remotely) and I have no interest in using cloud management either. Even my home firewall is running on a Dell Optiplex 780 with Intel Core 2 Duo E7500 which does not have AES-NI but is plenty powerful for what I use it for. There are no socket 775 CPU's with AES-NI so a complete hardware upgrade will be required.
I can understand the need to have good encryption between the cloud service and remote firewalls, but I imagine the vast majority of "home" users will not ever use the cloud service.
Can't you consider some other options, such as only making AES-NI a requirement IF you want to use the cloud service? Or perhaps consider ChaCha20, which has higher performance than AES on devices without AES-NI? It works well enough for Wikipedia and Cloudflare.
My business is primarily providing low cost networking to SOHO environments. I'm sure you can understand how pfSense and older/cheaper hardware plays a part in this. Things will be much more difficult from 2.5 onward because I won't simply be able to use $50 refurbished hardware, and will instead need to spend 5x as much on Netgate stuff.
I appreciate the long advance warning, but please consider my points above.
Thank you, and keep up the great work.
-
This is going to hurt me.
I manage about 40 sites which are mainly using re-purposed Dell small form factor desktops and APU devices with the AMD G-T40E CPU. None of them use VPN (except me to log in to them remotely) and I have no interest in using cloud management either. Even my home firewall is running on a Dell Optiplex 780 with Intel Core 2 Duo E7500 which does not have AES-NI but is plenty powerful for what I use it for. There are no socket 775 CPU's with AES-NI so a complete hardware upgrade will be required.
I can understand the need to have good encryption between the cloud service and remote firewalls, but I imagine the vast majority of "home" users will not ever use the cloud service.
Can't you consider some other options, such as only making AES-NI a requirement IF you want to use the cloud service? Or perhaps consider ChaCha20, which has higher performance than AES on devices without AES-NI? It works well enough for Wikipedia and Cloudflare.
My business is primarily providing low cost networking to SOHO environments. I'm sure you can understand how pfSense and older/cheaper hardware plays a part in this. Things will be much more difficult from 2.5 onward because I won't simply be able to use $50 refurbished hardware, and will instead need to spend 5x as much on Netgate stuff.
I appreciate the long advance warning, but please consider my points above.
Thank you, and keep up the great work.
I'm sorry but AES-NI is not exclusive to Netgate appliances.
-
This is going to hurt me.
I manage about 40 sites which are mainly using re-purposed Dell small form factor desktops and APU devices with the AMD G-T40E CPU. None of them use VPN (except me to log in to them remotely) and I have no interest in using cloud management either. Even my home firewall is running on a Dell Optiplex 780 with Intel Core 2 Duo E7500 which does not have AES-NI but is plenty powerful for what I use it for. There are no socket 775 CPU's with AES-NI so a complete hardware upgrade will be required.
I can understand the need to have good encryption between the cloud service and remote firewalls, but I imagine the vast majority of "home" users will not ever use the cloud service.
Can't you consider some other options, such as only making AES-NI a requirement IF you want to use the cloud service? Or perhaps consider ChaCha20, which has higher performance than AES on devices without AES-NI? It works well enough for Wikipedia and Cloudflare.
My business is primarily providing low cost networking to SOHO environments. I'm sure you can understand how pfSense and older/cheaper hardware plays a part in this. Things will be much more difficult from 2.5 onward because I won't simply be able to use $50 refurbished hardware, and will instead need to spend 5x as much on Netgate stuff.
I appreciate the long advance warning, but please consider my points above.
Thank you, and keep up the great work.
Actually, it might help you, and my reasoning has nothing to do with AES-NI.
One of the strengths of pfSense and other router distributions is that you can use them on nearly any hardware or in virtual systems. Lots of people use pfSense on old, junk, surplus hardware that was otherwise just sitting in a pile on the floor. It's 'free'.
Surprise, your free hardware is costing buckets of cash in electricity. Do a little math with your kw cost and some of those free firewalls probably cost $20 - $50 a year to use in electricity cost. Obviously, $50 is extreme but right now, power costs are low and not everyone pays extremely high prices per kwh. My little j1900 based router costs perhaps $1 a month to run/ or $12 per year. An old relic that uses 5x the electricity costs $60 per year. How could you consider that a favor for someone on a budget?
the final changeover won't happen for a couple of years at the earliest. More likely, it will be 3 - 4. By then, hardware costs will be even lower while capabilities will be higher. A wealth of options will be available for router duty. Used hardware will be almost a gift in cost. I got pfSense running on a tiny laptop with AES-NI and two usb network adapters in few minutes. It supported the entire house for a while. The processor used 8 watts.
Or, just load up another distro. I tried that for experimental purpose. There's lots of good ones. If you don't need openvpn that widens the field because most don't support openvpn so grandly. Geoblocking is iffy and most don't appear to support supplemental list blocking such as iblock lists. User certificates are hit or miss. IPS/IDS is supported by many but exceptions are not intuitive in many and none I looked into appear to be as granular as snort can be in pfSense. One likely candidate could support all of the above but had a fatal installer problems. After several install attempts I gave up on it, considering the install issues to be a measure of overall software quality.
Good luck to you – coming from a former changeover hater.
-
So you, ivor, don't respond to direct and yes relevant questions and then chastise people for making assumptions about those questions and what silence says.
Whatever.
Open source projects are a mixed blessing. The people doing the work are constantly getting bitched at by users they often see as technically inept free-loaders. Users get confused by poorly thought out public messages that throw into doubt what they thought they knew about the project. Raw attitudes and antagonistic cultures are just about inevitable. Unfortunately pfSense is no exception.
Have to agree. Great technical skills don't have anything to do with people skills. Back in my consulting days over a decade ago, many good communicators were phonies who talked their way into project management jobs without even a small technical skill set. They had numerous tricks to get others to do the job while they took the credit and maintained total control. Flunky types go along best with them. I never got along well with that type and most tried to 'get even with me'. I watched most get fired eventually. So the moral, if you see a technical person with good people skills, they might be like one of them. (I have poor people skills but great writing skills that cover it up.)
So, the next time some dick in the forum doesn't agree with you, they probably don't know any better. Let it go. These people obviously know what they are doing.
-
Quite a few moderators in this forum seem to be on Netgate's payroll nowadays. So they do not only represent an open source project but also a company.
-
Can we stay on topic please?
-
Quite a few moderators in this forum seem to be on Netgate's payroll nowadays. So they do not only represent an open source project but also a company.
As long as they offer a good free version and keep their hardware competitively priced, why does that matter? To a home user like me, I like the free stuff and it keeps people trying out their software. If I were buying hardware for a company, I wouldn't be using a junk server from the hall closet, I'd buy from someone who has as active base for quality control purposes, such as free software provides.
also, ivor, how can you be off topic in a general discussion … just asking.
-
also, ivor, how can you be off topic in a general discussion … just asking.
This thread is in the General Questions board, a child board of the English Support forum. GD is at the bottom of the main page.
