| |||||||||||||
Gathering session cookies with FiresheepGathering session cookies with FiresheepPosted Nov 4, 2010 16:06 UTC (Thu) by gerv (subscriber, #3376)In reply to: Gathering session cookies with Firesheep by nye Parent article: Gathering session cookies with Firesheep
I am saying that neither the security of telnet nor the security of SSH (when you don't bother to check the key fingerprints) is sufficient for people to do online banking or shopping. At the moment, "secure UI and no warnings" in a web browser means "safe to do online shopping and banking". If we switched to an SSH-style key change detection model for web site security, then "secure UI and no warnings" (it is the warnings you want to get rid of, isn't it?) would no longer give that safety. If that's the case, then it's clearly a bug. These situations are entirely orthogonal. Not so. Say you run a website which uses a self-signed cert. Your website gets compromised. You clean it up and start it up again, with a new cert (the old private key is known to the attacker, after all). Or perhaps your cert just expires. Either way, you change the cert. The user gets a warning saying "the cert has changed". What do they conclude? "Someone is trying to MITM me" or "the site admin just updated the cert"? Which would you tell them to conclude? How would you tell them to decide? In the CA model, as long as both certs were signed by a trusted CA, the user gets no warning in the safe case, and a warning in the unsafe case (because the attacker can't get a CA-signed cert for the domain). I don't really care, If you don't really care that Joe Public gets MITMed, then I don't think we are working from the same base set of assumptions, and it's unlikely this discussion will be fruitful. For me, I'm trying to stop Joe getting MITMed, as are the rest of the Mozilla security team. If you don't care, then we clearly have different security goals. Feel free to create your own browser which meets them. Gerv
(Log in to post comments)
Gathering session cookies with Firesheep Posted Nov 4, 2010 18:11 UTC (Thu) by paulj (subscriber, #341) [Link]
Why not make the UI for self-signed certs equivalent to plain old HTTP? That is, make no UI claims the page is secure; don't do anything UI wise that Joe User could perceive in fact.
Have an option somewhere unobtrusive to allow the (few) users who care to check the details of the cert.
What possible security objection could you have to that?
Gathering session cookies with Firesheep Posted Nov 4, 2010 20:17 UTC (Thu) by Simetrical (guest, #53439) [Link]
Because then when an attacker stages a MITM attack against your bank's website, you get no notification except the absence of HTTPS UI, which no one will notice. Whereas at present, if your browser starts to connect to an https:// URL, there's no way for anyone to stage a MITM attack without triggering a warning message.
(Of course, if your browser starts to connect to the http:// URL, like because you just typed the domain name without protocol into the URL bar, they can still MITM it. This is what Strict-Transport-Security is meant to prevent. That also causes all cert errors to fatal, so you can't MITM a site using STS even if you could persuade the user to click through a warning.)
Gathering session cookies with Firesheep Posted Nov 5, 2010 5:01 UTC (Fri) by foom (subscriber, #14868) [Link]
It sure would be nice if RFC 2817 actually was a thing. Then http:// urls could be opportunistically encrypted without cert checking and without warning on use of unencrypted or unauthenticated connections.
That would be a pure increase in security, without degrading the security or MITM protection of the https:// url scheme.
Gathering session cookies with Firesheep Posted Nov 5, 2010 16:45 UTC (Fri) by Simetrical (guest, #53439) [Link]
What attack does this prevent? Using more encryption doesn't help you if it doesn't prevent real-world attacks.
Gathering session cookies with Firesheep Posted Nov 5, 2010 18:49 UTC (Fri) by foom (subscriber, #14868) [Link]
Uh, it protects against all forms of passive snooping of your network links. That's a huge increase in practical security. Not only is an active attack frequently harder to achieve, it also risks detection by the victims.
If everyone's "insecure" HTTP sessions were being encrypted that also makes widespread untargeted monitoring by e.g. a spy agency less feasible. You'd have to put your sniffer in the middle of things, and risk detection. (which I'm sure they do sometimes, but it has to be targeted...) Currently, someone could be sniffing the whole internet and nobody would have any way of telling.
Gathering session cookies with Firesheep Posted Nov 5, 2010 20:40 UTC (Fri) by Simetrical (guest, #53439) [Link]
Granted. I think tcpcrypt.org is a much better way to approach this than Upgrade headers, though.
Gathering session cookies with Firesheep Posted Nov 5, 2010 7:31 UTC (Fri) by paulj (subscriber, #341) [Link]
A bank won't be using a self-signed cert. So it will be presented with the "this page (attempts) to be secure" UI, including whatever scary warnings are needed if things seem broken. Also, you could show self-signed pages with a broken padlock somewhere, e.g. beside the HTTPS in the URI - or you could /not/ show the "https" part of the URI for self-signed, etc (Chromium replaces the protocol scheme of URIs with icons).
The key point is that self-signed shouldn't be /worse/ to use than no-security, given that self-signed definitely solves /some/ security problems.
Gathering session cookies with Firesheep Posted Nov 5, 2010 16:48 UTC (Fri) by Simetrical (guest, #53439) [Link]
"A bank won't be using a self-signed cert."
Right . . .
"So it will be presented with the 'this page (attempts) to be secure' UI, including whatever scary warnings are needed if things seem broken."
. . . but now I don't follow you. Say you try to connect to your bank. I intercept the connection during the TLS handshake. The request never reaches the bank, so you never get the bank's certificate. You get my self-signed certificate instead, which appears to come from the bank's website. In this case you clearly want a warning of some type, or else you have no protection against MITMs at all. But how does the browser distinguish between this, and the case where the site's legitimate owners are using a self-signed cert?
Gathering session cookies with Firesheep Posted Nov 5, 2010 17:47 UTC (Fri) by paulj (subscriber, #341) [Link]
Why are we discussing banks? A good bank is never going to use self-signed certs, so whatever changes we're discussing about behaviour re self-signed certs don't apply to banks...
If you mean "what if the bank did use a self-signed cert, we'd need to warn the user!". This would be equivalent to a bank NOT using any HTTPS at all, yet browsers do NOT warn users if a bank uses only HTTP. Indeed, we can generalise this to say that browsers do not warn users where websites use HTTP for information which should otherwise be sent over a secure (i.e. authenticated + private) channel. This is because there is no practical way to do it. Nor is there any practical way to tell where self-signed certs are being used where better security should have been used.
However, in the one case the browser simply lets users get on with it. In the other case browser implementors have decided to make it hard for ordinary users to use. Worse, given self-signed certs continue to be used, this situation helps inure users to scary browser security warnings - precisely the situation at least some browser implementors say they wish to avoid!
So again, why not just make the self-signed case == HTTP case, more or less?
Gathering session cookies with Firesheep Posted Nov 5, 2010 19:23 UTC (Fri) by foom (subscriber, #14868) [Link]
You don't want to make https://mybank.com allow self-signed certs without warning, because the "s" on the end means both "try to encrypt" and "I expect this url to be MITM-free". What was a secure bookmark to a MITM-protected url would no longer be MITM-protected at all. That's a decrease in security.
This is what RFC 2817 (not implemented by anyone) would be useful for.
The right thing to do is to leave https:// alone, but to add the ability to encrypt http:// transactions, without requiring that MITM-protection be present. If http:// urls could be automatically encrypted whenever both the client and server support it, that's a pure win. Even more so if all the popular servers were configured to have that work out of the box.
Gathering session cookies with Firesheep Posted Nov 6, 2010 2:06 UTC (Sat) by paulj (subscriber, #341) [Link]
You're basically restating exactly my point, despite trying to disagree with me. ;)
Gathering session cookies with Firesheep Posted Nov 5, 2010 20:37 UTC (Fri) by Simetrical (guest, #53439) [Link]
Okay, let me try again in more detail. Let's say you go to https://yourbank.com/ in your browser. yourbank.com has paid for a perfectly good EV SSL certificate, and if you connect successfully, the browser will present no warnings or anything, and will put the company name in the URL bar, highlight it green, etc., etc.
But let's say you're doing this using a free Wi-Fi hotspot, and I happen to have set up that Wi-Fi hotspot with a malicious program on it. Now this malicious program sees your outgoing HTTPS request to some IP address, which it happens to know belongs to a bank.
Instead of passing the HTTPS request on to the actual bank, my program instead acts as a man-in-the-middle. It pretends to be the bank, and proceeds with the SSL handshake as though it were the real bank website. At some point, your browser demands my certificate to prove that I'm not an impostor. Unfortunately for me, I don't have a valid certificate for yourbank.com, because I don't control that domain and so I (hopefully) can't convince a CA to sign my certificate.
However, I can easily make up my own *self-signed* certificate. So I pass that certificate to your browser. Up to this point, I'm acting exactly like the real site would, but now I do something different: the bank provides a CA-signed cert, I provide a self-signed cert.
Currently, all browsers pop up a big warning message: "This might not be the site you think it is!" Hopefully this will scare you away from using the bank's site for now.
But in your scheme, the browser would raise no warning, just act the same as a regular HTTP request. In that case, my attack succeeds. You almost certainly won't notice the lack of HTTPS UI, so I'll get your username and password and promptly withdraw your account's balance in cash.
Now, of course the same attack would be possible if you visited http://yourbank.com/. But you hopefully are not -- that's the point of having different URLs for HTTP and HTTPS. The fact that the URL begins "https://" instead of "http://" means "Do not give me the results of this page unless you can verify that it's authentic." If it means anything less, you're opening up attacks by active MITMs, which are extremely practical if you're running free Wi-Fi, Tor exit nodes, an ISP's router (maybe hacked), etc.
So an https:// page that isn't secure *is* worse than an http:// page that isn't secure. In one case the lack of security is expected, but in the other it's unexpected. If https:// URLs behaved as you described, there would be no way for a URL to encode the information "I don't want to connect unless I'm sure it's the real site."
On the other hand, there is no reason in principle not to use some type of encryption over regular HTTP on port 80, even if you don't do authentication. This costs very little resources these days, and at least protects against passive snooping. tcpcrypt.org outlines a very interesting approach to this. But such encryption is not enough for connecting to websites that really want to be secure, like banks, and they need to be able to force authentication somehow. Currently the only way they have to do that is with an https:// URL. Hopefully the new Strict-Transport-Security header will allow a better way to distinguish, and then maybe we can relax warnings for self-signed certs.
Am I clear now?
Gathering session cookies with Firesheep Posted Nov 9, 2010 17:29 UTC (Tue) by nye (guest, #51576) [Link]
>Am I clear now?
This is the only coherent argument of this point that I've ever seen, and I thank you for it.
Gathering session cookies with Firesheep Posted Nov 11, 2010 2:49 UTC (Thu) by filteredperception (guest, #5692) [Link]
>>Am I clear now?
>This is the only coherent argument of this point that I've ever seen, and I thank you for it.
+1. I'm glad my eyes didn't glaze over this long thread and I kept skimming till that explanation. I too required that explanation before I finally 'got it'.
Gathering session cookies with Firesheep Posted Nov 11, 2010 3:10 UTC (Thu) by filteredperception (guest, #5692) [Link]
>>Am I clear now?
>This is the only coherent argument of this point that I've ever seen, and I thank you for it.
Ok, I too value that explanation, because it is the essence of the counterargument against the argument that allowing self-signed certs without warnings would be a net improvement.
But after a couple minutes of hopefully actually grokking this explanation of subsequent potential net-banking mitm attack vectors, this thought occurred to me-
Isn't the only added hurdle to pulling off this attack the need to get a non-self-signed cert? Which sure, is a bit of a relative pain and cost compared to a self-signed cert, but if you were mitm attacking peoples bank accounts, wouldn't getting a valid (effectively disposable) cert be just a 'cost of doing criminal business?'. Sure in the process of getting the cert, you have to leave some identity information, use a credit card, but in my estimation of current global security, I tend to imagine that the criminals could do those things effectively anonymously.
And if in the unlikely event that both my understanding of the issue, and that subsequent analysis are correct, then the question is- which is the bigger net gain for society- the benefits of facilitating easy https encryption with self-signed certs, or the benefits of adding the go-buy-or-steal-a-real-cert hurdle to bank attackers? And I think I'd lean towards the former. But odds are I'm still misunderstanding various aspects of this...
Gathering session cookies with Firesheep Posted Nov 11, 2010 3:57 UTC (Thu) by foom (subscriber, #14868) [Link]
> Isn't the only added hurdle to pulling off this attack the need to get a non-self-signed cert?
You can't get just *any* non-self-signed cert. It has to be a cert valid for the domain name the user is trying to access, signed by one of the certification authorities trusted by the browser.
And that's not a completely trivial thing to do with just a small application of money.
It's only trivial if you happen to run one of the ~500 trusted root or intermediate CAs (e.g. most major governments in the world, and a few companies besides), or have enough money to infiltrate one.
Gathering session cookies with Firesheep Posted Nov 11, 2010 5:24 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
that sort of thing has happened. it's been documented to happen to www.microsoft.com and there's no reason to believe that it can't happen with a bank as well.
but if you watch out for the cert changing, as opposed to just the cert existing, you cover most of that problem
Gathering session cookies with Firesheep Posted Nov 11, 2010 5:43 UTC (Thu) by filteredperception (guest, #5692) [Link]
> You can't get just *any* non-self-signed cert. It has to be a cert valid for the domain name the user is trying to access, signed by one of the certification authorities trusted by the browser.
duh, OK, I figured I was missing something. Hmmm... Maybe the real issue is that certs cost $$ for no good reason, and that is the central issue impeding much more widespread use of https.
Gathering session cookies with Firesheep Posted Nov 13, 2010 10:31 UTC (Sat) by gerv (subscriber, #3376) [Link]
Certs don't "cost $$ for no good reason". If all you want is a Domain Verified cert, get one from StartCom for free. And if you want an EV cert, the CA has to do a load of checks (see cabforum.org for the document listing them all) and that costs money, so you should expect to pay. Any CA can sign up to issue them, with the relevant audits, so it's not a closed market and there is competition.
Gerv
Gathering session cookies with Firesheep Posted Nov 13, 2010 23:40 UTC (Sat) by Simetrical (guest, #53439) [Link]
You're right that if you can get an illegitimate cert, the entire PKI falls apart. However, the cert has to match the domain, and certificate authorities will have their trust revoked by browsers (making their certs useless) if they're found to be giving certs away to people who don't actually control the domains they're for. Typically you have to at least control the e-mail for a domain to be able to get a cert for it. Large governments could probably get hold of illegitimate certs easily enough, but it's quite nontrivial for anyone else. And even for governments, a forged cert is inherently detectable, so any complicit CAs could be eventually found out and get removed from browsers' trusted lists.
This problem will potentially go away in the medium term with DNSSEC. Once sites can deploy certificates through DNSSEC, there's no reason we couldn't also devise a DNS record that says "only accept certificates from DNSSEC, not certificates that claim to be signed by CAs". Then the only way to publish a false certificate for the site would be to compromise their DNS, which gives you many fewer attack vectors than now, when you can compromise (or trick or bully) any one of hundreds of CAs.
There's been discussion about adding a feature like this to Strict-Transport-Security, so you can say "only accept a cert signed by this root CA". Then an attacker has to compromise a *specific* CA to compromise the site instead of being able to compromise *any* CA, making their job much harder.
Gathering session cookies with Firesheep Posted Nov 14, 2010 11:59 UTC (Sun) by anselm (subscriber, #2796) [Link] […] and certificate authorities will have their trust revoked by browsers (making their certs useless) if they're found to be giving certs away to people who don't actually control the domains they're for. Yeah right. Like this happened to VeriSign in March, 2001.
Gathering session cookies with Firesheep Posted Nov 14, 2010 12:11 UTC (Sun) by gerv (subscriber, #3376) [Link]
Is it your contention that a single mistake by a CA should mean they are thereafter disqualified from being included in browsers until the end of time?
There's a difference between a mistake (which happen to the best of us) and wilfully ignoring the necessary rules and safeguards, or a history of mistakes which leads to a diagnosis of institutional incompetence. I suggest that Verisign is guilty of neither of the latter two things.
In addition, the certificate(s) in the incident you reference were digital code-signing certificates, not web server certificates. Very occasionally, web server certs do fall into the wrong hands (which can be via hacking and theft as much as misissuance - how many SSL-running web servers do you think were rooted in the past year?) but I'd be impressed if you can show me a single reported incident where a fraudulently-acquired web server cert was used for spoofing.
Gerv
Gathering session cookies with Firesheep Posted Nov 9, 2010 17:25 UTC (Tue) by nye (guest, #51576) [Link]
>I am saying that neither the security of telnet nor the security of SSH ... is sufficient for people to do online banking or shopping
Nobody claimed it was. Stop making things up.
>Not so. ... In the CA model, as long as both certs were signed by a trusted CA, the user gets no warning in the safe case, and a warning in the unsafe case (because the attacker can't get a CA-signed cert for the domain).
I think I understand what you mean by this now, and it's really the same as the next point.
>If you don't really care that Joe Public gets MITMed
I was very upset to read this, and nearly responded in a very inflammatory manner, but fortunately I gave myself time to cool off.
It appears that you have deliberately and in bad faith removed the important part of that sentence in order to change its meaning entirely. In fact your entire argument against anyone who disagrees with you seems to be based around the use of ridiculous straw men, so I see that there is no point in attempting rational discourse with you.
Gathering session cookies with Firesheep Posted Nov 9, 2010 17:44 UTC (Tue) by gerv (subscriber, #3376) [Link] Nobody claimed it was. Stop making things up. With a small allowance for shorthand, yes they were. People are claiming that the SSH "notify on key-change" model, a.k.a. the self-signed cert model of security, is sufficiently secure to build into web browsers. And if it's built in, Joe Public will be using it, because he's using a tool which supports it. And having a security mode in a consumer product, used for banking or shopping, which does not have sufficient security for those activities is foolish. I have not "changed the meaning of your sentence entirely". You said you didn't care if Joe Public could tell the difference between two situations, one of which involved them being MITMed, and the other of them involved them not being MITMed. I interpreted this as you not caring if Joe was MITMed. That does not seem like an unreasonable inference. If you don't care if he can tell if he's being MITMed, then you must not care if it happens to him. I'm sorry you don't rate the quality of my argument. All I can say is that I and a large number of fairly bright people at Mozilla have spent quite a long time thinking about this, and come under regular pressure to make these sort of changes, with people advocating all sorts of reasons. We have heard and considered all the arguments, pretty much. And the case for making this change in consumer-facing browsers just doesn't stack up. Gerv
Gathering session cookies with Firesheep Posted Nov 10, 2010 6:21 UTC (Wed) by ekj (guest, #1524) [Link]
The thing is, it's a strawman, because an ordinary https-certificate, even one that's signed by a CA, is *also* not considered good enough for a bank, and infact, atleast where I live (Norway) I'm fairly sure no bank goes without extended validation or whatever it's named.
That causes significant and clear gui-changes, namely a large green bar stating the name of the institution.
In contrast, https causes a tiny grey padlock to appear in the bottom-right corner, next to the Sync-icon, which is pretty close to totally nonvisible.
Yes, I get the point that https:-self-signed has an identical url to https:-with-certificate and that thus users with bookmarks is at risk. (few users enter the url with https: Joe Public has by this time LONG gotten used to not typing http(s):// instead if they enter the address at all, they go for "www.mybank.com". That often redirects to https://www.mybank.com/ but I don't think a large fraction of users would notice if it stopped doing that.
AND - and that's my most significant point: The question isn't if a change would cause harm. The question is if the benefits would outweigh the harm, or vice versa. One practical consequence of the current situation, is that self-signed, is essentially not-usable. And encryption of any sort whatsoever is, essentially, not available for everyone hosting a simple website on a shared-ip-address which means probably 95% of the websites in the world.
The practical result of this decision, despite being made for reasons of security -- is that nearly all websites have no encryption whatsoever.
Gathering session cookies with Firesheep Posted Nov 10, 2010 7:32 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you would be surprised at how many banks don't use EV certs.
and frankly, I don't blame them. In many ways the EV certs are a way for a cartel of cert providers to be able to charge $1500/cert and cut outtheir competition that has ruined their prior scam of $900 for a 128 bit cert and $250 for a cert that would drop to 40 bits if a export browser connected to it (not that there are any of those around anyway)
the amount of real checking done is still not that much.
Gathering session cookies with Firesheep Posted Nov 10, 2010 8:29 UTC (Wed) by anselm (subscriber, #2796) [Link] There is nothing special about EV certificates except their extortionate price tag and the fact that they have a magic flag set which will cause the site name to show up on a green background in the browser. You don't get to produce your own EV certificates the way you can produce ordinary certificates (e.g., using OpenSSL) because the magic flag is CA-specific, and browsers that support EV certificates contain a hard-coded list of the CAs which are part of the EV certificate cartel and their corresponding magic flags. Basically, for EV certificates, the CAs that are in on the game promise that they will actually do the sort of checking they should have been doing for all certificates in the first place. That is, somebody applying for an EV certificate for an entity will have to prove that the entity really exists at the specified address. This is then used to justify a vastly increased price for the certificate.
|
|||||||||||||