14 ms·

HTTP/2.0 — Bad protocol, bad politics

219 points by ibotty 12y ago

ibotty 12y ago
phk (poul henning kamp) is the lead developer of varnish, in case people are not familiar with him.
- brohee 12y ago
  His technical prowess are only matched by his privacy champion credentials, see e.g. his Operation ORCHESTRA talk https://www.youtube.com/watch?v=fwcl17Q0bpk https://www.youtube.com/watch?v=fwcl17Q0bpk
  - Argorak 12y ago
    I can also recommend this one, which - strangely - turns into a privacy/security discussion for the second part of the talk. http://www.infoq.com/presentations/HTTP-Performance http://www.infoq.com/presentations/HTTP-Performance
  - tomwilde 12y ago
    > Local governments have no desire to spend resources negotiating SSL/TLS with every single smartphone in their area when things explode, rivers flood, or people are poisoned. That's one horrible argument, though. The cost of a text-based protocol on ethernet, over TCP greatly outweighs the cost of the encryption process. Yes, of course encrypting things will increase computational requirements yet the cost is negligible in comparison to the problem being solved (stopping the trade of personal data). It's hard for me to associate a privacy champion with these statements.
- discreditable 12y ago
  Isn't this the guy that basically refuses to implement SSL/TLS in varnish[1]? The more cynical part of me wonders if that has anything to do with his rejection of HTTPS everywhere. [1] https://www.varnish-cache.org/docs/trunk/phk/ssl.html https://www.varnish-cache.org/docs/trunk/phk/ssl.html
  - phkamp 12y ago
    Show me a quality implementation of SSL/TLS I can use ? All the ones I've looked at are shitty source code.
    - wmf 12y ago
      Why hold yourself to a much higher standard than your customers do? Even though OpenSSL is shitty, everyone still uses it.
      - phkamp 12y ago
        That's actually a very good question, thank you for asking it. Because I think that we can do much better than the pile of IT-shit we have produced until now. I am actively trying to do that, through my own code, through the articles that I write and through the discussions I engage in. Not everybody has the luxury of doing that -- the kids have to be fed and the mortgage has to be paid and a job is a job -- but those of us who can, have an obligation to try to make the world a better place, by raising quality if IT.
    - yellowapple 12y ago
      What about LibreSSL? -- Freely licensed -- Has been ported to FreeBSD -- Is certainly less of a tangled mess than OpenSSL
      - phkamp 12y ago
        It is certainly a step in the right direction, my main worry is that the OpenBSD crew has a tendency to to -- SQUIRREL!! and forget their old toy when they spot a new shiny one.
        yellowapple 12y ago
        They do? I personally haven't seen much of that, though I'm admittedly relatively new to the BSD world, so perhaps I just haven't been watching/using the BSDs long enough to notice that sort of tendency in OpenBSD relative to the others. I know they've been making a lot of switches lately in terms of what ships with the base OS, but pretty much all of them (that I know of) have been more akin to forgetting someone else's old toys and playing with their own shiny new ones. OpenSSH and PF in particular seem to still be alive and well, and they've been around for quite a long time.
- hsivonen 12y ago
  Indeed, so keep in mind that he has a vested interest in being able to use the FreeBSD feature to efficiently copy a file from a disk into a network interface. Having to break stuff into protocol frames or having every byte have compute done on it for encryption foils his optimization. It doesn't mean that his optimization is more important than TCP connection sharing and ubiquitous confidentiality, integrity and authenticity. (Edit: typo)
atc 12y ago
That's the second post by phk I've really enjoyed. The other being on "A Generation Lost in the Bazaar": http://queue.acm.org/detail.cfm?id=2349257 http://queue.acm.org/detail.cfm?id=2349257
johngd 12y ago
"Has everybody in IETF forgotten CNN's exponential traffic graph from 14 years ago?" Any ideas?
- tomwilde 12y ago
  Seriously though, 14 years in internet time is about 1400 years. Whatever was on that graph is probably not relevant today.
- Matthias247 12y ago
  I guess it's a reference to september 11th 2001.
teddyh 12y ago
As I keep having to mention: The omission of the use of SRV records is maddening, and the reasons given don’t make any sense. https://news.ycombinator.com/item?id=8550133 https://news.ycombinator.com/item?id=8550133 https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8404788
- tobz 12y ago
  From the responses given to your linked comments, it seems like there was a technically valid reason not to use them: performance You just kept pushing that it wasn't a good enough reason. Are you just going to keep posting and asking until people decide you're right and they're wrong?
  - marcosdumay 12y ago
    Take a better look at the responses. There's no inherent reason for the performance degradation (it's mainly because of noncompliance on Bind), and without it we are stuck with the much slower HTTP redirects.
    - teddyh 12y ago
      Yes. Also CDNs and having your servers in the Cloud™ for automatic failover would be no longer necessary. So of course every company providing these services are against it. These companies are also, of course, the “stakeholders” interested in development of HTTP/2.
  - teddyh 12y ago
    There actually is no performance problem. The closest anyone has come to a substantiation of that claim is to say, in essence, “If there is a buggy resolver somewhere which completely ignores SRV queries, the client would have to wait for a timeout.”. But this is not the normal, or even commonly occurring, case! SRV does not have such problems, or at least not enough for people to avoid using it for other protocols such as autodiscovery or Minecraft.
    - 12y ago
akerl_ 12y ago
"HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc." I wish the article had spent more time talking about these things rather than rambling about "politics". "HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." That would have destroyed any hope of adoption by content providers and probably browsers. "HTTP/2.0 will require a lot more computing power than HTTP/1.1 and thus cause increased CO2 pollution adding to climate change." Citation? That said, I'm not considerably shocked that web standards aren't judged based on the impact of whatever computing devices may end up using them on their power grids and those power grids' use of energy sources. "The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL anywhere" agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption." In the same paragraph, the author complains that HTTP/2.0 has no concern for privacy and then that they attempted to force encryption on everybody. "There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on." This is so close to "think of the children" that I don't even know how to respond. The listed groups may have restrictions placed on them in certain settings that ensure their communications are monitored. But this doesn't prevent HTTP/2.0 with TLS from existing: there are a variety of other avenues by which their respective higher-ups can monitor the connections of those under their control.
- ibotty 12y ago
  > That would have destroyed any hope of adoption by content providers and probably browsers. why adoption by browsers?
  - akerl_ 12y ago
    I'm less sure browsers wouldn't adopt, but if content providers are slow to adopt due to massive changes in how they handle sessions / tracking / everything else they do with cookies, browsers are not incentivized to adopt. I suspect it would end up looking similar to IPv6: Unless ISPs are providing the majority of users with IPv6, software developers aren't well incentivized to support IPv6 in their software. Similarly to browsers, they'd lose very little for supporting the new standard now, but the gains are low while adoption by the other group is low.
stephen_g 12y ago
I really don't understand this bit: > Local governments have no desire to spend resources negotiating SSL/TLS with every single smartphone in their area when things explode, rivers flood, or people are poisoned. I remember some concerns about performance of TLS five to ten years ago, but these days is anybody really worried about that? I remember seeing some benchmarks (some from Google when they were making HTTPS default, as well as other people) that it hardly adds a percent of extra CPU or memory usage or something like that. Also, these days HTTPS certificates can be had for similar prices to domains, and hopefully later this year the Let's Encrypt project should mean free high quality certificates are easily available. With that in mind, forcing HTTPS is pretty much going to be only a good thing.
- aroch 12y ago
  Even if not the CPU cost, I don't think small-town, USA IT wants to deal with incompatibilities between clients when SSL is enforced (ie. no SNI on pre-GB Android phones/winXP, only some [weak] ciphers available in IE etc) not necessarily the individual compute increase. To address what you've said, increasing the energy consumption of every internet connected device in the world will probably have noticeable effects on the aggregate (more power for the server, more power to cool the server, etc.).
  - acdha 12y ago
    “small-town, USA IT” has to outsource as much as possible anyway because their budgets have been cut annually for a long time. Spending an extra $100/year on an SSL certificate is the least of their worries if they're not simply using outside services for as much as possible. > increasing the energy consumption of every internet connected device in the world will probably have noticeable effects on the aggregate How would this compare to the energy used by e.g. a single wasteful banner ad campaign? Do you really think that it makes sense to be concerned with the part which is increasingly executed by optimized hardware?
