Hacker News Reader

Comment by heipei | Hacker News Reader

I can't say this trend surprises me. Years back I was an IETF meeting when people were already mentioning that the old saying "IP over everything, everything over IP" was slowly being phase out for "HTTP over everything, everything over HTTP".

The thing to realize here is how much middleboxes sit between a client and a server, boxes which are aware of higher layers than just IP. It's impossible today to deploy an Internet-wide layer-4 protocol other than TCP or UDP, and increasingly it will be harder and harder to deploy a truly universal L7 protocol but HTTP. That's my limited view of this issue, how things like IPv6 might affect it I have no idea.

View on HN

Building a protocol over HTTP has the added benefit of making security easy. HTTP+TLS has a lot more eyeballs than protocols on lower levels. Most protocols on layer 3 and below weren't designed with security as a priority. If you are building a domain specific protocol, it's a lot easier to build on top of one which already has a good security story backed by a triumvirate of internet unicorns, than trying to re-invent the whole public key dance on a homebrewed setup.

SSL/TLS with other protocols have a lot of usage too.

SFTP/FTPS, SSH, SMTPS, etc.

SSH is a cryptographic network protocol that doesn't use SSL/TLS.

My bad. I should have said SSL/TLS/SSH.

* SFTP/FTPS (SSH)

* SSH (SSH)

* SMTPS (SSL, TLS)

Still wrong. FTPS is vanilla FTP over TLS.

> Still wrong

You know that thing that gives security practitioners a bad reputation with engineers?

You're doing it.

As opposed to this, why not something more like "it's not uncommon for these two to be confused, but FTPS is FTP over TLS and isn't interchangeable with SFTP"?

Because it's longer? Pardon my foreign mind, but I do not understand, why you are offended by a simple short and valid statement nor why you are differentiating between "security pratitioners" and "engineers".

FTPS is FTP over TLS. However SSH and SFTP has nothing to do with TLS.

You only need TLS for that. HTTP adds nothing security-wise.

It adds Authorization, WWW-Authenticate, Proxy-Authentication, Proxy-Authenticate, Cache-Control, but those aren't even used that consistently.

As others have commented (adding a couple of notes): HTTP and HTTP/2 use TLS for security which is over TCP (reliable transfer requirement). Nothing more, nothing less. Sure layer 3 and below have different considerations (reliability). Layer 4 (say TCP) covers the end to end security. It would be nice if HTTP/2 added something security wise, as was discussed, but the committee was conservative. Thus I am not sold to this argument. The rich functionality of HTTP and multiplexing of HTTP/2 sound appealing (sections 3.1-3.4), if you are building an API. If not I would not rush to that conclusion. Why would I want to add the necessity for streaming if I am doing a over the network video compression and do not care about reliability or want to skip frames for instance?

I guess it is IETFs job to standardize stuff so that is what they do -- for a hammer everything is a nail, right?

P.S. I skimmed it, so perhaps it is worth a read, but nothing caught my eye really.

> Building a protocol over HTTP has the added benefit of making security easy

Not to take away from that, it's also very easy to get wrong as well.

- Not doing CA verification check[1]

- No alerts/monitoring of new certificates used by the IDP

- No verification on certificate-transparency of new certificates used by the IDP

- No online CRL checking

If you do not do these things, then your application-on-HTTP is insecure. Remember that it's very easy to get a new certificate if you can break IP either by MITMing the server or by BGP takeover of some space near the CA. Both of these things have happened.

If there's a way you can detect incorrect implementations, then blacklist them. For example, I use OAuth2 in my own systems, but I require clients retry (by randomly failing during onboarding) and implement fuzzing whereby the client_secret is invalidated if they accept an invalid certificate.

[1]: http://web.archive.org/web/20120317165131/http://forum.devel...

Those eyeballs almost all belong to the Web Browser vendors who are almost exactly a proxy for the Operating System vendors, you mention them as three "unicorns", though it's hard to pick three, I have an easier time saying four, or maybe five.

Specifically they are Google's Chrome (Android), Microsoft's IE/Edge (Windows), Apple's Safari (iOS/ macOS) leaving only Mozilla's Firefox (standing in for the Free Unixes). If there's a fifth it's Oracle, as custodians of Java.

A tremendous weight ends up resting on the shoulders of these vendors, all of them based on the US West Coast, and it's not as though this a power _seized_ by them, it's more something everybody else shirked.

It is possible. You just don't care about people that have shitty admins. It works for games (mostly UDP) and nobody complains, perhaps because people shouldn't be playing in the office.

Just curious, what do you think of QUIC? Seems like a layer 4 replacement, right?

QUIC operates on top of UDP, which would make it layer 5.

QUIC is the transport layer (layer 4).

> QUIC is an experimental transport layer network protocol [1]

You can run layer 4 on top of layer 4. (Just as you could say, run TCP layer 4 on top of HTTP layer 7.)

[1] https://en.wikipedia.org/wiki/QUIC

The fact that Google chose to build QUIC on top of UDP rather than on top of IP directly shows that not even Google think it's possible to introduce any new Layer 4 protocol.

Reply on news.ycombinator.com