6

I don't trust certificate authorities, so I'm using a self-signed certificate on my server. The server provides both a website as well as other services.

Most modern SSL-capable software, upon encountering SSL, checks if the certificate is given by a CA and if not throws up a very scary warning. Contrary to Mozilla's logic, I believe that in my case a self-signed certificate is actually more secure, because it avoids the risk of malicious or incompetent CAs.

But let's say I want to give a friend access to my website or my server. Maybe I have a few photos on it from my trip that I want to show them: If I just give them the secure URI, their computer will also throw up the usual warnings. But since unlike me, they weren't the ones who configured everything, how will they know that Everything Is Fine™ (unless the fingerprint doesn't match)?

I could have a little notice in the HTTP version of my page explaining the error, and how to manually verify the fingerprint and make sure that Everything Is Fine. But:

  • If the connection was compromised, the attacker could just alter this notice to say "nah bro self-signed certs are totally fine, trust me".
  • If the user goes straight to the HTTPS URI, how will they know to check the HTTP version?
  • If the user uses a non-web service accessed through its own program, how will they even know about the notice?
  • If the user doesn't know how SSL works, they'll just believe their browser and close the site, instead of investigating why there is a self-signed cert (since unfortunately the documentation/UI authors' attitude seems to have been "there's no good reason ever").

So how can I ensure that when I send a user to my server, and they are confronted with the "self-signed certificate" warning, they are able to decide for themselves whether to trust it or not, instead of having to believe the skewed picture that their software paints for them?

I don't want to tell users to "just ignore the warning, it's fine", because not only does this reinforce a bad habit in general (what if their CA-verified bank gets compromised one day and presents a self-signed cert?) but also there would be no way for them to tell if my server is compromised.

Also worth mentioning is that the certificates are not forever, and eventually expire, so the user must be able to tell the difference between suspicious change of cert (say well before the planned expiration of the current one), suspicious change of cert that is made to look non-suspicious (a MITM executed just when I was scheduled to renew my cert), legitimate change of cert (when my cert expires and I issue a fresh one), and legitimate change that happens to look suspicious (I decided to issue a new cert way ahead of schedule for whatever reason).

We can assume that:

  • I have few users, so scalability is not so important. For instance, the users emailing me or calling my phone number to verify the certificate are perfectly valid solutions.
  • The users trust me and can communicate with me through a secure channel. For example, they can talk to me in person or send me encrypted email.
  • The users are reasonably intelligent, and can be expected to understand basic security concepts like "if the certificate changes unexpectedly, the site may have been compromised".

My main concern is dealing with less technical users, who would be confused when they see the self-signed certificate warning.

  • Although Steffen and Philipp have already answered you, I'd like to emphasize that you're asking for users to get out of their way to solve a problem that your own negligence / mistake / limited budget has caused. You should not issue invalid certificates, and if you do, you should be the one who bears the cost of configuring client browsers for them to recognise your cert (rather than take users' time to "educate" them about something they don't care about). If (for any reason) you can't implement security properly, you should take it upon yourself to make things right. – Steve Dodier-Lazaro Apr 22 '15 at 10:47
6

So how can I ensure that when I send a user to my server, and they are confronted with the "self-signed certificate" warning, they are able to decide for themselves whether to trust it or not, instead of having to believe the skewed picture that their software paints for them?

If you are not using pre-defined trust anchors (e.g. the root CA of the browser) you have to find a way to give your users the necessary trust information in a secure way. The preferred way would be of course personal, because any indirect ways like phone call or PGP signed mails need a pre-established trust, e.g. associating phone numbers or keys with you.

Also worth mentioning is that the certificates are not forever, and eventually expire, so the user must be able to tell the difference between suspicious change of cert...

In this case you have again inform the user about the change in a secure way.

The whole idea of the trusted CA in the browser is to start with some pre-defined trust and then defer trust information about other sites. This is similar to real life: you initially trust some people (parents..) and from them to learn trust other people. But once you abandon any initial trust settings you have to start from zero and thus find your own way to make your users trust you.

If you want to establish your own certificate as trusted you can only start with the existing trust relationships, i.e. friends which know you directly, know your phone number, your PGP key etc. These trust relations then must be used to transport the new trust into your certificate (i.e. fingerprint or similar). The best approach then depends on the kind of trust relations you already have to your friends and which one can be used as the best transport for the new trust.

  • Personally distributing trust info was actually what I had in mind: I could just give them the correct fingerprint along with the URI when I tell them to go there (but they may get confused) or I can tell them to just call me and check (but how do I get the warning dialog to say "call Superbest"?). I was wondering if there's anything more practical. – Superbest Apr 21 '15 at 9:07
  • As for your second remark, I don't have a problem with the web-of-trust model. I have a problem with who is at the base of the current version. If I personally knew and trusted the operator of a CA, I would have no problem just having them sign me. But unfortunately, I neither know nor trust any of the CAs out there. – Superbest Apr 21 '15 at 9:09
  • 1
    @Superbest: You could have two different websites; one whose URI you give them and one they are directed to from the other. – user49075 Apr 21 '15 at 9:10
  • 1
    If your users are meant to be returning users of your website, then a point to highlight would be to ask them to check the box asking the browser to "Permanently store this exception". By this way, the browser will internally link this URL to the self-signed certificate and be able to tell on future visits whether your website is still showing the expected self-signed certificate or if it has been changed (similar behavior as the 'ssh' command, for instance). – WhiteWinterWolf Apr 21 '15 at 13:21
  • 1
    @Superbest: there might be other scenario, however the point here is that the average user reaction, seeing a warning about a suspicious certificate, would be to uncheck the "Permanently store" box because he has been told everywhere to never save any suspicious document from Internet to his computer. However, in this precise case, the most secure posture is the opposite one and store the certificate. This may not seem obvious to a lot of people... – WhiteWinterWolf Apr 22 '15 at 9:53
3

Edit: The question author made significant edits to their question after this answer was posted. This answer is based on an earlier version of the question which gave the impression that they were asking about a usual public website.

You can not explain that a self-signed certificate is fine, because on a public website it is not! The other question you mentioned was about a different context: Using your own CA to sign your certificates and have a limited and known number of clients which trust that custom CA. From the perspective of the browser this is technically not different from using an "official" CA and it requires that the clients obtain the CA root certificate via a trusted channel. But with anonymous internet users, this is not possible.

No matter how much you distrust the CA system (and you have good reason to do so, but that's a different topic), using a self-signed certificate on a public website is even worse. Any MITM attacker could decode the communication, replace your certificate with their own and re-encrypt it for the user. Without a trusted 3rd party to verify the signature of the certificate, there is no defense against this. So there is no way to verify that indeed "everything is fine".

Providing the fingerprint of your certificate is pointless, because you have no way to send it to the user in a way which can not be manipulated by the MITM attacker. A https website can be manipulated as previously described, and a http website is even easier to manipulate. The attacker could just replace the fingerprint on the website with that of their own.

There is hope that one day a better system like DANE (which moves the trust role to the DNS system) will finally replace the flawed CA system, but until then certificate authorities are still the best solution we have.

  • Sorry for the drastic edit! Your note about having no way of sending the fingerprint securely must refer to the earlier version where I failed to point out that I do have an alternative secure channel of communications with the user. In that case, you are quite correct. I expressly specified that I have a secure channel (eg. phone call or encrypted email) to avoid that caveat. The question isn't "how to get the fingerprint to user". The question is, how to make sure the user knows to call me and ask about the fingerprint, instead of just giving up and closing the browse window. – Superbest Apr 21 '15 at 16:47
  • @Superbest: You could use my comment to Steffen's answer. – user49075 Apr 22 '15 at 1:32
2

When you have secure(!) contact with all of your users over a different medium, you can send them the root certificate of your own certificate authority which you used to sign the certificate of your website and give them instructions how to add it to the list of trusted certificates of their web browser (or maybe even a handy install script which does it automatically).

When they did this correctly, the website will no longer appear as self-signed in their browser. The browser will instead treat it like if it were signed by any other "real" certificate authority.

This, of course, does not protect your users from a rogue CA which creates a false certificate for your website, because common web browsers do usually not support CA pinning (telling them to only trust one specific CA for a specific website).

You should also make your users aware that this means that you now can also impersonate other websites they visit, so it requires a large amount of trust. This problem is also not fixable, because currently there is no such concept as a CA which is only trusted for specific domains.

Thankfully, this problem might one day be solved with DANE which puts the DNS servers into the role of the certificate authorities. You will then be able to distribute your domains TLS certificate by the DNS server which is responsible for your domain (and only that one). But currently there are no browsers which support it out-of-the-box, and considering that there are several companies which have financial interests in keeping the CA system (which is practically a money printing license sold by browser developers) it might take a while until it takes off.

  • 1
    Not an expert in certificates, but I seem to believe you can now tell browsers to cache the last working certificate for your site and issue a warning when a different certificate is encountered instead? I really can't remember the name of the protocol that performs this, though. – Steve Dodier-Lazaro Apr 22 '15 at 10:43
-3

The Best approach (for the use case of a limited user group and a personal website) I use is to have a non secured page somewhere where my users can download the root certificate (my own CA) and find instructions how to install that into there trust store. this way the computer can trust my 'self-signed' certificate.

one of the headaches with this approach is that for windows or mac it usually suffices to put it in the systems key-store application. on Linux / UNIX most applications have there own certificates store. And sometimes browsers have there own store. I usually solve this by offering my users (remote) help installing the certificates and putting it on all the right places.

but with a user group of less than 100 people this is feasible.

as to your "more secure" remark. It is impossible to say its more secure. Those other CA's have regular audits. I doubt you have the time / money to be audited like a CA. so we simply do not know if your more secure.

  • How do the users ensure the root cert is secure? Couldn't an attacker simply issue their own root cert? The caveat of small groups is very apt - I'm assuming that I will never have to deal with so many users that I can't personally provide support if necessary. – Superbest Apr 21 '15 at 8:54
  • Also, about security: It's not that I believe I'm safer than the CA. However, I prefer trusting only my own security as opposed to trusting my own security AND the CA. – Superbest Apr 21 '15 at 8:56
  • 4
    heh,heh,heh,hahahaha. That certainly is "The Best approach" for Lawri; it would let him MitM connections without needing to subvert a CA. – user49075 Apr 21 '15 at 9:02
  • The page where you can get my root certificate is on a read only part of my webserver (as my nginx sees it anyway) and it also has MD5 / SHA1 / SHA256 / SHA512 signatures for it, as well as the "certificate signature" and instructions how to check any of them. The same page is also protected by my own Ca (on a https part) , as a means for the user to verify the root certificate is installed correctly. – LvB Apr 21 '15 at 9:02
  • 1
    @LawrivanBuël As a MITM I can easily manipulate your non-secure part of your website to serve my certificate instead of yours. I now also control the TLS-encrypted version and can replace all references to your certificate (like signatures, fingerprints etc.) with those to mine. – Philipp Apr 21 '15 at 16:02

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.