- workermonkey 12y ago
  On my load balancers it is more like 5-10%. Not terrible, but not trivial either. Also, it multiplies throughout the environment. If you are dealing with PII or financials, everything needs to be encrypted on the wire. Load balancer decrypts, looks at headers, decides what to do, re-encrypts, down to the app tier, decrypt, respond encrypted, etc. I'm not saying that is a bad thing, but that's why some people get cranky. Somewhat unrelated, compressed headers in HTTP 2.0 makes sense if you only think about the browser, it saves 'repeated' information. The problem is the LB has to decrypt them every time anyways, so someone still have to do the work, it just isn't on the wire. Server push on the other hand could be awesome for performance (pre-cache the resources for the next page in a flow) but also has the potential for abuse.
bayesianhorse 12y ago
After learning how public key infrastructure really works, I've become quite disillusioned by the security it seems to provide. After all, what use is a certification authority, if basically any authoritarian state and intelligence service can get on that list? In some countries the distinction between government officials, spies and organized crime is already extremely blurry...
- stephen_g 12y ago
  You can remove their CA certificates from your browser/OS and if you click the lock icon on your browser you can check what CA the website you're on was signed. You're right to say that the PKI doesn't work if you just want to trust any site that shows a padlock in the address bar, but it's useful if you do a little work.
  - bayesianhorse 12y ago
    I can't modify the CA lists of my users...
    - shawn-butler 12y ago
      Ship your own browser.
  - darkarmani 12y ago
    > You're right to say that the PKI doesn't work if you just want to trust any site that shows a padlock in the address bar, but it's useful if you do a little work. Not it isn't. It still suffers from not respecting name constraints. You can't setup trust for only a list of domains. If i run my own CA for some list of domains, there is no way i can prevent my CA from being able to sign for google.com. Instead people use wildcard certs so they can be delegated responsibility for a subdomain.
    - mike_hearn 12y ago
      You can get a certificate for a fixed list of domains. If name constraints were implemented more widely, that'd be great. But someone has to write the code, debug it, ship it, etc, and then you have to wait until lots of people have upgraded, etc, and ultimately wildcard certs work well enough.
zimbatm 12y ago
The article is basically a rant. I was hoping the author would go more into layer violation issues. Most of the interesting stuff from HTTP/2.0 comes from the better multiplexing of requests over a single TCP connection. It feels like we would have been better off removing multiplexing from HTTP altogether and then adopt SCTP instead of TCP for the lower transport. Or maybe he had other things in mind. > There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on. This argument is quite weak, SSL can easily be MITMed if you control the host, generate custom certs and make all the traffic go trough your regulated proxy.
- aidenn0 12y ago
  In the early days of SPDY there was an article comparing SPDY to HTTP/1.1 over SCTP. The short version was other than the lack of header compression, it got nearly all the wins of SPDY, except: 1) Unless tunneled over UDP (which has its own problems) failed to work with NATs and stateful firewalls. 2) HTTP(s) only environments (e.g. some big corporations) would not work with it; SPDY will look enough like HTTPS to fool most of these. 3) Lack of Windows and OS X support for SCTP (without installing a 3rd party driver) means tunneling over UDP.
  - worklogin 12y ago
    Yes, changing from TCP is about as difficult as changing from IPv4 - it would take years, and it would take a) catastrophic emergencies like IPv4's address exhaustion or b) completely passive, low-effort transitions/dual stack over years. Note that TCP processing is built into the hardware of all modern network ASICs from your PC to backbone routers and firewalls. Unfortunate, but true.
  - gsnedders 12y ago
    What are the problems with SCTP over UDP, except the obvious extra (eight byte) overhead?
    - aidenn0 12y ago
higherpurpose 12y ago
HTTPS can also be used to protect you from malware [1] [2] and stop censorship [3]. If anything, news sites should be among the first to adopt strong HTTPS connections since many people visit them and the news also needs to not be censored. [1] https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ https://citizenlab.org/2014/08/cat-video-and-the-death-of-cl... [2] http://www.ap.org/Content/AP-In-The-News/2014/AP-Seattle-Times-Upset-About-FBI-Impersonation http://www.ap.org/Content/AP-In-The-News/2014/AP-Seattle-Tim... [3] http://ben.balter.com/2015/01/06/https-all-the-things/ http://ben.balter.com/2015/01/06/https-all-the-things/ As for the performance side, SPDY is probably not perfect, but it seems to generally improve over current HTTP, even if it uses secure connection. But even if it didn't, using HTTPS seems to add negligible overhead, and compared to the security it gives I think it's well worth it. https://www.httpvshttps.com/ https://www.httpvshttps.com/
- deleted 12y ago
  [deleted]
kalleboo 12y ago
> The so-called "multimedia business," which amounts to about 30% of all traffic on the net, expresses no desire to be forced to spend resources on pointless encryption. I thought that "pointless encryption" was basically the definition of DRM? And the largest video site, traffic-wise (YouTube) is already encrypted.
- stingraycharles 12y ago
  I thought Netflix was the largest video site, traffic-wise?
  - kalleboo 12y ago
    Seems like it depends on who you ask. I imagine something closer to the truth is that Netflix are bigger in the US but YouTube are bigger globally.
acaloiar 12y ago
This is the sort of self-important technorant that I've come to despise in tech news. It is another example of a blogger pandering to readers' absurd addiction with outrage. HTTP/2.0 is not an outrage. It is imperfect, just as HTTP/1.1 is imperfect and ill-suited to today's rich web applications that were not envisioned at its inception. [edit] It's a bit ironic that this story was delivered to many of us (via Hacker News) over SPDY--HTTP/2.0's dominant source of inspiration.
- MatthewWilkes 12y ago
  Considering phk works as a developer for a very popular HTTP based application (Varnish) and contributed to competing specs for HTTP2 he's hardly a pandering blogger. He's an expert annoyed that the improvements in standards in his field are absurdly slow and perfectly entitled to voice his ire.
  - acaloiar 12y ago
    He is no doubt perfectly entitled to rant. I'm also fairly confident that phk has contributed to more important projects vital to the tech ecosystem than I ever will. I simply argue that there are more constructive and productive ways to go about pointing out a protocol's flaws. Phk has had issues with the process for quite some time, and I feel that his embitterment about the process has jaded his view of the protocol. Phk on SPDY/HTTP/2.0 http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0815.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...
    - jerf 12y ago
      "I simply argue that there are more constructive and productive ways to go about pointing out a protocol's flaws." Which he has done: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html It's a pet peeve of mine when people just fling this sort of accusation about as if every word-count limited column isn't any good unless it's 20 times longer and basically includes half of Wikipedia transitively. It's a column in a trade magazine. There isn't a place for a detailed technical discussion there, so complaining that there isn't one is complaining about something that can't be fixed. Besides, cards on the table, I think he's basically correct, cynicism and all here. Sometimes the right answer is to just say no, and failure to say no is not good thing when that is what is called for.
joosters 12y ago
Twenty-six years later, [...] the HTTP protocol is still the same. Not true at all. Early HTTP (which became known as HTTP/0.9) was very primitive and very different from what is used today. It was five or six years until HTTP/1.0 emerged, with a format similar to what we have today.
- TazeTSchnitzel 12y ago
  Thank you, I was going to point it out myself. Early HTTP was literally just this: GET /somepath That's it. Nothing more (well, that and a CRLF), nothing less. The response was equally barren: just pure HTML. Existent page? HTML. Non-existent page? HTML error message. Plaintext file? HTML. (The text is wrapped in a <plaintext> tag.) Anything else? Probably HTML, though you could also deliver binary files this way (good luck reliably distinguishing HTML and binary without a MIME type)! I actually like HTTP/0.9. If you're stuck in some weird programming language without an HTTP/1.1 client (HTTP/1.0 is useless because it lacks Host:, while HTTP/0.9 actually does support shared hosts, just use a fully-qualified URI) you can just open a TCP port to a web server and send a GET request the old fashioned way.
GotAnyMegadeth 12y ago
> One remarkable property of this name is that the abbreviation "WWW" has twice as many syllables and takes longer to pronounce. World Wide Web Dou Ble U Dou Ble U Dou Ble U I count three times as many, is this an accent thing?
- tobz 12y ago
  I think it's an accent thing. When I say WWW at normal speed, it sounds more like dubble-u dubble-u dubble-u. American, east coast USA.
  - barrkel 12y ago
    Unless you say "duh blew duh blew duh blew", you're still using 9 syllables rather than six 6.
    - tobz 12y ago
      I'm not arguing that it's nine syllables, just saying that it's most likely an accent / speed of speech thing as far as the author's six-vs-four thing goes.
