Earlier quoted context omitted.
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 su…
Mozilla SSL policy bad for the Web
81–89 of 89 posts
Re: Mozilla SSL policy bad for the Web
#82Earlier quoted context omitted.
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 su…
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.
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).
Re: Mozilla SSL policy bad for the Web
#83Earlier quoted context omitted.
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 doe…
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.
Re: Mozilla SSL policy bad for the Web
#84Earlier quoted context omitted.
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 doe…
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 peopl…
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.
Re: Mozilla SSL policy bad for the Web
#85Earlier quoted context omitted.
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 peopl…
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 stor…
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.
Re: Mozilla SSL policy bad for the Web
#86Earlier quoted context omitted.
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 stor…
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…
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.
Re: Mozilla SSL policy bad for the Web
#87Earlier quoted context omitted.
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…
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…
Re: Mozilla SSL policy bad for the Web
#88Earlier quoted context omitted.
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…
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.
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.
Re: Mozilla SSL policy bad for the Web
#89Earlier quoted context omitted.
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…
(2) is not a real problem; your browser won't let you hit a "rogue" SSL site without clicking through a scary warning.