Patrick McManus

Treating self-signed HTTPS as HTTP would be a behavior change with subtle implications that are hard to get right.

For instance, let's say that I log into https://example.com today, and it has a valid cert (but no HSTS). It sets a cookie with the "HTTPOnly" and "Secure" flags, indicating that it should only be sent over HTTPS, and not exposed to e.g. JS. I come back tomorrow, and https://example.com is now sporting a self-signed certificate.

There are now three possibilities for what's going on here. One is that this is an attack, so the browser should by default block the site. One is that the site downgraded to a self-signed certificate because they want to be treated as HTTP. One is that the site downgraded to a self-signed certificate because of misconfiguration, but you know out-of-band that it should be treated as HTTPS (the fingerprint matches what the support phone number tells you, or you're on a secure network, or something).

Those last two situations are different. In the former, that cookie should no longer get sent, just as it would not be sent to http://example.com. In the latter, it should be sent.

Right now, on the assumption that "intended to downgrade to HTTP with opportunistic encryption" is rare, the browser will put up a scary alert to make sure you're verifying the security of the connection out-of-band, and then send the cookie if you click through the warning. You'd have to somehow find a way for site owners to signal that they intend to do OE,…

Just code your site to do something sane with 3rd-party content blocked. E.g. handle load errors with fallbacks.

That way people with µMatrix or similar blockers can use the control tools they have instead of needing to do something site-specific.

Also, such decisions can't be remembered if cookies/localstorage are disabled. So prompting over and over again could also be annoying.

> 1. May we retrieve common libraries from third party CDNs? Doing so helps support this site by saving on our bandwidth costs, but may expose information about you to those third parties.

In an ideal world browsers would never send a cache-refresh request for resources tagged with SRI[0] because the hashes would guarantee that the content is 100% stable. Alas, it has non-trivial privacy implications, so they don't do that.

Maybe it could be implemented as a privacy addon with a whitelist for CDN domains, but then sites would still have to adopt SRI for that addon to do its work. Or maybe an addon that injects cache-control: immutable[1] to CDN could work too, but that's limited to https.

[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
[1] https://bitsup.blogspot.de/2016/05/cache-control-immutable.html

Your theory that it was just malware is easily disproven by reading the bug reports and blog posts from the years people spent trying to make this work.

Firefox found far from universal success even after years of testing and blacklisting known-noncompliant servers:

http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines-for-firefox.html

(the actual blacklist at the time
http://hg.mozilla.org/mozilla-central/file/1d122eaa9070/netwerk/protocol/http/nsHttpConnection.cpp#l666)

Opera's implementation apparently relied on some non-trivial heuristics but they apparently weren't well documented and were discontinued with the transition to Blink.

Similarly, it's easy to find cases where people discovered real problems in the wild with the iOS implementation:

http://tech.vg.no/2011/12/14/safari-on-ios-5-randomly-switches-images/

(This also affected Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=716840)

https://github.com/AFNetworking/AFNetworking/issues/528

It's easy to understand why people decided that it wasn't worth investing so much time in this when HTTP/2 would deliver significant additional benefits and by using TLS as a starting point could provably avoid the worst tampering proxies entirely.

I didn't have to look hard to find bug reports for pipelining. An example is https://bugs.launchpad.net/ubuntu/+source/apt/+bug/948461 for Amazon's S3. I'd be interested if the problem is still reproducible now. Also, one of the comments mentions Squid 2.0.2 as being buggy.

Also, see https://insouciant.org/tech/status-of-http-pipelining-in-chromium/ for a link to Firefox's blacklist of buggy servers (and a good discussion of pipelining in Chromium).

Most of the improvements in SPDY are latency improvements, so if you're downloading sites with netcat and then viewing them in a browser, I'm pretty sure the overhead of that would dwarf anything SPDY would save. That having been said, there's ample evidence of SPDY improving things. From http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines-for-firefox.html :

"Also see telemetry for TRANSACTION_WAIT_TIME_HTTP and TRANSACTON_WAIT_TIME_HTTP_PIPELINES - you'll see that pipelines do marginally reduce queuing time, but not by a heck of a lot in practice. (~65% of transactions are sent within 50ms using straight HTTP, ~75% with pipelining enabled).... Check out TRANSACTON_WAIT_TIME_SPDY and you'll see that 93% of all transactions wait less than 1ms in the queue!"

> By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why.

It's a "reasonable default", in the sense that it normally works quite well, and is easy to implement. The dangerous thing about congestion control is that it's really easy to get it wrong and not notice (as noticing requires performance testing and monitoring).

Google QUIC uses BBR on the server side. I wrote the initial version of said BBR implementation, and it took a lot of effort to get it to a production-ready state, so I would not generally recommend writing BBR from scratch. CUBIC is much simpler than BBR, but is also prone to subtle bugs like [0].

> 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution.

I'm actually curious what use cases you have in mind. TLS definitely does not cover 100% of all possible cases, but I've seen a surprising number of cases where people rolled their own thing when using (D)TLS would have just worked.

[0] http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-for-open-source.html

For more on the rationale behind this feature, see:

https://www.ietf.org/mail-archive/web/httpbisa/current/msg25463.html

https://bitsup.blogspot.co.uk/2016/05/cache-control-immutable.html

Rough summary:

> At Facebook, ... we've noticed that despite our nearly infinite expiration dates we see 10-20% of requests (depending on browser) for static resource being conditional revalidation. We believe this happens because UAs perform revalidation of requests if a user refreshes the page.

> A user who refreshes their Facebook page isn't looking for new versions of our _javascript_. Really they want updated content from our site. However UAs refresh all subresoruces of a page when the user refreshes a web page. This is designed to serve cases such as a weather site that says <img src="" ...

> Without an additional header, web sites are unable to control UA's behavior when the user uses the refresh button. UA's are rightfully hesitant in any solution that alters the long standing semantics of the refresh button (for example, not refreshing subresources).