- coriny 12y ago
  Maybe in Danish it's only 6 syllables? Because the English language completely agrees with you.
- teh 12y ago
  Most people I know pronounce it dub-dub-dub so I started doing that as well. Maybe a London thing?
- laichzeit0 12y ago
  I say "triple double u".
cpach 12y ago
Upvoted, not because I think it is a particularly good article, but we seem to have a pretty good discussion based on it.
blfr 12y ago
If there are already so many ways to fingerprint via cookies, JavaScript, Flash, etc. that it probably doesn't matter then why do cookies matter? That the EU parliament decided to pass some weird law is not much of an argument. They're not exactly known for their technological proficiency. And it did nothing for privacy. It only annoys people[1]. Sure, we could start with cookies. However, that would break a lot of the web with no immediate benefit. On SSL everywhere (not "anywhere"), how much resources does it cost to negotiate SSL/TLS with every single smartphone in their area? Supposedly, not much[2]. I run https websites on an Atom server. Frankly, that was rather unconvincing. Although it does seem likely than the entire process was driven by IETF trying to stay politically relevant in the face of SPDY. [1] https://github.com/r4vi/block-the-eu-cookie-shit-list https://github.com/r4vi/block-the-eu-cookie-shit-list [2] https://istlsfastyet.com/#cpu-latency https://istlsfastyet.com/#cpu-latency
- stingraycharles 12y ago
  For what it's worth, the cookie law in the EU is far more general than cookies, and had a totally different origin. Originally, the law was to require explicit consent when installing something on an electronic device, to combat malware. However, some clever politicians later realized that setting a cookie also "installs" something on an electronic device, and thus the law further known as the cookie law was passed. If a webserver were to set some secure session identifier, the same laws still apply -- just as installing software without explicit consent is covered by the same law.
  - boracay 12y ago
    Not if you are using the session identifier for it's intended purpose, see the exceptions at: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#section_2 http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#se...
    - stingraycharles 12y ago
      We all know how broad "intended usage" can be defined. Google has a cookie that is required for logging in into gmail (clearly intended usage), but is reusing that exact same cookie for tracking purposes. Until there is actual legal precedence after people sueing businesses abusing these abilities, I have no idea how to interpret these laws other than "they are very broad and vague".
