Closed Bug 1120377 Opened 6 years ago Closed 4 years ago
Update preferences so TLS error reports are POSTed to the new data pipeline
58 bytes, text/x-review-board-request
Per the Telemetry/FHR unification plan , 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.  https://docs.google.com/a/mozilla.com/document/d/1IGpzsYGi_sq3YFQDAPyKOkU_BKvXAC95fZYA2i4ceVs/
Whiteboard: [not a blocker] → [unifiedTelemetry]
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: > https://dxr.mozilla.org/mozilla-central/rev/ > 095988abdc560bf8ba07a94a425c6922a3e9bfd6/browser/base/content/browser.js#2823 > https://gecko.readthedocs.org/en/latest/browser/base/sslerrorreport/index. > 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]
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 https://data.mozilla.com/submit/sslreports Do we know yet what the new value will be?
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 https://incoming.telemetry.mozilla.org. Our teeing logic actually requires the trailing slash at present, but that could probably be adjusted.
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 'data.mozilla.com' to the new 'incoming.telemetry.mozilla.org' 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.
Review commit: https://reviewboard.mozilla.org/r/59002/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/59002/
Attachment #8762123 - Flags: review?(dkeeler)
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. https://reviewboard.mozilla.org/r/59002/#review56242 ::: 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", "https://data.mozilla.com/submit/sslreports"); > +pref("security.ssl.errorReporting.url", "https://incoming.telemetry.mozilla.org/submit/sslreports/"); 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+
https://hg.mozilla.org/integration/mozilla-inbound/rev/a12f445c45d1f41ade8e4fe230893381b4dffa99 Bug 1120377 - Update preferences so TLS error reports are POSTed to the new data pipeline. r=keeler
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/a12f445c45d1 Update preferences so TLS error reports are POSTed to the new data pipeline. r=keeler
You need to log in before you can comment on or make changes to this bug.