PfSense 2.5 will only work with AES-NI capable CPUs
-
I don't know how the cache timing attack works and I won't be reading it, I've written and read enough exploits in my early days…
The point is that if pfsense believes it can be exposed to an attack, it wants to protect itself and pfsense believes to solve the problem by making AES-NI mandatory on the box running RESTCONF. Makes pfsense ?Perhaps, but is it throwing the baby out with the bathwater, given OpenSSL already includes a software AES implementation resistant to cache timing attacks?
The question I would ask myself is assuming pfsense support a non-cloud based WebGUI, does the cache timing attack still applies ? Anybody that understand the cache timing attack can elaborate….
If yes, then it makes somewhat pfsense to make AES-NI mandatory…
If no, then pfsense could allow RESTCONF to run on a box without AES-NI ? possible ?The short answer is no. In the local webGUI case, the RESTCONF interface is entirely contained with the pfSense box. It's just an internal communications path. It will apparently be encrypted, but it's not exposed. Anything in a position to mount a cache timing attack on the pfSense box itself is already in a position to do much worse things.
Cache timing attacks, in theory, allow an attacker to learn a secret AES key after seeing a large number of samples showing fairly precise encryption times on mostly random data. If you get bored, here's a paper describing a possible mostly-passive remote cache timing attack. The specific attacks vary, but they're usually some form a known-plaintext attack requiring several gigabytes of data to be encrypted with the target key.
In the case of pfSense, the concern appears to be that an attacker may target the AES-GCM session key used within the HTTPS/TLS protocol encrypting the RESTCONF messages. To mount this attack (assuming a vulnerable AES implementation), an attacker would need to somehow get the victim to send a large amount of data over RESTCONF interface. And it can't just by any traffic from the victim- that traffic specifically has to go over the same HTTPS session. And the attacker has to see precise timings for the crypto operations themselves, which is hard to observe remotely when the victim is doing things other than just immediately responding to requests to encrypt data.
An attacker isn't going to be able to see traffic going over the local communications path. And if it could, it must already be in control of the pfSense box, which means the attacker has already won.
-
Thanks for the clarification ! Btw I won't be reading it, I promised the wife no more 24/7 coding and taking over the world with my army of gazillions of botnets…. I am no longer a Lord.... It's about balanced life...a bit of IT geeky stuff.... cooking.... exercise... go outside take a bit of air.... talk with humans.... :-[
[quote author=reggie14 link=topic=129842.msg717627#msg717627 date=1494354184]
The short answer is no. In the local webGUI case, the RESTCONF interface is entirely contained with the pfSense box. It's just an internal communications path. It will apparently be encrypted, but it's not exposed. Anything in a position to mount a cache timing attack on the pfSense box itself is already in a position to do much worse things.
There is some hope for the non AES-NI community :)
In the case of pfSense, the concern appears to be that an attacker may target the AES-GCM session key used within the HTTPS/TLS protocol encrypting the RESTCONF messages. To mount this attack (assuming a vulnerable AES implementation), an attacker would need to somehow get the victim to send a large amount of data over RESTCONF interface. And it can't just by any traffic from the victim- that traffic specifically has to go over the same HTTPS session. And the attacker has to see precise timings for the crypto operations themselves, which is hard to observe remotely when the victim is doing things other than just immediately responding to requests to encrypt data.
An attacker isn't going to be able to see traffic going over the local communications path. And if it could, it must already be in control of the pfSense box, which means the attacker has already won.
Interesting. I guess pfsense wants to be 100% air tight, even if an attacker is in your network the attacker won't be able to cause damage to pfsense). I guess a script kiddie won't be able to run a "cache timing attack" quickly on rooted box….
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything.
While I get it's a blog post, but I think notice about a change to a version 2 major point versions and probably 2 years away is about as good as a roadmap as you can expect.
No, it's the opposite of a roadmap. They very specifically have no intention of telling people what their plans are.
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything.
While I get it's a blog post, but I think notice about a change to a version 2 major point versions and probably 2 years away is about as good as a roadmap as you can expect.
No, it's the opposite of a roadmap. They very specifically have no intention of telling people what their plans are.
So you don't understand words apparently. They very specifically explained a requirement of a future version of the product and explained how they intend to architect the underlying components of configuration interface in that version. That version being multiple versions and years in the future. I'm not an English major, but I'm pretty sure that's very roadmap-esque. Definitely not the opposite of a roadmap.
-
So you don't understand words apparently.
I'm not an English major, but I'm pretty sure that's very roadmap-esque. Definitely not the opposite of a roadmap.
A bit harsh…go easy, some people have a lot of passion, have certain expectation of pfsense open source and it's roadmap... the expectation doesn't always align with reality 8)
If there enough critical mass (e.g. thousands and thousands of people that really want pfsense without AES-NI or other features that pfsense doesn't want to do ) well there can always be a spin off.... " pfsenseLite based on pfsense but some features tweaked in order to support more hardware and sometimes comprise on security"
Life is short...
-
Interesting. I guess pfsense wants to be 100% air tight, even if an attacker is in your network the attacker won't be able to cause damage to pfsense). I guess a script kiddie won't be able to run a "cache timing attack" quickly on rooted box….
Let's suppose they could. Why would they, though? With root it would be easier to simply read through memory looking for an AES key.
But then again, why even do that? If you already have root, how would getting an AES session key help you in any way? You already control the box at that point.
-
Yeah, if you are rooted in the same box it goes without saying :)
I was thinking more in the lines of an attacker rooting another systems running on the same VM box…
There are also ways without being root to access the cache memory and figure out the "secret keys" (e.g. VM, cross VM, shared hugepage, adjacent process running in same native OS, etc... ) There are countermeasures to reduce the risk (e.g. disabling hugepage sharing, disabling L3 shared cross VM, etc...)As you've stated earlier, OpenSSL has it fixed :)
Reference:
OpenSSL vulnerabilities fixes
https://www.openssl.org/news/vulnerabilities.htmlPage 10, B. The Cross-Core Cross-VM Attack
http://users.wpi.edu/~teisenbarth/pdf/SharedCacheAttackSnP2015.pdfUniversity writing tools to exploit time cache attacks....
https://ts.data61.csiro.au/projects/TS/cachebleed/ -
But ARM? Is the project now wanting to compete with lower end offering like Netgear/Asus/TP-Link/D-Link routers and Ubiquity EdgeRouters?
Many users were asking for it, now they got it!
To everyone whining about this here, stop complaining about your mistakes here. The appropriate way to handle this is to put in a feature request for 2.5 to support non-AES-NI systems (possibly getting the SSE3 OpenSSL build included) and maybe the devs will consider it. They sure as heck aren't going wade through a few whiny forum posts and decide to change direction because of them.
Things often changing fast, but good to know on what they are actual working.
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything. A roadmap helps me in understanding where the focus is, and where/when "major" architectural changes like this will be taking place. It also helps me in determining when a project/product is taking a direction is a direction that is focused on solutions that don't benefit me or help me solve the issues I'm trying to solve.
I see this blog more as a way they want to go and what we can expect from the next version, or what feature or
option will be inside of the next version, and for sure which known issues are there or are solved out. This might
be not the same as the most users will be expect, or something like a 100% right and matching way they are walking.I'm having a hard time understanding where the project direction is now: High-end high-throughput systems that would compete with CISCO/Checkpoint/Palo Alto? Centrally managed - again competing with higher end commercial offerings? Doesn't fit within my needs, but ok, I see many others demonstrating a desire for it in the forums (fastest residential Internet offeriing in my area is 500/50).
The most questions were running in that direction, 1 GBit/s on WAN, turning the firewall in a real UTM, getting
out the maximum of VPN throughput. This is more or less what the most peoples were asking so perhaps it
comes from that side a bit and you may seeing only the Netgate or pfSense developers side, can this perhaps be?Cisco is playing in many more playgrounds and is a NASDAQ notated company so what x_86 hardware can compete
against or plays in the same league likes the Cisco CRS-3 for 470.000 Euros?And PaloAlto is producing NG Firewalls, that are ASIC/FPGA supported and the greater models will starting at
80.000 Euros.Also not the same range where pfSense is actual operating.I'm really confused where PFSense's focus/direction is now. I could be wrong, but I didn't think there was enough development resources to support this many major initiatives.
This might be not alone pending on the pfSense team because FreeBSD is the base of it. And yes, also FreeBSD is
widely used as a Server OS in many companies and in private Networks, Linux and Windows servers are supporting
actual the QAT perhaps it comes from there, can this be?It's not a surprise to see the underlying BSD OS supporting ARM and hence giving PFSense the ability support ARM. It doesn't necessarily equate to trying to compete with the consumer, lower end offering like Netgear/Asus/TP-Link/D-Link routers.
Many users were asking for a cheaper device then the SG-2220 unit and mostly used only for pure firewall tasks.
Also, I wouldn't put Ubiquity EdgeRouters in the same boat as those consumer offerings, they're definitely Enterprise gear. Maybe the low end of Enterprise, but definitely not consumer oriented.
They produce WISP gear from the lower bottom to the higher end for sure, useable for all sections, from the end user
at home to get a good CPE or the WISP that will serve to that clients.No, it's the opposite of a roadmap. They very specifically have no intention of telling people what their plans are.
Dropping some lines what is actual going on might be better then getting nothing to hear until it is out! Other may think
different on this but I would be love to informed from time to time what is actual going on. -
-
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.
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
I am also not interested in having the manageable part of MY firewall in the cloud.
If this ever gets hacked, many users are sitting ducks and are exposed to all kinds of things.
When there is a rollout of a bad update of the manageable part in the cloud, many users are envolved.
And last, what about a closed network like a lab for testing purposes etc…. what doesn't have / require internet access,
that cannot be configured ?
Firewalls managed from the cloud is like driving a shoppingcart by pulling a few ropes on a parking lot,
untill someone cuts the ropes, your shoppingcart rolls down the street and bangs a parked car.Grtz
DeLorean -
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.