cflat 12y ago
Nitpick - It's HTTP/2 not HTTP/2.0 We've all learned from the failure of SNI and IPv6 to gain widespread adoption. (Thank you windows xp and Android 2.2) HTTP/2 has been designed with the absolute priority of graceful backward compatibility. This creates limits and barriers on what you can do. Transparent and graceful backward compatibility will be essential for adoption. I agree, HTTP/2 is Better - not perfect. But better is still better.
- nly 12y ago
  Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough').
  - dragonwriter 12y ago
    > Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough'). HTTP/2 isn't really like IPv6 in that fewer people need to act to adopt it -- if the browser vendors do (which they are already) and the content providers do (which some of the biggest are already), then its used. Its specifically designed to be compatible with existing intermediate layers (particularly when used with TLS on https connections) so that as long as the endpoints opt in, no one else needs to get involved -- and with one of the biggest content providers also being a browser vendor who is also one of the biggest HTTP/2 proponents... IPv6 requires support at more different levels (client/server/ISP infrastructure software & routers, ISPs actually deciding to use it when their hardware/software supports it, application software and both client and server ends, etc.) which makes adoption more complex.
    - ethbro 12y ago
      > > Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough'). > HTTP/2 isn't really like IPv6 in that fewer people need to act to adopt it -- if the browser vendors do (which they are already) and the content providers do (which some of the biggest are already), then its used. I, for one, welcome the HTTP/1.x+2 future of 5-10 years from now. (Obligatory http://xkcd.com/927/ http://xkcd.com/927/ )
peterwwillis 12y ago
"HTTP/2.0 will be SSL/TLS only" Yes! Finally 99% of users won't be hacked by a default initial plaintext connection! We finally have safe(r) browsing. ", in at least three out of four of the major browsers," You had ONE JOB! Jokes aside, privacy wasn't a consideration in this protocol. Mandatory encryption is really useful for security, but privacy is virtually unaffected. And the cookie thing isn't even needed; every browser today could implement a "click here to block cookies from all requests originating from this website" button. We need the option to remove encryption. But it should be the opposite of what we currently do, which is to default to plaintext unless you type an extra magic letter into the address (which no user ever understands, and is still potentially insecure). We should be secure by default, but allow non-secure connections if you type an extra letter. Proxies could be handled this way by allowing content providers to explicitly mark content (or domains) as plaintext-accessible. The problem I fear is as everyone adopts HTTP/2 and HTTP/1.1 becomes obsolete (not syntactically but as a strict protocol) it may no longer be possible to write a quick-and-dirty HTTP implementation. Before I could use a telnet client on a router to test a website; now the router may need an encryption library, binary protocol parser, decompression and multiplexing routines to get a line of text back.
dragonwriter 12y ago
> The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL anywhere" agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption. What is the basis of this claim? ISTR that SPDY and the first drafts of HTTP/2 were TLS-only, and that some later drafts had provisions which either required or recommended TLS on public connections but supported unencrypted TCP for internal networks, but the current version seems to support TLS and unencrypted TCP equally.
- wmf 12y ago
  Unencrypted HTTP/2 is a fake concession that isn't usable in the real world.
  - dragonwriter 12y ago
    The only respect in which that appears to be true is that no major browser vendor has yet committed to supporting HTTP/2 other than over TLS-encrypted connections. But given that that both some HTTP/2-supporting browssers and much of the server-side software supporting HTTP/2 is open source, and given that all the logic will be implemented and the only change will be allowing it on unencrypted TCP connection, it'll probably be fairly straightforward to anyone who cares much to put the proof of concept of the value of unencrypted HTTP/2 together. OTOH, the main gain of HTTP/2 seems to be on secure connections, so I'm not sure why one would want unencrypted HTTP/2 over unencrypted HTTP/1.1, and given that no browser seems to have short-term plans to stop supporting HTTP/1.1, there's probably no real use case. But the protocol supports unencrypted use just fine.
    - aidenn0 12y ago
      IIRC, the main issue with nonTLS HTTP/2 is broken web proxies. This is why Google deployed SPDY in https only, and also why they didn't use SCTP as the basis, but instead reinvented about 50% of it on top of TCP. Google didn't want something that would break even a tiny percentage of existing installs.
jbb555 12y ago
Couldn't agree with most of this more. HTTP/2.0 seems to be me to be an entirely pointless set of unwanted complications and agendas disguised as technical improvements.
phkamp 12y ago
I have go go shopping and cook dinner, but if I'll be back in a couple of hours. Poul-Henning
tanglesome 12y ago
When an article about technical problems with a protocol starts whining about how the protocol will increase CO2 pollution I know it's BS. WTH was the ACM thinking by wasting out time with this crap?
tanglesome 12y ago
When an article about technical problems with a protocol starts whining about how the protocol will increase CO2 pollution I know it's BS. WTH was the ACM thinking by wasting out time with this crap?
bad_user 12y ago
"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." It doesn't make much sense to get rid of cookies alone, not when there are multiple ways of storing stuff in a user's browser, let alone for fingerprinting - http://samy.pl/evercookie/ http://samy.pl/evercookie/ Getting rid of cookies doesn't really help with privacy at this point and just wait until IPv6 becomes more widespread. Speaking of which, that EU requirement is totally stupid. The author also makes the mistake of thinking that we need privacy protections only from the NSA or other global threats. That's not true, we also need privacy protections against local threats, such as your friendly local Internet provider, that can snoop in on your traffic and even inject their own content into the web pages served. I've seen this practice several times, especially on open wifi networks. TLS/SSL isn't relevant only for authentication security, but also for ensuring that the content you receive is the content that you asked for. It's also useful for preventing middle-men from seeing your traffic, such as your friendly network admin at the company you're working for. For example if I open this web page with plain HTTP, a middle-man can see that I'm reading a rant on HTTP/2.0, instead of seeing just a connection to queue.acm.org. From this it can immediately build a useful profile for me, because only somebody with software engineering skills would know about HTTP, let alone read a rant on IETF's handling of version 2.0. It could also inject content, such as ads or a piece of Javascript that tracks my movement or whatever. So what's that line about "many HTTP applications have no need for [SSL]" doing in a rant lamenting on privacy? HTTP/2.0 probably has flaws, but this article is a rant about privacy and I feel that it gets it wrong, as requiring encrypted connections is the thing that I personally like about HTTP/2.0 or SPDY. Having TLS/SSL everywhere would also make it more costly for the likes of NSA to do mass surveillance of user's traffic, so it would have benefits against global threats as well.
- phkamp 12y ago
  Actually, getting rid of cookies would fit almost all HTTP requests into a single packet, so there are tangible technical benefits, even without the privacy benefits. You seem confused about cryptography. Against NSA we only need secrecy, privacy is not required. Likewise integrity does not require secrecy, but authentication (which doesn't require secrecy either). You don't think that anybody can figure out what you are doing when you open a TCP connection to queue.acm.org right after they posted a new article, even if that connection is encrypted ? Really ? How stupid do you think NSA is ? Have you never heard of meta-data collection ? And if you like your encrypted connections so much, you should review at the certs built into your browser: That's who you trust. I'll argue that's not materially better than unencrypted HTTP. (See also Operation Orchestra, I don't think you perceive the scale of what NSA is doing)
cromwellian 12y ago
I'll just leave this here: http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html In 1995, the process began for HTTP to be replaced by a ground up redesign. The HTTP-NG project went on for several years and failed. I have zero confidence that a ground up protocol that completely replaces major features of the existing protocol used by millions of sites and would require substantial application level changes (e.g. switching from cookies to some other mechanism) would a) get through a standards committee in 10 years and b) get implemented and deployed in a reasonable fashion. We're far into 'worse is better' territory now. Technical masterpieces are the enemy of the good. It's unlikely HTTP is going to be replaced with a radical redesign anymore than TCP/IP is going to be replaced. Reading PHK's writings, his big problem with HTTP/2 seems to be that it is not friendly to HTTP routers. So, a consortium of people just approved a protocol that does not address the needs of one's major passion, http routers, and a major design change is desired to support this use case. I think the only way HTTP is going to be changed in that way is if it is disrupted by some totally new paradigm, that comes from a new application platform/ecosystem, and not as an evolution of the Web. For example, perhaps some kind of Tor/FreeNet style system.
- phkamp 12y ago
  Yes, clearly nothing has changed since 1995 at all, obviously nobody has gotten any wiser or anything. My big problem with HTTP/2 is that it's crap that doesn't solve any of the big problems.
  - MichaelGG 12y ago
    You say that, but as a small site operator, my experience is that I add the characters "SPDY" to my nginx config, and clients are happy cause stuff loads faster. Why did nothing happen since the HTTP1.1 spec? Everyone say around until Google decided to move stuff forward.
skywhopper 12y ago
Interesting that one of the primary developers of FreeBSD does not understand one of the two major use cases for SSL, namely identity assurance. News sites and local governments don't care about privacy when transmitting news or emergency information, true, but citizens should be concerned about making sure that information is coming from who they think it's coming from. I'm no fan of HTTP/2, but this article does not effectively argue against it. Too many bare assertions without any meat to them. And when you fail to mention a major purpose of a protocol (SSL) you dismiss as useless, you lose a lot of credibility.
- mst 12y ago
  I would have found your comment rather more useful had you led with the technical point rather than an attack on the author.
  - skywhopper 12y ago
    I don't understand. I did not attack the author, and describing the purpose of SSL is a technical point.
- phkamp 12y ago
  SSL does not provide identity assurance (=authentication), the CA-cabal does, SSL just does the necessary math for you. CA's are trojaned, that's documented over and over by bogus certs in the wild, so in practice you have no authentication when it comes down to it. Authentication is probably the hardest thing for us, as citizens to get, because all the intelligence agencies of the world will attempt to trojan it. Secrecy on the other hand, we can have that trivially with self-signed certs, but for some reason browsers treat those as if they were carriers of Ebola.
  - arielby 12y ago
    That's an argument against showing scary warnings on self-signed certs, not against SSL. It would be nice if there was a httpr:// scheme that would be like HTTPS but without certificate checking.
ak217 12y ago
The argument about computing power and CO2 pollution is misguided. HTTP/2 no longer requires encryption, so the TLS/non-TLS trade-offs remain the same as before (and their compute impact is mitigated by hardware AES support, etc.). The other relevant changes (SPDY, header compression, push) reduce the number of context switches and network round-trips required and the total time required for devices to spend in high power mode, and for the user to spend waiting. That results in a reduction, not increase, in total power consumption. Taking server CPU utilization numbers as an indicator of total power consumption is pretty misguided in this context, and my understanding is that even those are optimized (and will continue to be optimized) to the point where TLS and SPDY have negligible overhead (or, in the case of SPDY, may even result in lower CPU usage).
- phkamp 12y ago
  Show me the mainstream browsers that will use HTTP/2 without SSL/TLS ? The difference between you and me, may be that I have spent a lot of time measuring computers power usage doing all sorts of things. You seem to be mostly guessing ?
  - ak217 12y ago
    I don't have Kill-a-Watts or rack PDU data for fleets of webservers, unfortunately. What I do have is CPU performance data from running with and without SSL gateways and SPDY in production, and all I can say is that the server's CPU utilization is not significantly impacted by them. I also have client-side data that shows substantial load speed improvements when using SPDY. That should result in a C-state profile improvement on the CPU, but I'll need to collect more data to confirm.
arielby 12y ago
What's exactly the difference between cookies and session identifiers exactly? There's no law requiring you to send kilobytes of cookies (news.ycombinator.com gets by with a 22-byte cookie). Of course the way HTTP cookies handle ambient authority is rather imperfect, but that can be solved within the system.
- phkamp 12y ago
  The difference is who makes the decisions: session id is controlled by the client. cookies by the server. FaceBook, Twitter etc. track you all over the internet with their cookies, even if you don't have an account with them, whenever a site puts up one of their icons for you to press "like". With client controlled session identifies, uses would get to choose if they wanted that. The reason YC gets by with 22 bytes is probably that they're not trying to turn the details of your life into their product.
biggot_man 12y ago
I dont care about IETF or HTTP/2. Ill just keep using HTTP/1.1. It works on my computer.
jlebar 12y ago
> The same browsers, ironically, treat self-signed certificates as if they were mortally dangerous, despite the fact that they offer secrecy at trivial cost. (Secrecy means that only you and the other party can decode what is being communicated. Privacy is secrecy with an identified or authenticated other party.) I'm frustrated to read this myth being propagated. We should know better. In the presence of only passive network attackers, sure, self-signed certs buy you something. But we know that the Internet is chock-full of powerful active attackers. It's not just NSA/GHCQ, but any ISP, including Comcast, Gogo, Starbucks, and a random network set up by a wardriver that your phone happened to auto-connect to. A self-signed cert buys you nothing unless you trust every party in the middle not to alter your traffic [1]. If you can't know whom you're talking to, the fact that your communications are private to you and that other party is useless. I totally agree that the CA system has its flaws -- maybe you'll say that it's no better in practice than using self-signed certs, and you might be right -- but my point is that unauthenticated encryption is not useful as a widespread practice on the web. Browser vendors got this one right. [1] Unless you pin the cert, I suppose, and then the only opportunity to MITM you is your first connection to the server. But then either you can never change the cert, which is a non-option, or otherwise users will occasionally have to click through a scary warning like what ssh gives. Users will just click yes, and indeed that's the right thing to do in 99% of cases, but now your encryption scheme is worthless. Also, securing first connections is useful.
- phkamp 12y ago
  self-signed-certs is about making NSA&friends work for it, rather than giving them a free ride. Today they can grep plaintext as they want. With SSC's they would have to pinpoint what communication they really need to see. That would be a major and totally free improvement in privacy for everybody. As for why the browsers so consistently treat SSC's as ebola: I'm pretty sure NSA made that happen -- they would be stupid not to do so.
  - deleted 12y ago
    [deleted]
  - jlebar 12y ago
ademarre 12y ago
> the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative. What principles does he claim the IETF is conceding here?
cnst 12y ago
A very well written rant. HTTP is supposed to have had opportunistic encryption, as per RFC 7258 (Pervasive Monitoring Is an Attack, https://news.ycombinator.com/item?id=7963228 https://news.ycombinator.com/item?id=7963228), but it looks like the corporate overlords don't really understand why is it at all a problem for the independent one-man projects to acquire and update certificates every year, for every little site. As per a recent conversation with Ilya Grigorik over at nginxconf, Google's answer to the cost and/or maintenance issues of https --- just use CloudFlare! Because letting one single party do MITM for the entire internet is so sane and secure, right?

219 points by ibotty 12y ago

ibotty 12y ago

phk (poul henning kamp) is the lead developer of varnish, in case people are not familiar with him.

brohee 12y ago
His technical prowess are only matched by his privacy champion credentials, see e.g. his Operation ORCHESTRA talk https://www.youtube.com/watch?v=fwcl17Q0bpk https://www.youtube.com/watch?v=fwcl17Q0bpk
- Argorak 12y ago
  I can also recommend this one, which - strangely - turns into a privacy/security discussion for the second part of the talk. http://www.infoq.com/presentations/HTTP-Performance http://www.infoq.com/presentations/HTTP-Performance
- tomwilde 12y ago
  > Local governments have no desire to spend resources negotiating SSL/TLS with every single smartphone in their area when things explode, rivers flood, or people are poisoned. That's one horrible argument, though. The cost of a text-based protocol on ethernet, over TCP greatly outweighs the cost of the encryption process. Yes, of course encrypting things will increase computational requirements yet the cost is negligible in comparison to the problem being solved (stopping the trade of personal data). It's hard for me to associate a privacy champion with these statements.
discreditable 12y ago
Isn't this the guy that basically refuses to implement SSL/TLS in varnish[1]? The more cynical part of me wonders if that has anything to do with his rejection of HTTPS everywhere. [1] https://www.varnish-cache.org/docs/trunk/phk/ssl.html https://www.varnish-cache.org/docs/trunk/phk/ssl.html
- phkamp 12y ago
  Show me a quality implementation of SSL/TLS I can use ? All the ones I've looked at are shitty source code.
  - wmf 12y ago
    Why hold yourself to a much higher standard than your customers do? Even though OpenSSL is shitty, everyone still uses it.
    - phkamp 12y ago
      That's actually a very good question, thank you for asking it. Because I think that we can do much better than the pile of IT-shit we have produced until now. I am actively trying to do that, through my own code, through the articles that I write and through the discussions I engage in. Not everybody has the luxury of doing that -- the kids have to be fed and the mortgage has to be paid and a job is a job -- but those of us who can, have an obligation to try to make the world a better place, by raising quality if IT.
  - yellowapple 12y ago
    What about LibreSSL? -- Freely licensed -- Has been ported to FreeBSD -- Is certainly less of a tangled mess than OpenSSL
    - phkamp 12y ago
      It is certainly a step in the right direction, my main worry is that the OpenBSD crew has a tendency to to -- SQUIRREL!! and forget their old toy when they spot a new shiny one.
      - yellowapple 12y ago
        They do? I personally haven't seen much of that, though I'm admittedly relatively new to the BSD world, so perhaps I just haven't been watching/using the BSDs long enough to notice that sort of tendency in OpenBSD relative to the others. I know they've been making a lot of switches lately in terms of what ships with the base OS, but pretty much all of them (that I know of) have been more akin to forgetting someone else's old toys and playing with their own shiny new ones. OpenSSH and PF in particular seem to still be alive and well, and they've been around for quite a long time.
hsivonen 12y ago
Indeed, so keep in mind that he has a vested interest in being able to use the FreeBSD feature to efficiently copy a file from a disk into a network interface. Having to break stuff into protocol frames or having every byte have compute done on it for encryption foils his optimization. It doesn't mean that his optimization is more important than TCP connection sharing and ubiquitous confidentiality, integrity and authenticity. (Edit: typo)

atc 12y ago

That's the second post by phk I've really enjoyed. The other being on "A Generation Lost in the Bazaar": http://queue.acm.org/detail.cfm?id=2349257 http://queue.acm.org/detail.cfm?id=2349257

johngd 12y ago

"Has everybody in IETF forgotten CNN's exponential traffic graph from 14 years ago?" Any ideas?

tomwilde 12y ago
Seriously though, 14 years in internet time is about 1400 years. Whatever was on that graph is probably not relevant today.
Matthias247 12y ago
I guess it's a reference to september 11th 2001.

teddyh 12y ago

As I keep having to mention: The omission of the use of SRV records is maddening, and the reasons given don’t make any sense. https://news.ycombinator.com/item?id=8550133 https://news.ycombinator.com/item?id=8550133 https://news.ycombinator.com/item?id=8404788 https://news.ycombinator.com/item?id=8404788

tobz 12y ago
From the responses given to your linked comments, it seems like there was a technically valid reason not to use them: performance You just kept pushing that it wasn't a good enough reason. Are you just going to keep posting and asking until people decide you're right and they're wrong?
- marcosdumay 12y ago
  Take a better look at the responses. There's no inherent reason for the performance degradation (it's mainly because of noncompliance on Bind), and without it we are stuck with the much slower HTTP redirects.
  - teddyh 12y ago
    Yes. Also CDNs and having your servers in the Cloud™ for automatic failover would be no longer necessary. So of course every company providing these services are against it. These companies are also, of course, the “stakeholders” interested in development of HTTP/2.
- teddyh 12y ago
  There actually is no performance problem. The closest anyone has come to a substantiation of that claim is to say, in essence, “If there is a buggy resolver somewhere which completely ignores SRV queries, the client would have to wait for a timeout.”. But this is not the normal, or even commonly occurring, case! SRV does not have such problems, or at least not enough for people to avoid using it for other protocols such as autodiscovery or Minecraft.
  - 12y ago

akerl_ 12y ago

"HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc." I wish the article had spent more time talking about these things rather than rambling about "politics". "HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." That would have destroyed any hope of adoption by content providers and probably browsers. "HTTP/2.0 will require a lot more computing power than HTTP/1.1 and thus cause increased CO2 pollution adding to climate change." Citation? That said, I'm not considerably shocked that web standards aren't judged based on the impact of whatever computing devices may end up using them on their power grids and those power grids' use of energy sources. "The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL anywhere" agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption." In the same paragraph, the author complains that HTTP/2.0 has no concern for privacy and then that they attempted to force encryption on everybody. "There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on." This is so close to "think of the children" that I don't even know how to respond. The listed groups may have restrictions placed on them in certain settings that ensure their communications are monitored. But this doesn't prevent HTTP/2.0 with TLS from existing: there are a variety of other avenues by which their respective higher-ups can monitor the connections of those under their control.

ibotty 12y ago
> That would have destroyed any hope of adoption by content providers and probably browsers. why adoption by browsers?
- akerl_ 12y ago
  I'm less sure browsers wouldn't adopt, but if content providers are slow to adopt due to massive changes in how they handle sessions / tracking / everything else they do with cookies, browsers are not incentivized to adopt. I suspect it would end up looking similar to IPv6: Unless ISPs are providing the majority of users with IPv6, software developers aren't well incentivized to support IPv6 in their software. Similarly to browsers, they'd lose very little for supporting the new standard now, but the gains are low while adoption by the other group is low.

stephen_g 12y ago

I really don't understand this bit: > Local governments have no desire to spend resources negotiating SSL/TLS with every single smartphone in their area when things explode, rivers flood, or people are poisoned. I remember some concerns about performance of TLS five to ten years ago, but these days is anybody really worried about that? I remember seeing some benchmarks (some from Google when they were making HTTPS default, as well as other people) that it hardly adds a percent of extra CPU or memory usage or something like that. Also, these days HTTPS certificates can be had for similar prices to domains, and hopefully later this year the Let's Encrypt project should mean free high quality certificates are easily available. With that in mind, forcing HTTPS is pretty much going to be only a good thing.

aroch 12y ago
Even if not the CPU cost, I don't think small-town, USA IT wants to deal with incompatibilities between clients when SSL is enforced (ie. no SNI on pre-GB Android phones/winXP, only some [weak] ciphers available in IE etc) not necessarily the individual compute increase. To address what you've said, increasing the energy consumption of every internet connected device in the world will probably have noticeable effects on the aggregate (more power for the server, more power to cool the server, etc.).
- acdha 12y ago
  “small-town, USA IT” has to outsource as much as possible anyway because their budgets have been cut annually for a long time. Spending an extra $100/year on an SSL certificate is the least of their worries if they're not simply using outside services for as much as possible. > increasing the energy consumption of every internet connected device in the world will probably have noticeable effects on the aggregate How would this compare to the energy used by e.g. a single wasteful banner ad campaign? Do you really think that it makes sense to be concerned with the part which is increasingly executed by optimized hardware?
workermonkey 12y ago
On my load balancers it is more like 5-10%. Not terrible, but not trivial either. Also, it multiplies throughout the environment. If you are dealing with PII or financials, everything needs to be encrypted on the wire. Load balancer decrypts, looks at headers, decides what to do, re-encrypts, down to the app tier, decrypt, respond encrypted, etc. I'm not saying that is a bad thing, but that's why some people get cranky. Somewhat unrelated, compressed headers in HTTP 2.0 makes sense if you only think about the browser, it saves 'repeated' information. The problem is the LB has to decrypt them every time anyways, so someone still have to do the work, it just isn't on the wire. Server push on the other hand could be awesome for performance (pre-cache the resources for the next page in a flow) but also has the potential for abuse.

bayesianhorse 12y ago

After learning how public key infrastructure really works, I've become quite disillusioned by the security it seems to provide. After all, what use is a certification authority, if basically any authoritarian state and intelligence service can get on that list? In some countries the distinction between government officials, spies and organized crime is already extremely blurry...

stephen_g 12y ago
You can remove their CA certificates from your browser/OS and if you click the lock icon on your browser you can check what CA the website you're on was signed. You're right to say that the PKI doesn't work if you just want to trust any site that shows a padlock in the address bar, but it's useful if you do a little work.
- bayesianhorse 12y ago
  I can't modify the CA lists of my users...
  - shawn-butler 12y ago
    Ship your own browser.
- darkarmani 12y ago
  > You're right to say that the PKI doesn't work if you just want to trust any site that shows a padlock in the address bar, but it's useful if you do a little work. Not it isn't. It still suffers from not respecting name constraints. You can't setup trust for only a list of domains. If i run my own CA for some list of domains, there is no way i can prevent my CA from being able to sign for google.com. Instead people use wildcard certs so they can be delegated responsibility for a subdomain.
  - mike_hearn 12y ago
    You can get a certificate for a fixed list of domains. If name constraints were implemented more widely, that'd be great. But someone has to write the code, debug it, ship it, etc, and then you have to wait until lots of people have upgraded, etc, and ultimately wildcard certs work well enough.

zimbatm 12y ago

The article is basically a rant. I was hoping the author would go more into layer violation issues. Most of the interesting stuff from HTTP/2.0 comes from the better multiplexing of requests over a single TCP connection. It feels like we would have been better off removing multiplexing from HTTP altogether and then adopt SCTP instead of TCP for the lower transport. Or maybe he had other things in mind. > There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on. This argument is quite weak, SSL can easily be MITMed if you control the host, generate custom certs and make all the traffic go trough your regulated proxy.

aidenn0 12y ago
In the early days of SPDY there was an article comparing SPDY to HTTP/1.1 over SCTP. The short version was other than the lack of header compression, it got nearly all the wins of SPDY, except: 1) Unless tunneled over UDP (which has its own problems) failed to work with NATs and stateful firewalls. 2) HTTP(s) only environments (e.g. some big corporations) would not work with it; SPDY will look enough like HTTPS to fool most of these. 3) Lack of Windows and OS X support for SCTP (without installing a 3rd party driver) means tunneling over UDP.
- worklogin 12y ago
  Yes, changing from TCP is about as difficult as changing from IPv4 - it would take years, and it would take a) catastrophic emergencies like IPv4's address exhaustion or b) completely passive, low-effort transitions/dual stack over years. Note that TCP processing is built into the hardware of all modern network ASICs from your PC to backbone routers and firewalls. Unfortunate, but true.
