Update

In our pfSense 2.5.0 Development Snapshots Now Available blog posted March 18, 2019, we announced that AES-NI is no longer a requirement for pfSense 2.5.0. Please review that blog for more information.

As always, we appreciate all of the feedback and community interest this topic has generated. Thank you for your continued support of the pfSense project.

There have been some concerns expressed about the requirement for AES-NI (or other offload) with pfSense® 2.5, as announced two days ago.

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.

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 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.

First:

“The final result of our project seems to show that the cache timing attack is not successful on Intel Core i5 and Intel Xeon E5410, and it is somewhat successful on the Intel Atom N2800, which still has a relatively higher level of immunity against cache timing attack compared to the Pentium III used by Bernstein. We have two explanations for this result: multicore processors and AES-NI instruction.”

In order to prove that this was related to the use of AES-NI instructions, the authors then disabled AES-NI on the Intel Core i5 CPU used, and re-ran the test.

“[…], it still proves that after we disabled the AES-NI, the processor became vulnerable to the cache-timing attack.”

We want pfSense software to be safe for everyone.

So why the requirement?

Future versions of pfSense have a new management model. We’re leveraging YANG, via RESTCONF.

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.

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.

AES-GCM in particular has problems with side-channel attacks on pure software implementations. ChaCha20, which nicely avoids these issues when in software, isn’t an option. This is because: a) it’s not RFC-compliant, and b) there are currently no acceleration offloads for it, and the situation is that there could be thousands, or tens of thousands of pfSense instances hitting a single (clustered) instance of our cloud management platform.

So the choice is either to design, engineer and release a less-than-strong product, or require AES-NI or other offloads.

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.

So there is an excellent chance that pfSense 2.5 will use the new webGUI, talking to our RESTCONF back-end.

As should be obvious by now, this isn’t about VPN.