1

Here is a link to a screen grab of SSL Configuration Checker by GlobalSign for my domain: SSL Configuration Checker: http://i.imgur.com/CbVjVee.png.

Following recent discussions with the host, they concluded:

To achieve "A" rating,we will need to enable "Forward Secrecy" and for that we need Apache 2.4.X. The current Apache web server installed on the dedicated server is : Server version: Apache/2.2.24 (Unix).

The certificate is free with the hosting.

But, it occurred to me that this free status might be irrelevant if it's Server Configurations that determines if TLS tests pass with an 'A'.

Question:

Is it the Server that primarily determines optimum TLS configuration as far as ssllabs.com SSL Checkers and such like are concerned?

If so, then:

Is it right to conclude that no matter what grade of TLS one purchases (e.g. Basic SSL through to expensive EV SSL Certificates) if the Server is not configured so according to recognizable standards such as disabling SSL 3.0, and enabling TLS 1.2 (Apache version permitting), the TLS will never reach A, A-, OR A+ when tested?

Considering the impact that Apache version has on 'Forward Secrecy', would this issue still be true even with an EV SSL Certificate?

UPDATE:

Link: SSL/TLS Deployment Best Practices

Steps taken to resolve (achieve acceptable Grade):

With the TLS v1.2 protocol, updated OpenSSL and recompiled Apache: Apache/2.2.29 mod_ssl/2.2.29 OpenSSL/1.0.1e-fips mod_bwlimited/1.4 mod_fcgid/2.3.9

After that, adjusted the ciphers anew.

Patched the server for the Poodle vulnerability by disabling the SSL v3 protocol.

2 Answers2

2

The server and the client are both important. SSLLabs.com has a client test, as well as a server test.

There are more details in the How does SSL/TLS work? question, but quite simply, the in the SSL handshake, the client is the first to send the version of TLS it supports and ciphersuites it prefers, and then the server selects the highest version it can support and the ciphersuite to use.

So, yes, server configuration is extremely important, but you can see that client configuration is critical too. Not only do you want to ensure that your client is capable of accepting (and prefers) TLS configurations that offer strong protection, but also that you disable weak versions and ciphersuites so that an attacker can't forcibly downgrade you to use insecure options for your SSL/TLS connections.

Xander
  • 35,525
  • 27
  • 113
  • 141
  • Immensely informative details there. So, the server will send the highest possible version according to the client's capabilities. Presumably, it's a case of the server being able to select and deliver the _highest version, down to lesser version_, according, in this case, to Apache version. Importantly, the highest version is dependent on the server (e.g. Apache version), regardless of type of SSL Certificate, i.e [Symantec](http://www.symantec.com/en/uk/page.jsp?id=compare-ssl-certificates). 'Forward Secrecy' notices would still persist even with EV SSL Cert on Apache/2.2.24. –  Oct 15 '14 at 23:56
0

The "grade" that you get from such tests is mostly meaningless. What kind of sense does it make to say that your server is "sort of" secure, but not completely ? Does it mean that attackers will still break in but won't be so smug about it ?

The important point about SSL security, of security in general, is that it often is all-or-nothing: the attacker succeeds, or not; there is little room for an attacker to half-succeed. In that sense, SSL server configuration should be graded only "F" (vulnerable to a known attack) or "A" (not vulnerable to any of the known attacks). Getting a "B" or a "C" does not mean anything for security; at best, it rates the efforts invested by the sysadmin, not the result.

Grades are there to woo auditors and managers who don't understand the point explained above. To a large extent, EV certificates relate to the same kind of public relations. EV certificates don't bring extra real security (because they don't fix an issue that is really exploited by attackers), but they show that the server owner was ready and willing to spend an extra hundred bucks on the subject of SSL. That's security theatre at its best (or worst, depending on viewpoint).

(And, of course, people who make a business out of selling certificates just love to sell EV certificates, since they do so at a much higher price.)


That being said: as @Xander points out, for SSL/TLS, the client suggests, but the server decides. So the server's configuration is what matters most, although of course the server will not decide to use anything that the client does not support.

The certificate type is mostly unrelated to the SSL/TLS configuration; however, it can still have a bit of influence:

  • Cipher suites that mandate RSA-based key exchange necessarily need the certificate to contain a RSA key.
  • To use a DHE cipher suite (to get so-called "perfect forward secrecy", which is good), the server must use its certificate-and-key to compute a signature. The certificate must then allow (or at least not actively disallow) use of the public key for signatures.

That the certificate is EV, or how much it cost, has no impact whatsoever on the SSL/TLS internal mechanics. But it may alter the "grade" that your server gets, depending on how much the configuration test designer sold his soul to the people who sell EV certificates.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • I agree, from what I've been studying (with a certain level of sincerity & humility) that these online test seem to ignore the subtleties that only a sys. admin worth their _bread & butter_ can appreciate. I know now that the type of certificate is irrelevant in common & typical scenarios (e.g. PCI compliance). What would Ivan Ristic say? I seek to learn by trial & be glad of small successes. GlobalSign: '_CBC and RC4 based suites should not be used ... clients & servers support must be updated to support TLS 1.1/2_'. As Qualys link above. –  Oct 16 '14 at 17:16