- gsnedders 12y ago
  What are the problems with SCTP over UDP, except the obvious extra (eight byte) overhead?
  - aidenn0 12y ago

higherpurpose 12y ago

HTTPS can also be used to protect you from malware [1] [2] and stop censorship [3]. If anything, news sites should be among the first to adopt strong HTTPS connections since many people visit them and the news also needs to not be censored. [1] https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ https://citizenlab.org/2014/08/cat-video-and-the-death-of-cl... [2] http://www.ap.org/Content/AP-In-The-News/2014/AP-Seattle-Times-Upset-About-FBI-Impersonation http://www.ap.org/Content/AP-In-The-News/2014/AP-Seattle-Tim... [3] http://ben.balter.com/2015/01/06/https-all-the-things/ http://ben.balter.com/2015/01/06/https-all-the-things/ As for the performance side, SPDY is probably not perfect, but it seems to generally improve over current HTTP, even if it uses secure connection. But even if it didn't, using HTTPS seems to add negligible overhead, and compared to the security it gives I think it's well worth it. https://www.httpvshttps.com/ https://www.httpvshttps.com/

deleted 12y ago
[deleted]

kalleboo 12y ago

> The so-called "multimedia business," which amounts to about 30% of all traffic on the net, expresses no desire to be forced to spend resources on pointless encryption. I thought that "pointless encryption" was basically the definition of DRM? And the largest video site, traffic-wise (YouTube) is already encrypted.

