Ask HN: How bad is it to use a self-signed SSL certificate? | Hacker News Reader

Ask HN: How bad is it to use a self-signed SSL certificate?

56 pointsmark_l_watson115 comments

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

View on HN

If you are careful when generating your certificate (that is, careful to generate a subject certificate, and not a CA certificate) and can reliably distribute your certificate to all clients you are interested in, then self-signed certificates are usually much better than the public CA system.

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.

A site claiming to offer cryptographic security when it is in fact not is, in reality, worse than a site that simply doesn't offer cryptographic security. Both those sites --- the SSL site and the non-SSL site --- aren't offering security. But only one of them is also being deceptive about it.

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.

You have a point here. Perhaps the real solution is that we should make the browser throw a fit when someone tries to input a "password" into a page/authdialog that has no security as well.

Then the altered page just specifies that it is not a password field, and emulates it with javascript or whatever. So that could only work for sites where a password manager was used, assuming the user doesn't just go ahead and type it in themselves.

Not just passwords, any form submission. :P

you could simulate forms with JS and images. You dont even need to submit, once a user fills the form exfiltrate it through a JS image load, such as this http://www.lanmaster53.com/2011/05/stealth-cookie-stealing-n...

Unauthenticated SSL does provide security against passive attackers, which is what mass surveillance in developed countries is. If the NSA ever insists on widespread MITM of connections, we have much bigger problems.

I agree the UI needs to be properly worked out so that eg a bank can't be downgraded to an unauthenticated certificate.

I don't understand why they don't just use different colors for self-signed SSL connections.

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.

Well, it's not really a continuum. 'There should be only one mode, secure' and all that - asking users to make ad-hoc security assessments is generally a bad idea. In an ideal world, plaintext HTTP wouldn't exist and everyone would have a key delegated by their domain registrar.

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".

I think this is a good idea. It could be combined with a system similar to HSTS so banks could protect against MITM attacks.

I'd love to see something like SSH, you trust the self-signed certificate the first time, and then it's considered valid until it changes (but it should get treated differently from CA-signed certificates, your yellow padlock idea is great).

Then warn the user if the certificate ever changes.

That's the whole point: There's no way to determine "unauthenticated" SSL versus MITM SSL. Once you have that "worked out" then you've solved the issue of self-signing in the first place.

I think I have a good idea to solve this. What if a system similar to HSTS was implemented? https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security important sites (banks) could send a "don't allow self signed certs" header. Browser UI could change to educate users not to type personal information into self signed sites.

... Then an attacker MITMs the bank with a self-signed cert, and strips the "don't allow self-signed certs" header. Such a header would be literally useless.

HSTS already allows self-signed certificates, if the certificated is validated out-of-band.

But if a site is self signed the browser could show something like "This site is not authenticated, don't enter any personal info/passwords"

Right. It is questionable why self-signed certificates trigger scary warnings in browsers when totally unencrypted connections do not.

I think the whole UI aspect of web transport security needs re-thinking.

It's pretty simple: An unvalidated/unauthenticated certificate looks like a MITM. Requesting an HTTPS resource indicates you want a secured connection. If the certificate is not trusted, then you don't have a secure connection.

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.

I think if you try to responsibly design this feature in browser UI, you'll end up with the same problem.

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.

The idea behind HSTS is that the proper server commits to something for a significant period of time, making the later MITM fail.

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.

> If you are careful when generating your certificate (that is, careful to generate a subject certificate, and not a CA certificate) and can reliably distribute your certificate to all clients you are interested in, then self-signed certificates are usually much better than the public CA system.

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

Could whoever down-voted that please explain why you did so?

Wasn't me but I wonder about this: "Neither self-signed nor CA-signed certificates are securely authenticated...".

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.

Did you read the comment I linked to where I provided those details?

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

yes, this is my biggest problem with my favorite browser... why does Firefox do this? (Encrypted, unauthenticated: THE SKY IS FALLING.) edit: this is probably part of a NSL...

Depends what you want, if you want trust that you can only grant yourself, then go for self signed, especially internal projects.

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.

This is the right answer and it's too bad it was way down the page (I upvoted).

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.

Could you elaborate on what you find meaningful about the authentication a CA provides?

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.)

I meant that sending logon + password is somewhat pointless if it's plaintext over the internet, while if you have some encryption going on, someone intercepting the data in transit would have a harder time using it to trick the client or the server. In that sense authentication is more meaningful with a certificate -- even though using a CA still allows interception by a government actor. It narrows the range of those who can "break" the attempted security.

Well, a self-signed certificate still offers that encryption.

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.startssl.com/ gives out free SSL certificates. Just don't expect much on their part, given it's free. For example, they refused to reissue certificates for free after Heartbleed. Also you can't use them on commercial sites.

