1

I'm trying to compare the connection security of two different websites. I'm going to be entering some Sensitive personal information into one of these websites, and, because I'm not familiar with this part of the banking world, I'm looking for some opinions on their security. I've checked the Connection Security on both websites and one seems a bit "behind the times". I'm also not an expert on this aspect of Information Security, but I have a general understanding.

Website A: TLS 1.0 AES with 256 bit encryption (High); DH with 1024 bit exchange

Website B: TLS 1.2 AES with 256 bit encryption (High); RSA with 2048 bit exchange.

Both Websites use HTTPS (obviously), however the browser Google Chrome and Firefox flag Website A as trying to run "unsafe scripts". I looked into it and it appears to be loading some Javascript and trying to import a google font over an unsecure connection.

Website B seems more secure because its using TLS 1.2, though my understanding is the security also has to do with implementation. I am also more familiar with RSA vs "DH" though I won't pretend to be an expert. I also don't want to fall for the fallacy of "bigger numbers = better". Website B is also part of a major credit agency so I feel more comfortable with them.

Thank you for any help you can provide!

EDIT: I ran both sites in ssllabs.com as suggested by user kaidentity. Site A got a C- and Site B got an A-. I'm still interested in hearing (and learning) more if anyone has anything else to add.

  • Don't forget that the website is little more than a shop window...what they do with the data in the background is where the concern should be (choice of protocol and ciphers could be in an indicator of IS maturity, but it is a long way form being a reliable indicator). – R15 Oct 6 '16 at 20:09
  • I totally agree. I scoured their privacy policies. I was using their connection security as a rough indication of where their heads are at when it comes to data as a whole. If I can use a metaphor - While its possible that the front door is bullet proof but the house is falling down, its more likely a falling down house would have a falling down door. – niquat Oct 6 '16 at 20:22
  • I don't disagree with your logic, but I would not describe either as having a falling down door. – R15 Oct 7 '16 at 7:10
1

Note that new versions of Google Chrome don't support DHE. I personally disagree with their decision, but they decided[1] that the case of a server with 2048 bit RSA and 1024 bit DHE is sadly much too common (especially sad is DHE using a common prime which many believe the NSA has precomputed to enable fast bruteforcing of the key exchange), and since you can't specify minimum strength of DHE during the handshake, for best results security-wise you have to try handshake with DHE, check the size of the parameters offered by the server, compare them to the size of the RSA key in the certificate, and then decide whether you want to proceed or retry without DHE to try to get non-PFS RSA key exchange (which itself might be disabled on the server forcing you back to use DHE). This "probing" handshake introduces too much latency (even if you cache the ciphersuite per domain+ip address pair). So they opted to just not support DHE and recommended everyone switch to ECDHE over NIST P-256.

So between 1024 bit DHE and plain 2048 bit RSA key exchange, with Google Chrome you get the same in both cases while with other clients you need to tradeoff the chance the adversary can bruteforce 1024 DHE (some people think currently only NSA can) vs the chance someone records all encrypted traffic, waits for the certificate to expire, then retrieves the private key for the expired certificate from a dumpster and decrypts all recorded traffic, a year or more after the fact. I would prefer to have PFS, but both options are bad.

I assume both sites have 2048 bit sha256 certificates with correct chains from decently reputable CAs, so no difference there.

If both use CBC cipher suites, and the clients are modern and have BEAST countermeasures making TLS 1.0 no worse than TLS 1.1, then they are about equally bad.

Site B which uses TLS 1.2 has the option to use GCM instead of CBC, which is especially important because the MAC-then-encrypt construct in TLS is ridiculously hard[2][3][4] to implement correctly. Does site B use TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256 or TLS_RSA_WITH_AES_256_GCM_SHA384? In case site B uses GCM, it is more secure than site A.

1 - https://groups.google.com/a/chromium.org/d/msg/security-dev/WyGIpevBV1s/68W-VMOoxqkJ

2 - https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/

3 - https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13

4 - https://www.imperialviolet.org/2013/02/04/luckythirteen.html

  • Someday I'm going to definitely understand everything you just said. I understood alot of it, and followed most of it. To answer your question, it appears that the Cipher its using depends on the Agent you're using to access it (makes sense). In my Configuration of Google Chrome or FF on Windows 7 or Windows 10 (depends where I access it from) its using TLS1.2 with TLS_RSA_WITH_AES_256_CBC_SHA. Interestingly IE11 in both cases uses TLS_RSA_WITH_AES_256_CBC_SHA256. – niquat Oct 7 '16 at 0:08
  • These stats are gotten from ssllabs.com. The versions of the browser they're testing against seem a bit older. Chrome 51 and FF47. I'd be using Chrome 53 and FF 49. Still its interesting that according to those tests that Edge and IE11 appear to provide a greater level of security. – niquat Oct 7 '16 at 0:11
  • Yes both sites RSA 2048bit SHA256 Certs. As far as reputable vendor, I don't know that I'm familiar enough with all the vendors out there to know this. Site A is GoDaddy, Site B is Entrust CA L1K – niquat Oct 7 '16 at 0:16
  • @IrishInsomniac there is no security difference between TLS_RSA_WITH_AES_256_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA256 because HMAC-SHA1 is as secure as ever (see security.stackexchange.com/questions/84304/…). Since both sites use CBC, they are about equally secure. TLS 1.0-only might suggest old unupdated software, so might be more risky, but if security patches applied, as secure as TLS 1.2 CBC. DH1024 vs RSA2048 is a tossup as I wrote in the answer. – Z.T. Oct 7 '16 at 0:23
  • Ah thank you for that. This has been very enlightening. If I'm reading these reports correctly through the lense of what you just said, it seems like Site A received a lower score by virtue of supporting older protocols. It looks like one of their concerns with the DH protocol was that using a Logjam attack you could downgrade the encryption and attack a DH key exchange. Sorry if this doesn't sound right, I'm at about the limit of my current understanding of this. – niquat Oct 7 '16 at 0:29
1

The TLS version and cipher suite are the relevant parameters for the connection security of a TLS connection. The information above doesn't show the full ciphersuite, e.g. the hash algorithm is missing.

However, instead of getting opinions from individuals here on this site you can get some kind of official rating of the quality by submitting the host name to the "SSL check" on https://www.ssllabs.com/. It will give you a rating (A, B, C) and checks a lot of stuff.

  • Thanks! I ran both sites. Site A got a C- for This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. ---- The server supports only older protocols, but not the current best TLS 1.2. Grade capped to C. --- This server accepts RC4 cipher, but only with older protocol versions. Grade capped to B. ---- The server does not support Forward Secrecy with the reference browsers. – niquat Oct 6 '16 at 19:00
  • Site B got an A- only getting capped for Forward Secrecy – niquat Oct 6 '16 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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