stingraycharles 12y ago
I thought Netflix was the largest video site, traffic-wise?
- kalleboo 12y ago
  Seems like it depends on who you ask. I imagine something closer to the truth is that Netflix are bigger in the US but YouTube are bigger globally.

acaloiar 12y ago

This is the sort of self-important technorant that I've come to despise in tech news. It is another example of a blogger pandering to readers' absurd addiction with outrage. HTTP/2.0 is not an outrage. It is imperfect, just as HTTP/1.1 is imperfect and ill-suited to today's rich web applications that were not envisioned at its inception. [edit] It's a bit ironic that this story was delivered to many of us (via Hacker News) over SPDY--HTTP/2.0's dominant source of inspiration.

MatthewWilkes 12y ago
Considering phk works as a developer for a very popular HTTP based application (Varnish) and contributed to competing specs for HTTP2 he's hardly a pandering blogger. He's an expert annoyed that the improvements in standards in his field are absurdly slow and perfectly entitled to voice his ire.
- acaloiar 12y ago
  He is no doubt perfectly entitled to rant. I'm also fairly confident that phk has contributed to more important projects vital to the tech ecosystem than I ever will. I simply argue that there are more constructive and productive ways to go about pointing out a protocol's flaws. Phk has had issues with the process for quite some time, and I feel that his embitterment about the process has jaded his view of the protocol. Phk on SPDY/HTTP/2.0 http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0815.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/...
  - jerf 12y ago
    "I simply argue that there are more constructive and productive ways to go about pointing out a protocol's flaws." Which he has done: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html It's a pet peeve of mine when people just fling this sort of accusation about as if every word-count limited column isn't any good unless it's 20 times longer and basically includes half of Wikipedia transitively. It's a column in a trade magazine. There isn't a place for a detailed technical discussion there, so complaining that there isn't one is complaining about something that can't be fixed. Besides, cards on the table, I think he's basically correct, cynicism and all here. Sometimes the right answer is to just say no, and failure to say no is not good thing when that is what is called for.

joosters 12y ago

Twenty-six years later, [...] the HTTP protocol is still the same. Not true at all. Early HTTP (which became known as HTTP/0.9) was very primitive and very different from what is used today. It was five or six years until HTTP/1.0 emerged, with a format similar to what we have today.

TazeTSchnitzel 12y ago
Thank you, I was going to point it out myself. Early HTTP was literally just this: GET /somepath That's it. Nothing more (well, that and a CRLF), nothing less. The response was equally barren: just pure HTML. Existent page? HTML. Non-existent page? HTML error message. Plaintext file? HTML. (The text is wrapped in a <plaintext> tag.) Anything else? Probably HTML, though you could also deliver binary files this way (good luck reliably distinguishing HTML and binary without a MIME type)! I actually like HTTP/0.9. If you're stuck in some weird programming language without an HTTP/1.1 client (HTTP/1.0 is useless because it lacks Host:, while HTTP/0.9 actually does support shared hosts, just use a fully-qualified URI) you can just open a TCP port to a web server and send a GET request the old fashioned way.

GotAnyMegadeth 12y ago

> One remarkable property of this name is that the abbreviation "WWW" has twice as many syllables and takes longer to pronounce. World Wide Web Dou Ble U Dou Ble U Dou Ble U I count three times as many, is this an accent thing?

tobz 12y ago
I think it's an accent thing. When I say WWW at normal speed, it sounds more like dubble-u dubble-u dubble-u. American, east coast USA.
- barrkel 12y ago
  Unless you say "duh blew duh blew duh blew", you're still using 9 syllables rather than six 6.
  - tobz 12y ago
    I'm not arguing that it's nine syllables, just saying that it's most likely an accent / speed of speech thing as far as the author's six-vs-four thing goes.
