Closed Bug 1120377 Opened 6 years ago Closed 4 years ago

Update preferences so TLS error reports are POSTed to the new data pipeline.


(Toolkit :: Telemetry, defect, P4)




Tracking Status
firefox50 --- fixed


(Reporter: gfritzsche, Assigned: mgoodwin)



(Whiteboard: [unifiedTelemetry][measurement:client])


(1 file)

Per the Telemetry/FHR unification plan [0], we need to add an activation ping:
> (See bug 846489). A record of SSL error reports, opt-in. This ping does not include the profile ID or environement data.

Whiteboard: [not a blocker]
Blocks: 1122482
No longer blocks: 1120356
Whiteboard: [not a blocker] → [unifiedTelemetry]
Duplicate of this bug: 1197170
From bug 1197170 we found that there was already a custom solution implemented before Unified Telemetry:

> We have a separate submission path and controlling prefs for SSL error
> reporting:
> 095988abdc560bf8ba07a94a425c6922a3e9bfd6/browser/base/content/browser.js#2823
> html
> We should consider submitting them through Telemetry, which now comes
> basically down to e.g.:
> > TelemetryController.submitExternalPing("ssl-error", reportObject, options)

This bug would be about moving this over to the UT system.
Component: Client: Desktop → Telemetry
Product: Firefox Health Report → Toolkit
This would also require a server-side change to add "ssl-error" as a known telemetry document type.
Priority: -- → P3
Whiteboard: [unifiedTelemetry] → [unifiedTelemetry][measurement:client]
Priority: P3 → P4
Assignee: nobody → mgoodwin
mgoodwin, you and srich can decide on the timing for this, we'll support you when you're ready.
It looks like all we'll need to do here is change the pref that tells the client where to POST data. Renaming the bug accordingly.

The preference in question is: security.ssl.errorReporting.url

The current value is

Do we know yet what the new value will be?
Blocks: 1253472
Flags: needinfo?(mtrinkala)
Summary: Implement a Telemetry CertViolation ping → Update preferences so TLS error reports are POSTed to the new data pipeline.
whd may be able to answer this but I think the actual end point is under IT control
Flags: needinfo?(mtrinkala) → needinfo?(whd)
Per bug #1253474 this is set up at /submit/sslreports/ on Our teeing logic actually requires the trailing slash at present, but that could probably be adjusted.
Flags: needinfo?(whd)
The current value lacks a trailing slash, so it seems important that we accept reports without the trailing slash. Otherwise when we CNAME the current DNS endpoint '' to the new '' endpoint, all existing clients will break.
I wasn't aware that we were going to be CNAMEing the current endpoint to the new endpoint. Our SSL cert is set up for *.t.m.o only and I assumed that the client pref flip was the mechanism by which we were to move traffic to the new endpoint.
It might not be a finalized plan, I'm just thinking ahead.

The original theory shared with me back when I was first invited to this - which may be wrong - was that we'd run the Heka forwarder was to run it until we were satisfied, and then CNAME over to the new endpoint to remove the Heka forwarder from the loop eventually.

You're right that this would require offering a dual-cert for *.t.m.o and data.m.c - and we're absolutely not going to CNAME this over without coordination - but that seems like a reasonable plan for handling the users that *don't* upgrade, eventually.

(Timeline-wise, IT won't be ready to finalize anything related to this CNAME proposal until after London, so this is all theoretical until then anyways.)
Ok, so sounds like the best approach would be to also duplicate (with slight changes) the current heka forwarder into cloud ops infrastructure and then CNAME to that. This should be straightforward and we can schedule it for after London.
Oh. Okay. I didn't mean to generate work, sorry - I thought it could just accept them - but, that sounds good, too.
Comment on attachment 8762123 [details]
Bug 1120377 - Update preferences so TLS error reports are POSTed to the new data pipeline.

::: netwerk/base/security-prefs.js:86
(Diff revision 1)
>  pref("security.webauth.u2f", false);
>  pref("security.webauth.u2f_enable_softtoken", false);
>  pref("security.webauth.u2f_enable_usbtoken", false);
>  pref("security.ssl.errorReporting.enabled", true);
> -pref("security.ssl.errorReporting.url", "");
> +pref("security.ssl.errorReporting.url", "");

Looks like the default value for the documentation at browser/base/content/docs/sslerrorreport/preferences.rst needs to be updated as well.
Attachment #8762123 - Flags: review?(dkeeler) → review+
Bug 1120377 - Update preferences so TLS error reports are POSTed to the new data pipeline. r=keeler
Pushed by
Update preferences so TLS error reports are POSTed to the new data pipeline. r=keeler
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla50
You need to log in before you can comment on or make changes to this bug.