My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 107793: Provide information about the TLS connections to extensions via the webRequest API
57 people starred this issue and may be notified of changes. Back to list
Project Member Reported by, Dec 15, 2011
The webRequest API is an experimental API ( ) that allows extensions to inspect and/or modify network requests, both synchronously (in the case of modification) and asynchronously (observation)

It's implemented as a net::NetworkDelegate(), which receives notifications from the various URLRequests, most notably URLRequestHttpJob.

It would be useful for extensions to be able to have information about any TLS connections negotiated while satisfying the URLRequest - the certificate chain sent by the server, the certificate chain (as validated by Chrome/ium, which may differ), the TLS cipher suite, status errors, etc.

This information is traditionally available as part of URLRequestHttpJob's response_info_->ssl_info (for completed requests) or transaction_->GetResponseInfo()->ssl_info (for in progress requests). An initial version does not need to allow extensions to mutate the existing URLRequestHttpJob state machine (such as allowing errors to be overridden) - just provide the capabilities for webRequest extensions to know when they may occur and information about the errors.

Possible use cases:
  - Cert Patrol-style extension that can notify users if a previously encountered certificate has changed. At some point in the future, this may allow the extension the ability to abort the load before any sensitive information is exchanged, but for now, we should assume the primary use would be to better inform the error interstitial.
  - Reporting fraudulent certificate chains to third-party service providers (EFF's Certificate Observatory, Qualsys' SSL Labs, researchers, etc)
  - Potentially adding to some of the SSL verification logic by using the blocking webRequest APIs to abort connections that don't meet certain criteria (supporting new and novel revocation management schemes - without requiring integration into CertVerifier)
Dec 15, 2011
Note: No proposed API is fleshed out. This is just a tracking bug based on interest for/support of the idea from some of the Chromium developers I've spoken with.

A more detailed API proposal will come once work on this actually begins. 

If no one else is motivated for this, I'll look to begin working on this in a few weeks once I have a chance to work on some of the higher priority bugs. If you are interested, feel free to take it.
Labels: -Type-Bug -Pri-2 Type-Feature Pri-3
Dec 16, 2011
FYI, there is quite a bit of interest in this type of API from the security community, especially in the form of a blocking API that can approve or deny requests based on the certificate chain and throw up a warning of some kind to the user while doing so.

For example, Firefox currently has all of this information available in the equivalent of an async/after-the-fact property that can be inspected on nsIChannels, but what everyone really wants is some kind of blocking API. However, the exact form of what that API should provide is currently caught in quagmire. See:

Peter Eckersley of the EFF (and a co-author of HTTPS-Everywhere) is interested in distilling the cacophony into something resembling coherence. He is probably worth contacting about this: pde at eff dot org.
Dec 18, 2011
Mike, thanks for pointing me to that Mozilla bug - I was unaware of it.

Currently, wanting to support innovations from the security community is exactly what motivated me to file this bug. Briefly, I would like for Chromium to be able to support extensions that can:
- Potentially warn the user when a sites' certificate changes (intermediate || root CA)
- Support recording observed certificate chains and reporting those to one or more online repositories
- Experiment with alternative means of revocation checking (TAMP, Sovereign Keys, Certificate Transparency)
- Experiment with methods similar to Certificate Pinning ( )

However, similar to the concerns expressed in the Mozilla community, I'm more interested in focusing on ways to allow extensions to express /negative/ statements for certificate chains. Allowing an extension to express a /positive/ statement (such as requested by some extensions, such as Convergence or for DANE support) carries with it an inherent security risk of a malicious extension abusing that privilege. 

Rather than worry about that issue up-front and prevent any implementation, I'd like to iterate a minimal API for negative assertions, and then build on it to revisit possible support for positive assertions.
Feb 27, 2012
Initial draft of proposed API is by modifying the webRequest API, due to the overlap in concerns.

