PHK: HTTP 2.0 Should Be Scrapped

Via the HTTP working group list comes a post from Poul-Henning Kamp proposing that HTTP 2.0 (as it exists now) never be released after the plan of adopting Google's SPDY protocol with minor changes revealed flaws that SPDY/HTTP 2.0 will not address. Quoting: "The WG took the prototype SPDY was, before even completing its previous assignment, and wasted a lot of time and effort trying to goldplate over the warts and mistakes in it. And rather than 'ohh, we get HTTP/2.0 almost for free', we found out that there are numerous hard problems that SPDY doesn't even get close to solving, and that we will need to make some simplifications in the evolved HTTP concept if we ever want to solve them. ... Wouldn't we get a better result from taking a much deeper look at the current cryptographic and privacy situation, rather than publish a protocol with a cryptographic band-aid which doesn't solve the problems and gets in the way in many applications ? ... Isn't publishing HTTP/2.0 as a 'place-holder' is just a waste of everybody's time, and a needless code churn, leading to increased risk of security exposures and failure for no significant gains ?"

Comments

Encryption

[neokushan]

I hope that whatever HTTP2.0 ends up being enforces encryption by default.

Re:Encryption

[Anonymous Coward]

No, you really don't. Encryption is good for Facebook, but enforcing it for your Internet-of-Everything lightbulb or temperature probe in the basement gains nothing other than more complex bugs and lower battery life.

Re:Encryption

[Anonymous Coward]

Nice try NSA.

Re:Encryption

[jmv]

Last I heard, it still supports unencrypted, but only if both the client and server ask for it. If either one asks for encryption, then the connection is encrypted, even if there's no authentication (i.e. certificate). With no certificate, it's still possible to pull an active(MitM) attack, which is much harder to pull off at a large scale without anyone noticing (i.e. you can just collect all data you see).

Re:Encryption

[Blaskowicz]

I fear that would train users to mass click through certificate warnings, or even to install shady "helpful" software that will "manage" the problem for them.

Re:Encryption

[gweihir]

That is stupid. First, encryption essentially belongs on a different layer, which means combining it with HTTP is always going to be a compromise that will not work out well in quite a number of situations. Hence at the very least you should be able to leave it out, and either do without or use a different mechanism on a different layer. SSL (well, actually TLS) would have worked if it had solved the trust-in-certificates problem, which it spectacularly failed at due to naive trust models, that I now suspect were actively encouraged by various Three Letter Agencies at that time. In fact, if you control the certificates on both ends, TLS works pretty well and does not actually need a replacement.

That said, putting security for specific, limited (but widely used) scenarios in can be beneficial, but always remember that it makes the protocol less flexible as it needs to do more things right. And there has to be a supporting infrastructure that actually works in establishing identity and trust. In order for the security to have any benefit at all, it must be done right, must be free from fundamental flaws and must give the assurances it was designed to give. That is exceedingly hard to do and very unlikely to be done right on the first attempt.

Re:Encryption

[gweihir]

Nonsense. Enforcing encryption does not make things more secure, unless that encryption and the authentication going with it is flawless. That is very unlikely to be the case against an attacker like the NSA.

Re:Encryption

[abhi_beckert]

Last I heard, it still supports unencrypted, but only if both the client and server ask for it. If either one asks for encryption, then the connection is encrypted, even if there's no authentication (i.e. certificate). With no certificate, it's still possible to pull an active(MitM) attack, which is much harder to pull off at a large scale without anyone noticing (i.e. you can just collect all data you see).

A server cannot ask for encryption.

Unless the client establishes a secure connection in the first place, the server has no way of knowing if the client is actually who they claim to be. If the client attempts to establish a secure connection and the server responds with "I can't give you a secure connection" then the client needs to assume there is a man in the middle attack going on and refuse to communicate with the server.

There is no way around it, security needs to be initiated on the client and the server cannot be allowed to refuse a secure connection.

