From MozillaWiki
Jump to: navigation, search
Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

:80 vs. :443

No longer valid! Due to concerns with MITM attacks and mixing SSL and non-SSL we've decided to stay 100% on SSL. I'll leave this page up for reference.

Generic login function does something similar to:

  • expires existing session if it exists
  • secure cookie (we'll call it session cookie) is set:
    • Expires at end of session unless "remember me" was checked, then it expires in +X weeks.
    • https-only, includes:
      • session ID: uniquely identify session
      • hash(secretFromServer + sessionId + ??): This is a short hash (md5 is fine) that will tell us if the session ID has been tampered with
  • insecure cookie (we'll call it token cookie) is set:
    • Expires at end of session unless "remember me" was checked, then it expires in +X weeks.
    • includes:
      • a token: hash(random) is fine. This is stored alongside the secure session ID in the db
      • a hash: hash(secretFromServer + token + ??): hash to check tampering

  • We'll have a function to verify cookies using the hashes whenever anything secure is being accessed
  • When changing a password, all sessions/cookies are removed and the user changing the password is reissued another one
  • Insecure pages can key off the token cookie - if it exists, we can assume the user is logged in.

Use cases

User logs in from the front page:

  • [SSL] Goes to SSL page for logging in
  • user is forwarded back to the http front page. The front page now has generic "logged in" content like a link to "my add-ons" and such just because the token cookie exists.

User wants to edit a full page of content:

  • [SSL] If cookies don't exist or can't be verified they are sent to SSL page to log in
  • User is forwarded back to edit page (over either http or https, depending on implementation)
  • [SSL] edit page knows it's content needs to be SSL and verifies user is using https or forwards to https

User wants to adjust content on an insecure page

  • This is like an [edit] button next to an add-on description
  • User makes adjustment
  • [SSL] AJAX request is sent over SSL to API. Success/fail response is returned and user is shown appropriate message.
  • If user isn't logged in, they won't see [edit] buttons. If a user somehow submits a request via ajax without a valid session it will return failure.

User wants to install an add-on:

  • Doesn't matter if user is on https or not, logged in or not
  • User clicks "install"
  • [SSL] JS does an ajax request over SSL for the file hash, passing:
    • URL of file it wants the hash for
  • file (over plain text) and hash are passed to browser's add-on installer

User wants to download an add-on:

  • subtle difference, but we're assuming there is no installTrigger() fired
  • this is no different than going directly to the .xpi URL. There is no hash checking, and the user is forwarded to the mirror network.
  • No SSL involved.

Additional Domains

  • Will remain completely SSL

  • Will act like It will know what parts of itself should be SSL and will redirect accordingly

  • Will provide normal and SSL copies of itself, but won't do any redirection

Stuff that still needs addressing

  • We want to show [edit] buttons on a user's add-on detail page, their profile page, etc.
  • If a user manually goes to HTTPS, I think they should stay on it
  • security team verification that the add-on installing process is appropriate