Closed crypta closed 10 years ago
Thanks for submitting this - I agree, this is important. Do you have details on how the attack worked? Is there normally supposed to be a certificate used for the page, but this attack is able to remove it? If so why does the browser still treat it as https?
Would it be possible to set up a reproducible test case we could use when changing the code?
As i understand this, the browser would be talking http to the target site (otherwise a cert would be present). So the mechanism for this to be detected, is port 443 traffic being transmitted in the clear text http protocol. if the user is redirected to the port 80 version of the website, or, port 80 to the mitm attacker and from the attacker on port 443 to the target site, there would be no way of detecting this other than websites including a detectable hash or http header indicating that the site is only available in HTTPS format and the notaries being configured to check for this header even on HTTP pages.
Unless i understand this wrong, or havent thought of something critical
I tried to track down the problem and following are my findings and guesses for anyone who's interested.
Steps to reproduce the problem:
The original screenshot (attached for mirror purposes) does not provide any much insight that could led us to thinking that this was actually man in the middle attack. Indeed, guys at #firefox (@irc.mozilla.org), couldn't think of any other circumstances under which such behaviour could be observed.
I also tried to ask people at #tor (@irc.oftc.net) if they remember about having discussion on it, but with miserable effects. Maybe @myano could shed some light on this problem, as it seems he took part in the discussion [2]...
Anyway, I'd say that this is not a security bug, but just a wishlist item to fix probably non-existent Firefox bug, and should be closed, so that it doesn't confuse people about security level of Perspectives.
It's is indisputable, however, that Perspectives is subject to SSL stripping attacks as described by @moxie0 [3], but it's a whole different story.
[1] My guess is that https://torcheck.xenobite.eu used self-signed certificate at that time. For sure, it used to serve self-signed certificate in the past: https://bugzilla.mozilla.org/show_bug.cgi?id=437773
[2] https://groups.google.com/forum/#!topic/perspectives-dev/nc1RVENkBrk
Hi @crypta , I think there may be some confusion here about when Perspectives retrieves certificates, and why the Page Info dialog says the connection uses http.
Do your steps to reproduce this behaviour match what kuba posted? i.e. you visit a site with a self-signed certificate?
By default, when Firefox visits a site with a self-signed certificate, it displays the certificate warning before it actually connects to the site. That is why the Page Info dialog shows the connection using 'http'.
However, Perspectives does indeed retrieve certificate information for all https sites. In this case, Perspectives will retrieve the cert info before Firefox connects to the site (while the security warning page is still being displayed). You can then decide whether to proceed based on Perspectives' results. So Perspectives does get the certificate information from notaries even in this case.
So to address what I think is your request:
I think that [Perspectives] should do a lookup for any https-URI
It can and does! :) But thanks for reporting this, and it's good to keep an eye out for bugs where it might not.
Please let me know if I am misinterpreting what you wrote. Otherwise I vote to close this bug.
Thanks!
Okay, it has been 9 days. @crypta if you or anyone else have information or a repro case to show that something needs to be fixed, please just speak up and we can re-open this ticket! Otherwise I believe the code is behaving properly. I'm closing this bug for now.
A user on the tor IRC channel reported what seems to be a MITM attack similar to SSLStrip: for an https-URI he got an unencrypted result page: http://bayimg.com/IAnCIAAEo
Looking at https://github.com/danwent/Perspectives/blob/master/plugin/chrome/content/notaries.js to see if this would be detected by Perspectives, it seems that it would hit the return at line 546, with a noCertError and neutral result.
I think that it should do a lookup for any https-URI, and if the user has no certificate and the notaries return known certificates, there should be a mismatch and very large warning.