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

Varnish author criticizing HTTP/2.0 proposals

lists.w3.org

Post reply on HN
Print view View original

71–80 of 138 posts

Re: Varnish author criticizing HTTP/2.0 proposals

#71

Post by jvdongen »

angelbob wrote: post #53
danellis wrote: post #43

Earlier quoted context omitted.

I don't know what you mean by 'leakable' exactly, but you can already mark cookies as HttpOnly (not accessible from Javascript) and Secure (only transmitted over HTTPS).

"Leakable" in the sense that you can hand it to somebody else and they can actually use it. A cookie is leakable because the client chooses to send it, so copying it to somebody else is really bad. A server-assigned per-connection ID is not leakable unless you can spoof the IP address of the one you're sending as.

In principle you could already achieve that by binding a session (and corresponding cookie) to the client's IP address. No big deal.

Problem you may have is that some clients are behind proxy farms and can arrive with different source IP addresses within the scope of a single session.

If you do not bind the 'server-assigned-per-connection ID' to an IP address they become just as 'leakable' as a session cookie.

Re: Varnish author criticizing HTTP/2.0 proposals

#72

Post by comex »

phkamp wrote: post #57
phkamp wrote: post #51

Earlier quoted context omitted.

The client/user-agent gets to control what session-id gets sent to which sites. That makes it possible for a UI design where the user can press a button and say "don't surf this site anonymously" with the default being a new random session-id for all other sites. That will make tracking and correlation of webusage much harder, which I really don't see a downside to. Deflate is bad on its own, it is a DoS amplifier an…

(probably pressing wrong reply link here ?) Cookies are almost never mentioned in Vary: so all caches have to assume that the precense of cookies means non-cacheable.

Hmm. That would indeed be an advantage of a new mechanism.

What I meant about JavaScript is that a server side cookie->session bridge for legacy code would not work in general because corresponding client side code sometimes expects to be able to see the cookies in document.cookie.

Re: Varnish author criticizing HTTP/2.0 proposals

#73

Post by phkamp »

obtu wrote: post #68
bifrost wrote: post #40

Frankly many problems addressed by these proposals are not things that should be solved in a protocol like HTTP. Do you want every HTTP request to be slowed down with a crypto token exchange and verification? unlikely. In special cases you definately want it, but all the time? Absolutely not.

It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.

No, they are not. For one thing you have to terminate all your SSL on your loadbalancer in order to distribute the traffic. That makes SPDY a no-go for web-hotels/web-hosting where each customer has their own certificate.

Second, there are perfectly valid legally mandated circumstances which forbid end-to-end privacy, from children in schools to inmates in jail and patients in psych. hospitals, not to mention corporate firewalls and the monster that looks out for classified docs not leaking out of CIA.

Re: Varnish author criticizing HTTP/2.0 proposals

#74

Post by vidarh »

angelbob wrote: post #53
danellis wrote: post #43

Earlier quoted context omitted.

I don't know what you mean by 'leakable' exactly, but you can already mark cookies as HttpOnly (not accessible from Javascript) and Secure (only transmitted over HTTPS).

"Leakable" in the sense that you can hand it to somebody else and they can actually use it. A cookie is leakable because the client chooses to send it, so copying it to somebody else is really bad. A server-assigned per-connection ID is not leakable unless you can spoof the IP address of the one you're sending as.

Doing server side IP checks is already easy, but in reality it can lead to massive amounts of user complaints when their sessions keep disappearing, because as it turns out, some user segments have a lot of users coming through proxies where each request is not guaranteed to come from the same IP.

Re: Varnish author criticizing HTTP/2.0 proposals

#75

Post by neya »

rickmb wrote: post #61

After the whole IPv6 story, I'm surprised the author ignores the political dimension of designing a new protocol. As Mitch Kapor said "Architecture is Politics". It's not just about what solution is best from a technological perspective, it's about what we want our future to look like. The internet has become way more important than back when these protocols first became standard, and every time a protocol or standar…

This is a well thought, excellent comment that perfectly makes sense. Thank you. When huge corporations track you as how they are tracking you currently, most of the times, they don't get to know who you really are (except Facebook, because they know 'you'). That is, your identity. That's the only level of control you have over your anonymity. And these guys are proposing a new protocol just to remove that. Ridiculous.

