[monstermonster]

I don't understand your point.

80 and 443 are "well known ports"[1] which is fine.

What does this have to do with ports? TCP is connection based so a client can create as many connections as it likes to a port on a host.

If someone does indeed build a new "internet" built on top of HTTP which is tunnelled through well known ports with different services with the intention of circumventing the firewall then they will not be allowed through my firewall at all.

[1] https://www.ietf.org/rfc/rfc1700.txt

[dcsommer]

The problem is that opening new connections is horribly inefficient. The 2-3 round trips (TCP + SSL) required to set up a new connection and the ensuing slow start phase significantly delay the request, and thus the response. It is much more performant to use a single, well-utilized connection in congestion avoidance. The only way to avoid the ugliness of repeated flow control is to build on top of UDP (see QUIC), but there are practical issues with network connectivity and firewalls there.

EDIT: why do you want to block HTTP/2 by the way? You know that HTTP/1.1 can be used to tunnel other protocols too, right?

[monstermonster]

That's not horribly inefficient. That's the cost of doing business with HTTP.

In fact you're going to have to go to the same effort to establish a TCP connection that your HTTP/2 is going to run over, then still have to do a key exchange. That channel then has the same advantages of a persistent HTTP/1.1 channel plus the ability to provide multiple streams.

The multiple streams can be resolved simply by making more than one connection to the server defensively. Perhaps a mechanism to schedule that client-side would work. Oh wait, we already have one (connection limits and keep-alive).

Then again, all of this is moot as once you've loaded the static resources (images/css/js etc) via HTTP, you should only be seeing one request periodically when an operation takes place or at an interval if polling or kept alive for server-push so maximum two connections from a client to a server.

If you need to do anything more than that, you're probably using the wrong technology both on the server and client.

HTTP/1.1 tunnelling I understand. In fact I use it most of the day (RDP over terminal services gateway) which is RPC over HTTP.

The rationale I have is that effectively managing HTTP/2.0 at the firewall requires packet and protocol inspection rather than merely understanding what connections have been made and where from and where to. This has a significant complexity and tooling cost and effort. Plus there is a significant opportunity to mask illegitimate traffic as legitimate traffic. For those of us who deal with end user network security, this is a major problem.