HSTS is a partial solution for this problem (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

Re:Encryption

[jmv]

A server cannot ask for encryption.

AFAIK, HTTP2 allows the server to encrypt even if the client didn't want to.

Unless the client establishes a secure connection in the first place, the server has no way of knowing if the client is actually who they claim to be. If the client attempts to establish a secure connection and the server responds with "I can't give you a secure connection" then the client needs to assume there is a man in the middle attack going on and refuse to communicate with the server.

If you're able to modify packets in transit (i.e. Man in the Middle), then you can also just decrypt with your key and re-encrypt with the client key. Without authentication, there's just nothing that's going to prevent a MitM attack. Despite that, being vulnerable to MitM is much better than being vulnerable to any sort of passive listening.

Re:Encryption

[AuMatar]

It doesn't need to be perfect. If cracking it still takes some time, it lowers their resources. And it can still be unbreakable for attackers with fewer resources at their disposal.

Re:Encryption

[jmv]

Nothing is NSA-proof, therefore we should just scrap TLS and transmit everything in plaintext, right? The whole point here is not to make the system undefeatable, just to increase the cost of breaking it, just like your door lock isn't perfect, but still useful. If HTTP was always encrypted, even with no authentication, it would require the NSA to man-in-the-middle every single connection if it wants to keep its pervasive monitoring. This would not only make the cost skyrocket, but also make it trivial to detect.

Re:Encryption

[gweihir]

Unfortunately, breaking the crypto directly is _not_ what they are going to do. Protocol flaws usually allow very low cost attacks, it just takes some brain-power to figure them out. The NSA has a lot of that available.

Re:Encryption

[swillden]

In order for the security to have any benefit at all, it must be done right, must be free from fundamental flaws and must give the assurances it was designed to give. That is exceedingly hard to do and very unlikely to be done right on the first attempt.

SPDY's security component is TLS. SPDY is essentially just some minor restrictions (not changes) in the TLS negotiation protocol, plus a sophisticated HTTP acceleration protocol tunneled inside. So this really isn't a "first attempt", by any means. Not to mention the fact that Google has been using SPDY extensively for years now and has a great deal of real-world experience with it. Your argument might hold water when applied to QUIC, but not so much to SPDY.

It really helps to read the thread and get a sense of what the actual dispute is about. In a nutshell, Kamp is bothered less that HTTP/2 is complex than that it doesn't achieve enough. In particular, it doesn't address problems that HTTP/1.1 has with being used as a large file (multi-GB) transfer protocol, and it doesn't eliminate cookies. Not many committee members seem to agree that these are important problems for HTTP/2, though most do agree that it would be nice some day to address those issues, in some standard.

What many do agree on is that there is some dangerous complexity in one part of the proposal, a header compression algorithm called HPACK. The reason for using HPACK is the CRIME attack, which exploits Gzip compression of headers to deduce cookies and other sensitive header values. It does this even though the compressed data is encrypted. HPACK is designed to be resistant to this sort of attack, but it's complex. Several committee members are arguing that it would be reasonable to proceed without header compression at all, thus greatly simplifying the proposal. Others are arguing that they can specify HPACK, but make header compression negotiable and allow clients and servers to choose to use nothing rather than HPACK, if they prefer (or something better when it comes along).

Bottom line: What we have here is one committee member who has been annoyed that his wishes to deeply rethink HTTP have been ignored. He is therefore latching onto a real issue that the rest of the committee is grappling with and using it to argue that they should just throw the whole thing out and get to work on what he wanted to do. And he made his arguments with enough flair and eloquence to get attention beyond the committee. All in all, just normal standards committee politics which has (abnormally) escaped the committee mailing list and made it to the front page of /.

Re:Encryption

[fractoid]

Even lower cost is simply subpoenaing one end of the transaction. There's no point bothering with a cryptographic or man-in-the-middle attack when you control the man-at-the-other-end.

Re:Encryption

[gweihir]

I think the only thing we know is that they would like to be able to break modern crypto directly. There is no indication that they can. Of course, they can brute-force DES or 512 bit RSA keys, but that is not going to help them a lot and that capability does not scale to , say, 128 bit symmetrical or 2048 bit asymmetrical keys. There are also indications that they _may_ be able to break some non-compromised ECC crypto and they likely know of ways to compromise elliptic curves in a way that allows them to cheaply (!) attack some ECC crypto. All of which is not a problem when algorithm selection is done carefully.

Note that sabotaging crypto is not the same as breaking it. Breaking crypto means successfully attacking non-sabotaged crypto. (Crypto lingo deviates a bit from common use here.)

Re:Encryption

[gweihir]

Indeed. Crypto is only ever going to help against mass-surveillance, not against targeted attacks against a small number of people. But that is the idea here.

Re:Encryption

[pklinken]

http://xkcd.com/538/

Re:Encryption

[rioki]

Except that HTTP 500 is a proper and valid response when it comes to the HTTP. Following your oddball logic a 404 would also be "refused", what nonsense. The server accepted the connection, the request handler for that resource crapped it's pants and the server is dutifully informing you of that fact. What is "not accepting the connection", where? The fact that you got a 500 means the server accepted your connection. Even a 401 Unauthorized is technically an accepted connection, since the authorization is for the resource not the server.

Re:Encryption

[TheRaven64]

With encryption without authentication, many people will assume they gain some security when they are not

The do gain some security. They gain security against passive adversaries. They don't gain security against adversaries who are able to intercept and modify their traffic. The question is whether the first threat model is a sensible one to care about. Given that we now know that there is at least one global passive adversary (and likely others who didn't have a Snowden), it seems sensible to me.

