New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 148 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature

Sign in to add a comment

Issue 107793: Provide information about the TLS connections to extensions via the webRequest API

Reported by, Dec 15 2011 Project Member

Issue description

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)

Comment 1 by, Dec 15 2011

Labels: -Type-Bug -Pri-2 Type-Feature Pri-3
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.

Comment 2 by, Dec 17 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.

Comment 3 by, 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.

Comment 4 by, 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.

Comment 5 by, Jun 6 2012

See also  Issue 49469 .

Comment 6 by, Mar 10 2013

Project Member
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

Comment 7 by, 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.

Comment 8 by, 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.


Comment 9 by, 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.

Comment 10 by, 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.

Comment 11 by, 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.

Comment 12 by, 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?

Comment 13 by, Jan 25 2014

re #12 - Yes, I was trying to achieve something similar with an extension. Was this feature released recently in Chrome?

Comment 14 by, 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

Comment 15 Deleted

Comment 16 by, 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. ;)

Comment 17 by, Jan 27 2014

Re #16: Thanks for the information, it was really helpful. And it's ok, I didn't wanted you to debug for me. :)

Comment 18 by, 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.

Comment 19 by, 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.

Comment 20 by, Mar 7 2015

Status: WontFix
Closing this as WontFix for now.

The issue here (and why multiple attempts at it have stalled) is that sockets are rightfully decoupled from the activity of URL request infrastructure. That is, between oreload, prefetch, pretender, socket pools, and other experimental features, the mapping of sockets to requests is problematic.

Add to it the complexity of context-dependent rejections (e.g. how would HTTP/2 pooling work when connections are valid from Chrome's perspective, but invalid from the extension's view), and this quickly becomes a lurching mass of code complexity and performance regressions.

The main argument in favour of this is to allow experimental protocols to polyfill, but the total proposal space has seen only two such proposals, one of which would be better implemented in Chrome proper.

I don't deny there is interest in observing the certificate data passively, thus expanding the response objects may make more sense (currently, they share format with Web Page Replay WARs, so more work on that spec side is needed), but that only gives information after the request has been sent.

I'm just deeply concerned about the code complexity cost here, which increases the opportunity for both performance and security bugs.

So marking this as WontFix, a more accurate state than the P3, to indicate that the entire proposed approach rests on my originally flawed understanding of the network stack.

Comment 21 by, Mar 9 2015

Ryan: Sounds like  bug 49469  is also WontFix, is that right?

Comment 22 by, Mar 9 2015

 Issue 49469  has been merged into this issue.

Comment 23 by, Mar 13 2015

It is understandable that the ability to interfere with the SSL subsystem is undesirable from both a code complexity and security standpoint, but is there any chance of a read-only API, like you propose in #3? The ability to layer alternate certificate-validation systems on top of Google's efforts is a pretty valuable feature to security-conscious users and organizations, even if it takes the form of a warning alert rather than a blocked connection.

Comment 24 by, May 1 2015

Now that NPAPI has been disabled, we're looking for an alternative way to securely authenticate an end-user via a smart card using a Chrome Extension.
In order to prevent certain MITM attacks, we need to be able to implement something called "secure channel binding". Here the end-user not only signs the server-side challenge, but also the currently used transport-level SSL certificate. Hence we need a way to access the SSL certificate of a page from within our Chrome Extension. How can this be done?

Comment 25 by, May 1 2015

There is explicitly no plan to expose that detail.

Comment 26 by, May 1 2015

Why not though? I understand that the code may become more complex and security could be compromised if extensions were allowed to modify data or connections, but what about a read-only API as mentioned by that simply allows an extension to passively observe?

Comment 27 by, May 1 2015

There is explicitly no plan to expose TLS channel binding information (key material extractor, TLS-unique CB). You could synthesize a TLS-server-id CB by massively observing the certificate, but there is zero API guarantee that such a channel will be used to deliver the request, which is why such an implementation has issues.

Comment 28 by, May 4 2015

I don't see that such a feature could be this complex. If you navigate Chrome to an SSL-protected site, Chrome clearly shows next to the URL the SSL information. Hence this information is clearly available within Chrome on a per window basis. How hard can it be to simply expose this (private window) information via for example: (maybe this one is tricky because the SSL engine probably manages SSL sessions independently from the Chrome perceived secure channel).

Comment 29 by, Sep 21 2017

I would like to add my two cents to this issue.
I recently was asked, via user request, to provide encryption information about the endpoint they are connecting to (endpoint is a proxy).
As it stands, this appears not possible.
This is not good for extensions who provide proxy services, because sometimes these type of extensions want to inform the user incase of poor encryption negotiation (eg TLSv1.0).

The fact this is a "wontfix" is quite disappointing. Very much so.

Comment 30 by, Sep 21 2017

I guess "middlepoint" might be more accurate there. Hopefully it is understood.

Comment 31 by, Sep 21 2017

Comment 32 by, Jul 6 2018

Components: Internals>Network

Comment 33 by, Jul 6 2018

Components: -Internals>Network>HTTP

Sign in to add a comment