Ask HN: How bad is it to use a self-signed SSL certificate?
I have a few "information only" (i.e., no customer data stored, no user logins) for almost 20 years that I just added HTTPS support for.
I did this after reading the EFF's "Join us on June 5th to Reset the Net" article and the two linked articles at the bottom of the page.
If any accesses my sites with HTTPS, they have to look at my certificate and OK it. A pain.
Ask HN: How bad is it to use a self signed SSL certificate?
Also, suggestions for the cheapest/easiest ways to get signed certificates?
BTW, I used this article for configuring nginx for SSL: https://www.digitalocean.com/community/articles/how-to-set-up-multiple-ssl-certificates-on-one-ip-with-nginx-on-ubuntu-12-04
117 comments
[ 3.0 ms ] story [ 176 ms ] threadnamecheap.com sells PositiveSSL certs for $9/year -- that's pretty cheap and easy.
The vast majority of modern browsers know how to find intermediate certificates online. Android's browser doesn't, for whatever reason. You have to bundle it on your web server.
"Class 1 certificates are limited to client and server certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature, when using high-profile brands and names or if involved in obtaining or relaying sensitive information such as health records, financial details, personal information etc."
Looking further, it appears that while these classifications are not formally encoded (that I can find after a cursory investigation; please let me know if I am wrong), it does appear to be the case that the concept/nomenclature exists amongst multiple CAs. Wikipedia context: http://en.wikipedia.org/wiki/Public_key_certificate#Classifi..., Indian Government CA policy: http://cca.gov.in/cca/?q=node/45
Thanks for pointing this out, as I have been erroneously indicating that the StartCom free certificates might be viable options in all cases, where it seems like the reality is somewhat different. (Although I still believe the barrier to usage of valid/non-self-signed certificates to be quite low and for it to be strongly advisable for server operators to use them.)
(edit note: inserted the missing word "been" shortly after submitting.)
The visible UI of a self-signed is admittedly terrible. The invisible UI of the Certificate Authority system is an outright catastrophe.
So, if you know how MITM operates, tell me: How would the server operator ever know?
(I'm assuming the site requires a login or perhaps even takes CC information - the kind of stuff a user might notice a third-party using)
So right there, there's a good chance that it wouldn't get reported and there's less of a chance that management would understand the implications and hire the consultant.
About 0.2% for Facebook is MITM. And they are not using self signed certificates.
The problem with Self Signed Certs in a practical sense is that they enable a much broader range of attacks. Neither of them protect you from LEO and NSA. Neither of them protect you from the people that own and/or can run code on your PC. CA issued certs will protect you from the carder that is connected to the same public WiFi, but self signed certs wont.
This phrasing is misleading. Self-signed certs will protect against passive attackers, assuming the certificate can be verified out-of-band[0].
If the validity of a self-signed certificate cannot be verified, yes, it could be issued by a MITM. But it still protects against passive attackers, and the NSA (so far) has predominantly been considered to be a passive attacker.
Self-signed certificates are arguably more secure against LEO/NSA, because (again, assuming the validity of the cert can be verified), it is harder to MITM clients without the server admin finding out. With a CA, they can serve a subpoena to a third party (the CA) and force them to present a compromised certificate as "valid". For the LEO/NSA to masquerade as the legitimate server, it would have to subpoena the server administrator.
[0] Which is always required with SSL. CA-issued certificates are also verified out-of-band, just indirectly (via the chain of trust).
No, but it's not easier, either - without verification, it's exactly the same. It's not meaningful to try and make SSL secure in the situation in which out-of-band verification cannot be done. If there is no out-of-band verification, all SSL fails to protect against MITM.
At the very least, it protects against passive snooping (ie, the NSA).
If you are talking about a thick client, with the appropriate checks built in, I'll agree that it's possibly more secure. Other than that, its only possibly more secure if you are the only user or you can eliminate the security warning (e.g. by distributing the certificate).
I'm skeptical that any US based company could get away with not rolling in the face of a subpoena/NSL so the protection provided by the service provider knowing they have been compromised is minimal IMO.
The bigger deal is the confusion it creates and the assumptions a lot of the users of self signed certs (and certs in general) make about security.
Lastly I want to point out that if your certificate is signed by some external entity that doesn't prevent you from doing out-of-band management of your public key. As long as your private key is secret you never lose any security by having your cert signed by a third party. People can argue about how secure that signature is vs. those agencies who can force the third party to reveal their secret key but while that's an important consideration, until the government sells my banking information to somebody I mostly care about this at a principle level.
See detailed reply here: https://news.ycombinator.com/item?id=7826443
If the site is particularly trusted (say, a news site), misleading users into trusting another party. If CNN ran an article about how adding some SSL cert to your trust store would make YouTube faster, a lot of people would do it.
Or you could directly attack the user by providing false information.
It's actually both terrible and the best security you can get.
- Terrible because today's browsers participate in a pay-for-insecurity model, where any CA certificate can be used to compromise any website on the internet (except for the tiny number of hard-coded/"pinned" certs that some browsers ship for their company's websites). Certificate Transparency only makes the problem worse [1]. Browsers currently have no way to securely verify either self-signed OR CA-signed certificates.
- It's the best security you can get because unlike certificates based on the aforementioned pay-for-insecurity "X.509 PKI" (public-key infrastructure), the security of a self-signed certificate depends on NO ONE except the issuer (i.e. _you_). Plus, they are 100% free.
I like to refer to today's X.509 PKI as "the internet's oldest backdoor" (about two decades old now [2]), because browser vendors have been aware of this problem for quite some time now and haven so far chosen to either do nothing, or make the problem worse (like with Certificate Transparency [1]).
Aaron Swartz wrote in 2011 that the solution to this problem is to use the blockchain [3]. I spoke with him about this at the time [4] and today am working on a project to bring that vision to life [5].
[1] http://www.ietf.org/mail-archive/web/trans/current/msg00233....
[2] http://lists.randombit.net/pipermail/cryptography/2014-April...
[3] http://www.aaronsw.com/weblog/squarezooko
[4] http://okturtles.com/img/Aaron_Swartz_Email.jpg
[5] https://github.com/okTurtles/dnschain
I upload an image file; the next time I found myself at Yahoo's login prompt, the image file was there; the time after that, it was absent. It has not re-appeared since.
Just offering a data point: I don't know enough to have an opinion about the technique.
The one catch is, as you noticed, the key has to be distributed. Depending on your goals, and your audience, this might be impractical, or within the realm of reason.
Here's a link that goes into more detail.
https://blogs.oracle.com/java-platform-group/entry/self_sign...
You will never have to share your private key when getting a certificate from a proper CA, either.
edit: small IT departments, too. nobody really pays attention as long as the lock icon is green.
I saw a sorta tech-savvy person doing this and they didn't see anything wrong with it. It's yet another thing that CAs should not be allowed to do but get away with anyways.
Most people setting up web pages simply have no idea what's going on with a CSR. It's all some weird files to them. Most of them probably think the key is included in the certificate the CA sends you.
For example: How do you get the private key to a second IIS server, if you are doing poor man's DNS load balancing with the same hostname?
If you want exposure of your certificates to common browsers and don't want to raise warnings in them, go for cert authorities.
But remember Snowden, certificate authorities are less trustfull than you can trust yourself.
For your situation, mark_I_watson, probably get a cert from a CA, the cheap "domain only" variety where you can verify your site to the CA simply by putting a file in the web root directory.
I say this assuming the content is whatever you were already displaying to the world without encryption - therefore low-security. The cert allows you to put meaningful authentication on your site (otherwise passwords go in plaintext, for example).
For a medium security level, sufficient for online money transactions, you would have to get a higher-assurance type of cert - this requires more money, sending business and personal ID documents to verify your business to the CA, etc..
For really secret communications - getting into a degree of NSA-proofing - among other things you have to avoid involving a CA, and preferably make browser certificates for trusted clients, to spare them the warnings that browsers throw up on non-CA server certificates. This is unsuitable for (legal) commerce (commercial payment processors would reject your business), and still vulnerable to metadata collection (unless you put it on TOR or equivalent), and still vulnerable to state coercion of private keys or forced code-trojaning.
Note that the third solution requires that your clients have a means of verifying that the site is yours rather than an imposter - you avoid a CA having the power to enable some other site to impersonate yours, but trusted users must have a basis for trust by a "side channel" such as knowing you personally, you being their employer, or reputation of your digital signature over time.
Another neat trick is creating your own CA, and putting your root into the local trust stores of client nodes that you care about. (Be sure to permanently airgap your root key, and create intermediate signers.)
None of my arguments about X.509 / CAs are about government actors in particular, though. There are enough root CAs trusted by the major browser vendors that breaches can (and have) happened with minimal resource expenditure.
https://www.ssllabs.com/ssltest/analyze.html
otherwise https://www.gogetssl.com/ is probably as cheap as it gets.
Not only that, but I believe they refused to revoke the certificates in the first place without payment. So if you don't pay up, even if you go buy a certificate from someone else or decide to use self-signed certificates, an attacker could still use your old certificate to MITM your website.
From a security perspective, however, I think you need to meet some minimum standards to remain credible as a CA, and I think at least being willing to revoke certificates that may have been compromised for free and very quickly is one of those standards.
I find it difficult to support retaining StartSSL certificates as trusted-by-default in browsers given their response to Heartbleed and the consequent relatively high probability that any certificate ultimately depending on them has been compromised.
Sure, most of the complaining was due to the entitlement, but I'd be interested in a list of all the companies that complained about this and/or failed to pay for a revoke.
Looks like maybe StartSSL filled out their FAQ a little since then, but only a little:
https://www.startssl.com/?app=25#10
The big problem is that since it's almost not used, browsers implement it but haven't done any job in making it user friendly (for example, you can see the certificates currently stored in your browser in Firefox by going in preferences > Advanced > Certificates > View Certificates > "Your certificates" tab, not exactly user friendly). Also (if I remember correctly) StartSSL implementation is not the nicest one as well, as you have to keep your tab open while they validate your account.
All adding HTTPS support will do is make it marginally harder for someone to spoof your site.
And why is NSA surveillance a concern? Your site is wide open for anyone to see, with or without HTTPS.
That in itself may be considered a breach of privacy, as it exposes your users to passive capture and profiling.
Also, accessing the content you are hosting might be considered legal in some countries but illegal in others, regardless of if it is public or not.
Even if the site is HTTPS protected, a surveillance actor on the net would still be able to read the entire site, maybe to determine if the site has content worthy of tracking those who access it.
And, surveillance would still reveal that your IP address is accessing the site, and thus triggering something.
What HTTPS would protect is the specific URL path you are going after on the site, because that's in the HTTP GET which is part of the encrypted data traffic.
I guess you could say that maybe the site has some pages that are more sensitive than others, and revealing the exact URL paths you are accessing might set off a surveillance trigger that would otherwise not be noticed. But, the site in question is probably not like that.
If visits alone are problematic, it seems to me that the only possible solution is Tor.
But actually achieving the pre-distribution step is pretty hard, and basically impossible over the internet. You can achieve it pretty well in a business setting, where you can push your certificates to all the clients through AD, MDM, or similar.
Sidenote: You should also take this opportunity to appreciate how dismally mis-designed web transport security is:
* Cleartext, unauthenticated: just works, no warnings.
* Encrypted, unauthenticated: THE SKY IS FALLING.
* Encrypted, authenticated: little padlock.
However, you'll get no argument from me if you constrain your argument about dismal mis-design to browser UI/UX. The browser UX design for TLS security hasn't meaningfully changed since Netscape.
I agree the UI needs to be properly worked out so that eg a bank can't be downgraded to an unauthenticated certificate.
CA-signed: Green lockpad
Self-signed: Yellow lockpad, with question mark superimposed over it
Regular HTTP: Orange, no lockpad (insecure)
Invalid or revoked cert: Red, "stay away" displayed within <blink> tags.
The current UI that most browsers present implies that self-signed certificates are worse ("scarier") than regular HTTP, which is not true.
No lock would suffice for unauthenticated https; those that find the distinction meaningful can investigate the URL. But then you still risk someone bookmarking https://example.com and suffering a downgrade attack from not paying attention to color changes.
The best way forward is probably the creation of a new protocol designator (httpz or something) that is SSL using the SSH key model. But there's no impetus to do this as it's easy enough to pay the CA tax and be on your way with unquestioned "full security".
Then warn the user if the certificate ever changes.
HSTS already allows self-signed certificates, if the certificated is validated out-of-band.
I think the whole UI aspect of web transport security needs re-thinking.
The criteria is not self-signed, it's trusted/authenticated or not. Most self-signed certs are not trusted, and solving that solves the CA problem. But if a self-signed cert is trusted then browsers happily display the secure UI without any errors.
User requests an HTTPS resource, which means the connection must be secure. The UA is unable to establish a secure connection, just as if a MITM attack was underway.
So, now, the user has just entered https://facebook.com. Currently, when this secure connection fails, the browser warns the user in no uncertain terms.
Your suggestion would be to what, exactly? Put a small, unobtrusive dot somewhere in the UI indicating "yeah, I know you asked for HTTPS, and I ignored that, but I didn't wanna really bother you"?
If you're responsible for user's safety, which may depend on the UA treating HTTPS as it should, then you've just betrayed your user.
And at any rate, by not aborting while verifying the certificate, you're already leaking potentially personal information: The URL, cookies, etc. So if you treat the user's data with respect, you don't go sending that insecurely after the user requested HTTPS.
And if you can't transmit the request, because you need to warn the user... you end up with a UI like browsers have.
In response to your previous post, the idea is that the user has to take some responsibility for their security (we can't stop them from entering their bank credentials into a friendly form on www.phish.com either), through a UI that makes it clear that the identity of the server is unauthenticated.
Indeed, and the blockchain (combined with a proxy like DNSChain), can be used to do this securely and for free at-scale.
> Encrypted, authenticated: little padlock.
Neither self-signed nor CA-signed certificates are securely authenticated, so the padlock is completely misleading.
See this comment for details: https://news.ycombinator.com/item?id=7826443
I'm no expert on CAs but saying their certs are not securely authenticated is worrying. Seems to defeat their purpose, no? Maybe expand on that point if you can as I don't understand how it can be true.
Here it is again: https://news.ycombinator.com/item?id=7826443
And if you want a longer version of that, you can go here: http://blog.okturtles.com/2014/02/introducing-the-dotdns-met...
> I'm no expert on CAs but saying their certs are not securely authenticated is worrying.
Yes. I'm glad we agree on that. :P
If, as you say, just an information site, I would get rid of them immediately.
I understand the difference between a single domain and wildcard SSL. But, as an example, what's the difference between Positive SSL and Essential SSL (2 types of SSL certs sold by Namecheap) - Essential being about 3x the price.
compatibility (mobile, different browsers, etc)
steps taken to verify (via phone, email, fax, proof of business registration, etc)
insurance (they'll offer various amounts of payment in liability insurance)
There are however many applications where a self-signed certificate (chain) is perfectly fine and even preferred. Think of mobile apps where you have control over how certificate validation is done on the client-side.
I'm using SSL for my personal website and it's not a commercial website.
In that sense self-signed certificates are mainly useful for small amount of people when you have another way to validate that the certificate is valid (i.e. installing it in person in the intended client devices). Else anyone could just create another certificate with the same human readable info.
There are some free or cheap enough certificates around that are already suggested, and other ways to validate certificates that may be useful even for self-signed ones, like http://convergence.io/
Training users, who have no way to properly asses this risk, to click OK to the SSL error, is like Jim Jones's practice runs drinking the Koolaide.
Firefox had it right when the briefly made it impossible to OK the use of misconfigured SSL.
Most IT people don't understand the risk of self-signed certs. We can't expect users to make good choices here.
Of course, very few clients support DANE as of yet. Nevertheless, that is the most modern solution and you'll spur adoption of DNSSEC and DANE if you offer it to clients.
[1] https://tools.ietf.org/html/rfc6698
"It is strongly recommended that you do not enable this option unless you have a good understanding of what it is and does: you could easily make your domain name inoperative."
which doesn't exactly inspire confidence, especially since most small website owners (such as myself) really don't have a good understanding of it!
Opinions on DNSSEC are... mixed, to say the least: https://news.ycombinator.com/item?id=5571937
As a small website owner, are you using TLS? That's the biggest single thing you should be doing - don't worry about DNSSEC.
This depends on what you mean by "small", but IMHO, you don't need DNSSEC. Depending on how small/important your website is, you probably don't even need to bother with DNSCurve either, though you might like to for the fun of it.
> As a small website owner, are you using TLS?
Yes, but I don't require it. Just a free certificate from StartSSL.
"Regarding DANE: Any TLS registry can apply to be a trust anchor in Mozilla's CA program and we'll add them if they meet our requirements. We can constrain them to issuing certificates that are trusted only for their own TLDs; we've done this with some CAs in our program already. Any CA can give away free certificates to any subset of websites (e.g. any website within a TLD). Consequently, there really isn't much different about the CA system we already have and DANE, as far as the trust model or costs are concerned."
I have decided to not use a self signed cert.
Another question: any comments on CloudFlare's auto SSL support on paid plans? $20/month does not seem too much for CDN and SSL support.
For an external web application/web service/API/... it is pretty bad. Users will run into certificate errors with their browsers or the code. Some will be smart enough but many will be scared away. Not good for your growth plans :)
For an enterprise web apps it is a completely different game. Pretty much you MUST setup your own CA (for example, it would allow you to spy on your employees - if you are paranoid about leaking secrets to competitors or press). The usability issue is not a problem since the laptop/desktop will be configured by the IT team anyway and they can setup the trusted certs along the way.
Lastly, for your internal mid-tier services (you are following SOA, right?) having your own CA would allow you to create as many certs as needed fast and "for free". Thus, you can easily implement cert based authentication and separate roles for different mid-tier/backend services. By implementing the usual security measures to protect private keys (including root CA keys), you actually get a much better security than using one "real" cert for everything. Again, configuration should not be a big deal since you are controlling internal services and network anyway.
You will quickly learn that certificates are 99% noise. Here are some observations:
1) ad sites present certificates, constantly changing. I don't care about them, but at the moment there is no way to tell Certificate Patrol to completely ignore certificates from a domain. The vast majority of certificates presented to a browser are from ad sites.
2) major websites use a plethora of constantly changing certificates. Quite often even the root signing certificate changes. Certificates change in days or weeks, not months or years as might be expected by simply looking at validity dates.
3) Some commenter [1] linked to an mitm paper written by Facebook people. It's enlightening. The paper also makes the point that while a certificate identifies a website, it doesn't identify a browser. So, even ignoring all the possible firewall MITM and malware, how can a website be sure that a user is who he says he is? Only half the problem is solved unless the user presents a certificate to the website. Most aren't set up for that.
[1] https://news.ycombinator.com/item?id=7826420