Also, it has higher overhead and higher implementation complexity, increasing cost both for the implementation and the platform it runs on (thing small embedded devices, e.g., that can do (very basic) http even on small 8 bit controllers, but forget about fitting any crypto on the

Most IoT platforms are looking at using the ARM Cortex-M0 (or M0+) as the client devices. At the data rates required for IoT tasks, this can easily keep up with the demands of modern crypto. If it can't, then an accelerator is only a few thousand extra transistors for your SoC.

Re:Encryption

[gbjbaanb]

DNSSEC gives you assurance that the domain you're connecting to is the server that says its hosting that domain. So you have no MitM attacks with un-authenticated encryption.

So splitting auth from encryption is a good thing, and can be done properly. You can have both, but at the moment you can only have both or none. None, is obviously not good.

His previous comments are much better

[Anonymous Coward]

Why HTTP/2.0 does not seem interesting

Good point, except...

[Anonymous Coward]

...the entire idea is to cripple security and the ability to provide for privacy. In the end, National Security agencies take the view that digital networks are a primary source of intelligence. Thus, being able to bug and break into systems is a national security priority. The group are dominated by companies that rely on government contracts, so they do their bidding and weaken the specs.

Ultimately, you live in an Oligarchy, not a democracy, so no one cares about your opinion or that of anyone else, unless you happen to have lots of cash. If you did have lots of cash, then you too would be trying to undermine security and privacy to ensure no one takes it from you.

Deal with it.

Re:Good point, except...

[jackspenn]

From reading the HTTP/2.0 thread, it seems like some of us "normal" users should respond to the working group last comment call and point out that encryption alone is not enough. That privacy and anonymity are at least equal to encryption, if not more important.

Was tempted to post as an Anonymous Coward for effect.

Re:Good point, except...

[MassacrE]

It is a technical discussion. Unless you are prepared to provide feedback on how to make a more private/anonymous protocol which can serve as a drop-in replacement for HTTP 1.1, "normal users" will just serve as background noise.

PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).

Re:Good point, except...

[philip.paradis]

PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).

