<div dir="ltr"><div>It would be secure against wifi eavesdropping. But worse it might instill a false sense of security.<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 18, 2014 at 9:29 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Anyone know why this hasn't gained adoption?<div><br></div><div><a href="http://tools.ietf.org/html/rfc2817" target="_blank">http://tools.ietf.org/html/rfc2817</a></div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>



<div><br></div><div>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?</div><span class="HOEnZb"><font color="#888888"><div>

<div><br></div>

-- <br>Tony Arcieri<br>
</div></font></span></div>
<br>_______________________________________________<br>
cryptography mailing list<br>
<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
<a href="http://lists.randombit.net/mailman/listinfo/cryptography" target="_blank">http://lists.randombit.net/mailman/listinfo/cryptography</a><br>
<br></blockquote></div><br></div>