21–30 of 113 posts
http://tools.ietf.org/html/draft-ietf-httpbis-header-compres...
To those saying HTTP2 should require HTTPS: do you really want to be stuck with our shitty CA model for even longer?
Alternative? Non-https is really harmful to users who browse via open wifi.
There exist several semi-viable alternatives at the moment. The most promising is Namecoin, which essentially allows for cryptographically authenticated public key/value storage, and so can function as both a DNS system and a system for announcing SSL pubkeys (without any trusted parties).
Earlier quoted context omitted.
STARTTLS mixes concerns in a very bad way and is a horrible hack. Let it die with FTP and SMTP. Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".
Faced with a choice of obtaining a TLS certificate or just going for the old HTTP/1.x protocol, it'd be a hard sell for HTTP/2 for any one-off, quick hack experiment/microsite/internal APIs...
The 1% of sites it does matter for are things like banks and the like, where you need to hammer into users heads that certificates should be valid via other means.
Of course, it's casually accepted that it's a-ok for companies to MitM their employees encrypted connections anyway, so I don't really know where that leaves us.
So TLS still isn't mandatory? Seems like a missed opportunity.
I agree encryption is something that should be mandatory, but you can't pin down an encryption algo to be used by HTTP/2 without allowing for future changes..
Defaulting to "encryption enabled" and throwing a browser warning of "encryption disabled" makes perfect sense, but you definitely should be able to turn it off for content where it doesn't matter.
To those saying HTTP2 should require HTTPS: do you really want to be stuck with our shitty CA model for even longer?
Alternative? Non-https is really harmful to users who browse via open wifi.
I don't need to know that my connection to lol cats is secure and uninterrupted.
The accompanying HTTP header compression standard seems a lot more terrifying on the complexity scale, compared to Googles suggestion with SPDY of just dumping everything through zlib: http://tools.ietf.org/html/draft-ietf-httpbis-header-compres...
I wrote some terrible, terrible code for Chromium to patch zlib in order to segment different sources of data and compress them separately while still being wire compatible with zlib. I'll be very happy when I can remove it.
There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.
I'm curious to see how transparent proxies handle all the crazy framing (will poor software corrupt the bytestream?) and if there will be a wave of exploits for both client and server implementations; the complexity and subtleties appear to be almost a magnitude higher than http/1.
There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.
At the very least, regular http should support starttls to allow encryption. That at least requires your attacker to go to the trouble of man in the middle.
There is so much open wifi nowadays that non-https should really start to be considered harmful. A large portion of website visitors are probably connecting via Starbucks, airport wifi, etc., which means their session cookies are basically public information. So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.