I see that some product are shipped with a default server certificate. I guess that a lot of these installed products still use the default server certificate in a real environment.

If your server certificate is known (eg. someone know which server certificate you are using and can download it), is your HTTPS still secured even if nobody can access your server(s) ?

In another point of view, is HTTPS or SSL with a 'public' server certificate can be called 'security' ?

  • If the default server certificate doesn't raise a certificate warning/error on the client when accessed, then the client is insecure even when you replace the server certificate with a proper certificate. TLS security relies in the client verifying the certificates properly. If the client is not warning the users of certificates that doesn't have trusted root, then you might as well just use no encryption. – Lie Ryan Mar 5 '15 at 1:18

To get terminology straight: the certificate is the public part. It is public so everybody knows it, and when a client connect to a SSL server, that certificate is one of the first things that the server sends to the client. What you mean is: when the private key is not really private, can SSL still be considered as "secure" ?

The answer is basically: No.

However, there are subtle details. When client and server talk to each other, they agree on a set of cryptographic algorithms to use, called the cipher suite. See the standard for (most of) the currently defined cipher suites. One of the elements of the cipher suite is the key agreement method used to exchange the "pre-master secret" from which all other keys are derived. When the cipher suite is a basic "RSA" suite (i.e. the cipher suite names begins with "TLS_RSA"), then the key agreement is basic asymmetric encryption with RSA: the client generates a random pre-master secret, encrypts it with the server's public key (from its certificate), and the server decrypts it to recover the pre-master secret.

When the server's private key is known to an attacker who merely eavesdrop on the channel, then that attacker can also decrypt the message from the client, obtain the pre-master secret, and decrypt all the data. It seems safe to say that, under these conditions, there is very little security left.

However, if the negotiated cipher suite is of type "ephemeral Diffie-Hellman" (the name begins with "TLS_DHE"), then the actual key agreement uses Diffie-Hellman with public/private DH key pairs which have been randomly generated on the spot. The server's private key (the one which is hardcoded and thus not very private at all) is used only to sign the DH public key. Under these conditions, a purely passive attacker, who merely spies on the data packets but does not interfere, will not be able to get the pre-master secret, and the connection will remain secure. This feature of DHE is called Perfect Forward Secrecy.

However, even with DHE, an active attacker can impersonate the server and mount a Man-in-the-Middle attack, voiding any security. PFS is an actual advantage only when considering the case of a private key ulterior theft, where the attacker steals the server's private key after the connection has occurred. At that time, it is too late for the attacker to be "active", and PFS locks him out. But this is not your situation: you envision a case where the attacker already knows the server's private key when the connection happens. The attacker can then mount an active attack.

So, to sum up: when the server's private key is known to attackers, then security is maintained only against passive-only attackers, and then only if the client and server agree on a DHE cipher suite.

(Strictly speaking, security can be salvaged even against active attackers if the cipher suite is DHE and the server requires a client certificate and the client private key is not known to the attacker. That's an edge case.)

  • Thanks - Ok it is not so 'bad' then. I thought the answer would have been more negative. About the DHE, is it widespread ? Especially for HTTPS Web apps nowdays ? – JoeBilly Aug 30 '13 at 21:50

If you use an SSL certificate where someone knows the private key, it could be possible for them to decrypt the data in transit between the client and server, assuming they can get access to the data (for example by sniffing the traffic going over a wireless network)

Also unless you use perfect forward secrecy if an attacker can get access to a stored copy of your transmissions at a later date and they have the server private key they will also be able to decrypt the transmission.

so yes if someone uses a server certificate (e.g. in an appliance) where it's shipped with the system there is a risk if they don't change the certificate. You'd hope that vendors would either advise a change of certificates in their documentation or, better, force it when the device is commissioned.

  • You are right, I am sure most vendor advise to generate your own certificate. However, I am pretty sure a lot of IT staff don't have the knowledge or don't want to spend time if the product is shipped with a working HTTPS out-of-the-box. My feeling is they think "HTTPS, it's ok". – JoeBilly Aug 30 '13 at 22:20
  • Absolutely, I'd agree, it's the same sort of problem as default crentials. If an IT department gets something and it works, they're inclined not to mess with it. – Rory McCune Aug 31 '13 at 10:47

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.