Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- <pde> tanvi: oh dear
- <pde> that's really bad
- <pde> The way HTTPS Everywhere works is only somewhat similar to HSTS. We use rulesets to specify the redirects, and sometimes they're cross-domain redirects so that (for instance) CDN content can be secured.
- <tanvi> how does it tap into gecko?
- <mgoodwin> pde: this sounds interesting; what's the context?
- <pde> mgoodwin: https://bugzilla.mozilla.org/show_bug.cgi?id=878890
- <firebot> Bug 878890 maj, --, mozilla23, nobody, NEW, Mixed content blocking activates even if extensions rewrite all resources to HTTPS
- <mgoodwin> ahh, right
- <mgoodwin> thanks pde
- <tanvi> the mixed content blocker is all in c++
- --> davida (davida@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
- <pde> tanvi: it nsIOserves "http-on-modify-request" and then invokes nsIChannel.redirectTo()
- <pde> an API which we only just landed after vast amounts of effort
- <pde> :)
- <pde> in the past (pre Gecko 20) we used a crazy patchwork of APIs, including ContentPolicy
- <tanvi> i dont know much about that API, so let me look into it
- <pde> but ContentPolicy was designed to have some holes in it, so we couldn't depend on it exclusively
- <tanvi> HTTPS Everywhere might also have some compatibility issues with websites with CSP, but there aren't very many of those right now
- <pde> that wouldn't surprise me at all
- --> lipsin (lipsin@1BF9271A.9894D6F0.E7AA4C72.IP) has joined #security
- --> hubutm20 (hubutm20@37481E2E.B666433E.9BEFC002.IP) has joined #security
- <pde> I think we've had to fight some youtube video embedding bugs caused by CSP.
- <tanvi> i didnt know youtube used csp
- <tanvi> hmm; they might just use it in chrome via the meta tag instead of a csp header
- <pde> I don't know if it does, but some people embedding it do
- <pde> https://mail2.eff.org/pipermail/https-everywhere-rules/2011-November/000755.html
- <tanvi> ah okay
- <tanvi> the embed links for youtube from http://youtube are defaulted to http
- <tanvi> *for = from
- <tanvi> the embed links from youtube from https://youtube are defaulted to https
- <pde> youtube also has some DOM introspection code that expects the scheme to be what Youtube said it was
- <pde> (this may be unrelated to CSP)
- <tanvi> if an https website wants to embed a youtube link, and they copy the embed src from http://youtube.com, the video will be blocked by IEs and Firefox's mixed content blocker
- --> grobinson1 (garrett@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
- <-- lizzard has quit (Quit: lizzard)
- <tanvi> what youtube said it was?
- --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
- <pde> http://reworld.org/bugs/httpse-bug-4408.html
- <-- lsblakk_ has quit (Quit: Changing server)
- --- felipe is now known as felipe|ic
- --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
- <-- lsblakk_ has quit (Quit: leaving)
- <pde> but we're offtopic now :)
- <-- grobinson has quit (Ping timeout)
- --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
- <tanvi> yeah :)
- <-- lsblakk_ has quit (Quit: leaving)
- <pde> anyway, I haven't read your MCB patches but I presume it would be "easy" to fix this bug by delaying the MCB code until after all http-on-modify-request observers have returned
- <tanvi> we can't really delay that code
- <tanvi> MCB is one of ~6 content policies that are called one after another.
- <pde> what factors determine their orderings?
- <tanvi> if we want to delay MCB, we have to delay content policy
- <tanvi> i'm not sure how the 6 content policies are ordered. i actaully have a bug open to make sure that MCB is the last of the 6, but thats still open.
- <tanvi> we have had some discussions with the platform team about rewriting content policy, but it is not close to the top of their todo list (from my understandng) and without a rewrite, we need to implement a hack.
- <tanvi> regardless, i dont think this will be "easy"
- <pde> tanvi: can you link me to the MCB patches?
- <tanvi> http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp
- --> francois (francois@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
- <tanvi> that's the main file
- <pde> And from our point of view: we have a similar bug in Chrome that's been deemed "too hard to fix". We believe it's the reason that we have millions of Firefox users, and about one tenth that number on Chrome.
- <tanvi> there are some more backend changes in this bug - http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp
- <tanvi> and the frontend implementation is here: https://bugzilla.mozilla.org/show_bug.cgi?id=822371
- <firebot> Bug 822371 nor, --, Firefox 21, tanvi, RESO FIXED, Implement Mixed Content Blocker Doorhanger - Frontend Changes
- <-- francois has quit (Quit: leaving)
- --- gregglind is now known as gregglind_afk
- <tanvi> chrome also blocks http links that HSTS would have upgraded to https. so there implementation may be similar (the blocker is invoked before the redirects) and difficult to change
- <tanvi> chromes is happy with the way it blocks http links on HSTS pages though, taking the position that it is a bug in the website and not all users are protected.
- --> francois (francois@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
- <tanvi> we have so far taken a similar position (https://bugzilla.mozilla.org/show_bug.cgi?id=838395)
- <firebot> Bug 838395 nor, --, mozilla21, nobody, NEW, HSTS sites that have subresources with http:// URLs are displayed as having mixed content even thoug
- <pde> tanvi: HSTS and extensions are different cases https://code.google.com/p/chromium/issues/detail?id=122548#c26
- <-- francois has quit (Ping timeout)
- --> rbarnes (rbarnes@moz-24C73CF3.col.bbn.com) has joined #security
- <-- lsblakk has quit (Quit: Changing server)
- <pde> one alternative to reordering the whole necko pipeline is that we work harder on a way for extensions to selectively disable MCB on sites that they're in the process of securing
- <-- Jesse has quit (Ping timeout)
- --> mhamrick (msh@moz-76C492A0.hsd1.ca.comcast.net) has joined #security
- --> lsblakk (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
- --> Jesse (jruderman@2557E599.66715431.D25A875A.IP) has joined #security
- <tanvi> what would happen if there were an https page with two pieces of mixed content. one https everywhere has a rewrite rule for and will upgrade to https. the other it doesn't.
- <pde> I think we'd only want to disable it on pages where the site operator is serving the original page over http://
- <tanvi> also, we odnt have a whitelist for mcb right now; it can be enabled/disabled in about:config globally. or per page (https everywhere could write chrome code to "disable protection")
- <pde> xkcd is a good example of that
- <pde> tanvi: how does the per-page disablement work?
- <tanvi> i'm not sure that is a good idea. mixed content on an https website may be worse than just using an http website (ex: secure cookies become vulnerable to MITM attackers)
- <pde> I agree that the phenomenon exists
- <pde> I think we can tell when it might happen
- <pde> it's only possible on domains that have (1) large amounts of http:// content ; (2) some portion of the domain that is actually, successfully secured with https://
- <pde> this is an extremely rare situation
- <pde> amazon and ebay are examples
- <tanvi> when the user disables protection, we call https://mxr.mozilla.org/mozilla-central/ident?i=BrowserReloadWithFlags(https://mxr.mozilla.org/mozilla-central/ident?i=nsIWebNavigation.https://mxr.mozilla.org/mozilla-central/ident?i=LOAD_FLAGS_ALLOW_MIXED_CONTENT);
- <tanvi> let me try that again
- <pde> but really only extremely good web security teams are capable of deploying HTTPS correctly if they give themselves the additional challenge of intending to allow http sometimes
- <tanvi> BrowserReloadWithFlags(nsIWebNavigation.LOAD_FLAGS_ALLOW_MIXED_CONTENT);
- <tanvi> yahoo is another example
- --> spock (spock@moz-830EADAF.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com) has joined #security
- <tanvi> also eventbrite
- <-- mwobensmith has quit (Quit: Leaving.)
- <tanvi> i dont think it is extremely rare
- <tanvi> https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#6529 (call to browserreloadwithflags)
- <pde> yahoo may have done so recently; about a year ago IIRC they were still vulnerable to account hijacking
- <pde> in any case, we can merrily do this on domains where we know that we are not going to create mixed content situations
- <pde> such as the xkcd.com example
- <tanvi> how will you determine that?
- --> breck (breck@8342E71E.A6B4685D.DC877F3B.IP) has joined #security
- <pde> human inspection is the most likely method
- --- vng is now known as vng|afk
- --> ErvisTusha (ErvisTusha@D9945EAF.F69FB6EA.363D84A4.IP) has joined #security
- <-- lco has quit (Quit: lco)
- <-- ErvisTusha has quit (Quit: Leaving)
- <pde> we'd add a flag to rulesets like the xkcd dev branch one ( https://www.eff.org/https-everywhere/atlas/domains/xkcd.org.html ) that say "disable MCB" )
- <tanvi> would you be able to disable by using the nsIWebNavigation flag? i've got to go back and see how that implementation works
- <pde> that will be a research question
- <-- lsblakk has quit (Quit: Changing server)
- <pde> there are perhaps two answers
- <pde> 1. if we can detect that the MCB fired we can call that reload with flags function. But I worry that that would be (a) slow and (b) might have side effects due to rePOSTing/reGETing
- <pde> 2. perhaps the flags can be added in other places too? If we could hook to the right place we might be able to turn that flag on without a reload
- <-- lipsin has quit (Ping timeout)
- --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
- --- lsblakk_ is now known as Mozilla
- --- Mozilla is now known as IRCMonkey55418
- --- IRCMonkey55418 is now known as lsblkk
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement