On 8/19/14, Tom Ritter <t...@ritter.vg> wrote: > On 18 August 2014 23:29, Tony Arcieri <basc...@gmail.com> wrote: >> Anyone know why this hasn't gained adoption? >> >> http://tools.ietf.org/html/rfc2817 >> >> I've been watching various efforts at widespread opportunistic >> encryption, >> like TCPINC and STARTTLS in SMTP. It's made me wonder why it isn't used >> for >> HTTP. > > What's the point? Anything that speaks HTTP also speaks HTTPS, so > there's no need for the "If you support it, I have TLS available." > Just use any of multitude of redirect mechanisms for your webserver to > kick people onto HTTPS. >
Not all HTTPS ports are properly configured to match what is served on a given HTTP server. Also some networks block port 443 but not port 80. Also, it is an inband way of signaling that the server supports TLS. I've heard that this is how TahoeLAFS does TLS with foolscap (HTTP upgrade). >> Opportunistic encryption could be completely transparent. We don't need >> any >> external facing UI changes for users (although perhaps plaintext HTTP on >> port 80 could show a broken lock). Instead, if the server and client >> mutually support it, TLS with an unauthenticated key exchange is used. > > I didn't read the draft word for word, but I don't see anything in it > that indicates the client MUST NOT validate the server certificate or > MUST use anonymous ciphersuites. Indeed it seems to say the opposite. It seems to have all of the normal TLS certificate issues, yes. All the best, Jacob _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
