I didn't say it was in everything since 2008. I said that both companies widely released it by 2010 and that most of the x64 (64 Bit) processors released in the past few years years do support them (except for some of the low end systems, usually used in price constrained embedded style processors). From the link you provided, the last server grade x64 processors without AES-NI were discontinued by 2011.
Also, the release of the AES-NI allows for systems to use cryptography securely without a significant performance impact. I know I've heard people argue for years that we shouldn't use HTTPS by default because it puts too much of a load on the system. With AES-NI, this much less of an argument. For something like OpenSSL and the software/hardware pieces of AES-NI, managing all of the details and getting then right is not a simple process. Just look at the number of times that OpenSSL has screwed up its own code. Google and Amazon now have their own TLS code bases to prevent them from having the same issues that OpenSSL has. Netgate is not a large company and pfSense is not a large project, which means they have limited resources. Making everything work for everyone is something that Microsoft did for years and years. They stopped do this. Just try running Windows 10 on older hardware. For that matter, try running old copies of Linux, FreeBSD, Windows etc on the most recent Dell hardware (things like USB mice, SSDs, Video don't work). It gets worse when you move to phones, were hardware may only be supported for 1-2 years before updates stop flowing. In the mobile phone world, this is were Apple has had longer lives than Microsoft. Also, I can see Netgate looking at numbers (hypothetical, as I have not seen the numbers) and see that if people put pfSense on hardware without AES-NI and then complaining about performance. Worse, competitors could rig the demos, and show crap results for pfSense as compared to their systems (not the first or last time someone lied with benchmarks). With the ever increasing speeds of networking: 100 megabit internet, 1 gig on desktop common, 10 gig on servers not on common, 40-100 GB now found on higher end server networks, with 2.5 and 5 gig cheap networking on way, I can see Netgate wanting to prep for the day when AES-NI is a requirement for encrypted traffic to keep up with speeds that people do and will expect. I have plenty of sympathy for wanting to keep older hardware running (I too have some 8 year old servers that don't have AES-NI). But this is why equipment depreciates, it is supposed to be replaced when it ages out. Given the speed increases, power savings, increased reliability, support for newer technologies, you should be able to make a case for new hardware. On your primary VM host, I would expect it to be at least 6 years old at a minimum if it doesn't support AES-NI. Standard business practice is to replace machines every 3-5 years. At the very least, add some used hardware of only 3-5 years age that has AES-NI. Or, you know, move the firewall from a VM to physical box that has AES-NI. Then all of your VM can continues to run on the old server. I view the threat of people to move the OpnSense to be largely hot air. I think pfSense is great and and don't want to see them compromise the project by trying to be everything to everyone. If they have to lose the old end of the market (systems older than 6-8 years) to maintain the standard of excellence that they have set, I'm fine with that (let OpnSense have the bottom end of an market that costs more that it is worth). I don't want pfSense to value growth or total support base over good quality and newer/better systems. Note, in 2020 (the earliest date when 2.4 could lose new support), your main VM server would them be at least 10 years old. If you can't afford to replace it this year, this gives you another couple of years to plan and budget for upgrades and replacements in 2021. Modern servers are not like houses, they are not meant to run for decades (that is one of the differences between PCs and Mainframes). On Thu, Feb 15, 2018 at 4: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. > > > 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 < > 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 > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > > -- 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
