Hacker News Reader

Comment by cjbprime | Hacker News Reader

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.

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

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

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.

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.

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

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

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.

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!

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

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?

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

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.

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.

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.

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

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.

Reply on news.ycombinator.com