1

Is it correct that TLS 1.2 prohibits MD5 as a Signature hash algorithm in X.509 certificates used? Is this just an SChannel + TLS 1.2 limitation?
Trying to find any webpage/documentation that is stating this explicitly in relation to TLS 1.2 or SChannel.
I've found the following in the TLS 1.2 RFC but I'm not sure if this is in relation to X.509 certificates or the TLS 1.2 protocol itself:

  • The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256.

  • The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash. Signed elements now include a field that explicitly specifies the hash algorithm used.

3
  • As far as I know, it has indeed been deprecated. But this seems a bit like an XY-Problem - why do you want to know?
    – user163495
    Commented Dec 10, 2020 at 21:18
  • 1
    The parts you refer to are not about use of MD5 as a signature algorithm in the certificate. I don't think that MD5 is explicitly disallowed at all for certificates in TLS itself. This deprecation happened independent from TLS and is also done for other uses of certificates. Commented Dec 10, 2020 at 21:32
  • 1
    @SteffenUllrich is right 1.2 doesn't affect certs. The sig-algs extension in 7.4.1.4.1, and CertRequest message in 7.4.4, include a value for MD5 and apply to both protocol signatures and certificate signatures. (Both of those are changed in 1.3.) No RFC has been published to alter this, unlike RC4 which was explicitly removed by rfc7465. OTOH CABforum Baseline Requirements do not allow MD5 signature in certificates used for HTTPS and codesigning, except some early versions allowed but deprecated it on roots where it isn't used for security. You certainly shouldn't USE it. Commented Dec 11, 2020 at 3:39

1 Answer 1

1

TLS 1.2 was defined in RFC 5246. That RFC does mention the use of MD5 as a possible hash algorithm and does not explicitly forbid it. However, that RFC has been updated by RFC 8446, which specifies TLS 1.3. That RFC modifies the requirements of TLS 1.2 and says the following of the SignatureScheme extension:

Some legacy pairs are left unallocated. These algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or negotiated by any implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST NOT be used.

It is therefore completely forbidden to use MD5 for a signature in either TLS 1.2 or TLS 1.3, and the IANA has removed these algorithms from the specified list, so they are no longer part of TLS. As a result, the server can't send certificates that use MD5 because “all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in [the client's negotiated] extension” and we've just established that MD5 is no longer valid in this extension.

It is also forbidden to use MD5 by the CA/Browser Forum, which regulates the Web PKI, although that doesn't prevent internal CAs from using it. In any event, responsible parties are not using MD5 for any purpose.

The part you mentioned from the RFC is a little different. In TLS 1.0 and 1.1, the PRF (pseudo-random function) used to generate session keys from the negotiated secret used a combination of MD5 and SHA-1. This use was not insecure, but it ended up causing practical problems for cryptographic proofs of the security of the function, and in any event, nobody wanted to keep using MD5 and SHA-1. As a result, the PRF was switched to use a single hash algorithm, which is much easier to reason about and model cryptographically, and avoids obsolete algorithms in favor or SHA-256 (or, in some cases, SHA-384).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .