4

I'm getting notifications of untrusted https connections on reputable domains such as paypal.com and skype.com. Since big companies like those probably employ the top security professionals and best practice, I'm inclined to think the problem must lie at my end, or in transit. Can someone advise me what I should do to narrow down the problem?

Here are some screenshots from paypal paypal firefox paypal chrome I find it interesting that FF and Chrome give different errors, and that Chrome shows up a green padlock in the address bar, despite the "obsolete cryptography".

And some screenshots from skype skype firefox skype paypal Note that this is not the login page (my browsers accept the https certificate there), it is the page where I want to top up my balance.

P.S. I want to reiterate that I'm not trying to blame Microsoft or Paypal. I'm inclined to trust them as corporations, and suspect that the problem lies somewhere else. On the other hand, I got in touch with both of their support departments a week ago, and have not had anything back other than an automated response.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
craq
  • 384
  • 4
  • 11
  • similar question: http://security.stackexchange.com/questions/89695/paypal-encrypted-with-obsolete-cryptography – craq Jun 14 '15 at 12:05

1 Answers1

6

Yes, www.paypal.com is really using RC4 as their preferred cipher, even though this cipher is considered broken for a while. It does support some better ciphers like AES256-SHA but unless the browser explicitly denies support for RC4 (like recent Firefox versions and IE11 do by default) it will use RC4. See also the analysis of SSLLabs.

Interestingly paypal.com (w/o the www) is a different server and supports the more modern GCM ciphers and also enables them by default. It will use RC4 only with older clients not supporting TLS1.2. See also the SSLLabs analysis.

Apart from that none of these servers support any ciphers with forward secrecy, which means if somebody gets hold of the private key of the server (by accident or by law) they can decrypt all the traffic they captured in the last time.

As for www.skype.com: they do support forward secrecy and use it by default, but they don't support any of the modern TLS1.2 AEAD ciphers and thus chrome considers the cryptography obsolete. See Chrome showing cryptography as 'obsolete' and Google Chrome "Your connection to website is encrypted with obsolete cryptography" for more information.

Note that using RC4 as the preferred cipher as done by www.paypal.com is considerable different from offering RC4 as the last resort for clients which don't support better ciphers. RC4 is considered insecure and RFC7465 from 02/2015 goes so far as to explicitly prohibit its use with all versions of TLS:

... However, RC4 has long been known to have a variety of cryptographic weaknesses, e.g., see [PAU], [MAN], and [FLU]. Recent cryptanalysis results [ALF] exploit biases in the RC4 keystream to recover repeatedly encrypted plaintexts. ... As a result, RC4 can no longer be seen as providing at sufficient level of security for TLS sessions.

In the context of www.paypal.com the cipher might probably currently still be safe enough, since not enough data with known plaintext will be transferred with the same key. When used for long-lived TLS based VPN tunnels it might be more problematic. Also, attacks only get better and NSA is known to have top experts in cryptography and might even have better attacks than known to the public.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • woah! So you're saying this warning is legitimate? i.e. these sites compromise security a little bit in the name of usability? My interpretation is that Grade B from SSLLabs is acceptable but not great? (Thanks for the SSLLabs link btw, I think that's actually the answer to my question, and where I will go if this issue comes up again.) – craq May 02 '15 at 17:11
  • For now I guess I will just live with the compromised security, but I think this raises a UX question: if a browser shows an insecure https connection, then that should be a reason to freak out. Users need to be able to trust that indication, otherwise they will ignore it. Maybe it would help if browsers implemented a traffic light principle? Green=optimal protection Yellow=adequate protection, but some stuff needs updating Red=insecure? – craq May 02 '15 at 17:14
  • 1
    "... these sites compromise security a little bit in the name of usability..." - I don't see the usability part here. It is possible to offer better security without changing the usability. I guess there is simply time and money involved, i.e. maybe they have some load balancer in front which does not support modern ciphers yet. – Steffen Ullrich May 02 '15 at 17:22
  • maybe I misunderstood part of the SSLLabs report. It sounded like they (paypal) were continuing support of RC4 because some older browsers weren't compatible with the 1/n-1 TLS encryption. Removing support of RC4 would cut off part of their customer base, which they might view as a usability problem.... or as you say, maybe it's just taking some time/money to upgrade their servers/load-balancers – craq May 02 '15 at 17:26
  • 2
    There is a difference between having RC4 as the last resort and preferring RC4. In case of the chrome connection a much better cipher would have been AES256-SHA which are supported by both sites, but the server of www.paypal.com decided to choose the insecure RC4. They might prefer RC4 instead of AES256-SHA because of the [BEAST attack](http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack) but all modern browsers have a mitigation against this attack so it would not make sense to use this together with TLS1.2, which they do. – Steffen Ullrich May 02 '15 at 17:31
  • ok great, thanks for that clarification. Just one last thing to ease my conscience - is my interpretation of the SSLLabs grade "B" correct, in that the encryption is OK for general use but vulnerable to an extremely well resourced attack (i.e. government scale)? If so, it might be good to add this to your answer. – craq May 02 '15 at 17:44