PfSense 2.5 will only work with AES-NI capable CPUs
-
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
+1 here as well!
-
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
-
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
No answer is also an answer.
-
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
No answer is also an answer.
Will this "‘back-end’ (written in ‘C’)" be open source?
I'll just quote this again! ::) Any response to this question ivor?
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.
-
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions.
Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons. Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
Anyway, thank you for taking the time to respond. -
Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons.
Then you should not make assumptions like: "No answer is also an answer."
Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
Anyway, thank you for taking the time to respond.There's no need for passive-aggressive remarks. Thanks.
-
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions.
Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons. Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
Anyway, thank you for taking the time to respond.I too find Ivor's an interesting moderator. I will leave it at that!
-
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions.
Right, I have not noticed. Because when someone does not respond, you usually don't know their reasons. Especially not in a public forum. But you seem to have your own views of forums. I.e. I have never seen a moderator delete something in this forum before, but then again I sure have not read the whole forum either. :)
Anyway, thank you for taking the time to respond.I too find Ivor's an interesting moderator. I will leave it at that!
I don't see what the problem is. Thread went off-topic, it's still here and you're welcome to discuss further. Just don't demand or try to force me to respond to your off-topic questions.
-
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.
Are you willing or able to comment on what the developers have decided was unacceptable with Mike Hamburg's constant-time (and cache-timing-resistant) AES implementation already in OpenSSL?
That question seems directly applicable to the original post.
-
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.
Are you willing or able to comment on what the developers have decided was unacceptable with Mike Hamburg's constant-time (and cache-timing-resistant) AES implementation already in OpenSSL?
That question seems directly applicable to the original post.
Our developers have not made such decision. I suggest you read the blog posts again. It appears you have missed this part:
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.
It's worth to point out that you've made a lot of assumptions on this thread.
Thanks.
-
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.
Are you willing or able to comment on what the developers have decided was unacceptable with Mike Hamburg's constant-time (and cache-timing-resistant) AES implementation already in OpenSSL?
That question seems directly applicable to the original post.
Our developers have not made such decision. I suggest you read the blog posts again. It appears you have missed this part:
Perhaps you haven’t noticed, I stopped responding on this thread because of many off-topic questions and solid amount of assumptions. We will be providing more development progress updates. I suggest you be more patient.
It's worth to point out that you've made a lot of assumptions on this thread.
Thanks.
I'm confused. Are you saying now that the Netgate team hasn't decided to require AES-NI now, and are still considering whether to include bit-sliced software implementations? That seems to contradict the blog posts.
The first blog post specifically said AES-NI (or other hardware accelerators) would be required:
pfSense Community Edition version 2.5 will include a requirement that the CPU supports AES-NI.
The second blog post reiterated this, seemingly further emphasizing that AES-NI would be required, and rejecting bit-sliced implementations:
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.
So to me, it definitely sounds like you've already decided to require AES-NI, and for some reason you don't like the existing bit-sliced implementation in the crypto library you already use.
If I've made any incorrect or unfounded assumptions, I've love to know what they were.
-
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 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.
