Hiya, On 19/08/14 07:09, Ryan Carboni wrote: > It would be secure against wifi eavesdropping. But worse it might instill a > false sense of security.
Well, protocols don't do that, but user agents (browsers in this case) can. However, the httpbis WG are on the topic and have a proposal for HTTP/2.0 for opportunistic security [1] that they're working on that I don't believe has that problem. (There's no user indication at all that its happening.) I'm not sure why 2817 never took off, but suspect its mostly that 2818 had already taken off when both were published. S. > > > > On Mon, Aug 18, 2014 at 9:29 PM, Tony Arcieri <[email protected]> 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. >> >> 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. >> >> It seems most modern web browsers and web servers are built with TLS >> support. Why not always flip it on if it's available on both sides, even if >> it's trivially MitMed? >> >> -- >> Tony Arcieri >> >> _______________________________________________ >> cryptography mailing list >> [email protected] >> http://lists.randombit.net/mailman/listinfo/cryptography >> >> > > > > _______________________________________________ > The cryptography mailing list > [email protected] > http://www.metzdowd.com/mailman/listinfo/cryptography > _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