Re: Varnish author criticizing HTTP/2.0 proposals

#76

Post by comex »

jasonwatkinspdx wrote: post #65
comex wrote: post #59

Earlier quoted context omitted.

There is no difference between browsers implementing a locally encrypted resumption store for a nonce and for cookies (since again, most sites where security is important already use cookies purely as identifiers); nor does it affect whether sites will start requiring two factor for all logins. The two systems are equivalent except that one is simpler, but the (small amount of) complexity of cookies is not what's blo…

They are different because a server suggested resumable session nonce requires no form based authentication. User entered entropy never hits the wire. I do not know how to emphasize this point more strongly. Please read the research on trends in brute force and timing attacks vs human capacity for entropy memorization. Evidence is clear: The majority of sites do not handle cookies securely. They do not handle user su…

Server suggested resumable session nonce is just a cookie. If you want the user to be able to put in a password without sending it in plaintext to the server (i.e. make HTTP authentication actually work properly) that would be really really great but, I think, also a different proposal.

Well... I don't think it's worth drawing a line in the sand here, because the speed and, should TLS-always-on make it in, security benefits of the existing protocol are significant enough that everyone should be able to use them without rewriting their authentication system. But I'd certainly be for a comprehensive proposal for a new authentication system; it would probably be significantly cleaner than BrowserID.

Re: Varnish author criticizing HTTP/2.0 proposals

#77

Post by comex »

phkamp wrote: post #70
obtu wrote: post #69

Earlier quoted context omitted.

The key difference with IPv6 is that SPDY is opaque to routers and only needs changes at the endpoints. IPv6 has the chicken-and-egg problem that it only becomes usable once everyone (hosters, ISPs, core networks, home networks, web frameworks, client devices) has deployed it, and most of those actors don't bother with things that bring no immediate benefit.

You do know that when IPv6 roll-out was initially contemplated, it would happen on IPv4-convertible addresses only, until everybody had converted. That would have allowed seamless IPv6/IPv4 interop and made migration a breeze. Lacking any "must have" features, nobody could see a reason to bother. Now we have to do the migration without the benefit of seamless conversion.

Luckily, HTTP only requires the browser (which tend to be frequently updated) and server to be upgraded, not some random aging routers, there is little reason to fear adoption, there is minimal harm in keeping both protocols around for some time, and there is something much closer to a "must have" feature - speed.

Re: Varnish author criticizing HTTP/2.0 proposals

#78

Post by mooism2 »

jfoutz wrote: post #20
patrickaljord wrote: post #5

> See for instance how SSH replaced TELNET, REXEC, RSH, SUPDUP > Or I might add, how HTTP replaced GOPHER[3]. telnet and gopher were used by a few thousands servers only and were not consumer facing technologies (for the most part), it doesn't make sense to compare that to IPv4 and HTTP that are used by millions (billion?) of servers.

Who won't support spdy by the end of the year? The pace of protocol obsolescence is increasing. I can't find stats about how much http traffic facebook is responsible for, but i'd bet it's at least 1% Governments and home grown enterprise apps are my guess about who's late to the party.

El cheapo web hosting will be late to the party. TLS certificates will be a stumbling block.

Re: Varnish author criticizing HTTP/2.0 proposals

#79

Post by rmc »

rickmb wrote: post #61

After the whole IPv6 story, I'm surprised the author ignores the political dimension of designing a new protocol. As Mitch Kapor said "Architecture is Politics". It's not just about what solution is best from a technological perspective, it's about what we want our future to look like. The internet has become way more important than back when these protocols first became standard, and every time a protocol or standar…

Some of the concepts they tried to shove into IPv6 were downright evil, and would have killed the internet as we know it

Oh? Got an example? I've never heard of this (but don't really follow IPv6 stuff).

Re: Varnish author criticizing HTTP/2.0 proposals

#80

Post by rmc »

ars wrote: post #41
quotemstr wrote: post #19

Earlier quoted context omitted.

How so? A unique identifier is a unique identifier.

If the browser created the unique identifier instead of the server it could create a new one as often as necessary. I think that would actually work very nicely.

Browsers can do that now with cookies, by just clearing old cookies.
Post reply on HN