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