Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Many browsers and Internet companies have recently claimed that SSL Certificates with a signature algorithm of SHA1 will imminently no longer be considered secure. Most notably, Google and Google Chrome.

Yet I've read that since the SSL/TLS negotiation and Cipher Suite don't make use of plain SHA1 (or even MD5), and instead use SHA1 within an HMAC; that using a Cipher Suite with SHA1 is still an acceptable security practice.

Is this the case?

While we're on it, is it also the case of using MD5 in a cipher suite?

share|improve this question
    
Just as a side note, imminent and immanent are very different words. You used the wrong one by mistake. –  hobbs Sep 23 at 23:40
    
To be honest, I don't think I had ever realized. I updated my post to include the correct usage "imminently", rather than immanent. Thanks for the heads up, hobbs. –  Eddie Sep 24 at 20:35

1 Answer 1

up vote 6 down vote accepted

The main thing that makes HMAC secure in typical use even with MD5 is that it is used with a secret key. That means only preimage attacks are really relevant, since finding a collision is always an online attack if you don't know the key. With known attacks the preimage resistance of both MD5 and SHA-1 is > 100 bits. Additionally, HMAC may be secure even with some insecure hash functions.

However, not all cipher suites just use HMAC for message authentication. Older SSL cipher suites (before SSLv3) use plain hash functions for that. Hash functions are also used in many suites as message digests for public key signatures. Is that secure?

Well, yes. Probably. Again, only preimage attacks should apply to the ways they are used in SSL/TLS. A collision attack would require generating a large number of messages to find a pair with equal hash values. That is only a concern whenever the attacker can both predict the data to be signed and influence some of it. E.g. signatures are used for key exchange, where they are used to sign random keys, which the attacker cannot know much less influence.

Still, attacks only get better. Where using more modern algorithms is possible, you should do that.

share|improve this answer
1  
SSLv2 used a keyed hash for MAC, but not a doubled one as HMAC uses to block length extension. SSLv3 and all TLS all ciphersuites use HMAC, except the authenticated-encryption ones (GCM and CCM) added in TLSv1.2 that don't need any separate MAC. –  dave_thompson_085 Sep 24 at 12:27
    
Interesting. Let me make sure I understand. SHA1/MD5 to sign SSL Certificates is not secure because an attacker knows the starting text (is Plaintext still the appropriate term?) that generated a particular digest. Whereas with SSL/TLS (3.0+), since the starting text is encrypted HTTP data, it isn't known and therefore finding a collision against the HMAC Digest in the packet is much, much more difficult? If that is the case, since SSL/TLS does Encryption and then HMAC'ing, isn't the "starting text" simply the cipher text in the application data record, and therefore already known? –  Eddie Sep 24 at 22:04
2  
@Eddie not really. First, SSL/TLS (except AE) does MAC-then-encrypt, which is today unpreferred (there are other Qs on this) but was liked ~1990. Collisions are a concern when an attacker can choose (enough of) the signed data, and X.509 certificates can allow that. For SSL/TLS data HMAC even if data is chosen the (prefixed) key is not, and (as otus pointed out) for the signatures used in some handshakes the data is independent of an attacker and well randomized. –  dave_thompson_085 Sep 24 at 23:32
    
Ahh yea. This morning I woke up thinking about this question and I realized I had the order wrong with TLS/SSL, I was studying IPsec and I had the orders confused between the two. Either way, I think you're answer (@dave_thompson_085) and @otus 's edit clarified things for me. Thanks for your help! –  Eddie Sep 25 at 13:40

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.