14

A guide on this site on how to make a decent Certificate Signing Request (CSR) says that I should be using SHA-2 certificates to secure a HTTPS webserver.

Are SHA-2 certificates considered obsolete, or current for TLS/SSL website certificates (as of 20th November 2015)?

If they are, what should I be using to secure TLS/SSL/HTTPS on my Apache2 webserver instead (as of 20th November 2015)?

And where can I find a authoritative source of current information concerning obsoletions of this sort?

Community
  • 1
leeand00
  • 1,297
  • 1
  • 13
  • 21

2 Answers2

40

"SHA-2" is the traditional codename for a family of six functions that includes SHA-256 and SHA-512. These functions are considered completely fine and current and non-obsolete.

There is a newer family of functions called SHA-3, but it has been formally defined only very recently, and nobody really supports them yet. Moreover, SHA-3 is not formally defined as a replacement for SHA-2, but as an alternative.

All the current fuss is about an older function called "SHA-1", not "SHA-2" (and most of the panic is greatly exaggerated).

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    Great answer! But where do you go to find these things out? What feed of authoritative information do you get this information from? – leeand00 Nov 20 '15 at 16:26
  • 36
    Thomas **is** the authoritative feed :-) – Rory Alsop Nov 20 '15 at 16:27
  • 196k rep on a serious SE site is authoritative. @leeand00 – Mindwin Nov 20 '15 at 19:15
  • 4
    I don't mean to offend Thomas, what I'm referring to is who releases this sort of information. Even if Thomas is the guy who writes the code for this...(I don't know if he is or not) but is there an organization that will do a news release or a mailer or an RSS feed that says, yes this is the new security algorithm that is safe, or this number of bits is no longer safe? – leeand00 Nov 20 '15 at 19:28
  • 3
    @leeand00 - Ultimately there is no such single organization. Would you trust it? Everyone trusts someone higher up the expertise chain, and specialists follow a large number of sources without necessarily trusting them, but rather forming their own understanding of the "demonstrated" or sometimes just "potential" vulnerabilities. Furthermore, you can (these days) verify that something is broken, but not that something is safe. So a "safe algorithm" is one that isn't widely known to be broken or much inferior for the same kind of application. – Jirka Hanika Nov 20 '15 at 19:52
  • @JirkaHanika Well what about using something like `Qualys SSL Labs` to test for known vulnerabilities? – leeand00 Nov 20 '15 at 20:15
  • In practice, most recommendations for crypto algorithm usage come, directly or indirectly, from [NIST](http://csrc.nist.gov/). Various government bodies (from various governments) tend to edict their own rules, but most of the time they just copy whatever NIST says, with some local, mostly cosmetic variations. – Thomas Pornin Nov 20 '15 at 21:16
  • @ThomasPornin I think the "panic" about SHA-1 is about avoiding a repetition of what happened with MD5. MD5 remained in mainstream usage for 4½ years after the first published collision. As of today producing a SHA-1 collision through brute force is possible though very expensive. Presumably the value of a SHA-1 collision is less than the price it would cost to produce one. – kasperd Nov 21 '15 at 12:15
  • @kasperd: certainly the value of *publishing* a collision is less than the price of producing one ;-) – Steve Jessop Nov 21 '15 at 13:50
  • @SteveJessop If you mean value to whoever publishes it, then you are most certainly right about that. If we instead consider the value to society of such a collision being published, then that is something which is very hard to measure. – kasperd Nov 21 '15 at 14:27
  • Related: A cryptographic hash called BLAKE2, considered for the SHA-3 family is now [RFC 7693](https://tools.ietf.org/html/rfc7693) "[BLAKE2 hash authors post code as RFC Strong, fast, but NIST is wary](http://www.theregister.co.uk/2015/11/09/blake2_hash_authors_post_code_as_rfc/)" – David Tonhofer Nov 21 '15 at 23:25
  • @kasperd: note that while MD5 is thoroughly broken, it would still be mostly safe when used ins SSL/TLS, or for signing certificates. Leveraging a collision attack to get a fake certificate has been demonstrated once, but requires some specific conditions (in particular predictable serial numbers) that no longer apply to any decent CA. Thus I am not overly worried about continuous usage of SHA-1 in SSL/TLS and in certificates. – Thomas Pornin Nov 22 '15 at 14:19
  • @ThomasPornin If it was mandatory for the signatures used by TLS to include some random bytes in the data to be hashed, you might have been able to convince me. But since that is not the case, I consider phasing out SHA-1 to be a good idea. – kasperd Nov 22 '15 at 14:41
  • 1
    In the signatures used by TLS, it _is_ mandatory to include some random bytes in the data to be hashed -- the "client random" and the "server random" are part of that data. (To be precise, in ECDHE, the server ECDH parameters are signed by the server and do not include randomness, but this is server-chosen data signed by the server itself, so collision attacks do not apply there; for DHE, and for client authentication, random values from both client and server are part of that which is signed.) – Thomas Pornin Nov 22 '15 at 14:48
  • Of course, none of this means that MD5 should not be phased out; only that MD5 usage in SSL/TLS is not as much a vulnerability as it is often assumed to be. And SHA-1 even less so. – Thomas Pornin Nov 22 '15 at 14:49
  • I've just had to write a document in response to the SHA-1 panic that looks at the possible real-world effects when used with certs. For browser PKI, it's mostly a non-issue, your server switches from a SHA-1 cert to a SHA-2 cert, your browser accepts it as before (and at some point will reject the SHA-1 cert), and all is fine. For client auth, an attacker would need to be able to forge the auth (create a collision) in real-time, so even the more or less totally broken MD5 is fine, the cert forgery that was done there used a huge amount of precomputation. – Dave Apr 28 '16 at 16:18
  • (continued) The real reason for the panic is that if an attacker can create a collision affecting a CA certificate, the whole browser PKI house of cards will collapse (or at least collapse even more than previous CA compromises have caused it to do). This is why the browser vendors are so keen to move everything to SHA-2, an attack on a single SHA-1 browser CA cert will break the entire browser PKI. For everyone and everything else, it's much, much less serious. – Dave Apr 28 '16 at 16:22
20

SHA-2 is currently good. It is SHA-1 that is deprecated:

Due to the insecure nature of the SHA1 algorithm, it is good practice to replace SHA1 certificates with SHA2 certificates as soon as possible. (Check SHA2 compatibility first). But for practical reasons, the process will generally need to be staggered to occur within the critical dates promoted by Microsoft and other vendors.
Your plan should replace SHA1 SSL certificates in the following order:

  • certificates with an expiry date of 1 January 2017 or later.
  • certificates with an expiry date between 1 June 2016 and 31 December 2016, inclusive.
  • certificates with an expiry date before 1 June 2016.

No expiry date has been determined for SHA-2.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320