Live data from Hacker News

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

news.ycombinator.com

111–118 of 118 posts

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

#111

Earlier quoted context omitted.

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.

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

#112

Earlier quoted context omitted.

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

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.

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

#113
post #14

Earlier quoted context omitted.

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!

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

#114

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…

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.

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.

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

#115

Earlier quoted context omitted.

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

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

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

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

#117
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

Post reply on HN