UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36

Steps to reproduce the problem:
1. Try to extract information about the underlying TLS/SSL transport from the details object passed to a webRequest.onCompleted event listener

What is the expected behavior?
Information about the underlying transport (cipher and key exchange algorithms etc) and the sent and built certificate chains should be provided.

What went wrong?
No TLS/SSL information is provided.

Did this work before? N/A 

Chrome version: 47.0.2526.80  Channel: n/a
OS Version: 
Flash Version: 

This feature is required for the EFF to keep operating its Decentralized SSL Observatory (DSO) project which collects observed certificates from users of the HTTPS Everywhere extension who opt in. At the moment only Firefox users are able to use this feature due to the lack of webRequest support but with the upcoming XPCOM depreciation it will soon be impossible in both Chrome and Firefox.

Ryan Sleevi previously investigated a similar issue (https://bugs.chromium.org/p/chromium/issues/detail?id=107793) and resolved it as a WontFix due to the complexities/dangers of allowing extensions to meddle with the validation process. I agree with those original conclusions but believe a simpler, and much less fraught, solution exists which would provide an extremely useful set of data.

Whereas the previous issue mainly seemed to deal with hooking into the validation process (and t he possibilities of overriding various stages and/or errors) this issue suggests *only* providing connection information via the onCompleted event listener and not allowing any kind of interference in the validation process. Extensions would still be able to show their own UI hints about certificates but because onCompleted listeners are only called after internal security UIs are shown (i.e. certificate warning screens) and bypassed the danger is far lower.

While the main use case for this would be enabling cross-browser feature parity in HTTPS Everywhere I have heard from a number of other extension developers and security researchers who would be very interested in having this ability.