Peter Gutmann
2017-04-25 07:48:36 UTC
Microsoft's NDES implementation of SCEP has been broken in various ways for
many years, to the point where cryptlib fingerprints the server it's
connecting to and enables various workarounds for the different bugs to deal
with it.
However in Server 2012 there's a new, pretty major bug that can't be
transparently worked around: If you send in a message secured with modern
crypto, AES and SHA-2, it sends back an invalid response that can't be
decrypted. If you fall back to the twenty-year-old SHA-1 and the forty-year-
old DES/3DES, it works OK, or at leas as OK as NDES has ever worked.
There are two possible options to deal with this problem:
1. If Server 2012 is detected, quietly switch to the obsolete crypto
algorithms in order to connect.
2. Stay with the modern crypto and report an error.
What would people prefer for cryptlib? Silently switching to obsolete crypto
will make things work, and probably won't introduce any practical vulns
because to carry out an attack you'd need to be able to perform a real-time
break of SHA-1, and even then I can't imagine anyone bothering for SCEP, but
it does violate the implied contract that if you're set up for AES and SHA-2
you expect to actually use AES and SHA-2.
On the other hand reporting an error and stopping isn't terribly useful, it
just means you need to add an additional manual step of falling back to SHA-1
and DES yourself before continuing anyway.
The code currently reports an error and exits, but I'm trying to get a feel
for whether people think I should switch to the fall-back-to-old-crypto
behaviour.
Peter.
_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
many years, to the point where cryptlib fingerprints the server it's
connecting to and enables various workarounds for the different bugs to deal
with it.
However in Server 2012 there's a new, pretty major bug that can't be
transparently worked around: If you send in a message secured with modern
crypto, AES and SHA-2, it sends back an invalid response that can't be
decrypted. If you fall back to the twenty-year-old SHA-1 and the forty-year-
old DES/3DES, it works OK, or at leas as OK as NDES has ever worked.
There are two possible options to deal with this problem:
1. If Server 2012 is detected, quietly switch to the obsolete crypto
algorithms in order to connect.
2. Stay with the modern crypto and report an error.
What would people prefer for cryptlib? Silently switching to obsolete crypto
will make things work, and probably won't introduce any practical vulns
because to carry out an attack you'd need to be able to perform a real-time
break of SHA-1, and even then I can't imagine anyone bothering for SCEP, but
it does violate the implied contract that if you're set up for AES and SHA-2
you expect to actually use AES and SHA-2.
On the other hand reporting an error and stopping isn't terribly useful, it
just means you need to add an additional manual step of falling back to SHA-1
and DES yourself before continuing anyway.
The code currently reports an error and exits, but I'm trying to get a feel
for whether people think I should switch to the fall-back-to-old-crypto
behaviour.
Peter.
_______________________________________________
Cryptlib mailing list
***@mbsks.franken.deAdministration via Mail: cryptlib-***@mbsks.franken.de
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please