otherwise https://www.gogetssl.com/ is probably as cheap as it gets.

> For example, they refused to reissue certificates for free after Heartbleed.

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.

Thank you for the gogetssl.com link. I've been looking for a multi-SAN/wildcard cert that wasn't insanely expensive.

If you read startssl'a justification on the free cert, you'll see that they charge in relation to the time they need to spend. A low level 1 year cert involves no human time. They don't have fully automated systems for revokes/reissues, so it's pretty lame for people to complain about them charging for it.

That's perfectly fair and reasonable from a commercial perspective.

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.

That's understandable and probably a good reason for startssl to build an automated revoke tool, for the sake of keeping their name healthy. However, I would be way more concerned about a company unwilling to pay a trivial amount of money to revoke a cert that was compromises due to their own choice in how they used it. The best CA in the world won't fix bad security incident handling of another company.

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.

I'm surprised it's not a requirement of being a CA. Further speaks to the apparently weak standards the browsers have.

Not to mention their inscrutable information and documentation. I was caught out trying to renew a StartSSL cert 6mos ago and could not even access the renewal site. Apparently they use personal certs (or the cert I got?) as authentication? I don't know, because there was no explanation, anywhere. I had no idea whether this is security by obscurity or what, but f-them. I wound up paying $5 to Comodo and having a somewhat more comfortable experience, at least to the degree that there's a standard user control panel and payment flow.

Looks like maybe StartSSL filled out their FAQ a little since then, but only a little:

https://www.startssl.com/?app=25#10

They use browser certificates (I'm not sure if this is the right name), which is actually pretty cool. When you create an account, a certificate is generated in your browser, and then you can login with it.

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.

It's non-repudiation, it's so they can be sure that the person who received the email is also the person who requested the email.

  Proof of data integrity is typically the easiest of these requirements to accomplish.
  A data hash, such as SHA2, is usually sufficient to establish that the likelihood
  of data being undetectably changed is extremely low. Even with this safeguard, it is
  still possible to tamper with data in transit, either through a man-in-the-middle
  attack or phishing. Due to this flaw, data integrity is best asserted when the
  recipient already possesses the necessary verification information.

https://en.wikipedia.org/wiki/Non-repudiation

Yeah, I got that far, but I had reinstalled, not backed this up, and there was less than zero information about what to import. I tried installing and/or converting every chunk of certificate-type data I could find. No joy, no help, no nothing.

If your zones are signed with DNSSEC, just add a TLSA record for the self-signed certificates to the zones. Clients with DANE [1] support will then recognize that the self-signed certificates are valid.

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

Off-topic, but speaking of spurring adoption of DNSSEC: does anyone know of any good (dumbed-down) guides on setting up DNSSEC on personal domains / using dnssec-keygen? I keep seeing it mentioned in HN threads as a Good Thing, and I know my registrar supports it, but they have a big warning:

"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!

> I keep seeing it mentioned in HN threads as a Good Thing,

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.

Thanks for the link; that's actually very informative. My interest in DNSSEC came from reading that it provided a mechanism to securely transmit SSH host key fingerprints, though I'm not sure if there's a better way of doing that.

> As a small website owner, are you using TLS?

Yes, but I don't require it. Just a free certificate from StartSSL.

Try this https://translate.google.com/translate?sl=ru&tl=en&js=y&prev...

Also somewhat off-topic but interesting in the context of DANE and the cost of certificates. Brian Smith (a mozilla security contributor) recently said the following in a discussion about adding support for invalid/self-signed certificates to the Firefox OS e-mail app. The quote below can be found at the bottom of https://groups.google.com/d/msg/mozilla.dev.platform/lT4Mhi-... noting that I think the first TLS is meant to be TLD.

"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."

One thing that always confuses me is the plethora of options for buying SSL certificates.

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.

I think at some point I contacted support about that. It generally comes down to one of a few issues:

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)

It is 99% marketing. For all practical and meaningful intents and purposes, there are no differences. Go with the cheapest, unless you need the features offered by wildcard/EV.

It's terrible, because Man-In-The-Middle attacks are trivial and automatable.

namecheap.com sells PositiveSSL certs for $9/year -- that's pretty cheap and easy.

Thanks. I needed some encouragement. I will buy two PositiveSSL certificates today.

You might be able to use StartSSL's free one: https://www.startssl.com/

Just keep in mind that Class 1 (free) certificates are for non-commercial sites only.

Also, StartSSL's certs don't work on android (you get cert not trusted error) for some reason.

I haven't checked any recent Android trust stores, but this might be due to a lack of an intermediate certificate.

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.

That was the problem. Works well on my android now. Thanks!

Works for me - I have a StartSSL personal cert and an Android phone (Nexus 5 / KitKat), and all of Chrome, Chrome Beta, and Firefox load up the site without any sort of warning or other indication. I also dug out a Jelly Bean phone (Galaxy Nexus) to try with the stock Android Browser and didn't have any issues.

