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. > 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. > 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. I cannot counter the attack possibility, but I would like to ask: is this unsolvable without hardware acceleration? > 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. 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. 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. 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. 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. > 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 <email@example.com >>>>>> 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 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> pfSense mailing list >>>>>> https://lists.pfsense.org/mailman/listinfo/list >>>>>> Support the project with Gold! https://pfsense.org/gold >>>>>> >>>>> _______________________________________________ >>>>> pfSense mailing list >>>>> https://lists.pfsense.org/mailman/listinfo/list >>>>> Support the project with Gold! https://pfsense.org/gold >>>> _______________________________________________ >>>> pfSense mailing list >>>> https://lists.pfsense.org/mailman/listinfo/list >>>> Support the project with Gold! https://pfsense.org/gold >> _______________________________________________ >> pfSense mailing list >> https://lists.pfsense.org/mailman/listinfo/list >> Support the project with Gold! https://pfsense.org/gold _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold