Kathleen Wilson Reporter
	Description • 12 years ago

Initial Questions:

Project/Feature Name: Create an SSL Error Reporting Mechanism
Tracking  ID:846489
Description:
The goal of this project is to create a certificate error reporting mechanism that will transmit and store the following information on a Mozilla server, allowing the data to be analyzed both automatically and manually.
- Domain of bad connection
- Error type (e.g. Pinning, domain mismatch, etc)
- Cert chain (at minimum, same data to distrust each cert in the chain)
- Request data (e.g. User Agent, IP, Timestamp)

Initially this reporting mechanism will be used to report, store, and analyze certificate pinning violations. In the future it could also be used for user-reported certificate errors, and other related concerns.

Certificate pinning is a mechanism by which site owners can specify a set of keys (actually fingerprints of the keys) such that in the next connection to the site, the set of keys in the certificate chain MUST intersect with the set of keys 'pinned' in the browser.
- https://bugzilla.mozilla.org/show_bug.cgi?id=744204
- https://wiki.mozilla.org/Security/Features/CA_pinning_functionality

When the set of keys in the certificate chain do not intersect with the set of keys 'pinned' in the browsers, then an alert will be generated and sent to Mozilla to be stored and analyzed. There may be some false alarms, but if a real issue (such as MITM) is identified, the security-group should be alerted for further action.

This reporting mechanism should be available before Key Pinning is live, which is targeted for May 2013. 
Additional Information:
https://etherpad.mozilla.org/CA-KeyPinningReporting 
Urgency: 2-4 weeks
Key Initiative: Firefox Platform
Release Date: 2013-05-10
Project Status: active
Mozilla Data: Yes
New or Change: New
Mozilla Project: none
Mozilla Related: SSL, security
Separate Party: Yes
Type of Relationship: Other
Data Access: No
Privacy Policy: None -- it may be the case that the user should have to click to allow the data to be sent to Mozilla.
Vendor Cost: N/A

	Kathleen Wilson Reporter
	Comment 1 • 12 years ago

Bug 846502 - Security Review: Create an SSL Error Reporting Mechanism
Bug 846503 - Legal Review: Create an SSL Error Reporting Mechanism
Bug 846504 - Data Safety Review: Create an SSL Error Reporting Mechanism
Bug 846505 - Privacy-Technical Review: Create an SSL Error Reporting Mechanism
Bug 846506 - Privacy-Policy Review: Create an SSL Error Reporting Mechanism

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 2 • 12 years ago

(In reply to Kathleen Wilson from comment #0)
> - Domain of bad connection
> - Error type (e.g. Pinning, domain mismatch, etc)
> - Cert chain (at minimum, same data to distrust each cert in the chain)

We should really send the entire cert chain (as sent by the server, not as computed).

> - Request data (e.g. User Agent, IP, Timestamp)

The actual HTTP request is not available. However, the three things you mentioned are.

> Initially this reporting mechanism will be used to report, store, and
> analyze certificate pinning violations. In the future it could also be used
> for user-reported certificate errors, and other related concerns.

> Privacy Policy: None -- it may be the case that the user should have to
> click to allow the data to be sent to Mozilla.

If user interaction is required then certificate pinning violations are just a special case of user-reported certificate errors and wouldn't need to be treated specially.

I think there should be a way for sites to opt into automatic (without user interaction) sending of this information to us (and/or to them) when a certificate errors occurs on their site.

	Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]
	Comment 3 • 12 years ago

unhiding as this should be public

	Kathleen Wilson Reporter
	Comment 4 • 12 years ago

Copying David Ascher's comment in bug #846504 because that bug was closed due to process change, but the questions are still relevant.

https://bugzilla.mozilla.org/show_bug.cgi?id=846504#c1
> Kathleen, this is cool.  I would strongly encourage you to come up with a
> comms plan, as a) if it works, it's worth getting good press about it, and
> b) the more transparent we can be about it early, the easier it'll be to get
> people to understand it, etc.
> 
> Kathleen -- have you thought about engaging the CAB folks about it?
> 
> (and side-note: do we have plans to detect changes-in-certs-over-time, to
> detect MITM, in parallel w/ pinning?)
> 
> also detailed point: think about whether you can get a lot of value with
> only coarse measures for things like UA, as a full UA can carry a strong
> fingerprinting signal.

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews) Assignee
	Comment 5 • 11 years ago

Something to keep in mind: there's a key-pinning draft in the works that can report pinning errors: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-3
This is the current format:
   {
     "date-time": date-time,
     "hostname": hostname,
     "port": port,
     "certificate-chain": [
       pem1, ... pemN
     ],
     "known-pins": [
       known-pin1, ... known-pinN
     ]
   }

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews) Assignee
	Comment 6 • 10 years ago

I believe this bug was created as part of the project kick-off form and involves some other bugs for getting review from different parts of the organization. However, since it has had the same summary as the implementation bug (bug 846489 - "Create an SSL Error Reporting Mechanism"), it's been quite confusing. I'm not sure it's still necessary to have this bug, but since some of the dependent bugs haven't been closed (particularly the privacy policy review one), I figure the best course of action for now would be to rename this to something more descriptive.

	Kathleen Wilson Reporter
	Comment 7 • 9 years ago

SSL Error Reporting landed in Firefox 36, per Bug #846489.