OK, so I'm a bit off base with the title - we don't get a vote, but that's a good thing!
Those last two I hadn't thought of until I read this article - I could see lots of organizations being vulnerable on application and ActiveX signing and not realizing it. (many companies don't realize that they are even using signed applications or controls!) The follow-on blog entry covers how to implement work-arounds to permit continued operation. Their approach uses (of course) certutil.exe, the command line certificate utility that is in all affected versions of windows. Find this follow-on blog here: Hopefully the impact of this change will be minimal. Remember that the 1024 bit keys in question are in the certificate, so these are the keys used to secure the initial authentication of an SSL conversation. These keys are not the used in the subsequent cipher that encrypts the actual data. Most of the public CAs (Certificate Authorities) all moved to longer keys quite some time ago, so support for weak keys within the certificates is likely a legacy issue, one that will mostly be seen on poorly implemented internal CA infrastructures. =============== |
Rob VandenBrink 521 Posts ISC Handler |
Subscribe |
Jul 18th 2012 7 years ago |
They haven't gone far enough. 1024-bit keys have a strength approximately equivalent to a 80 bit symmetric cipher.
What they should be doing is rejecting all keys less than 1024 bits, regardless of "signed date"; since the signed date could just be faked. AND reject all keys less than 2048 bits signed after the date of the patch. Then release another patch in 1 year, to reject all keys less than 2048 bits. |
Anonymous |
Quote |
Jul 21st 2012 7 years ago |
Sign Up for Free or Log In to start participating in the conversation!