Firefox3.1/AboutCertError SecurityReview

From MozillaWiki
Jump to: navigation, search

Overview

Implement a new error page customized for SSL errors, to allow for greater usability than the current netError.xhtml overrides.

Background links

Security and Privacy

  • What security issues do you address in your project?

The current errors are difficult to understand, and put technical jargon ahead of human descriptions of the situation. The netError.xhtml framework makes it difficult to customize this experience.

  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

If the new error page is not available, it falls back to the existing netError error page.

  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

The assumption is that, like the old page, this page must not be privileged, since content can cause it to be displayed. Like the old page, this page must not render its arguments as generic html since they can be controlled to some extent by an attacker.

  • How are transitions in/out of Private Browsing mode handled?

PBM does not alter the behaviour of this page.

Exported APIs

  • Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

This exposes a new about page, about:certerror, which has the same interaction methods as the existing about:neterror. No new XPCOM interfaces are created.

  • Does it interoperate with a web service? How will it do so?

No

  • Explain the significant file formats, names, syntax, and semantics.

No new profile files are created.

  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

The only interface is the arguments to the about page, which are documented in the page, as with the existing about:neterror

  • Does it change any existing interfaces?

No

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)

This code lives as a component in browser/, and has a minimal, non-dependency impact on docshell.

Data

  • What data is read or parsed by this feature

A url.

  • What is the output of this feature

A content error page.

  • What storage formats are used

No new storage is introduced.

Reliability

  • What failure modes or decision points are presented to the user?

In the case where the user encounters an untrusted certificate, the user is presented with information about the problem, and given the option to "Get me out of here". There is also an "I know what I'm doing" section that allows expert users to add a trust exception and proceed to the site.

  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

No files/locks.

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

This page respects the same prefs as the original about:neterror.

  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No.

  • What ranges for the tunable are appropriate? How are they determined?

N/A

  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

No ongoing maintenance at this time. Possible that in the future this page might link to a support.mozilla document with extra information.

Relationships to other projects

Are there related projects in the community?

  • If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

Not directly - obviously many people have an interest with experimenting with error pages.

  • Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

Not directly, although we are influencing the presentation of information that comes from PSM. Kai and Nelson are both on the bug, and contributing to its development.

Review comments

  • in the "bad domain" case can an attacker insert random text in the technical details section? It may not get auto-linked, but could be a set of instructions to the user. It could have bidi chars, spaces or unicode things that look like spaces.
  • bug 433422 covers complaints about calling self-signed certs "invalid". The new text is much clearer but the "Technical Details" from PSM still uses this word. It would save us a lot of grief from tech-savvy people if we changed this terminology to match the rest of the new page.