Varnish was never intended to support TLS, nor do the majority of Varnish users (myself included) want it to. The core issues being discussed have little to do with Varnish, aside from the fact that PHK has an excellent understanding of HTTP and high performance content delivery. Having written an HTTP proxy of my own to perform certain other tasks, I understand and largely agree with his sentiments.

That said, it should be noted that many people who need to support TLS connections already use separate software in front of Varnish for cases where high performance intermediate HTTP caching is desirable. This is really a separate topic from discussion of HTTP/2 and/or SPDY, but implementation of a SPDY to HTTP proxy could handle cases where an administrator wishes to run software that only speaks HTTP, albeit with the drawback that SPDY-specific features would be unavailable.

For many use cases, the ability to support 30,000 concurrent HTTP connections with a single VM outweighs the value proposition of encrypting the content in transit, especially for cases where the content in transit isn't remotely sensitive in nature. While "encryption doesn't add much overhead, Google said so" is a commonly parroted idea these days, if you take the opportunity to test various deployment scenarios you'll quickly find that assertion is false for many of those use cases.

Re:If you are a programmer and have a Wikipedia pa

[Anonymous Coward]

Dang, I'm sad Linus Torvalds, John Carmack, et. al. are "too self important" because someone else made a wikipedia page about them. Or maybe programming, especially concerning the next standard for what most of the internet would ideally run, is too important for fucking hipsters to get involved.

Convincing

[gweihir]

There is also the other thing that there is no urgent need to replace HTTP/1.1, despite of what people claim. Sure, it has problems, but the applications it does not support so well are things that there is not urgent need for, hence there is no urgent need for a protocol replacement. It would be far better to carefully consider what to put into the successor and what not. And KISS should the the overriding concern, anything else causes a lot more problems and wastes a lot more resources than having the successor a few years later.

Re:If you are a programmer and have a Wikipedia pa

[l0ungeb0y]

And why shouldn't have a moratorium and review ESPECIALLY in regards to what has come to light about how fucked the internet is in just the last year?

Why proceed blindly with a protocol that comes from Google, who gladly works hand in hand with the NSA and is a Corporation whose core focus to track and monitor every single person and thing online?

What? Just proceed with something that addresses NONE of the present mass surveillance issues, and possibly could make us less secure than we are now just because we don't have a fall back lined up?

Or how about we take this time to step back and reevaluate what HTTP2.0 needs to be -- such as changing to a focus on security and privacy.

Moving goal posts

[abhi_beckert]

I don't think HTTP has any problems with security. All the real world problems with HTTP security are caused by:

  * dismally slow roll out of dnssec. It should have been finished years ago, but it has barely even started.
  * the high price of acquiring an SSL certificate (it's just bits!).
  * slow rollout of IPv6 (SSL certificates generally require a unique IP and we don't have enough to give every domain name a unique IP).
  * arguments in the industry about how to revoke a compromised SSL certificate, which has lead to revocation being almost useless.
  * SSL doesn't really work when there are thousands of certificate authorities, so some changes are needed to cope with the current situation (eg: dsnssec could be used to prevent two certificate authorities from signing the same domain name)

Re:Moving goal posts

[fuzzyfuzzyfungus]

The trouble is that SSL is really playing two roles that aren't trivial to separate, because of the 'well-just-MiTM-with-a-self-signed-cert' problem; but which are substantially at odds with one another in other respects.

You've got identification, which you only really want in a subset of cases (your bank, say); but which is actually slightly expensive to do properly and then you've got encryption, which you want in basically all cases (would you ever not at least want it?) which is cheap; but requires the certificate. Arguably, what we really need is some mechanism for measuring (presumably by consulting some number of 3rd parties, ideally widely distributed) certificate stability and certificate duration.

There are some certificates where you would actually want somebody to have done some thorough checking that the entity on the cert is who they say they are. However, much of the time your main concern is that the certificate isn't an MiTM, and that you are talking to the same person or entity you were talking to previously. You don't actually need to know their Real Official Name or anything; but you want to be sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs, and you want to be sure that the certificate didn't change suddenly for mysterious reasons.

Death by Committee

[bill_mcgonigle]

HTTP/1.1 is roughly seventeen years old now - technically HTTP/1.0 came out seven years before that, but in terms of mass adoption, NSFNet fizzled in '94 and then people really started to pay attention to the web - I had my first webpage about six months before that (at College) and there were maybe a dozen in the whole school who had heard of it previously. Argue for seven years if you'd like, but I'll say that HTTP/1.0 got seriously revised after three years of significant broad usage. SSLv3, still considered almost usable today, was released the year before. TLSv1.2, considered good, has been a standard for over five years and still it's poorly supported though now critically necessary for some security surfaces.

After this burst of innovation, somebody dreamt up the W3C and we got various levels of baroque standards, all while everybody else solved the same problems over and over again. IETF used to be pretty efficient, but it seems like they're at the same point now.

I won't argue for SPDY becoming HTTP/2.0 but I will admire it as an effort to freaking do something. Some guys at Google said, "look, screw you guys, we're going to try to fix this mess," and they did something. While imperfect, they still did enough that the HTTP/2.0 committee looked at it and said (paraphrasing), "hrm, since we haven't done anything useful for 15 years, let's take SPDY and tweak it and call it a day's work well done."

The part Google got most right was the "screw you guys" part - central-planning the web is not working.. I'm not positive what the right organization structure looks like, but it's not W3C and IETF. We need to figure out what went right back in the mid 90's and do that again, but now with more experience under our belts. This talk of "one protocol to rule them all for 20 years" is undeniably a toxic approach. HTTP/1. 1 should have been deprecated by 2005 and we should be on to the third iteration beyond it by now. Yeah, more core stuff for the devs to do - used to be we had people who could start a company and write a whole new web browser in a year - half the time it takes to change the color of tabs these days.

And don't start with this "but this old browser on ... " crap either - we rapidly iterated before and can do it again. Are there people who fear change? Sure - and nobody is going to stop HTTP/1.1 from working 50 years from now, but by golly nobody should want to use it by then either.

Re:Death by Committee

[fuzzyfuzzyfungus]

I'd be inclined to suspect that the stagnation of the W3C and IETF is more a symptom than a cause: they might be 'central planners' in the sense that they get a bunch of technocrats together and try to hammer out the Glorious 3rd Five Year Plan; but they lack essentially all power that a real central planner would have(either to expropriate anyone who sneaks a patent into an IETF standard, or to crush somebody who just wanders off and does his own thing).

Trouble is, if you just wander off and do your own thing, you swiftly learn that the internet of today, unlike the early internet, is huge, heavily populated by people and companies who see it as a necessary evil rather than having any active desire to deal with it, and a certain amount of perverse cat-and-mouse caused by 'security'(why does so much stuff use, or look like, HTTP over port 80, even if it probably isn't the best solution? Because anything that doesn't won't be visible to cube drones slacking off or people on really shit ISPs...)

Given that it takes time for hardware and software to age out and be replaced, it's obviously a bad thing that the people who should be working on future standards, to guide the implementation of what replaces the stuff aging out, have absorbed the inertia of the larger internet (Even if it won't actually be in the field until everybody's old shit drops dead, it'll never reach production if it isn't hammered out and ready to be baked in to the replacements when that does happen); but I'd be very, very, surprised if the standards bodies actually manage to impose stagnation, rather than drawing their membership heavily(but somewhat unavoidably) from entities in the grips of stagnation themselves.

It's probably not for nothing that it was Google, rather than somebody smaller, who came up with that proposal: in terms of engineering resources a substantially smaller company could have done it; but they wouldn't be able to say "Yeah, here's our HTTP replacement. We think it's pretty neat, and will probably use it when the millions of users of our browser and/or operating system contact our tens to hundreds of thousands of servers, which is often. If you guys like it, you can use it too; but even if you don't, we don't really care."

If you are very big, or a lot of your product line is very insular, there is still nothing preventing you from Just Doing It and assuming that things will work out(because, in your case, they very well might). If you are not one of those things, the pond in which you are a small fish is vastly larger than it used to be...

Re:Death by Committee

[jandrese]

My impression is that the IETF was doing a pretty good job until the businesses started taking the internet seriously and instead of being a group of engineers trying to make the best protocols it became a bunch of business interests trying to push their preferred solution because it gives them an advantage in the market. Get a few of those in the same room and deadlock is the result.

Re:Death by Committee

[MatthiasF]

Bullshit. BULLSHIT!

Google has derailed so much of the web's evolution in an attempt to control it that they do not have the right for them or any Google lover to suggest they get to the web's standards from committees. From the "development" trees in Chrome, to WebRT and WebM, they have splintered the internet numerous times with no advantage to the greater good.

The committee was strong armed into considering SPDY simply because they knew Google could force it down everyone's throats with their monopoly powers across numerous industries (search, advertising, email, hosting, android, etc.). HTTP/1.1 has worked well for the web. The internet has not had any issues in the last 22 years except when assholes like Google and Microsoft decided to deviate from a centralized standard.

There is no way we should let Google set ANY standard after the numerous abuses they have done over the last 8 years, nor should any shills like you be allowed to suggest they should be the one calling the shots.

So, kindly go to hell.

Too much.

[bussdriver]

It's better they chuck some of it and stick with a few good bits. The encryption can be trashed as far as I care; that can be another group's problem. We need proxy caching and you can't do it with encryption and be secure.

The reason we can't move like before isn't the committee, it's that we now have a global system built around it and a great deal of investment in it. In the 90s it was all new; low risk, low impact. Today, there is a vast territory claimed and set; when you make new things you can't destroy all you've gained and unless you have a killer app (like the web was) people will not be motivated to make drastic changes.

DNSSEC is a great example of not having much motivation to do the pain in the ass it creates; furthermore, it doesn't completely solve a problem we all are that worried about. They may have made it quickly but people are not using it. IPv6 is long past due and here we sit... (at least we don't have a huge movement of IPv4 deniers saying it's not full and if it is, it wasn't our fault.)

Arguing about other peoples arguments

[WaffleMonster]

I think following demonstrates reality participants in standards organizations are constrained by the market and while they do yield some power it must be exercised with extreme care and creativity to have any effect past L7.

As much as many people would like to get rid of Cookies -- something
you've proposed many times -- doing it in this effort would be counter-productive.

Counter-productive for *who* Mark ?

Counter-productive for FaceBook, Google, Microsoft, NSA and the other mastodons who use cookies and other mistakes in HTTP
(ie: user-agent) to deconstruct our personal identities, across the entire web ?

Even with "SSL/TLS everywhere", all those small blue 'f' icons will still tell FaceBook all about what websites you have visited.

The "don't track" fiasco has shown conclusively, that there is never going to be a good-faith attempt by these mastodons to improve personal privacy: It's against their business model.

And because this WG is 100% beholden to the privacy abusers and gives not a single shit for the privacy abused, fixing the problems would be "counter-productive".

If we cared about human rights, and privacy, being "counter-productive" for the privacy-abusing mastodons would be one of our primary goals.

It is impossible for me to disagree with this. Have several dozen tracking/market intelligence/stat gathering firms blackholed in DNS where creative use of DNS to implement tracking cookies do not work. I count on the fact they are all much too lazy to care about a few people screwing with DNS or operating browser privacy plugins.

I'm personally creeped out by hoards of stalkers following me everywhere I go...yet I see the same mistakes play out again and again... people looking to solve problems without consideration of second order effects of their solutions.

You could technically do something about those army of stalker creeps ... yet this may just force them underground, pulling same data thru backchannels established directly with site - rather than a cut and paste javascript job it would likely turn into module loaded into backend stack with no visibility to the end user or ability to control.

While this would certainly work wonders for site performance and bandwidth usage... those limited feedback channels we did have for the stalked to watch the stalker are denied. On flipside of the ledger not collecting direct proof of access could disrupt some stalker creeps business models.

I think emotional half-assed reaction to NSA with established ability to "QUANTUM INSERT" ultimately encourages locally optimal solution having effect of affording no actual safety or privacy to anyone.

Not only does opportunistic encryption provide a false sense of security to the vast majority of people who simply do not understand relationship between encryption and trust such deceptions effectively work to relieve pressure on need for a real solution.. which I assume looks more like DANE and associated implosion of SSL CA market.

My own opinion HTTP 2.0 is only a marginal improvement with no particular pressing need... I think they should think hard and add something cool to it.. make me want to care...as is I'm not impressed.

Re:cost of SSL certificates

[WaffleMonster]

The cost of SSL certificates is not in the bits.

Back in the day you actually had to pick up the phone, speak with someone and provide corporate documentation. Now you purchase certs from a computer in an 100% automated process. Completely "just bits" worthless.

It's in the security of the private key, some validation in extended verification certs

Extended verification is a foolish scam to enrich CAs. Users hardly understand what the padlock icon means in URL bar after being intentionally inundated with fake padlock gifs and "we're secure" believe what we say assertions littering every online commerce and banking site on the planet.

MITM from day one breaks key continuity management

[tepples]

However, much of the time your main concern is that the certificate isn't an MiTM, and that you are talking to the same person or entity you were talking to previously.

That's called the "key continuity management" paradigm. But KCM breaks down if the first time you talk to someone happens to be through a man in the middle. If your Internet connection is through a MITM proxy, as seen in bug 460374 and in many corporate networks, then "the same person or entity you were talking to previously" would be the MITM. For this reason, even though SSH is most often used in KCM mode, the "Please answer yes or no" prompt urges the user to confirm the server's key fingerprint out of band.

Mixing insensitive and sensitive content

[tepples]

For many use cases, the ability to support 30,000 concurrent HTTP connections with a single VM outweighs the value proposition of encrypting the content in transit, especially for cases where the content in transit isn't remotely sensitive in nature.

It isn't necessarily that the work that you're trying to serve is "remotely sensitive in nature". It's that other parts of the same page may be "sensitive in nature", and browsers throw up pop-up windows about "mixed content" when a secure document transcludes an insecure resource. For example, the logged-in user's session cookie is "sensitive in nature" because an attacker can view it and replay it to impersonate the user. But because ad networks have a history of not supporting HTTPS, many sites have had to remain vulnerable to Firesheep in order to serve ads to logged-in users. (Only in September of last year did Google's AdSense add HTTPS support.)

How does WebM splinter the Internet?

[tepples]

From the "development" trees in Chrome, to WebRT and WebM, they have splintered the internet numerous times with no advantage to the greater good.

VP8 is a royalty-free video codec whose rate/distortion performance is in the same league as the royalty-bearing MPEG-4 AVC. WebM is VP8 video and Vorbis audio in a Matroska container. Did Xiph likewise "splinter[] the Internet" by introducing Vorbis as a royalty-free competitor to the royalty-bearing MP3 and AAC audio codecs? If so, how? If not, then how did Google's On2 division "splinter[] the Internet" by introducing WebM as a competitor to MPEG-4?

Re:Run your own CA

[gmhowell]

Reasonable idea, but I suspect GE, Samsung, Whirlpool, and all the other manufacturers of Internet connected widgets will force you to buy a certificate from their app store. Hacking your light bulb to install your own certificate will be a federal crime, punishable by PMITA prison or worse.

SPDY doesn't solve the real issues

[Aethedor]

The biggest problem with SPDY is that it's a protocol by Google, for Google. Unless you are doing the same as Google, you won't benefit from it. In my free time, I'm writing an open source webserver and by doing so, I've encountered several bad things in the HTTP and CGI standard. Things can be made really more easy and thus faster if we, for example, agree to let go of this rediculous pathinfo, agree that requests within the same connection are always for the same host and make the CGI headers work better with HTTP.

You want things to be faster? Start by making things more simple. Just take a look at all the modules for Apache. The amount of crap many web developers want to put into their website can't be fixed by a new HTTP protocol.

We don't need HTTP/2.0. HTTP/1.3 with some things removed, fixed or at least have some vague things be specified more clearly, would be more than enough for 95% of all the websites.

Tunnelling

[msobkow]

Maybe if we weren't trying to tunnel every god damned protocol and transport known to mankind through HTTP it wouldn't be such a massive problem to re-engineer and fix.

Seriously: The idea of TCP was to have multiple protocol ports, not to tunnel everything over :80.

Re:Tunnelling

[Aethedor]

Yeah, tell that to the firewall administrator who thinks that opening an extra port is far more insecure than to tunnel that extra connection via HTTP. The IT world is defined by a mass amount of incompetent administrators and developers.

Re:If you are a programmer and have a Wikipedia pa

[swillden]

Google, who gladly works hand in hand with the NSA

I have to call bullshit on this rather common but unsupported and unsupportable claim.

There is no evidence that Google had cooperated with the NSA in any way other than actually required by law, and there they claim to be sticklers in demanding that the government dot the i's and cross the t's, including refusing any requests that are overly broad. We can't see what they actually do, of course, because the law makes it illegal for them to say... however Google was the company that first started publishing transparency reports and took the initiative to negotiate permission to publish aggregate statistics about the requests they're legally prevented from publishing. Those published numbers make it clear that Google is not providing information about large numbers of users.

There is evidence that the NSA had an extensive operation in place tapping Google's internal network. When this was revealed, Google immediately accelerated plans to encrypt all of those links to foil the snooping.

Beyond that, look at Google's Internet security track record. Google was the first major webmail provider to switch to HTTPS. Google is still the only major web search engine that requires HTTPS. For logged-in uses, all Google services are all-encrypted, all the time, and for most services even users that aren't logged in get HTTPS by default. Yes, Google designed SPDY, and designed it without an unencrypted mode. The HTTP/2 committee may have added support for unencrypted operation, but Google didn't design it in. Google's next-gen protocol, QUIC, not only doesn't have an unencrypted mode, security is baked so deeply into it that it's basically impossible to remove or disable.

FWIW, I'm a Google engineer, and until recently my job was to work on part of the internal communications security infrastructure. It's vanishingly unlikely that Google could have had any kind of sanctioned NSA tap in place without it being visible to me, and I saw no hint of any such thing.

I happen to personally know several of the people involved with SPDY and there's no way any of them would be party to any attempt to deliberately weaken the protocol.

Beyond that, I can tell you that the internal response to the Snowden revelations about NSA access into Google was one of fury, and a deep and abiding commitment to make sure it can't happen again. Google wants to ensure that the only way the government can get data about Google's users is to come in through the front door, with appropriate court documentation.

[Google] is a Corporation whose core focus to track and monitor every single person and thing online?

This is also simply untrue. Google's core focus is in its mission statement, which you can search for. 90% of its revenue comes from targeted advertising, and Google does collect information to do that ad targeting... but only with user approval. If you don't want Google to track you, Google provides tools you can use to ensure you're not tracked. In the process you'll have to give up some (not all, but some) use of Google's services, because the targeted advertising is the fee you pay for those services. Google hopes you'll like that deal and be happy with it. But if you're not, Google wants to ensure you can opt out. See http://google.com/privacy/tool...

(Disclaimer: The above is not an official company statement. In fact, company policy encourages me not to make it (though policy doesn't prohibit me). It is, however, my firm personal view.)