It seems to me that this could be mitigated by the browser vendors by:- Attempting connection to HTTPS by default, if the address given does not specify a protocol (as GOu pointed out, most people just type in "www...")- Failing over to HTTP if the site does not respond to HTTPS (or refuses the connection), and finally- Failing over to HTTPS if the site does not respond to HTTP (or refuses the connection).This could marginally increase connection time as the browser waits for a timeout. The last item is needed because if this were the (de facto or otherwise) standard for browsers, web sites could *refuse* connections via HTTP, rather than redirecting them to HTTPS.I agree with LongOfTooth's recommendation that users can protect themselves by creating and using bookmarks to commonly-visited secure sites, and specifying https: in the bookmark.The cost, in both monetary and performance terms, of an SSL certificate is nominal these days. Any site handling confidential data absolutely must provide their site over HTTPS, and even those sites that don't handle confidential data should consider it anyway. Setting the browser to try HTTPS (either first or anytime HTTP fails) would allow site administrators to reject HTTP connection attempts wholesale, instead of referring them to the HTTPS (and risking the referral being intercepted).Although I guess then the programmer of SSLStrip could then have it watch for refused HTTP connections and use *that* to jump in as a proxy. All the more reason to program browsers to use HTTPS by default.Any thoughts?
↧
