InformAction Forums

Hi,

Firefox 37 enabled opportunistic encryption for HTTP/2 connections. It's a good thing, but depends on HTTP Alternative Services (Alt-svc), a concept that doesn't sound very secure, much less transparent. From what I read, alternative services allow an URL to be redirected in a silent way to a different host, while hiding that fact to the application layer (probably JavaScript, possibly the actual address bar ??, what about add-ons like ABP and NoScript ?). It is up to the implementer, Mozilla in our case, to decide whether the redirect can be seen in the browser console or during debugging.

Opportunistic encryption is good, but I don't know what to think of other uses of alternative services. Like, will we be able to trust the address bar in the future ? Or URLs being displayed on link hovering ? How will the various NoScript protection modules deal with this ? Won't some of them be made less efficient ?


I'm wondering whether I should disable Alt-svc altogether. (network.http.altsvc.enabled)


Here's the security considerations bit in the IETF draft.

Akamai and CDNs obfuscating real IP addresses and making whois lookups useless is frustrating, but if an URL can actually point to a different host than it says, I'm annoyed >_<

Wow, thanks for the heads up.

bgmnt wrote:I'm wondering whether I should disable Alt-svc altogether. (network.http.altsvc.enabled)

I'm going to disable this altogether in user.js for now, but I'm curious if there's an extension to intercept all loads using this feature, pause the load, and ask the user whether to go to the selected alternative? At least that way control and transparency would go back to the user so I wouldn't mind this feature.

My question is, are the security concerns sufficient that that extension could be NoScript?

Also, this sounds like a feature I removed from my fork of Adblock Plus for much the same concerns as yours here (this feature is now also removed from official ABP for other reasons).

My question is, are the security concerns sufficient that that extension could be NoScript?

I don't know, but if NoScript has an option to forbid meta refreshes, shouldn't it consider monitoring the use of HTTP alternative services as well ?
(I can't read well those IETF drafts and what they imply, so maybe I got some things wrong.)

I'm going to disable this altogether in user.js for now

If you disable alt-svc you probably can't benefit from opportunistic encryption either (network.http.altsvc.oe, I assume).

(this feature is now also removed from official ABP for other reasons).

Out of curiosity do you remember which one or which ABP version removed it ?

[Self quote]
Firefox 37 enabled opportunistic encryption for HTTP/2 connections.

And HTTP 1.1 too I think, but not HTTP 1.

bgmnt wrote:If you disable alt-svc you probably can't benefit from opportunistic encryption either (network.http.altsvc.oe, I assume).

I just don't like the idea of not knowing what I'm loading, sorry. That's why I refuse to use such a feature if it's at all opaque to me.
Sure I'll miss out on some benefits but at least what I see is what I get.

bgmnt wrote:

(this feature is now also removed from official ABP for other reasons).

Out of curiosity do you remember which one or which ABP version removed it ?

It wasn't this exact feature but a similar sounding idea.
Removed in https://hg.adblockplus.org/adblockplus/rev/47b81b7c76f5 so ABP 2.3 was the last to support it.
Their rationale is documented here.

I just don't like the idea of not knowing what I'm loading, sorry. That's why I refuse to use such a feature if it's at all opaque to me.

That irks me too. On the other hand, load balancing has been doing something similar for more than a decade. Instead of redirecting the browser to a separate host, the server is used as a proxy and decides which other server it will fetch the resource from before getting it back to the client. From that point of view, alt-svc just cuts out the proxy it seems.

I wish I knew someone knowledgeable enough to understand all the implications of such a feature and explain them in terms of security and privacy implications for the end user.

bgmnt wrote:

I just don't like the idea of not knowing what I'm loading, sorry. That's why I refuse to use such a feature if it's at all opaque to me.

That irks me too. On the other hand, load balancing has been doing something similar for more than a decade. Instead of redirecting the browser to a separate host, the server is used as a proxy and decides which other server it will fetch the resource from before getting it back to the client. From that point of view, alt-svc just cuts out the proxy it seems

That's true, but unfortunately alt-svc, being based on a HTTP header sent over the plain-text connection, considerably increases the attack surface by allowing both MITM and content injection attacks (similar to reflected XSS) to silently manipulate the real endpoint of a HTTP connection with no indication whatsover of what is happening.
Also, since alt-svc is not very well tested "on the field" yet, it's not unreasonable to expect some subtle, more or less critical, bugs to surface in the short period.
Therefore I'm disabling it as well, for the moment being at least.

Thanks it's clearer now. That settles it then, if both of you have it disabled I'm doing it too


I noticed that I actually disabled SPDY and HTTP/2 temporarily for similar reasons when they were released, ie. less fishy than alt-svc but young, not tested enough, and me unsure of the security and privacy implications. I'm starting to wonder whether I should enable some of them though.

network.http.spdy.enabled
network.http.spdy.enabled.deps (Dependencies ? New in Fx 37)
network.http.spdy.enabled.http2
network.http.spdy.enabled.http2draft
network.http.spdy.enabled.v3-1

And if SPDY is enabled:
network.http.spdy.allow-push
network.http.spdy.coalesce-hostnames ( https://groups.google.com/d/topic/spdy-dev/jDvy1DVyXO0 )

Giorgio Maone wrote:That's true, but unfortunately alt-svc, being based on a HTTP header sent over the plain-text connection, considerably increases the attack surface by allowing both MITM and content injection attacks (similar to reflected XSS) to silently manipulate the real endpoint of a HTTP connection with no indication whatsover of what is happening.
Also, since alt-svc is not very well tested "on the field" yet, it's not unreasonable to expect some subtle, more or less critical, bugs to surface in the short period.
Therefore I'm disabling it as well, for the moment being at least.

OK... in that case:

NoScript RFE: Please have NoScript warn the user about any alt-svc that tries to load something from a different domain/subdomain than what the user sees, and let the user decide whether to load the selected alternative. (Same-origin alt-svc has no significant concerns right?)

Mozilla arrived first: https://www.mozilla.org/en-US/security/ ... sa2015-44/
Already on Firefox 37.0.1

Yay, although they will reenable it at some point.

I wonder how the second security issue was fixed in 37.0.1. I guess I'll have to dig a little to figure out whether or not I have to disable Reader mode when it hits desktop release channel