Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hypertext Transfer Protocol Version 2

tools.ietf.org

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Hypertext Transfer Protocol Version 2

#11

Post by api »

diafygi wrote: post #6

There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.

At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.

Re: Hypertext Transfer Protocol Version 2

#13

Post by api »

stonogo wrote: post #9
johnrob wrote: post #8

Earlier quoted context omitted.

I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).

I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.

The world is full of clueless firewall administrators who block everything but port 80 and 443 because security. It inconveniences users a lot more than attackers, but if you try explaining this you get a bunch of cargo cultism about reducing attack surface area, etc.

Never mind that these protocols now tunnel everything and thus have equivalent attack surface area to just opening your network. I call it cargo cultism because these people superficially know security buzz-concepts but do not understand them deeply. The application of security concepts in this superficial way does tremendous harm, not to mention creating a false sense of security among the cargo cultists and their followers.

So we engage in an arms race with ourselves. We block everything, then design protocols to tunnel through our firewalls to reenable all the things we blocked, then repeat.

SSH is another penultimate tcp over tcp protocol.

The only real solution to the security problems these hacks fix is to fix operating system app and privilege isolation. But that's more work so let's just break IP with firewalls and then pretend it secures us.

Re: Hypertext Transfer Protocol Version 2

#14

Post by bkeroack »

api wrote: post #11
diafygi wrote: post #6

There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.

At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.

STARTTLS mixes concerns in a very bad way and is a horrible hack. Let it die with FTP and SMTP.

Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".

Re: Hypertext Transfer Protocol Version 2

#15

Post by johnrob »

stonogo wrote: post #9
johnrob wrote: post #8

Earlier quoted context omitted.

I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).

I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.

It's hard to beat the browser when it comes to building adequate software on a budget. It will never beat a native app in a race to be the best, but most software is about "making it work" instead of being #1 in the app store. The latter case of course gets a lot more press.

Re: Hypertext Transfer Protocol Version 2

#16

Post by dictum »

stonogo wrote: post #9
johnrob wrote: post #8

Earlier quoted context omitted.

I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).

I'm amused and depressed that the industry is willing to consider almost any solution -- except using something other than a web browser for tasks that do not involve browsing the web. Seriously... it works for Spotify, even now.

You say that as if cross platform development was easy.*

* (without cheating and effectively embedding a browser engine in your application.)

Re: Hypertext Transfer Protocol Version 2

#17

Post by 0x0 »

I'm curious to see how transparent proxies handle all the crazy framing (will poor software corrupt the bytestream?) and if there will be a wave of exploits for both client and server implementations; the complexity and subtleties appear to be almost a magnitude higher than http/1.

Re: Hypertext Transfer Protocol Version 2

#19

Post by 0x0 »

bkeroack wrote: post #14
api wrote: post #11

Earlier quoted context omitted.

At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.

STARTTLS mixes concerns in a very bad way and is a horrible hack. Let it die with FTP and SMTP. Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".

Faced with a choice of obtaining a TLS certificate or just going for the old HTTP/1.x protocol, it'd be a hard sell for HTTP/2 for any one-off, quick hack experiment/microsite/internal APIs...

Re: Hypertext Transfer Protocol Version 2

#20

Post by derefr »

johnrob wrote: post #8
stonogo wrote: post #7

The best description of this protocol I have seen is "TCP over TCP."

I wonder if most of the mileage here could be gained by simply augmenting javascript's networking capabilities, enabling the use of non-HTTP servers (and keeping the HTTP protocol simple).

HTTP is really good at being a generic RPC protocol, what with proxy support and authentication and caching and content negotiation and automatic redirects and chunked streaming and etc. etc. ad infinitum. This, and not the fact that web browsers use it, is why people implement their service APIs in HTTP.

When you give a developer a websocket/WebRTC data channel/etc. and tell them to do RPC over it as a "lower-overhead alternative to HTTP", you inevitably get badly-greenspun (and almost never actually-lower-overhead) HTTP. Making HTTP itself lower-overhead is the best decision in the medium-term.

(In the long term, an HTTP-compatible RPC protocol that runs directly over SCTP+DTLS would be pretty cool, though.)

Post reply on HN