On Thu, Feb 15, 2018 at 6:11 PM, Jim Thompson <j...@netgate.com> wrote:
> > > > On Feb 15, 2018, at 6:47 PM, Kyle Marek <pspps...@gmail.com> wrote: > > > > On 02/15/2018 05:33 PM, Jim Thompson wrote: > >> Mr. Marek, > >> > >> I think you may be missing the point that this is about 2.5 and the > RESTCONF interface, not any kind of VPN. > > > > I became aware of this after reading the follow up post. > > > >> Yes, there are constant time implementations of AES, they’re quite > slow, as alluded here: > >> https://www.netgate.com/blog/more-on-aes-ni.html < > https://www.netgate.com/blog/more-on-aes-ni.html> > >> > >> Read the whole thing, please, and please remember that this was our > attempt to explain what is coming for future pfSense, well before it would > occur. > >> > >> There is a whole rewrite that needs to occur for 2.5. All the PHP goes > away, and, as we did with the 2.3 -> 2.4 transition, which eliminated > support for 32-bit Intel), and we promised to continue to release 2.3 > images for 32-bit Intel for at least a year past the date of 2.4.0-RELEASE, > we are also on record for support the 2.4 series for at least a year after > the 2.5.0-RELEASE. > > > > As I understand, pfSense uses OpenSSL to implement these functions that > > utilize AES-NI. Is slow bulk throughput the only reason why OpenSSL's > > software implementations are not being allowed? > > > >> So many people want to make this about Netgate attempting to sell more > appliances. This is not true, and anyone looking critically at the > assertion would see the fallacy of it. I will attempt to outline why. > >> > >> It’s now early 2018, and, unknown to us (or anyone else in the FreeBSD > community) before December last year, Meltdown and Spectre are here. While > the appliance model of pfSense is, as far as we can tell, unaffected by > these (unless you load software from strange places), we’re committed to > fixing them anyway. This will include support for 32-bit Intel on the 2.3 > series as FreeBSD (our upstream) implements and releases same. > >> > >> And, none too subtly, the Spectre attacks are (non-crypto) cache-timing > attacks. Point-in-fact, the AES cache-timing attack that I referenced last > May is, indeed, referenced on the first page of the Spectre paper. > >> https://spectreattack.com/spectre.pdf > > > > I understand that Netgate offers support for non-Netgate hardware. > > True, but the “support” I’m talking about here is that we continue to > maintain, build and test new releases of 2.3 and 2.4 for a period of time. > These are available to everyone, without charge. > > > > >> What did anyone running 2.3 on a 32-bit Intel or AMD CPU pay Netgate > for this continued support? > >> > >> Nothing. > >> > >> > >> > >> So assume that a miracle occurs, and a year from now we have a > 2.5.0-RELEASE on 15-Feb-2019. This would mean that the 2.4 series of > pfSense software would continue to be supported until at least 15-Feb-2020. > >> > >> What did anyone running 2.4 on a 64-bit Intel or AMD CPU that doesn’t > implement AES-NI pay Netgate for this continued support? > >> > >> Again, nothing. > > > > I'm failing to see why any additional effort is needed to support > > non-AES-NI AES implementations considering OpenSSL is implementing it. > > If AES-NI is not available, OpenSSL will either use Vector Permutation AES > (VPAES https://www.shiftleft.org/papers/vector_aes/vector_aes.pdf) or > Bit-sliced AES (BSAES https://cryptojedi.org/papers/aesbs-20090616.pdf), > provided the SSSE3 instruction set extension is available. SSSE3 was first > introduced in 2006, so there is a fair chance that this will be available > in most computers used. Both of these techniques avoid data- and > key-dependent branches and memory references, and therefore are immune to > known timing attacks. VPAES is used for CBC encrypt, ECB and "obscure" > modes like OFB, CFB, while BSAES is used for CBC decrypt, CTR and XTS. > > The bit sliced (constant-time) implementation in OpenSSL could be used, > but the GUI model with RESTCONF is very (very) different. Except for the > various “monitoring” widgets and graphs, a web browser running against > today’s pfsense is all but silent until something like an “Apply” button is > pushed. With RESTCONF, things are much more “chatty”. > > This means that there is more load on the box to keep things encrypted. > The bit sliced implementation in OpenSSL is slow, especially on older > processors. I’ve run it on a J1900, and it’s glacial. > > As I explained in the blog post, we’re going to move 2.5 to the RESTCONF > interface. We don’t have the resources to carry both the historic PHP and > RESTCONF interfaces forward. > > > > >> Now remember that 2.5 is unlikely to occur by 15-Feb-2019, and thus 2.4 > will continue to be supported beyond 15-Feb-2020. Were we to get a > 2.5.0-RELEASE by 1 May 2019, 2.4.x would be supported until 1 May 2020, and > this is three years after the initial announcement that 2.5 would require a > CPU with AES-NI (or other hardware crypto offload. I’ll note that ARM8v > CPUs have instructions similar to AES-NI, and that the ARM appliances > released by Netgate have crypto offload available.) > >> > >> So if the goal was to somehow coerce people into buying new appliances, > it’s not working until at least then, and even then, all that occurs if you > choose to remain on 2.4 is that some bugs won’t be fixed. > >> > >> So your “shame” Mr. Marek, while noted, is, in my view, specious. > I’ve documented the cache-timing attacks possible against AES-GCM, and you > haven’t countered these. > >> > >> I’ve explained (on the forum and elsewhere) that the bit sliced AES > implementation in OpenSSL is too slow, and you haven’t countered these, > either. Warning: some implementations look fast until you realize that > they’re only fast on large (say 2048 byte) blocks, and that they don’t > “scale down” (a 576 byte payload takes exactly the same amount of time.) > >> > >> I’ll note that one can make a bit sliced AES implementation go faster > with AVX instructions, but then one also has AES-NI, so the point is moot. > >> > >> So any *shame*, Mr. Marek would be if I knowingly and willing put the > security of the pfSense community at risk lest I be attacked. > >> > >> To be clear, this has not occurred. > > > > I apologize for my comments of shaming. I was under the impression that > this was a meritless artificial limitation rather than any kind of > > support burden. However, I still don't understand why the existing > software solutions are insufficient in any way besides throughput. > > If they’re fast, they’re problematic from a security standpoint. > > On a Westmere (so one generation forward from your Xeons), AES GCM > performs at 3.54 cycles/byte. > Compare this with 10.68 cycles/byte got bitsliced AES GCM with table > lookups (not secure) or > 21.99 cycles/byte without table lookups (much more difficult to mount a > side-channel attack) as implemented in OpenSSL. > > On a V4 Xeon, AES-GCM runs at 0.77 cycles/byte, and on the newest Xeon > ‘Scalable’ cores, it runs at 0.65 cycles/byte. > > Since we just mentioned “really new hardware”… and yes, it’s off the > subject of OpenSSL, but possibly of some interest, > > With TNSR (the DPDK re-write) on AWS we’re doing 4.59 gbps IPsec > (AES-GCM-128) or 4.58 gbps IPsec (AES-CBC-128 + HMAC-SHA1) between a pair > of C5.large instances (so those same Xeon ’Scalable’ cores), using a single > core. These instances have a maximum 5 gbps single stream ‘cap’. The > traffic generator hosts used iperf3 to send traffic. Tests were run both > with a single stream and with 4 streams. > > The traffic generator hosts (outside the tunnel) had their MTU adjusted > down to 1500 (from the default value of 9001). Tests with iperf3 were > invoked with a flag that set the TCP MSS to 1375 in order to ensure that > each segment sent would not exceed 1500 bytes once the encapsulation > overhead (ESP header, initialization vector, padding, integrity check > value, outer IP header) is added. > > Raw (no IPsec) throughput using iperf3 was 4.79 gbps. The measurements > taken by iperf3 use the amount of data sent in the TCP payload to calculate > throughput. The 32 byte TCP header (standard 20 byte TCP header plus 10 > bytes for optional field containing timestamps and 2 bytes to pad optional > fields to a multiple of 4 bytes) and 20 byte IP header on each packet are > not included in the calculation. If 52 bytes from each 1500 byte packet are > considered overhead that is not included in the measurement, the maximum > result that iperf3 could achieve on a 5 gbps link would be approximately > 4.83 gbps. > > Additional overhead from ESP includes 20 bytes for an outer IP header, 8 > bytes for an ESP header, 2 bytes for padding length & next header type, 16 > (AES-CBC) or 8 (AES-GCM) bytes for an initialization vector, and 12 > (HMAC-SHA1) or 16 (AES-GCM) bytes for an integrity check value. The total > extra overhead is 58 bytes (AES-CBC HMAC-SHA1) or 54 bytes (AES-GCM). Thus, > the maximum measurement possible using iperf3 on a 5 Gbps link is 4.63 gbps > for AES-CBC-128 HMAC-SHA1 and 4.65 gbps for AES-GCM-128 ICV16. > > Net-net, it’s probably faster than that, since we’re obviously hitting the > Amazon-imposed bandwidth limit. Between a pair of i7-6950s (so Broadwell > cores) we see 13.7 gbps (single-stream) AES-GCM-128 and 7.42 gbps > AES-GCM-128 + HMAC-SHA1 (again, single-stream). Adding our CPIC QAT card > gets us to 32.68/32.73 gbps respectively. > > > I cannot counter the attack possibility, but I would like to ask: is > this unsolvable without hardware acceleration? > > It has a lot to do with what one might consider “acceptable” performance > of the web gui. > > > > >> I side with Mr. Parker here. How long does a project have to wait > before demanding certain features for future revisions, assuming it gives > adequate warning to the existing and future users of that project? I’ll > note that you didn’t answer his question. > > > > I never answered the question because I did not think the answer or the > > question was relevant. Until today, it was my understanding that AES-NI > > was simply to improve throughput of applications utilizing AES. I had > > previously not been presented with anything to indicate that it helps > > with any security issues such as the timing attacks discussed here. > > OK, but I did point these out in the blog posts of last May. Quoting: > > "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.” > > I’ve listed the performance of the various implementations in OpenSSL > above. > > > However, to address the question in some way, I do agree that features > > like this should be taken advantage of as much as possible. However, > > unlike other advances such as x86 to x86_64, AES-NI does not create any > > new functionality that did not already exist. Until the security > > benefits have been presented, I did not see any use case where AES-NI > > would be necessary over the software implementation. > > > > I would like to point out that AES-NI is not "in everything" since 2008 > > as previously indicated. While I understand these may not fall under the > > "all major x64 processors" category, Intel has launched CPUs without > > AES-NI within the past couple of years. > > It’s true that not everything Intel and AMD have released in the last > decade has AES-NI. > > > > > See: > > https://ark.intel.com/Search/FeatureFilter?productType= > processors&AESTech=false&BornOnDate=Q4%2716 > > > >> And, finally, Mr. Volotinen called it exactly. We announced this in > May last year, so that those buying hardware in the now would know about > the future requirements. Anyone buying hardware now can make an informed > decision as to if they want to buy or otherwise obtain a platform for > pfSense that supports AES-NI, or not. Either will work as long as they are > running a 2.4.x release of pfSense, and, as above, 2.4 has a plan that > includes support until, at least, 2020. > > > > This is acceptable. It just also just sucks, and I understand it must be > > faced. > > > > This is, however, beyond just replacing some networking equipment, as I > > have to replace my primary VM host due to CPU replacements supporting > > AES-NI not existing. Before knowing that the AES-NI requirement was to > > address the timing attack, I felt as if I have to pay for new hardware > > due to Netgate not "wanting" non-AES-NI AES implementations being > > utilized. Until this, I have not exactly had software support issues > > with even this aging hardware. > > Nor do you now. It’s only (at least) a year after the release of 2.5 that > we’ll stop supporting 2.4, and then it’s a matter of when a security issue > or other bug that is important enough to you switch gets addressed in 2.5 > but not in 2.4 might occur (gosh that’s an awful sentence, Jim). > > > I understand that a lot of people are effectively threatening to switch > > to OpnSense due to this, but I fear that I will *have to* if I can't > > replace my hardware by the time support for software AES ends entirely. > > People should run what suits their purpose best. Perhaps someone else > will fork pfSense and continue the 2.4 train on a different track. That’s > the beauty of open source software. > > > > See: > > https://ark.intel.com/Search/FeatureFilter?productType= > processors&SocketsSupported=LGA771&AESTech=true > > > > I thank you for addressing this with me. I appreciate your conduct with > > me despite my comment. > > Sure thing. I also appreciate your response here. > > Thanks, > > Jim > > > > >> Jim > >> > >>> On Feb 15, 2018, at 2:11 PM, Kyle Marek <pspps...@gmail.com> wrote: > >>> > >>> I think you're missing the point that software support exists; pfSense > >>> supports software AES *now*, and this is being removed. New technology > >>> is cool; things not working anymore is not. > >>> > >>> Anyway, what are are other projects such as the TLS libraries doing > >>> about this? Is hardware acceleration really the only solution? > >>> > >>> On 02/15/2018 01:39 PM, Walter Parker wrote: > >>>> Well, both Intel and AMD starting shipping the AES-NI instructions 8 > years > >>>> ago... > >>>> > >>>> How long does a project need to wait before it can require a feature > found > >>>> on all major x64 processors? Waiting 8-9 years seems reasonable to me. > >>>> > >>>> Given the fact that the project is only supporting 64-bit and suggests > >>>> using a modern processor this requirement should be a non issue for > most > >>>> users. > >>>> > >>>> The only place where the AES-NI instructions are not found is in a > small > >>>> number of embedded/dev boards using older Celeron processors. > >>>> > >>>> > >>>> Walter > >>>> > >>>> On Thu, Feb 15, 2018 at 9:37 AM, Kyle Marek <pspps...@gmail.com> > wrote: > >>>> > >>>>> This is silly. I shouldn't have to replace my hardware to support a > >>>>> feature I will not use... > >>>>> > >>>>> I shame Netgate for such an artificial limitation... > >>>>> > >>>>> Thank you for the information. > >>>>> > >>>>> On 02/15/2018 12:20 PM, Eero Volotinen wrote: > >>>>>> Well: > >>>>>> > >>>>>> https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html so we are > >>>>> talking > >>>>>> about 2.5 not 3.x ? > >>>>>> > >>>>>> "While we’re not revealing the extent of our plans, we do want to > give > >>>>>> early notice that, in order to support the increased cryptographic > loads > >>>>>> that we see as part of pfSense verison 2.5, pfSense Community > Edition > >>>>>> version 2.5 will include a requirement that the CPU supports > AES-NI. On > >>>>>> ARM-based systems, the additional load from AES operations will be > >>>>>> offloaded to on-die cryptographic accelerators, such as the one > found on > >>>>>> our SG-1000 <https://www.netgate.com/products/sg-1000.html>. ARM > v8 CPUs > >>>>>> include instructions like AES-NI > >>>>>> <https://www.arm.com/files/downloads/ARMv8_Architecture.pdf> that > can be > >>>>>> used to increase performance of the AES algorithm on these > platforms." > >>>>>> > >>>>>> > >>>>>> Eero > >>>>>> > >>>>>> On Thu, Feb 15, 2018 at 7:18 PM, Edwin Pers <ep...@ansencorp.com> > wrote: > >>>>>> > >>>>>>> I believe I read somewhere that the new version that requires > aes-ni > >>>>> will > >>>>>>> be 3.x, and they plan to continue the 2.x line alongside it, as 3.x > >>>>> will be > >>>>>>> a major rewrite > >>>>>>> > >>>>>>> > >>>>>>> -Ed > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of > Eero > >>>>>>> Volotinen > >>>>>>> Sent: Thursday, February 15, 2018 12:14 PM > >>>>>>> To: Kyle Marek <pspps...@gmail.com> > >>>>>>> Cc: pfSense Support and Discussion Mailing List < > list@lists.pfsense.org > >>>>>>> Subject: Re: [pfSense] Configs or hardware? > >>>>>>> > >>>>>>> Well. Next version of pfsense (2.5) will not install into hardware > that > >>>>>>> does not support AES-NI, so buying such hardware is not wise ? > >>>>>>> > >>>>>>> Eero > >>>>>>> > >>>>>>> > > Well Said. Thank you for sharing the numbers. Walter -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
