Closed Bug 846506 Opened 11 years ago Closed 9 years ago

Privacy-Policy Review: Create an SSL Error Reporting Mechanism

Categories

(Privacy Graveyard :: Product Review, task, P2)

Product:
Privacy Graveyard
Component:
Product Review
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: ahua)

References

Details

(Whiteboard: under privacy review)

Attachments

(1 file)

Certerror-spec.png
299.61 KB, image/png
Details 
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

Privacy Policy: No
Privacy Policy Link: 
User Data: Yes
Data Safety  ID: 
Legal  ID:
Kathleen, can you schedule some time with me and Alina to talk about the plan for this feature? It'd be best if whoever is designing & implementing this is also present, as we're going to want to talk about the UI/opt-in/notice plans in detail.
Group: mozilla-corporation-confidential
Assignee: bugs → ahua
Hi Kathleen, 

Just wanted to follow up as I didn't see your response. Have you talked with anyone about this yet?  If not, could we schedule some time this week to discuss?  

Thanks,

Alina
Hi Alina,

I don't know who will be designing/implementing this yet, so nothing to discuss at the moment. 

Thanks,
Kathleen
We're beginning to work on the SSL Error Reporting mechanism.

https://wiki.mozilla.org/Security/Features/SSL_Error_Reporting

We have a few privacy-related questions that we would like to discuss with you before we get to far along in the design.
For instance:
- Do we need the user's permission to send us the data?
- Do we need to tell the user what data will be sent to Mozilla? As a description? Or the specific data?
- Can the user opt-in once, and then always have their untrusted error connections sent to Mozilla?

I would like to setup a Vidyo meeting with you, the developer, and the UX designer. 
Who from the privacy team should be included in this meeting?
From Gerv: My meta-suggestion is that we should tie this as closely as possible to the existing practices and permission grants around telemetry and/or crash data. 

http://www.mozilla.org/en-US/legal/privacy/firefox.html

Crash-Reporting Feature
- opt-in
- personal info (e.g. IP address and URL of site) are additional opt-in

Usage Statistics (also known as Telemetry)
- opt-in (on/off via preference)
- transmitted via SSL
Actually, I think there are two things here. Firstly, we have a desire to gather info about SSL errors in general. We should tie that in to the telemetry permission - that's the sort of thing it is, feedback on browser performance. 

Secondly, we really, really want to know about pin violations, because they are indicative of MITMing. I think that in that case, even if the user has not opted in to automatic data transmission, the pin violation error should have a "Report this to Mozilla" button. (And if that reporting fails, we should warn the user that the reporting mechanism may be being blocked, and put the info into a file that the user can email or submit via some other way.)

Gerv
(In reply to Gervase Markham [:gerv] from comment #6)
> Actually, I think there are two things here. Firstly, we have a desire to
> gather info about SSL errors in general. We should tie that in to the
> telemetry permission - that's the sort of thing it is, feedback on browser
> performance. 
> 
> Secondly, we really, really want to know about pin violations, because they
> are indicative of MITMing. I think that in that case, even if the user has
> not opted in to automatic data transmission, the pin violation error should
> have a "Report this to Mozilla" button. (And if that reporting fails, we
> should warn the user that the reporting mechanism may be being blocked, and
> put the info into a file that the user can email or submit via some other
> way.)
> 
> Gerv


Gerv, David and I discussed this, and we agree with you on this approach. What is the next step regarding privacy policy?

We think that the best approach for this project is to nail down the privacy requirements, then work on the user interface design, and then work on the actual implementation.

So, we will greatly appreciate your help in nailing down the privacy part of this.

Thanks,
Kathleen
We need someone from the privacy team, really. Although I work for Alex, I'm not going to put myself forward for that (although he may nominate me :-).

Gerv
Actually, I now see that this bug is already assigned to Alina, and she's commented earlier in its life. So she seems like the right person to start with. Alina?

Gerv
Flags: needinfo?(ahua)
I'm not staff on the privacy team any more, but I also like this approach.

If Alina (or whoever Alex nominates) also agrees on the approach then we should be basically set for the privacy requirements, except for paying close attention to the implementation as it progresses.

The Firefox's privacy policy will need a small update to note the additional Telemetry collection, and what happens with the optional submission: retention, use restrictions, &c. That only needs to be published by the time the feature goes live in release (or possibly beta, I'm a little out of touch on that).

