21–30 of 51 posts
I hate this new HTTP. They seem to have taken a beautifully simple concept and added so much complexity it's ugly and horrible and awful.
I hear this a lot, but without a consistent argument as to why that's the case. Do you have anything more than that to offer? HTTP 1.1 is relatively simple, but it's also a bottleneck.
Earlier quoted context omitted.
It's hard to see what benefit that would offer. Non-authenticated TLS is trivially vulnerable to MITM attacks. This is especially the case because I can't foresee a situation in which a website would put the effort in to implement opportunistic TLS, but not implement straightforward authenticated HTTPS…
It completely prevents passive surveillance, however. Sure, you can MITM, but the point is now to look at anything you have to do an MITM attack, unlike now, where most traffic is unencrypted and you can do surveillance passively. This makes surveillance more difficult. Net gain for everyone.
Earlier quoted context omitted.
Is is more complex - why is that inherently a bad thing?
Complexity is bad, all other things being equal, because it takes longer to implement, is more likely to contain bugs, etc..
Earlier quoted context omitted.
Don't shift the burden of proof-It is up to HTTP/2 proponents to demonstrate that the benefits are greater than the costs and from everything I've seen the benefits are meager and the costs are large.
I'm not trying to shift the burden here, but the point made was along the lines of "HTTP2 is rubbish" - I've seen this a lot, with little to back it up. But I'd say some of the benefits were: - Server push support - Multiplexed requests/header compression/other performance improvements - Mandatory encryption support Downsides are (from what I understand): - Not a plaintext protocol There may be more downsides, which…
It's disappointing to hear that the idea of requiring TLS with HTTP/2 has lost traction. For me, TLS-everywhere was the carrot on the stick. I recognize that getting consensus is hard work, but I don't think creating another encryption-optional protocol and letting vendors duke it over security is going to end well for the users. HTTP is a deployed protocol with lots of existing stakeholders, like proxy vendors, netw…
One obvious change here is that it would make CA-signed certificates mandatory for all HTTP2 web servers - is that really a situation we want?
Regardless of the form of PKI employed, there's going to be a cost associated with validating the identity of the parties you're communicating with.
For the average Joe, certs that require domain ownership validation are pretty cheap these days -- certainly on par with domain name registration fees. As with domain names, people need to just start treating it as a necessary cost of running a website.
To be clear, I am far from a fan of X.509, but I'm not holding my breath for something better to come along (and be widely deployed) this decade. So let's use what we've got.
I also find the naming very disingenuous. This is not even an HTTP-style protocol, it should not be named HTTP2.
As for people who want to require CA certs everywhere: Are all the free certs out there accepted by all browsers? (Honest question).
For example, in the current design of HTTP the decision as to whether to use encryption is completely up to the server; the only thing the user can do is observe whether a URL is “HTTP” or “HTTPS” (or maybe watch a lock icon) and decide whether they can continue surfing. This seems a strange characterization. As in any other network protocol, if the client and server don't agree then nothing happens. If either insist…
But this is something clients can actually do today, without the need for a new protocol or any awareness on the server side. URL isn't HTTPS? Don't load it. I actually did a Firefox plugin that implements this, called http-nowhere.
Earlier quoted context omitted.
One obvious change here is that it would make CA-signed certificates mandatory for all HTTP2 web servers - is that really a situation we want?
That doesn't have to be the case. You could still allow self-signage, with all of the security caveats that presents. Who knows. Maybe that arrangement could even spur a sorely needed push for a free certificate trust network and get rid of CA's entirely.
StartSSL is one place where you can get a free cert for your website today (and yes, they charge for revocation, but revocation is pretty ineffective anyway). I got a free cert from them, but my mobile browser doesn't trust it, so I decided to shell out $10 for a cert that's more widely auto-trusted by browsers. Not a huge cost, IMO.
It's disappointing to hear that the idea of requiring TLS with HTTP/2 has lost traction. For me, TLS-everywhere was the carrot on the stick. I recognize that getting consensus is hard work, but I don't think creating another encryption-optional protocol and letting vendors duke it over security is going to end well for the users. HTTP is a deployed protocol with lots of existing stakeholders, like proxy vendors, netw…
One obvious change here is that it would make CA-signed certificates mandatory for all HTTP2 web servers - is that really a situation we want?
This alone would make me forgive just about any other problem with HTTP/2.