coriny 12y ago
Maybe in Danish it's only 6 syllables? Because the English language completely agrees with you.
teh 12y ago
Most people I know pronounce it dub-dub-dub so I started doing that as well. Maybe a London thing?
laichzeit0 12y ago
I say "triple double u".

cpach 12y ago

Upvoted, not because I think it is a particularly good article, but we seem to have a pretty good discussion based on it.

blfr 12y ago

If there are already so many ways to fingerprint via cookies, JavaScript, Flash, etc. that it probably doesn't matter then why do cookies matter? That the EU parliament decided to pass some weird law is not much of an argument. They're not exactly known for their technological proficiency. And it did nothing for privacy. It only annoys people[1]. Sure, we could start with cookies. However, that would break a lot of the web with no immediate benefit. On SSL everywhere (not "anywhere"), how much resources does it cost to negotiate SSL/TLS with every single smartphone in their area? Supposedly, not much[2]. I run https websites on an Atom server. Frankly, that was rather unconvincing. Although it does seem likely than the entire process was driven by IETF trying to stay politically relevant in the face of SPDY. [1] https://github.com/r4vi/block-the-eu-cookie-shit-list https://github.com/r4vi/block-the-eu-cookie-shit-list [2] https://istlsfastyet.com/#cpu-latency https://istlsfastyet.com/#cpu-latency

stingraycharles 12y ago
For what it's worth, the cookie law in the EU is far more general than cookies, and had a totally different origin. Originally, the law was to require explicit consent when installing something on an electronic device, to combat malware. However, some clever politicians later realized that setting a cookie also "installs" something on an electronic device, and thus the law further known as the cookie law was passed. If a webserver were to set some secure session identifier, the same laws still apply -- just as installing software without explicit consent is covered by the same law.
- boracay 12y ago
  Not if you are using the session identifier for it's intended purpose, see the exceptions at: http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#section_2 http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#se...
  - stingraycharles 12y ago
    We all know how broad "intended usage" can be defined. Google has a cookie that is required for logging in into gmail (clearly intended usage), but is reusing that exact same cookie for tracking purposes. Until there is actual legal precedence after people sueing businesses abusing these abilities, I have no idea how to interpret these laws other than "they are very broad and vague".

cflat 12y ago

Nitpick - It's HTTP/2 not HTTP/2.0 We've all learned from the failure of SNI and IPv6 to gain widespread adoption. (Thank you windows xp and Android 2.2) HTTP/2 has been designed with the absolute priority of graceful backward compatibility. This creates limits and barriers on what you can do. Transparent and graceful backward compatibility will be essential for adoption. I agree, HTTP/2 is Better - not perfect. But better is still better.

