So it's not that Windows uses the wrong curve parameters or anything like that, it's that at some point the key used to index into a validated cert cache is (serial, pub) when it should be (serial, pub, params). As they say, one of the hardest problems in CS is caching.

How difficult is it to exploit? Ie. how much processing power does it take to create the key pair with an identical public key? Or perhaos those are already for sale?

It takes the same amount of time as to generate a key normally. So microseconds. Maybe milliseconds.

I disagree with your assessment. Yes it could've been fixed by storing cache correctly, but that's like a compiler dev saying "well what you did is UB". He's right but also wrong, crypto should be designed to be resilient. TLS and Crypto32 should've never allowed custom curves.

The bug is in not treating EC params as part of certificate identity. However, you *are* correct that supporting custom curves at all is a bug, because RFC5480 explicitly forbids that. I assume they support it because ANSI X9.62 does, because banks or something?

So the attacker provides a cert that gets cached. If that cert has a pub key and serial that matches one the user already has in his local root store, the attacker cert is trusted and used? Is crafting a cert like that possible? I'm assuming yes, or did I miss something?

The real cert gets cached, then the attacker cert masquerades as the cached cert and gets trusted. Yes, doing this is trivial and there is code on GitHub already. It's standard OpenSSL commands and a few lines of Python.

Are you tempting me? :P

Finally! Thanks! This is the first time I get details on this. I was unsure how exactly the “fake cert” was able to impersonate a real root CA!