Advertisement
Guest User

https://bugzilla.mozilla.org/show_bug.cgi?id=878890

a guest
Jun 3rd, 2013
165
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 9.66 KB | None | 0 0
  1. <pde> tanvi: oh dear
  2. <pde> that's really bad
  3. <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.
  4. <tanvi> how does it tap into gecko?
  5. <mgoodwin> pde: this sounds interesting; what's the context?
  6. <pde> mgoodwin: https://bugzilla.mozilla.org/show_bug.cgi?id=878890
  7. <firebot> Bug 878890 maj, --, mozilla23, nobody, NEW, Mixed content blocking activates even if extensions rewrite all resources to HTTPS
  8. <mgoodwin> ahh, right
  9. <mgoodwin> thanks pde
  10. <tanvi> the mixed content blocker is all in c++
  11. --> davida (davida@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
  12. <pde> tanvi: it nsIOserves "http-on-modify-request" and then invokes nsIChannel.redirectTo()
  13. <pde> an API which we only just landed after vast amounts of effort
  14. <pde> :)
  15. <pde> in the past (pre Gecko 20) we used a crazy patchwork of APIs, including ContentPolicy
  16. <tanvi> i dont know much about that API, so let me look into it
  17. <pde> but ContentPolicy was designed to have some holes in it, so we couldn't depend on it exclusively
  18. <tanvi> HTTPS Everywhere might also have some compatibility issues with websites with CSP, but there aren't very many of those right now
  19. <pde> that wouldn't surprise me at all
  20. --> lipsin (lipsin@1BF9271A.9894D6F0.E7AA4C72.IP) has joined #security
  21. --> hubutm20 (hubutm20@37481E2E.B666433E.9BEFC002.IP) has joined #security
  22. <pde> I think we've had to fight some youtube video embedding bugs caused by CSP.
  23. <tanvi> i didnt know youtube used csp
  24. <tanvi> hmm; they might just use it in chrome via the meta tag instead of a csp header
  25. <pde> I don't know if it does, but some people embedding it do
  26. <pde> https://mail2.eff.org/pipermail/https-everywhere-rules/2011-November/000755.html
  27. <tanvi> ah okay
  28. <tanvi> the embed links for youtube from http://youtube are defaulted to http
  29. <tanvi> *for = from
  30. <tanvi> the embed links from youtube from https://youtube are defaulted to https
  31. <pde> youtube also has some DOM introspection code that expects the scheme to be what Youtube said it was
  32. <pde> (this may be unrelated to CSP)
  33. <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
  34. --> grobinson1 (garrett@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
  35. <-- lizzard has quit (Quit: lizzard)
  36. <tanvi> what youtube said it was?
  37. --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
  38. <pde> http://reworld.org/bugs/httpse-bug-4408.html
  39. <-- lsblakk_ has quit (Quit: Changing server)
  40. --- felipe is now known as felipe|ic
  41. --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
  42. <-- lsblakk_ has quit (Quit: leaving)
  43. <pde> but we're offtopic now :)
  44. <-- grobinson has quit (Ping timeout)
  45. --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
  46. <tanvi> yeah :)
  47. <-- lsblakk_ has quit (Quit: leaving)
  48. <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
  49. <tanvi> we can't really delay that code
  50. <tanvi> MCB is one of ~6 content policies that are called one after another.
  51. <pde> what factors determine their orderings?
  52. <tanvi> if we want to delay MCB, we have to delay content policy
  53. <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.
  54. <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.
  55. <tanvi> regardless, i dont think this will be "easy"
  56. <pde> tanvi: can you link me to the MCB patches?
  57. <tanvi> http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp
  58. --> francois (francois@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
  59. <tanvi> that's the main file
  60. <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.
  61. <tanvi> there are some more backend changes in this bug - http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp
  62. <tanvi> and the frontend implementation is here: https://bugzilla.mozilla.org/show_bug.cgi?id=822371
  63. <firebot> Bug 822371 nor, --, Firefox 21, tanvi, RESO FIXED, Implement Mixed Content Blocker Doorhanger - Frontend Changes
  64. <-- francois has quit (Quit: leaving)
  65. --- gregglind is now known as gregglind_afk
  66. <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
  67. <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.
  68. --> francois (francois@moz-BE33DA21.fw1.sfo1.mozilla.net) has joined #security
  69. <tanvi> we have so far taken a similar position (https://bugzilla.mozilla.org/show_bug.cgi?id=838395)
  70. <firebot> Bug 838395 nor, --, mozilla21, nobody, NEW, HSTS sites that have subresources with http:// URLs are displayed as having mixed content even thoug
  71. <pde> tanvi: HSTS and extensions are different cases https://code.google.com/p/chromium/issues/detail?id=122548#c26
  72. <-- francois has quit (Ping timeout)
  73. --> rbarnes (rbarnes@moz-24C73CF3.col.bbn.com) has joined #security
  74. <-- lsblakk has quit (Quit: Changing server)
  75. <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
  76. <-- Jesse has quit (Ping timeout)
  77. --> mhamrick (msh@moz-76C492A0.hsd1.ca.comcast.net) has joined #security
  78. --> lsblakk (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
  79. --> Jesse (jruderman@2557E599.66715431.D25A875A.IP) has joined #security
  80. <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.
  81. <pde> I think we'd only want to disable it on pages where the site operator is serving the original page over http://
  82. <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")
  83. <pde> xkcd is a good example of that
  84. <pde> tanvi: how does the per-page disablement work?
  85. <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)
  86. <pde> I agree that the phenomenon exists
  87. <pde> I think we can tell when it might happen
  88. <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://
  89. <pde> this is an extremely rare situation
  90. <pde> amazon and ebay are examples
  91. <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);
  92. <tanvi> let me try that again
  93. <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
  94. <tanvi> BrowserReloadWithFlags(nsIWebNavigation.LOAD_FLAGS_ALLOW_MIXED_CONTENT);
  95. <tanvi> yahoo is another example
  96. --> spock (spock@moz-830EADAF.c3-0.nwt-ubr1.sbo-nwt.ma.cable.rcn.com) has joined #security
  97. <tanvi> also eventbrite
  98. <-- mwobensmith has quit (Quit: Leaving.)
  99. <tanvi> i dont think it is extremely rare
  100. <tanvi> https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#6529 (call to browserreloadwithflags)
  101. <pde> yahoo may have done so recently; about a year ago IIRC they were still vulnerable to account hijacking
  102. <pde> in any case, we can merrily do this on domains where we know that we are not going to create mixed content situations
  103. <pde> such as the xkcd.com example
  104. <tanvi> how will you determine that?
  105. --> breck (breck@8342E71E.A6B4685D.DC877F3B.IP) has joined #security
  106. <pde> human inspection is the most likely method
  107. --- vng is now known as vng|afk
  108. --> ErvisTusha (ErvisTusha@D9945EAF.F69FB6EA.363D84A4.IP) has joined #security
  109. <-- lco has quit (Quit: lco)
  110. <-- ErvisTusha has quit (Quit: Leaving)
  111. <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" )
  112. <tanvi> would you be able to disable by using the nsIWebNavigation flag? i've got to go back and see how that implementation works
  113. <pde> that will be a research question
  114. <-- lsblakk has quit (Quit: Changing server)
  115. <pde> there are perhaps two answers
  116. <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
  117. <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
  118. <-- lipsin has quit (Ping timeout)
  119. --> lsblakk_ (lsblakk@moz-DB4A9C19.scl3.mozilla.com) has joined #security
  120. --- lsblakk_ is now known as Mozilla
  121. --- Mozilla is now known as IRCMonkey55418
  122. --- IRCMonkey55418 is now known as lsblkk
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement