Georg Fritzsche [:gfritzsche] Reporter
	Description • 10 years ago

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.

[0] https://docs.google.com/a/mozilla.com/document/d/1IGpzsYGi_sq3YFQDAPyKOkU_BKvXAC95fZYA2i4ceVs/

	Georg Fritzsche [:gfritzsche] Reporter
	Comment 2 • 9 years ago

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.

	Mark Reid [:mreid]
	Comment 3 • 9 years ago

This would also require a server-side change to add "ssl-error" as a known telemetry document type.

	Katie Parlante
	Comment 4 • 8 years ago

mgoodwin, you and srich can decide on the timing for this, we'll support you when you're ready.

	Mark Goodwin [:mgoodwin] Assignee
	Comment 5 • 8 years ago

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?

	Mike Trinkala [:trink]
	Comment 6 • 8 years ago

whd may be able to answer this but I think the actual end point is under IT control

	Wesley Dawson [:whd]
	Comment 7 • 8 years ago

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.

	:Atoll
	Comment 8 • 8 years ago

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.

	Wesley Dawson [:whd]
	Comment 9 • 8 years ago

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.

	:Atoll
	Comment 10 • 8 years ago

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.)

	Wesley Dawson [:whd]
	Comment 11 • 8 years ago

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.

	Mark Goodwin [:mgoodwin] Assignee
	Comment 12 • 8 years ago

Review commit: https://reviewboard.mozilla.org/r/59002/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/59002/

	:Atoll
	Comment 13 • 8 years ago

Oh. Okay. I didn't mean to generate work, sorry - I thought it could just accept them - but, that sounds good, too.

	Dana Keeler (she/her) (use needinfo) (:keeler for reviews)
	Comment 14 • 8 years ago

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.

	Mark Goodwin [:mgoodwin] Assignee
	Comment 15 • 8 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=72cdbb8f1451

	Mark Goodwin [:mgoodwin] Assignee
	Comment 16 • 8 years ago

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

	Pulsebot
	Comment 17 • 8 years ago

Pushed by mgoodwin@mozilla.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

	Carsten Book [:Tomcat]
	Comment 18 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/a12f445c45d1