11

I have a server which hosts my own internal code among other things. Since it's only me using it, I've generated a self-signed SSL certificate and key, hoping that it'd give me a bit more security than just HTTP.

I would think that the main advantage of having a signed certificate is that someone else authenticates and verifies the certificate, ie: Verisign says that sitea.com is legitimate and certifies it. However, since I'm not so concerned about the entire world knowing that my site is valid, does a self-signed certificate still give me much better security than just raw HTTP?

If this is insecure, would a verified client-side certificate installed on my computers greatly enhance the security? I want this to be secure and if possible to not have to shell out a bunch of money per year for a site which only I by myself will be using.

Naftuli Kay
  • 6,715
  • 9
  • 47
  • 75
  • 3
    Self signed certificates use the same algorithms as the certificate authorities, so you get the protection of encryption. Related: http://security.stackexchange.com/questions/8110/what-are-the-risks-of-self-signing-a-certificate-for-ssl – Travis Pessetto Jul 10 '13 at 22:14
  • 1
    In short: Against passive attacker, yes. Against active attacker, no – copy Jul 10 '13 at 22:40
  • Sort of disagree: most CAs are ultimately self-signed. But they are subject to (or subject themselves to) a variety of things to 'enable' the world at large to trust them. If you are creating a PKI for your own purposes, and that PKI will not be used in anything user facing, then basically, you are as secure as your CA is (e.g. if you leave a key on a public site with a password of `1234`, then you probably shouldn't trust your own CA). For things that involve others not predisposed to trusting you, use a recognised CA - teaching people to accept otherwise invalid certs is bad for everyone – iwaseatenbyagrue Feb 28 '17 at 16:23

3 Answers3

21

Self-signed certificate means that:

  • You are still using SSL, so you use encryption, so you are defeating passive attackers: someone who wants to see your secrets will have to commit visibly to the effort, by mounting a fake server or a man in the middle attack.

  • On the client side, you can use "direct trust", i.e. specifically instructing your browser to trust the specific server's certificate. The first connection to the server is vulnerable to a MitM, but afterwards you are protected. See this answer for some discussion.

So yes, in many situations, SSL with a self-signed certificate is much better than no SSL at all. Of course, "better" and "good" are not the same thing...

A client-side certificate is about convincing the server of the client identity. A fake server is able to ask for a client certificate just like the genuine server, so no improvement here. A client-side certificate can help against MitM, though, if the genuine server is educated to require a valid client certificate (a true MitM is a double-impersonation: the genuine server talks to a fake client, and the genuine client talks to a fake server; if the server requires a client certificate, then half of the MitM won't work, namely the part with the fake client).

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 1
    `The first connection to the server is vulnerable to a MitM, but afterwards you are protected`. Of course, you're only protected on subsequent requests if the first connection was not attacked. It's not like you can just connect, trust the first self-signed cert you receive, disconnect and reconnect and have defeated the MitM. I'm sure you realize that; I'm just clarifying for other readers. – Paul Jul 17 '15 at 21:31
7

Well, it does give more security, if you trust that the entity that signed their own certificate is who they say they are. Since that's you, it's pretty straightforward, assuming you can be sure that nobody else has ever had unfettered access to that certificate.

Certificate signing by a public CA is a means to provide evidence of identity to more or less complete strangers that are trying to find the "real" Facebook, or Bank of America, or eBay. When connecting for the first time, or even the first time in a while, they can have no assurances that the IP address the DNS server returned is really correct. So, the server on the other end sends its certificate, matching the IP address to a name and providing proof that the data on that certificate has been vouched for by someone else, who in turn has a certificate that's been vouched for by a third party, and so on up to a small number of "trusted roots" that you simply have no choice but to trust if you are to trust anyone at all.

Since your server and your client can be "introduced" in a secure environment, where you can sit in a single chair in a single room, export a generated key file from your server's certificate store and import it into your client computer as a trusted personal certificate, with every machine, wire and thumb drive involved sitting right there in front of you, this "first time" connection actually happens offline. From then on, when you connect remotely over a network, you can verify the identity of your server, because it presents exactly the certificate your client machine was told to trust. This method is called "certificate pinning" and it is used all the time in situations like yours, where one computer you control needs to prove it's talking to another computer you control.

Once you've answered the trust question, the tunnel created for confidentiality between your two computers using a self-signed certificate is no different than one created using a CA-signed certificate. Your client asymmetrically encrypts and sends a request to establish a symmetric encryption channel of a specific type by using a predefined key exchange method, the server decides whether it wants to use that method, and if so it responds with encrypted information that allows the client to complete the channel on their end (or simply an encrypted acknowledgement, if the "key exchange method" was simply for the client to send the server the key they wanted to use).

KeithS
  • 6,678
  • 1
  • 22
  • 38
6

Is it more secure than HTTP?

Yes, it is. HTTP will be transfering your data via plain-text while a self-signed certificate will provide the protection by encrypting your data.

Do verified certificates provide more security?

Where I think not having a verified certificate may be a problem is with Man in the Middle attacks. If your computer doesn't know that the certificate is trusted, via an authority or already stored certificate, it is possible for someone to intercept traffic decrypt, read, and re-encrypt it using their own SSL keys and certificates. Of course if you have your certificate stored as trusted on the computer you're using it would show an alert if it was a man in the middle attack.

You will also want to make sure your private key is protected very well because you loose revocation that many CAs provide.

Travis Pessetto
  • 670
  • 3
  • 6