1. 17 Mar, 2021 1 commit
    • Richard Pospesel's avatar
      Bug 23247: Communicating security expectations for .onion · 3b0641f3
      Richard Pospesel authored and Matthew Finkel's avatar Matthew Finkel committed
      Encrypting pages hosted on Onion Services with SSL/TLS is redundant
      (in terms of hiding content) as all traffic within the Tor network is
      already fully encrypted.  Therefore, serving HTTP pages from an Onion
      Service is more or less fine.
      
      Prior to this patch, Tor Browser would mostly treat pages delivered
      via Onion Services as well as pages delivered in the ordinary fashion
      over the internet in the same way.  This created some inconsistencies
      in behaviour and misinformation presented to the user relating to the
      security of pages delivered via Onion Services:
      
       - HTTP Onion Service pages did not have any 'lock' icon indicating
         the site was secure
       - HTTP Onion Service pages would be marked as unencrypted in the Page
         Info screen
       - Mixed-mode content restrictions did not apply to HTTP Onion Service
         pages embedding Non-Onion HTTP content
      
      This patch fixes the above issues, and also adds several new 'Onion'
      icons to the mix to indicate all of the various permutations of Onion
      Services hosted HTTP or HTTPS pages with HTTP or HTTPS content.
      
      Strings for Onion Service Page Info page are pulled from Torbutton's
      localization strings.
      3b0641f3
  2. 27 May, 2020 1 commit
    • Matt Woodrow's avatar
      Bug 1631405 - Move nsISecureBrowserUI to be owned by the canonical browsing... · e060a86c
      Matt Woodrow authored
      Bug 1631405 - Move nsISecureBrowserUI to be owned by the canonical browsing context instead of docshell. r=nika,ckerschb,Gijs,webcompat-reviewers,twisniewski
      
      This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
      
      I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
      
      Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
      
      Differential Revision: https://phabricator.services.mozilla.com/D75447
      e060a86c
  3. 26 May, 2020 2 commits
    • Bogdan Tara's avatar
      Backed out 4 changesets (bug 1631405) for multiple mochitest failures CLOSED TREE · a54ec307
      Bogdan Tara authored
      Backed out changeset 9963cc0b23cb (bug 1631405)
      Backed out changeset 469ac933ed7c (bug 1631405)
      Backed out changeset 0c5f55864268 (bug 1631405)
      Backed out changeset 20dcbcc2f3b8 (bug 1631405)
      a54ec307
    • Matt Woodrow's avatar
      Bug 1631405 - Move nsISecureBrowserUI to be owned by the canonical browsing... · 240d417e
      Matt Woodrow authored
      Bug 1631405 - Move nsISecureBrowserUI to be owned by the canonical browsing context instead of docshell. r=nika,ckerschb,Gijs,webcompat-reviewers,twisniewski
      
      This removes all docshell nsISecureBrowserUI and mixed content properties, and moves them into CanonicalBrowsingContext/WindowGlobalParent. It makes the mixed content blocker just compute the state for the current load, and then send the results to the parent process, where we update the security state accordingly.
      
      I think we could in the future remove onSecurityChange entirely, and instead just fire an event to the <browser> element notifying it of changes to the queryable securityUI.
      
      Unfortunately we have a lot of existing code that depends on specific ordering between onSecurityChange and onLocationChange, so I had to hook into the RemoteWebProgress implementation in BrowserParent to mimic the same timings.
      
      Differential Revision: https://phabricator.services.mozilla.com/D75447
      240d417e