41–50 of 113 posts
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.
Earlier quoted context omitted.
No, I don't think we need free certificates, I think we need people who can carefully evaluate an untrusted certificate and make their own decision. The whole idea of a CA is pretty broken at current scale. Meanwhile, self-signed certificates are seen as a red flag. Should they be?
Opportunistic encryption of all sessions doesn't require any certificates. All that's needed is a key exchange algorithm and browser support. The UI would make it clear when a certificate was presented and validated, but no cert is needed for unauthenticated encrypted connections. The next step up from that would be unsigned public keys with pinning (like ssh) to reduce MITM, and finally above that would be identity…
That is a common misconception. If I MITM when you establish connection, how would you notice? My self-signed certificate looks like a real one.
That's why we need CAs (or WoT, or whatever), to verify identity after we've established a secure channel.
Earlier quoted context omitted.
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.
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".
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...
But dumping everything through zlib turned out to be a security hole: http://en.wikipedia.org/wiki/CRIME . 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.
So TLS still isn't mandatory? Seems like a missed opportunity.
Earlier quoted context omitted.
Alternative? Non-https is really harmful to users who browse via open wifi.
can be really harmful, in some applications I don't need to know that my connection to lol cats is secure and uninterrupted.
Do you want to bet there are no vulnerabilities in your browser's mp4/vp8 decoder? If there are, anyone can MITM your non-SSL connection and compromise the video decoding process, limited only by their cleverness and by whatever sandboxing your browser employs.
It seems like given the past 20 years of the web there is clearly a need of a presentation protocol, a stateful application protocol, and a stateless application protocol.
Seems like it makes more sense to separate them.
Earlier quoted context omitted.
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..
I think you should always be able to turn encryption off. Encryption is expensive. I run OpenSSH-HPN partly so, on my local network I can get secure logins but then not pay the throughput hit of encryption when it just doesn't matter. The same even applies to internet connections, such as big but generally uninteresting things like log files. Defaulting to "encryption enabled" and throwing a browser warning of "encry…
Earlier quoted context omitted.
Opportunistic encryption of all sessions doesn't require any certificates. All that's needed is a key exchange algorithm and browser support. The UI would make it clear when a certificate was presented and validated, but no cert is needed for unauthenticated encrypted connections. The next step up from that would be unsigned public keys with pinning (like ssh) to reduce MITM, and finally above that would be identity…
> but no cert is needed for unauthenticated encrypted connections That is a common misconception. If I MITM when you establish connection, how would you notice? My self-signed certificate looks like a real one. That's why we need CAs (or WoT, or whatever), to verify identity after we've established a secure channel.
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.
1. Unencrypted (for casual/ad-hoc web servers serving cache-able static assets)
2. Encrypted-untrusted (for casual/ad-hoc web servers that just want to thwart basic Wi-Fi cookie sniffing)
3. Encrypted-trusted (for most established websites)
Right now, #2 isn't a viable option, because HTTPS servers with self-signed certificates are correctly treated as dangerous. A URL that designates the HTTPS protocol must always require a trusted connection.
The solution is (relatively) simple: HTTP 2.0 should allow encrypted-untrusted connections for URLs designated with the HTTP protocol.