In the mean time, it'd probably be a good idea to start working on the UX and implementation. As new details, questions, and issues emerge during the implementation, it would be prudent to check-in with Alina to make sure that things are still in line with our privacy principles
(In reply to Tom Lowenthal [:StrangeCharm] from comment #10)
> In the mean time, it'd probably be a good idea to start working on the UX
> and implementation. As new details, questions, and issues emerge during the
> implementation, it would be prudent to check-in with Alina to make sure that
> things are still in line with our privacy principles

OK. We've requested the UX wireframes for this approach. Thanks.
Gerv / Tom - Thanks for flagging this. 

Kathleen - Are you free to discuss this week?
Status: NEW → ASSIGNED
Flags: needinfo?(ahua)
Whiteboard: under privacy review
(In reply to Gervase Markham [:gerv] from comment #6)
> Actually, I think there are two things here. Firstly, we have a desire to
> gather info about SSL errors in general. We should tie that in to the
> telemetry permission - that's the sort of thing it is, feedback on browser
> performance. 

We already gather telemetry on the types of SSL errors that our users encounter.  We don't collect info like which sites, but we do measure the frequency of each type of error.

Are you suggesting we collect site info too?

> even if the user has
> not opted in to automatic data transmission, the pin violation error should
> have a "Report this to Mozilla" button.

Yes, this.  Lets do that.
(In reply to Sid Stamm [:geekboy or :sstamm] from comment #13)
> (In reply to Gervase Markham [:gerv] from comment #6)
> > Actually, I think there are two things here. Firstly, we have a desire to
> > gather info about SSL errors in general. We should tie that in to the
> > telemetry permission - that's the sort of thing it is, feedback on browser
> > performance. 
> 
> We already gather telemetry on the types of SSL errors that our users
> encounter.  We don't collect info like which sites, but we do measure the
> frequency of each type of error.
> 
> Are you suggesting we collect site info too?

No, not under the telemetry permission. I was obviously arguing for something we already do. Stats link? :-)

Gerv
see bug 767676 and bug 707275.  I was wrong about the cert error telemetry, but we gather a little bit about what errors people see (bug 767676).

It's hard to link into the Telemetry dashboard, but the histogram for the UI measurements is SECURITY_UI.  We should probably try to finish 707275 to understand more about types of certs encountered.
Priority: -- → P2
Status of Privacy-Policy Review of the SSL Error Reporting Mechanism:

After several meetings with Alina and Jishnu there was agreement on updates to the Firefox Privacy policy, which (to my understanding) are expected to be published soon.

The UX changes and content were approved in those meetings. The UX was implemented, but during review a request was made to change from using a popup to using a doorhanger (https://bugzilla.mozilla.org/show_bug.cgi?id=846489#c6). However, the content is the same, so no change with respect to privacy.

A SUMO page was added to describe website certificates (https://support.mozilla.org/kb/secure-website-certificate). The new UX has a "learn more" link that points to this SUMO page.

Is there anything else we need to do in regards to Privacy-Policy Review?
Flags: needinfo?(jmenon)
Flags: needinfo?(ahua)
I just spoke with Mika - she said that the Privacy Notice changes need to go through Governance review, which she will post in the next few days. She estimates that WebDev will make the updates to the website in a couple weeks.
Flags: needinfo?(ahua)
Updated Privacy Policy was published
(http://www.mozilla.org/en-US/privacy/firefox/)

Unfortunately some links incorrect -- Bug #1006204
Flags: needinfo?(jmenon)
Current UI mockup: http://cl.ly/image/2F0d2e2K061v

The text "Reporting the address and certificate information for this site..." 
and the "Learn More..." link to https://support.mozilla.org/kb/secure-website-certificate
tell the user what information they would be sending to Mozilla.
(In reply to Kathleen Wilson from comment #19)
> Current UI mockup: http://cl.ly/image/2F0d2e2K061v

This mockup has a "Retry" button. In what circumstances do we think that the Retry button will ever produce a different result to the first try? Certainly if the cert is marked as revoked, and we retry, and for some reason we make a successful connection, that's probably bad!

This mockup says "please contact the website owners to inform them of this problem", and it also has a "Report problem" link which does not contact the website owners (it contacts us). We should perhaps remove the text about the site owners, or clarify that there are two entities the user may wish to contact.

Also, "please contact the website owners to inform them of this problem" is bad advice because they can't get through to the website, so how could they possibly do that?

There are more wording things we should fix. What does "Peer's certificate" mean? It talks about "the authenticity of the received data", but if the cert was revoked, then we never received any data. 

"Automatically report errors in the future" should be "Automatically report similar errors in future", so it doesn't seem too broad in scope as a permission.

Having said all that, the new part looks pretty good, and it's an awesome feature :-)

Gerv
Attached image Certerror-spec.png — 
The latest spec for the new part with some modifications and clarifications.

Gerv, the issues you mention all sound very reasonable to me, but they really should be a separate bug.
(In reply to Philipp Sackl [:phlsa] from comment #21)
> Gerv, the issues you mention all sound very reasonable to me, but they
> really should be a separate bug.

Some of them, perhaps, but others are caused by the new UI because they are about the interactions between it and the old text. E.g.:

"This mockup says "please contact the website owners to inform them of this problem", and it also has a "Report problem" link which does not contact the website owners (it contacts us). We should perhaps remove the text about the site owners, or clarify that there are two entities the user may wish to contact."

Also, the last one was about the new UI specifically.

Gerv
Current UI plan: http://cl.ly/image/1f3k0Q1R0l2Q
I've been doing some work on this; I need to know what steps I need to take to ensure we're OK from the privacy point of view.

The current plan is to keep data for 5 days (this is enough for us to observe bad things, identify trends, etc). The data (and an explanation) are as follows:

An example report:

  {
    "timestamp":1413490449366,
    "errorCode":-16384,
    "errorMessage":"An error occurred during a connection to include-subdomains.pinning.example.com.\n\nThe server uses key pinning (HPKP) but no trusted certificate chain could be constructed that matches the pinset. Key pinning violations cannot be overridden.\n\n(Error code: mozilla_pkix_error_key_pinning_failure)\n",
    "failedCertChain":[
        "MIIDCjCCAfKgAwIBAgIENUiGYDANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDExtBbHRlcm5hdGUgVHJ1c3RlZCBBdXRob3JpdHkwHhcNMTQxMDAxMjExNDE5WhcNMjQxMDAxMjExNDE5WjAxMS8wLQYDVQQDEyZpbmNsdWRlLXN1YmRvbWFpbnMucGlubmluZy5leGFtcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALxYrge8C4eVfTb6/lJ4k/+/4J6wlnWpp5Szxy1MHhsLB+LJh/HRHqkO/tsigT204kTeU3dxuAfQHz0g+Td8dr6KICLLNVFUPw+XjhBV4AtxV8wcprs6EmdBhJgAjkFB4M76BL7/Ow0NfH012WNESn8TTbsp3isgkmrXjTZhWR33vIL1eDNimykp/Os/+JO+x9KVfdCtDCrPwO9Yusial5JiaW7qemRtVuUDL87NSJ7xokPEOSc9luv/fBamZ3rgqf3K6epqg+0o3nNCCcNFnfLW52G0t69+dIjr39WISHnqqZj3Sb7JPU6OmxTd13ByoLkoM3ZUQ2Lpas+RJvQyGXkCAwEAAaM1MDMwMQYDVR0RBCowKIImaW5jbHVkZS1zdWJkb21haW5zLnBpbm5pbmcuZXhhbXBsZS5jb20wDQYJKoZIhvcNAQELBQADggEBAAmzXfeoOS59FkNABRonFPRyFl7BoGpVJENUteFfTa2pdAhGYdo19Y4uILTTj+vtDAa5yryb5Uvd+YuJnExosbMMkzCrmZ9+VJCJdqUTb+idwk9/sgPl2gtGeRmefB0hXSUFHc/p1CDufSpYOmj9NCUZD2JEsybgJQNulkfAsVnS3lzDcxAwcO+RC/1uJDSiUtcBpWS4FW58liuDYE7PD67kLJHZPVUV2WCMuIl4VM2tKPtvShz1JkZ5UytOLs6jPfviNAk/ftXczaE2/RJgM2MnDX9nGzOxG6ONcVNCljL8avhFBCosutE6i5LYSZR6V14YY/xOn15WDSuWdnIsJCo=",
        "MIIC2jCCAcKgAwIBAgIBATANBgkqhkiG9w0BAQsFADAmMSQwIgYDVQQDExtBbHRlcm5hdGUgVHJ1c3RlZCBBdXRob3JpdHkwHhcNMTQwOTI1MjEyMTU0WhcNMjQwOTI1MjEyMTU0WjAmMSQwIgYDVQQDExtBbHRlcm5hdGUgVHJ1c3RlZCBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBT+BwAhO52IWgSIdZZifU9LHOs3IR/+8DCC0WP5d/OuyKlZ6Rqd0tsd3i7durhQyjHSbLf2lJStcnFjcVEbEnNI76RuvlN8xLLn5eV+2Ayr4cZYKztudwRmw+DV/iYAiMSy0hs7m3ssfX7qpoi1aNRjUanwU0VTCPQhF1bEKAC2du+C5Z8e92zN5t87w7bYr7lt+m8197XliXEu+0s9RgnGwGaZ296BIRz6NOoJYTa43n06LU1I1+Z4d6lPdzUFrSR0GBaMhUSurUBtOin3yWiMhg1VHX/KwqGc4als5GyCVXy8HGrA/0zQPOhetxrlhEVAdK/xBt7CZvByj1Rcc7AgMBAAGjEzARMA8GA1UdEwQIMAYBAf8CAQAwDQYJKoZIhvcNAQELBQADggEBAJq/hogSRqzPWTwX4wTn/DVSNdWwFLv53qep9YrSMJ8ZsfbfK9Es4VP4dBLRQAVMJ0Z5mW1I6d/n0KayTanuUBvemYdxPi/qQNSs8UJcllqdhqWzmzAg6a0LxrMnEeKzPBPD6q8PwQ7tYP+B4sBN9tnnsnyPgti9ZiNZn5FwXZliHXseQ7FE9/SqHlLw5LXW3YtKjuti6RmuV6fq3j+D4oeC5vb1mKgIyoTqGN6ze57v8RHi+pQ8Q+kmoUn/L3Z2YmFe4SKN/4WoyXr8TdejpThGOCGCAd3565s5gOx5QfSQX11P8NZKO8hcN0tme3VzmGpHK0Z/6MTmdpNaTwQ6odk="
      ],
    "userAgent":"Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0"
  }

Where the data represents the following:

"timestamp"
  The (local) time at which the report was generated

"errorCode"
  The error code

"errorMessage"
  The error displayed to the user

"failedCertChain"
  The certificate chain which caused the pinning violation

"user agent"
  The user agent string of the browser sending the report

What steps do I need to make before I land?
Flags: needinfo?(ahua)
Just so you know, I've also added:
Version (of the report format)
BuildID
Product, and
Channel (is the user release, aurora, etc)

at bsmedberg's request (see also bug 846489)
*nudge*
I discussed this with Geoff yesterday. We're fine to land this to nightly. I'll coordinate with Alina and Geoff to make any changes to the Firefox privacy policy as this rides the trains.
Is there anything left to do here?
Flags: needinfo?(benjamin)
SSL Error Reporting landed in Firefox 36, per Bug #846489.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: needinfo?(benjamin)
Flags: needinfo?(ahua)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: