Hacker News Reader

Comment by fendale | Hacker News Reader

I don't fully agree with what you are saying. A self signed certificate DOES provide 100% cryptographic security, in that nobody sniffing on the the wire, or whatever open wi-fi I happen to be using can see my data.

Securing the connection from 'spies' is only one part of an general SSL certificates function - the other is proving the identity of the site you are connecting to. A self signed cert provides zero use here.

So a self signed cert has some uses - that said, perhaps its the more techy person who would ever care about encrypted connections but not identity, and they can probably work out how to get FF to accept their cert anyway.

View on HN

Would you like to bet your social security on that statement? I'll win that bet. If I can watch your packets on the wire, I can inject my own packets, or redirect you to the middleman of my choosing. If I can inject my own packets, I can sub in my own certificate. You won't know, because you're using self-signed certificates --- meaning, meaningless certificates.

If I can watch your packets on the wire, I can inject my own packets

You're certainly persistent, but this is not strictly true.

1. Major links that are sniffed, summarized by ASICs, and backhauled. These are necessarily passive, and public key ops are too expensive to do at this scale.

2. Service providers would take a lot of heat from both the public and banks themselves if they started proxying encrypted connections to insert ads or track browsing history.

If I can see your packets, I can sub in my own ARP (local) and DNS (remote) responses. In the absolute worst case, which never happens, I also see your TCP sequence numbers, and can simply inject segments directly. You have no hope of keeping me out of your connections. The "passive-only" attacker is a myth --- hackers don't use solsniff.c anymore.

Yes, I've used ARP spoofing to perform MITM attacks.

You seem to be ignoring that some established institutions are malicious these days. An ISP can happily track their users all day long, and perhaps inject some ads that the average user won't care about.

However, an ISP cannot routinely proxy SSL connections. As I said, such blatant tampering would cause too many complaints (at least at this time). And is a bank supposed to accept risk from the ISP proxy being compromised?

When the gloves are off and ISPs are inserting themselves that far up the protocol, I'll gladly say that crypto without PKI is absolutely useless. Until then, there is a class of passive only attacker. Perhaps you don't see this kind of attack as a problem, but some of us do.

It seems bizarre to me that someone would engineer a protocol that makes connections resilient against nosy ISPs, but not resilient against the lowest common denominator of organized crime.

Which is why I frown when I see somebody who wants to "dabble" in crypto by making their own cipher that probably "wouldn't stand up to serious analysis" (is there any other kind?).

But the protocol has already been engineered. Its a matter of handling certain a use case sanely rather than flipping out. An https connection with an untrusted CA has exactly the same absolute security as a plain http connection. Why doesn't Firefox throw up big warnings for every http page I visit?

Having said that, Mozilla could alleviate the situation by including CAcert in their trusted certs. Domain ownership assurance is really the only thing common SSL certs get you anyway. (And I've got no problem with "high assurance" CAs getting special indications).

I agree. An HTTPS connection with an untrusted certificate has exactly the same security as a plain HTTP connection. So don't use HTTPS without trusted certificates. It's confusing to end-users and, by instilling the click-through reflex, is damaging the security of the Internet.

It is vanishingly unlikely that Mozilla is ever going to include cacert.org among their trusted CAs, because hundreds of thousands of people use Firefox to access their banks, and there are plenty of smart security people that work at and with Mozilla.

The algorithmic security of unsigned HTTPS is the same as HTTP. Luckily, Mozilla already has a method of displaying such a page - leaving out the lock icon and colored background. There should be no "click through" unless you're proposing a user click OK for every http page they visit as well.

PKI is a hard problem, and CAs do it well for brick and mortar identities. However, that is certainly not the end of the story. The reason someone would choose to run SSL without paying for a certificate is that they believe most everything should be encrypted, but do not value the security properties provided by CAs.

You still haven't said why Mozilla should arbitrarily block the use of HTTPS in such a fashion. Should GPG prevent me from verifying a signature if it is not in my web of trust?

The only thing a basic SSL certificate (from one of the 47 (!) default CAs) does is guarantee ownership of a domain. This is exactly what CAcert does. Visiting paypal.com, I see the name of the company and country in green, from a higher assurance certificate where more thorough checks were done. This is what banks should be using.

You're steadfastly avoiding answering a really basic question:

If Mozilla "accepted" self-signed certs (to some definition of "accepted"), what should it do when someone browsing to onlinebanking.bankofamerica.com receives a self-signed cert that an attacker has spliced into the connection? It sounds like you want to make the warning for that condition less severe. Your browser cannot tell the difference between your personal self-signed cert on your own app, and an attacker's self-signed cert appearing on a BofA connection.

If the user is already interacting with onlinebanking.bankofamerica.com and the certificate changes, that's a serious error.

If the browser has a longer-stored certificate for onlinebanking.bankofamerica.com (say because they've bookmarked it), and the level of the certificate changes, that's an error.

If the browser has no idea about onlinebanking.bankofamerica.com (perhaps the user typed it in, probably without the https prefix), then the user must verify the security properties of the site. This is what a user must do now, as there may be no redirect to https, or redirect to an arbitrary https. If the site sends a certificate signed by an unknown CA, the user would not see a lock icon, blue background, green company name, etc.

I missed this comment because it's 4 days old, and I waste too much time here so that's like 5 clicks back through my comment history. But here's the answer to that: the first time you connect to a site, your browser has no certificate to "remember". People are unwilling to accept a security model that doesn't protect their first access to B of A, especially when a security model that does is available.

(And who knows if you'll get this. Interesting that HN fails at direct discussions)

The current usage model doesn't protect my initial access to BoA without me verifying that:

1. I've got a https connection

2. I haven't been redirected away to a rogue (SSL) site

You see the (https url)->(page retrieval) process as uniformly trusted (correct me if I'm wrong). I see stratification based on which third parties are doing the verification. Perhaps I'll have to wait for the emergence of a protocol explicitly designed for such things.

(1) is why browsers have a little "key" icon.

(2) is not a real problem; your browser won't let you hit a "rogue" SSL site without clicking through a scary warning.

Reply on news.ycombinator.com