StartSSL has worked on Android since version 2.2, which was released 4 years ago.

Wow! This surprised me since https://www.startssl.com/?app=1 makes no mention of this, but indeed section 3.1.2.1 of the StartCom CA policy at https://www.startssl.com/policy.pdf does state:

"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.)

It isn't terrible advice, but it isn't good advice either. X.509's entire trust model is based on MITM. There is nothing wrong with a self signed certificate if all you want to do is encrypt on the wire.

The visible UI of a self-signed is admittedly terrible. The invisible UI of the Certificate Authority system is an outright catastrophe.

I agree with your answer, but I don't recall ever seeing a post mortem write-up of such an attack. Are people who have seen them in the wild all bound my NDAs or something?

I agree with your answer, but I don't recall ever seeing a post mortem write-up of such an attack.

So, if you know how MITM operates, tell me: How would the server operator ever know?

Reports of user data being compromised could lead to a consultant being hired to figure out where the security problem is, for instance.

(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)

Reports of user data being compromised could lead to a consultant being hired...

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.

http://www.scmagazine.com/researchers-detect-ssl-mitm-attack...

About 0.2% for Facebook is MITM. And they are not using self signed certificates.

I'm going to go out on a limb here and say that the vast majority of that 0.2% are people sitting behind corporate proxies with a fake CA cert installed and pushed out to workstations via Group Policy. A hostile (and targeted) MITM could remove or alter the JavaScript that posts the fingerprint back to the server in which case it would be very difficult to detect.

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.

> 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.

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).

The problem is that the people who can understand what you said don't ask questions about self signed certificates and the people who don't understand will somehow interpret this as support for using self signed certificates when you don't have an out-of-band method of getting your public key out. It's not harder to MITM a self signed cert when it's validty can't be verified which is 99.99% of the use cases where they're used...

> It's not harder to MITM a self signed cert when it's validty can't be verified which is 99.99% of the use cases where they're used...

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).

WiFi attacks are not necessarily passive, ARP poisoning can redirect a victim's traffic to your machine at which point you can MITM to your hearts content. If you have trained your users to ignore the inevitable security warning (Grandma isn't going to check an SSL fingerprint) they are going to be operating under the false assumption that their communications are secure. For most people this is a worse scenario than the NSA having their data.

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.

I see snooping as a lesser concern. For one thing the three letter agency snooping somewhere on the backbone can't even see the identity of the parties involved. They will typically see NATted IPs on both ends of some service provider. Once they decode the protocol they can get a little more information but at the end of the day the difference between knowing you established an SSL connection with respect to some static site and seeing the actual content of the page that you've viewed is IMO not a big difference.

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.

Not many postmortems on people discovering the NSA was reading all their email either.

Terrible compared to what? http? I don't understand why we get big scary warnings from browsers for self signed https, but never a peep out of them when submitting the same form over http.

Because encountering a site with a self-signed certificate likely means that the connection is MITM'd. In any case, with a self-signed cert you can't who you're connecting to.

CA-signed certificates do not mean that you are not being MITM'd. They are actually worse in that they give everyone (including the browser) a false sense of security that you have to pay for.

See detailed reply here: https://news.ycombinator.com/item?id=7826443

What could be achieved with a MitM attack on an information-only site?

Finding out what someone is interested in. Search queries or specific articles. Determining their browser information.

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 terrible, because Man-In-The-Middle attacks are trivial and automatable.

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

Ever mobile phone carrier makes themselves a root CA on devices they sell and routinely Man-In-The-Middle sites like Youtube.

Aw come on, all you have to do is let your users choose an icon of their favorite animal or sport, save that as an account preference, and show it to them while they enter their password. We don't need better certificate verification!

Yahoo did something very much like that about 5 or 6 years ago: inviting me to upload an image file, then telling me to make sure the image is present every time I log in.

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.

I think he was making a joke. Those pictures do nothing to prevent TLS MITM attacks.

I thought about this for a second, and what it does do is take an "offline" phishing attack and make it an "online" phishing attack that presumably has logs and can be throttled.

TLS means Transport Layer Security, and people would do good to remember it was not invented to be used in the HTTPs browser webserver configuration exclusively. For that particular application though, it doesn't make sense to use a self-signed certificate as you can't control the client side and modern browsers will raise hell.

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.

Self-signed cert is probably a bad idea in pretty much all cases. But implementing your own CA is a different story. And the answer to your question for your own CA is the usual - "it depends" :)

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.

