Ref: https://kb.cert.org/vuls/id/849224/
Quote from: https://kb.cert.org/vuls/id/849224/The Microsoft Windows CryptoAPI, which is provided by Crypt32.dll, fails to validate ECC certificates in a way that properly leverages the protections that ECC cryptography should provide. As a result, an attacker may be able to craft a certificate that appears to have the ability to be traced to a trusted root certificate authority.
This is why you dont ask an intern to release code. :squint:
Its not as apocalyptic as on first glance, but yeah haha
- only affects windows
- only affects ECC certs and not RSA (i.e. majority)
- doesn't affect firefox or chrome
But yeah, don't leave all your programming up to interns, MSFT...
Yep, not the doom and gloom everyone was preaching yesterday. Not only is it ECC only it is also only ECC when not using a normal curve. This is pretty easy to detect using snort, or a bunch of other network monitoring tools.
-Otanx
Quote from: Otanx on January 15, 2020, 09:10:01 AM
Yep, not the doom and gloom everyone was preaching yesterday. Not only is it ECC only it is also only ECC when not using a normal curve. This is pretty easy to detect using snort, or a bunch of other network monitoring tools.
-Otanx
Also only on Win10, from what I gather.
Why does it not affect firefox or chrome? IS it to do with the cert store of the application? Chrome uses the windows cert store. However firefox by default does not use the windows cert store. However in our organisation because I push certs via AD, I've instructed the users to use the windows cert store in firefox and other apps to avoid the browsers and apps complaining about non-secure internal applications (like jira / git etc). :twitch:
I read it was windows and server also.
Does this affect anything with cert delivery as part of 802.1x?
Our systems folks have been furiously patching. For once it's not a network issue.
:sitting:
It will affect anything that uses the windows crypto subsystems. It isn't the cert store, but the use of the crypt32.dll. Both Chrome and Firefox have their own crypto libraries. This could impact 802.1x. There are two ways...
1. The server validating the clients. This is probably the bigger issue. It could allow an unauthorized system on the network. Only an issue if the server doing your 802.1x auth is using crypt32.dll. Windows NPS for sure. Cisco ISE does not. Check with your vendor for confirmation.
2. The client validating the network. Not a major issue. Someone would need to already be on your network, and able to intercept the RADIUS traffic between the server and client. I also am not coming up with what doing this would buy an attacker.
-Otanx
If an attacker is already intercepting RADIUS traffic, it's either reading all the traffic on the wireless network, has a tap on the line from the switch/WLC to the RADIUS server, or - worst case - is somehow set up as a RADIUS proxy and can issue RADIUS-Reject commands and CoA commands.
But yeah, I'm with config t and Charlie Day. :)