Please see . Comments are welcome either on that page or on this bug.
Jun 6, 2012
See also Issue 49469.
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-Internals -Area-UI -Feature-Extensions -Internals-Network-SSL -Internals-Network-HTTP Cr-Platform-Extensions Cr-Internals-Network-SSL Cr-UI Cr-Internals-Network-HTTP Cr-Internals
Sep 11, 2013
I would like to give my own list of CAs that I want to trust instead of what is put by Windows update or administrators remotely. I would like to prune and keep the list short.

At the least, I would like to write an extension that would tell me if the certificate was built-in or what added by administrators. I still use Opera or Firefox as it allows me to directly prune certificate from within the browser.

Sep 11, 2013
rajesh: Unfortunately, such a use case is not one we plan to support, even with the ability to provide extensions.

The right way to prune trust is to remove trust locally - eg: by adding certificates to the distrusted store on Windows. Anything short of that does not provide adequate or the desired security.

Sep 11, 2013
It might be interesting to consider if the proposed API could be extended with an event that would allow an extension to detect and act on offered cipher suites.

The usecase would be as follows:If for example a server is recorded (by the extension) to support many cipher suites, and at a later time in negotiation for example only RC4 based ciphers are offered, or AES256-SHA used to be offered, but now only AES128-SHA is available. The extension could (using publicly available sources) keep track of known and rumoured cipher suite weaknesses, and conclude if a likely MITM cipher-suite downgrade attack might be happening.

Jan 8, 2014
I would very much like to see this added.  I am about to release a custom build of Chromium with a bunch of privacy enhancements and would like to be able to notify users if a web site is using Perfect Forward Secrecy.

Currently Netcraft's extension has this ability but it relies on information from a 3rd party (a remote Netcraft server) which may not yield accurate results for the specific client session.

If I could simply check which cipher suite was being used I could very simply notify the user via an icon in the address bar if PFS is being used.

Given the Snowden revelations, it is important to encourage more organisations to enable PFS and by showing users when this is happening it will help build trust between users and online services.
Jan 24, 2014
@Paladine: I will like to use/test that custom build of yours. Actually I am trying to build an extension for chrome which can alert users against self-signed/expired/invalid ssl certificates and don't allow them to navigate further for specific set of sites, more like but with error message in plain english. 
I can use the guidance of you people regarding that. Thanks in advance.
Jan 24, 2014
re #11 - Are you referring to the error you see at Are there portions of it that are too hard to understand?
Jan 25, 2014
re #12 - Yes, I was trying to achieve something similar with an extension. Was this feature released recently in Chrome?
Jan 25, 2014
re #12 - I am now getting similar sort of error as on page for another website I visit frequently on latest chrome build, this was not the case earlier. While other people using same Chrome build are not getting "Cannot connect to the real ***" error page. Even in latest Canary build I am able to open the website using "Continue Anyway" button. Is this feature added to the latest chrome version?
Screenshot 2014-01-25 19.59.50.png
82.8 KB   View   Download
Jan 26, 2014
Re #13/14: No, the feature is not new -- Chrome blocks when there's a pinning failure, HSTS failure, cert is mangled, or cert has been revoked. The only thing that's new is that the warning has been reworded/re-styled. If you're getting that for a website you visit frequently but other people aren't, something is screwing with your network traffic. Note that Canary doesn't support pinning checks which is why you don't see the blocking error page on Canary. (However I can't debug for you here, this conversation has veered off-topic -- my bad. ;)
Jan 26, 2014
Re #16: Thanks for the information, it was really helpful. And it's ok, I didn't wanted you to debug for me. :)
Apr 26, 2014
Any chance of this feature seeing the light of day, especially given the Heartbleed shenanigans of late.  I think its clear there needs to be better approaches to client side SSL validation, audit etc.  It's an area Chrome still lacks behind Firefox.
Apr 28, 2014
Agreed. It would nice to be able to show an indicator if a site's certificate was issued before April 8, 2014 because as it stands any such certificate needs further investigation (with tools like the netcraft site report) before it can be trusted.
Sign in to add a comment

Powered by Google Project Hosting