Anyone interested in how certificates work in "the real world" should install Certificate Patrol (I think it's only for Firefox).

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

I don't know why you're bothering with SSL at all. Your use case is that your site is informational, it's intended to be open to anyone, there is no personal/customer information on it, and there's no authentication (everyone is anonymous).

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.

If only "important" traffic is https, then that narrows the search for them quite a bit, doesn't it?

By sending data in plain text, your users are revealing their intent to retrieve the content hosted on the site, even though that content is public.

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.

Good points, but I would argue that HTTPS provides little protection against this kind of access tracking.

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.

DNS and IP are not encrypted by TLS, right? So passive monitoring will see traffic to that site even if the specifics of each packet are encrypted.

If visits alone are problematic, it seems to me that the only possible solution is Tor.

As others have said - don't use a self-signed cert. When you do settle on a CA and config your SSL - this tool from SSL labs will really help. I used it today to identify and resolve a chaining issue. It makes sure you've done everything correctly.

https://www.ssllabs.com/ssltest/analyze.html

Certificates not just encrypt communication, they also tell that the site is really the one you think.

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/

I'm not a tech savvy person (at least around here) but I used Gandi to purchase my certificate. I paid 12 bucks and it was extremely easy to implement it. To give you an idea, I didn't even know how to enable access to my site without entering "www." in front of my URL. But getting the certificate and implementing it was so easy that I was actually surprised once my SSL was active. I was expecting to run into a couple of problems as I usually do when I deal with these sort of thing.

I'm using SSL for my personal website and it's not a commercial website.

I've got a couple at Gandi too, and I was pleased at how easy it was to set up. I used the free first year (included with a domain name purchase) but then went looking for the cheapest I could find. https://cheapsslsecurity.com/ sold me a simple domain validated cert for $19.96/5 years. That's the lowest I've seen but it looks like they raised their prices slightly since then.

Honestly, I don't mind that Gandi isn't offering the cheapest option out there. My domain and my host are from Gandi, so it was a no brainer for me to get my certificate from Gandi. I didn't even check the alternatives. If it was a hefty price, say, like $50/yr instead of $12, I'd have probably looked for other alternatives but I'm happy with them so far and I like to reward companies that serves me well as a customer.

We just went through this process at my startup. The gist of it is that if you self sign your certificate the user will get a warning say "do you trust this site? yes or no" -- this will lead to alot of people leaving. The best option is to get a cheap signed SSL certificate, godaddy has them for like 70$ a year. You can probably shop around a get them for cheaper. Moreover, if your using AWS, consider letting ELB (elastic load balancer) handle the HTTPS.

You should quit using them if anyone other than you ever needs to open the page in a browser. The warnings will never be good enough for partial clicking through of them. If a user (even a technical one) gets talked into clicking through an SSL error, it is likely that they have been talked into a bad habit.

It used to be pretty easy to install a self-signed certificate from the browser. Now it seems quite a bit harder--e.g., in Chrome you seem to have to export it to a file, I think? And in IE people say they can't even inspect a bad certificate, because the UI hides it entirely.

If money is short at the time you can also get a 90-day free SSL from Comodo. Good for testing and getting SSL setup or if you are tight on funds at the time it can get you started until you have the cash on hand to purchase the certificate.

I posted this Ask HN earlier today. Thanks for the useful comments.

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.

EDIT: I did go with CloudFlare: works great, and my site is loading faster. Seems worth $20/month.

They are pretty bad from a user perspective. Some of the browser UIs make it very scary looking to continue, if you can even figure out how.

If, as you say, just an information site, I would get rid of them immediately.

It's good, because you have control over the certificate creation, and never have to share your private key.

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...

> It's good, because you have control over the certificate creation, and never have to share your private key.

You will never have to share your private key when getting a certificate from a proper CA, either.

This is true, but you wouldn't believe the system-as-practiced by most large IT departments.

edit: small IT departments, too. nobody really pays attention as long as the lock icon is green.

Can't speak to the state of this on Linux, but on Windows/IIS if you "just follow the wizard" and send the generated file to your CA it will not include the key.

Some CAs offer a "service" that will generate the key and sign it for you. So you just follow the CA's wizard and never generate a key locally.

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.

My remark wasn't about the software tools, it was about the human processes around them. There are major knowledge gaps in every organization I've ever interacted with (hundreds) that use certificates.

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?

Is it worth adding HTTPS when you're running an internal app?

YOU ARE DESTROYING THE INTERNET

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.

In re: Jim Jones. That isn't cute.

It's still more secure than plain-text http tho.

Since there's no way to distinguish MITM and an unverified certificate, it can make people think they are secure when they are not. That's not "more secure".

Except for the fact that the CA system is centralized and easily corruptable, giving everyone a false sense of security. Yes, signing your cert gives you some protection, however let's not kid ourselves that any CA could be susceptible to payoffs or gag orders. It comes down to trusting some slimy security company. We need decentralized CA systems before we can kick back and think we're actually secure.

Reply on news.ycombinator.com