Chromium to start marking HTTP as insecure

My point is, client software which hardcodes the application server's certificate or CA will simply reject the proxy's certificates or CA, because it's different from what's hardcoded.

An example: suppose I create a service which shows an alert on your smartphone when your bus is late. This service has two components: a server I control, and a client I put for download on Google Play. To protect the user's login, I use TLS between the client (on the user's smartphone) and the server.

Since I control both the client and the server, I don't need the traditional CA model. Instead, I hardcode the server's certificate hash in the client application source code. If it ever changes, I'll hardcode a new server certificate and put a new version of the client on Google Play.

That model is safer than the traditional CA model, since no third-party CA can ever produce a valid certificate for my server. The only way to produce a valid certificate is to either extract the private key from the server, or produce a modified version of the client application which accepts the new certificate.

That model also completely breaks transparent MITM proxies; even if the MITM root CA is imported into the phone, the application will ignore it and reject the connection with an "invalid certificate" error. The application is correct, since it knows that the server certificate does not come from that new CA (there is no distinction between a MITM CA and a normal CA that is new enough to not be in the default root CA store).

And notice that, if the proxy verifies the server certificate, it will reject it as invalid, since it's not signed by any CA on its list! But it's in fact the correct certificate for this application (and only for this application).

----

The MITM proxy model is broken. It exploits one of the worst problems of the current CA model: that any of the hundreds of CAs in the root CA list is trusted to create a valid certificate for any server. When that problem is fixed or worked around (as in my example), MITM proxies stop working.

We already see problems with certificate pining; browsers work around this by allowing any root CA which is on the root CA list but is *not* on the default root CA list (that is, any CA added by the user or by a malware) as trusted even for pinned domains (set security.cert_pinning.enforcement_level to 2 to disable that misfeature).

TLS enforces end-to-end security. MITM proxies, not being on either end, go against the TLS model. The correct solution would be to have a protocol where an explicitly configured client offloads TLS initiation to a trusted proxy, since it makes said proxy one of the ends; I don't think such a protocol exists at the moment, and even if it did exist, it wouldn't be implemented by most clients. If a client did implement it, it would be vulnerable to malware silently enabling the TLS offload, which would be a good reason for security-conscious developers to not implement such a protocol.

having them make their own checks after you have made yours is one thing. Trusting the users to do all the checks against the raw Internet is something very different.

BYOD is appropriate for some things and not for others. It's a different topic.

Actually, zeroing the bits was the best response. It just made ECN behave as non-ECN. IIRC, I even suggested it to someone at one point as an alternative (they were concerned about OS fingerprinting, which is a completely bogus concern IMHO).

Blocking ECN, on the other hand, completely breaks things. Their firewall was in front of a server; they have NO way of knowing whether some future, possibly experimental protocol (thus perhaps not even public yet) uses that bit as signaling, expecting it to be ignored if the server does not support the new protocol.

Note that you also have to zero out the negotiation. ECN seems to have grown a way to detect whether the server is cheating and pretending it didn't receive marked packets; if ECN is negotiated between two peers, erasing the marking will cause problems.

> How could the firewall know that it was safe for these bits to be set when they were unused at the time the firewall was written. It could easily have been an attack to take advantage of some bug in some vendor's TCP stack.

It could also easily be an attempt to take advantage of some feature in some vendor's TCP stack.

If a packet-validating firewall (as opposed to one which merely triggers on well-known fields like the TCP port) is in front of a server or client, it *must* know *all* the features which can possibly be used by that server or client's network stack, and the correct way to make it ignore unknown features at each part of the protocol. Otherwise, either a new feature introduced at both ends of the connection will make it get out of sync, or a new feature introduced at the uncontrolled (outside) end will cause connections to be incorrectly blocked.

New features to network protocols are almost always introduced in a backwards-compatible manner. Either or both endpoints set a flag or add an option to tell the other endpoint that they support the new feature. This allows new features to be introduced in an uncoordinated fashion, which is necessary for a decentralized architecture like the Internet. If the other endpoint doesn't support the new feature, it will just ignore it.

When you add a middlebox, this end-to-end model breaks. The middlebox is in front of one of the ends; if the other end is upgraded and now tries to negotiate a new feature, and the middlebox drops the connection in response, the communication between the endpoints breaks. If the middlebox doesn't drop the connection, things keep working, until the endpoint it's "protecting" is also upgraded; now both sides are speaking a new version of the protocol, and the middlebox gets out of sync. The only hope for the middlebox, therefore, is to scribble over the negotiation flags or options in both directions, so either end thinks the other end doesn't support the new feature and they keep speaking the old version of the protocol. But for the middlebox to do that, it has to know *every* place a feature negotiation flag or option can be found, and how to safely overwrite it with a NOP.

And that works only for non-security-sensitive protocols. Security-sensitive protocols tend to validate that an attacker didn't change any of the negotiation flags or options, because changing them could be used to force the connection to use a more vulnerable version of the protocol (a "downgrade attack"). On TLS, it's the Finished message, which checksums the whole protocol negotiation up to that point.

The problem with middleboxes is that they are from a different networking model. In what I could call a "hop-by-hop" or "gateway" model, for a computer at organization A to talk to a computer at organization B, it talks to organization A's gateway, which talks to organization B's gateway, which talks to the destination computer. Any feature negotiation is hop-by-hop; there's no chance of getting out of sync. The gateways are natural places to do all the protocol validation the organization desires.

The Internet, however, uses mostly an "end-to-end" model, where the computer at organization A talks directly to the computer at organization B. There is no place for middleboxes in that model. Any attempt is a kludge, which will sooner or later break.

The only valid solution, for those who insist in a "gateway" model, is to use an application-level gateway, that is, to take the middlebox out of the middle and make it be one of the ends. Instead of scrubbing packets to try to take out anything which could confuse the protected endpoint, make the connection terminate at the gateway and relay its contents to the protected endpoint in a separate connection. It's easy to see that this is much more robust against both new features and unknown bugs.

It works at a higher level, too. If you are concerned about HTTP-level attacks, make the connection terminate at an HTTP gateway, parse the request as an HTTP server would, create a new request from scratch as an HTTP client would, and send it to the real server. That's not transparent, since it will discard any details the gateway doesn't understand, but if you are of a "gateway" model mentality, transparency is precisely what you do not want.