13

My Chrome just complained from PayPal's security, similarly to this issue:

Google Chrome "Your connection to website is encrypted with obsolete cryptography"

The identity is verified, but it complains the cryptography is obsolete.

Says it uses RC4_128 with SHA1.

Should I be worried? Should PayPal be ashamed? Should Chrome stop scaring me?

UPDATE: Chrome was v 42 and after the update to v 43 the message stopped and now the certificate shows AES_256_CBC -- which, according to some of the comments, makes me believe that choice of using "RC4_128 with SHA1" was made by Chrome 42, not PayPal.

Bad Google: making people think the server is in the wrong, while it was your browser making the decision...

Community
  • 1
noderman
  • 407
  • 1
  • 5
  • 9
  • 1
    My Chrome (43.x) shows AES256 w/ SHA1, and I get the same message. Eventually everyone will be using SHA2, but I wouldn't be worried about it. – RoraΖ May 20 '15 at 15:42
  • Funny: is this decided by the browser? I thought the server would define what is accepted. – noderman May 20 '15 at 15:45
  • I mean "everyone" being server certificates and CAs. – RoraΖ May 20 '15 at 15:46
  • 2
    @cburatto The selected cipher suite is agreed upon by both the client and server, depending upon support and suite priorities. – Polynomial May 20 '15 at 15:47
  • @Polynomial: the client offers ciphers, the server decides based on this offer based on what the server thinks is best. – Steffen Ullrich May 20 '15 at 21:46
  • @raz: SHA1 as HMAC as in AES256-SHA1 is not the problem (yet), only SHA1 as signature in certificates. The obsolete part is not using a modern cipher (ECDHE GCM etc). – Steffen Ullrich May 20 '15 at 21:52
  • similar question: http://security.stackexchange.com/questions/87335/insecure-https-connection-to-reputable-companies-domains – craq Jun 14 '15 at 12:05

1 Answers1

24

This message is Google trying to push people nilly-willy into the 21st century of cryptography. So they point and mock when they see "RC4" or "SHA-1". This does not mean that such algorithms can be broken immediately. Only that Google would find the world a better place (or possibly a googler place) if everybody were using algorithms more to their liking, i.e. TLS 1.2 with AES/GCM.

In practice, there are a few "worries" about RC4 and SHA-1, though neither should prove fatal to your communications:

  • RC4 has known biases. These biases could theoretically be exploited to recover secret data, provided that the attacker can observe lots of connections (millions), all containing the same secret data at the same predictable place in the stream, provided that the secret appears early enough in that stream (because these biases get lower the further you go down the stream). The last condition is the one which is the biggest problem for an attacker trying to break through HTTPS; the interesting secret (HTTP cookie) appears relatively far in the HTTP header. To my knowledge, there has been no application of such attacks spotted in the wild so far.

  • SHA-1 has theoretical weaknesses with regards to resistance to collisions. No actual collision was produced yet; the theory (which is considered rather solid) is that building a collision would imply a computing cost of 261 function evaluations or so, i.e. substantially less than the expected 280 (for a function with a 160-bit output), but still too much to be casually contemplated even by academics with a lot of budget. Moreover, use of SHA-1 within TLS is through HMAC, which would not be impacted by collisions. There is no known weakness, theoretical or otherwise, in SHA-1 as it is used in SSL/TLS.

Paypal enforces RC4 because they want to avoid the perceived weakness induced by AES in CBC mode (so-called "BEAST attack" that no longer works in practice). They sure would prefer if Chrome was not claiming that they are "obsolete" because that may scare away customers; for a bank, security is important, but projecting an image of security even more. Customers must feel safe, or they will bring their money elsewhere (this is why most 19th-century banks were opening offices with very massive architecture, with granite columns and steel doors: to instill an inconscious feeling of solidity).

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 1
    Chrome actually shows this message for AES-CBC suites as well. The only suites you can use that *won't* raise this message are AES-GCM and ChaCha20-Poly1305 suites. – Xander May 20 '15 at 18:15
  • 2
    Well, I almost gave up accessing PayPal due to this message. It sounded like it was pretty bad. This a big deal, because the user might start considering real threats as false positives and ignore them. For example, next time I see the X-ed HTTPS protocol on the address bar while accessing PayPal, I'll probably not check the certificate like I did today. – noderman May 20 '15 at 21:01
  • It looks like Paypal gets [6 month certs](http://gyazo.com/7ba817be868fee85eddd276c49cc44bd). So they'll likely update the algorithms when they actually become old. – Neil Smithline May 20 '15 at 21:49
  • 1
    WRT RC4, it's Google's idea of implementing [RFC 7465](https://tools.ietf.org/html/rfc7465). – Compro01 May 20 '15 at 23:16
  • 2
    @NeilSmithline They could update the algorithms at any point in time; the algorithms used by an SSL server/client aren't dependent (usually) on a specific key. – Naftuli Kay May 21 '15 at 02:38
  • 2
    Note that in banning RC4, google isn't actually spearheading anything. That ciphersuite has been officially banned by the IETF in [RFC7465](https://datatracker.ietf.org/doc/rfc7465/) so they are just conforming to standards. – eltrai May 21 '15 at 13:29