1499592 - browser.webRequest.getSecurityInfo() should be available earlier than at onHeadersReceived

Status: UNCONFIRMED

(WebExtensions :: Request Handling, enhancement, P5)

Description

[Alexander Færøy]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce:

While working on a primitive prototype of an extension to do "TLS pinning" I investigated the current webRequest API landscape and was happy to see the availability of the browser.webRequest.getSecurityInfo() API.

Unfortunately, the API response object is only useful from the event triggered at onHeadersReceived, which triggers after the browser have already made its request to the server. It would be useful to have access to as many of these values as possible before Firefox sends any data on the wire to the server. This would allow extension developer to write extensions that blocks requests based on different parameters from the securityInfo object return value.


Actual results:

Call to browser.webRequest.getSecurityInfo() in onBeforeSendHeaders returns the object:

`{ "state": "insecure" }`

Which lacks much of the TLS knowledge the browser (should?) already have at this point in the request lifetime.


Expected results:

Call to browser.webRequest.getSecurityInfo() in onBeforeSendHeaders returns an object with as much TLS information that is available at that time and allow the application developer to cancel the request.

Comment 1

[Shane Caraveo (:mixedpuppy)]

While this would be nice to have, it would require some restructuring in platform support.

Comment 3

[jbash]

Whatever the priority, it seems truly inappropriate to mark this as an enhancement. It is a defect. There's existing TLS information retrieval functionality for extensions, and it's not fit for purpose. The functionality was added in response to a previous report, bug #1322748. That report was marked closed, but many of the use cases mentioned very early in its discussion can't be met using what Firefox does now.

Much of the value of being able to see this information is in having control over whether or not the browser will actually send sensitive information to the server. That means you have to have the cert information before the request is sent. I was tempted to say that 95 percent of the value was lost by delaying until the headers come back, but that might prompt an argument, so I'll leave at at "much".

The existing behavior could easily create an incentive to write extensions that give users a false sense of security, and that's dangerous. I'd almost suggest that you take away the existing function if you can't provide it earlier than that.

I could see calling it an enhancement if somebody wanted to know what was going on with client certificates, or know the server's OCSP status, or know about non-X.509 keying or authentication. But being able to stop something bad before you send God-knows-what sensitive information to the server is a real core issue.

As for the priority, I won't argue too much with you guys about priorities. But I'll allow myself to say that X.509 is an unsafe mess. The "solutions" offered by browsers in general, and by the CA-browser forum, mostly tend to be effective only for major, centralized destination sites... if then. Yes that includes CT, CAA, and all the rest. And every request or bug report that might make it possible to get really trustworthy crypto in any browser seems to end up treated as a P5, if it's not rejected outright. Nobody seems to want to build in what's needed, but nobody seems to want to enable extensions to add it, either.

Comment 4

[James E. A. (any) [:codegeek98]]

The existing behavior could easily create an incentive to write extensions that give users a false sense of security, and that's dangerous.

@jbash Your speculation is not unwarranted: I am currently writing an extension to do just that (though, ideally, in a not-false way).

being able to stop something bad before you send God-knows-what sensitive information to the server is a real core issue.

Although, FWIW, if the add-on is properly coded, you can at least limit the damage (race conditions notwithstanding) to "merely" the entirety of one (1) outbound request including all headers and cookies (unless, perhaps, a very clever attacker thought to not send any response, even headers, in order to farm out a few more requests). I'd love to see Mozilla bring that number down to simply zero, though, by giving us access to the securityInfo in time to do something about it.

This bug is unambiguously a defect in the API, and prevents an add-on which relies on it from ever evolving beyond a beta.
https://github.com/JamesTheAwesomeDude/cerdicator/issues/5

Comment 5

[James E. A. (any) [:codegeek98]]

One possible sub-issue of this: should another level be added, in the case of TLS Client Certificates, to allow Add-Ons to inspect/verify the server's claimed credentials before the client sends its own (if this is already something Firefox does, itself)?

Comment 6

[Shane Caraveo (:mixedpuppy)]

The reality is that we do not have the security info until a point in between onSendHeaders and onHeadersReceived. I wouldn't be against adding a new notification, such as onSecurityInfo, which would be called between those two. There is a point at which we are able to access the securityInfo in the nsIHttpActivityObserver (that is currently only used to support onErrorOccurred). I'm not certain that we could block the request at that point without further investigation and probably a chunk of work to support that in nsHttpChannel. If we could not make it a blocking call, then a new api like that doesn't make sense.