nly 12y ago
Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough').
- dragonwriter 12y ago
  > Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough'). HTTP/2 isn't really like IPv6 in that fewer people need to act to adopt it -- if the browser vendors do (which they are already) and the content providers do (which some of the biggest are already), then its used. Its specifically designed to be compatible with existing intermediate layers (particularly when used with TLS on https connections) so that as long as the endpoints opt in, no one else needs to get involved -- and with one of the biggest content providers also being a browser vendor who is also one of the biggest HTTP/2 proponents... IPv6 requires support at more different levels (client/server/ISP infrastructure software & routers, ISPs actually deciding to use it when their hardware/software supports it, application software and both client and server ends, etc.) which makes adoption more complex.
  - ethbro 12y ago
    > > Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough'). > HTTP/2 isn't really like IPv6 in that fewer people need to act to adopt it -- if the browser vendors do (which they are already) and the content providers do (which some of the biggest are already), then its used. I, for one, welcome the HTTP/1.x+2 future of 5-10 years from now. (Obligatory http://xkcd.com/927/ http://xkcd.com/927/ )

peterwwillis 12y ago

"HTTP/2.0 will be SSL/TLS only" Yes! Finally 99% of users won't be hacked by a default initial plaintext connection! We finally have safe(r) browsing. ", in at least three out of four of the major browsers," You had ONE JOB! Jokes aside, privacy wasn't a consideration in this protocol. Mandatory encryption is really useful for security, but privacy is virtually unaffected. And the cookie thing isn't even needed; every browser today could implement a "click here to block cookies from all requests originating from this website" button. We need the option to remove encryption. But it should be the opposite of what we currently do, which is to default to plaintext unless you type an extra magic letter into the address (which no user ever understands, and is still potentially insecure). We should be secure by default, but allow non-secure connections if you type an extra letter. Proxies could be handled this way by allowing content providers to explicitly mark content (or domains) as plaintext-accessible. The problem I fear is as everyone adopts HTTP/2 and HTTP/1.1 becomes obsolete (not syntactically but as a strict protocol) it may no longer be possible to write a quick-and-dirty HTTP implementation. Before I could use a telnet client on a router to test a website; now the router may need an encryption library, binary protocol parser, decompression and multiplexing routines to get a line of text back.

dragonwriter 12y ago

> The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL anywhere" agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption. What is the basis of this claim? ISTR that SPDY and the first drafts of HTTP/2 were TLS-only, and that some later drafts had provisions which either required or recommended TLS on public connections but supported unencrypted TCP for internal networks, but the current version seems to support TLS and unencrypted TCP equally.

wmf 12y ago
Unencrypted HTTP/2 is a fake concession that isn't usable in the real world.
- dragonwriter 12y ago
  The only respect in which that appears to be true is that no major browser vendor has yet committed to supporting HTTP/2 other than over TLS-encrypted connections. But given that that both some HTTP/2-supporting browssers and much of the server-side software supporting HTTP/2 is open source, and given that all the logic will be implemented and the only change will be allowing it on unencrypted TCP connection, it'll probably be fairly straightforward to anyone who cares much to put the proof of concept of the value of unencrypted HTTP/2 together. OTOH, the main gain of HTTP/2 seems to be on secure connections, so I'm not sure why one would want unencrypted HTTP/2 over unencrypted HTTP/1.1, and given that no browser seems to have short-term plans to stop supporting HTTP/1.1, there's probably no real use case. But the protocol supports unencrypted use just fine.
  - aidenn0 12y ago
    IIRC, the main issue with nonTLS HTTP/2 is broken web proxies. This is why Google deployed SPDY in https only, and also why they didn't use SCTP as the basis, but instead reinvented about 50% of it on top of TCP. Google didn't want something that would break even a tiny percentage of existing installs.

jbb555 12y ago

Couldn't agree with most of this more. HTTP/2.0 seems to be me to be an entirely pointless set of unwanted complications and agendas disguised as technical improvements.

phkamp 12y ago

I have go go shopping and cook dinner, but if I'll be back in a couple of hours. Poul-Henning

tanglesome 12y ago

When an article about technical problems with a protocol starts whining about how the protocol will increase CO2 pollution I know it's BS. WTH was the ACM thinking by wasting out time with this crap?

tanglesome 12y ago

When an article about technical problems with a protocol starts whining about how the protocol will increase CO2 pollution I know it's BS. WTH was the ACM thinking by wasting out time with this crap?

bad_user 12y ago

"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." It doesn't make much sense to get rid of cookies alone, not when there are multiple ways of storing stuff in a user's browser, let alone for fingerprinting - http://samy.pl/evercookie/ http://samy.pl/evercookie/ Getting rid of cookies doesn't really help with privacy at this point and just wait until IPv6 becomes more widespread. Speaking of which, that EU requirement is totally stupid. The author also makes the mistake of thinking that we need privacy protections only from the NSA or other global threats. That's not true, we also need privacy protections against local threats, such as your friendly local Internet provider, that can snoop in on your traffic and even inject their own content into the web pages served. I've seen this practice several times, especially on open wifi networks. TLS/SSL isn't relevant only for authentication security, but also for ensuring that the content you receive is the content that you asked for. It's also useful for preventing middle-men from seeing your traffic, such as your friendly network admin at the company you're working for. For example if I open this web page with plain HTTP, a middle-man can see that I'm reading a rant on HTTP/2.0, instead of seeing just a connection to queue.acm.org. From this it can immediately build a useful profile for me, because only somebody with software engineering skills would know about HTTP, let alone read a rant on IETF's handling of version 2.0. It could also inject content, such as ads or a piece of Javascript that tracks my movement or whatever. So what's that line about "many HTTP applications have no need for [SSL]" doing in a rant lamenting on privacy? HTTP/2.0 probably has flaws, but this article is a rant about privacy and I feel that it gets it wrong, as requiring encrypted connections is the thing that I personally like about HTTP/2.0 or SPDY. Having TLS/SSL everywhere would also make it more costly for the likes of NSA to do mass surveillance of user's traffic, so it would have benefits against global threats as well.

phkamp 12y ago
Actually, getting rid of cookies would fit almost all HTTP requests into a single packet, so there are tangible technical benefits, even without the privacy benefits. You seem confused about cryptography. Against NSA we only need secrecy, privacy is not required. Likewise integrity does not require secrecy, but authentication (which doesn't require secrecy either). You don't think that anybody can figure out what you are doing when you open a TCP connection to queue.acm.org right after they posted a new article, even if that connection is encrypted ? Really ? How stupid do you think NSA is ? Have you never heard of meta-data collection ? And if you like your encrypted connections so much, you should review at the certs built into your browser: That's who you trust. I'll argue that's not materially better than unencrypted HTTP. (See also Operation Orchestra, I don't think you perceive the scale of what NSA is doing)

cromwellian 12y ago

I'll just leave this here: http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html In 1995, the process began for HTTP to be replaced by a ground up redesign. The HTTP-NG project went on for several years and failed. I have zero confidence that a ground up protocol that completely replaces major features of the existing protocol used by millions of sites and would require substantial application level changes (e.g. switching from cookies to some other mechanism) would a) get through a standards committee in 10 years and b) get implemented and deployed in a reasonable fashion. We're far into 'worse is better' territory now. Technical masterpieces are the enemy of the good. It's unlikely HTTP is going to be replaced with a radical redesign anymore than TCP/IP is going to be replaced. Reading PHK's writings, his big problem with HTTP/2 seems to be that it is not friendly to HTTP routers. So, a consortium of people just approved a protocol that does not address the needs of one's major passion, http routers, and a major design change is desired to support this use case. I think the only way HTTP is going to be changed in that way is if it is disrupted by some totally new paradigm, that comes from a new application platform/ecosystem, and not as an evolution of the Web. For example, perhaps some kind of Tor/FreeNet style system.

phkamp 12y ago
Yes, clearly nothing has changed since 1995 at all, obviously nobody has gotten any wiser or anything. My big problem with HTTP/2 is that it's crap that doesn't solve any of the big problems.
- MichaelGG 12y ago
  You say that, but as a small site operator, my experience is that I add the characters "SPDY" to my nginx config, and clients are happy cause stuff loads faster. Why did nothing happen since the HTTP1.1 spec? Everyone say around until Google decided to move stuff forward.

skywhopper 12y ago

Interesting that one of the primary developers of FreeBSD does not understand one of the two major use cases for SSL, namely identity assurance. News sites and local governments don't care about privacy when transmitting news or emergency information, true, but citizens should be concerned about making sure that information is coming from who they think it's coming from. I'm no fan of HTTP/2, but this article does not effectively argue against it. Too many bare assertions without any meat to them. And when you fail to mention a major purpose of a protocol (SSL) you dismiss as useless, you lose a lot of credibility.

mst 12y ago
I would have found your comment rather more useful had you led with the technical point rather than an attack on the author.
- skywhopper 12y ago
  I don't understand. I did not attack the author, and describing the purpose of SSL is a technical point.
phkamp 12y ago
SSL does not provide identity assurance (=authentication), the CA-cabal does, SSL just does the necessary math for you. CA's are trojaned, that's documented over and over by bogus certs in the wild, so in practice you have no authentication when it comes down to it. Authentication is probably the hardest thing for us, as citizens to get, because all the intelligence agencies of the world will attempt to trojan it. Secrecy on the other hand, we can have that trivially with self-signed certs, but for some reason browsers treat those as if they were carriers of Ebola.
- arielby 12y ago
  That's an argument against showing scary warnings on self-signed certs, not against SSL. It would be nice if there was a httpr:// scheme that would be like HTTPS but without certificate checking.

ak217 12y ago

The argument about computing power and CO2 pollution is misguided. HTTP/2 no longer requires encryption, so the TLS/non-TLS trade-offs remain the same as before (and their compute impact is mitigated by hardware AES support, etc.). The other relevant changes (SPDY, header compression, push) reduce the number of context switches and network round-trips required and the total time required for devices to spend in high power mode, and for the user to spend waiting. That results in a reduction, not increase, in total power consumption. Taking server CPU utilization numbers as an indicator of total power consumption is pretty misguided in this context, and my understanding is that even those are optimized (and will continue to be optimized) to the point where TLS and SPDY have negligible overhead (or, in the case of SPDY, may even result in lower CPU usage).

phkamp 12y ago
Show me the mainstream browsers that will use HTTP/2 without SSL/TLS ? The difference between you and me, may be that I have spent a lot of time measuring computers power usage doing all sorts of things. You seem to be mostly guessing ?
- ak217 12y ago
  I don't have Kill-a-Watts or rack PDU data for fleets of webservers, unfortunately. What I do have is CPU performance data from running with and without SSL gateways and SPDY in production, and all I can say is that the server's CPU utilization is not significantly impacted by them. I also have client-side data that shows substantial load speed improvements when using SPDY. That should result in a C-state profile improvement on the CPU, but I'll need to collect more data to confirm.

arielby 12y ago

What's exactly the difference between cookies and session identifiers exactly? There's no law requiring you to send kilobytes of cookies (news.ycombinator.com gets by with a 22-byte cookie). Of course the way HTTP cookies handle ambient authority is rather imperfect, but that can be solved within the system.

phkamp 12y ago
The difference is who makes the decisions: session id is controlled by the client. cookies by the server. FaceBook, Twitter etc. track you all over the internet with their cookies, even if you don't have an account with them, whenever a site puts up one of their icons for you to press "like". With client controlled session identifies, uses would get to choose if they wanted that. The reason YC gets by with 22 bytes is probably that they're not trying to turn the details of your life into their product.

biggot_man 12y ago

I dont care about IETF or HTTP/2. Ill just keep using HTTP/1.1. It works on my computer.

jlebar 12y ago

> The same browsers, ironically, treat self-signed certificates as if they were mortally dangerous, despite the fact that they offer secrecy at trivial cost. (Secrecy means that only you and the other party can decode what is being communicated. Privacy is secrecy with an identified or authenticated other party.) I'm frustrated to read this myth being propagated. We should know better. In the presence of only passive network attackers, sure, self-signed certs buy you something. But we know that the Internet is chock-full of powerful active attackers. It's not just NSA/GHCQ, but any ISP, including Comcast, Gogo, Starbucks, and a random network set up by a wardriver that your phone happened to auto-connect to. A self-signed cert buys you nothing unless you trust every party in the middle not to alter your traffic [1]. If you can't know whom you're talking to, the fact that your communications are private to you and that other party is useless. I totally agree that the CA system has its flaws -- maybe you'll say that it's no better in practice than using self-signed certs, and you might be right -- but my point is that unauthenticated encryption is not useful as a widespread practice on the web. Browser vendors got this one right. [1] Unless you pin the cert, I suppose, and then the only opportunity to MITM you is your first connection to the server. But then either you can never change the cert, which is a non-option, or otherwise users will occasionally have to click through a scary warning like what ssh gives. Users will just click yes, and indeed that's the right thing to do in 99% of cases, but now your encryption scheme is worthless. Also, securing first connections is useful.

phkamp 12y ago
self-signed-certs is about making NSA&friends work for it, rather than giving them a free ride. Today they can grep plaintext as they want. With SSC's they would have to pinpoint what communication they really need to see. That would be a major and totally free improvement in privacy for everybody. As for why the browsers so consistently treat SSC's as ebola: I'm pretty sure NSA made that happen -- they would be stupid not to do so.
- deleted 12y ago
  [deleted]
- jlebar 12y ago

ademarre 12y ago

> the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative. What principles does he claim the IETF is conceding here?

cnst 12y ago

A very well written rant. HTTP is supposed to have had opportunistic encryption, as per RFC 7258 (Pervasive Monitoring Is an Attack, https://news.ycombinator.com/item?id=7963228 https://news.ycombinator.com/item?id=7963228), but it looks like the corporate overlords don't really understand why is it at all a problem for the independent one-man projects to acquire and update certificates every year, for every little site. As per a recent conversation with Ilya Grigorik over at nginxconf, Google's answer to the cost and/or maintenance issues of https --- just use CloudFlare! Because letting one single party do MITM for the entire internet is so sane and secure, right?