There aren't a lot of .NET exploits for a variety of reasons. Its pretty much the Java of the MS world so a lot of issues more liberal languages have, it doesn't, especially in regards to buffer overflows. Its attack surface is also pretty low as it only really inter-operates, by default, with a limited number of MS applications and is frequently the most common setup, while PHP supports anything and everything. Http.sys also seems like a more secure product than openssl.

That said, its also the minority platform so it benefits from a lack of effort to target it. I also worry that the closed nature of the platform could lead to someone(s) building up an army of zero days while the more open stuff gets discovered and disclosed faster. I'm not sure how realistic that fear is.

At my job we're always scrambling with our FOSS architecture in regards to emergency patching. The MS stuff is more or less 'do monthly patches and forget.'

.Net Core is 100% open source.

How is a goddamn HTTP parser in THE KERNEL more secure than a crypto/TLS library?

http.sys is a fundamentally horrendous idea, see CVE-2015-1635 https://technet.microsoft.com/library/security/MS15-034 An exploited HTTP parser shouldn't lead to RCE "in the context of the System account".

Historically, the schannel infrastructure has been secure, especially as compared to openssl.

>How is a goddamn HTTP parser in THE KERNEL more secure than a crypto/TLS library?

Because, lets face it, openssl is a shit project of legacy code no one wants to fix and https a design by committee standard no one can work well?

"Disable IIS kernel caching"

That's definitely not client-side at all. IIS is the thing that uses http.sys, and classic ASP.NET apps (not the new Core stuff) are usually deployed with IIS.

The number of config permutations in openssl is staggering, and that has to have an effect on the overall test coverage - which probably affects the number of bug that pass through testing.