Should All Web Traffic Be Encrypted?

Lesser known HTTP feature that I love, instead of linking to resources like follows:<p>&#60;link rel="shortcut icon" href="<a href="http://static4.scirra.net/images/favicon.ico" rel="nofollow">http://static4.scirra.net/images/favicon.ico</a> /&#62;<p>You should link as follows:<p>&#60;link rel="shortcut icon" href="//static4.scirra.net/images/favicon.ico" /&#62;<p>The double forward slash will select the current protocol the page is being viewed on which means no security errors if you're switching between http/https!

I use the EFF's Firefox addon called "HTTPS Everywhere". It has a list of websites that have HTTPS enabled, and whenever your browser is directed to the plain-HTTP version, it will go to the HTTPS version instead. <a href="https://www.eff.org/https-everywhere" rel="nofollow">https://www.eff.org/https-everywhere</a> A useful (but tbh kinda annoying) companion addon is the HTTPS Finder. It checks to see if the website you're currently browsing also has an HTTPS version, and will add a rule to the HTTPS Everywhere addon. (It also has a "whitelist" of sites that this breaks.) <a href="https://addons.mozilla.org/en-US/firefox/addon/https-finder" rel="nofollow">https://addons.mozilla.org/en-US/firefox/addon/https-finder</a>

One item that this (excellent) blog post does not adress is what to do about referer information which is generally not passed along when clicking on links on sites being browsed over SSL.<p>In order to "get credit" for all of the traffic that they send everywhere twitter had to develop a fairly elaborate system of redirections (built into t.co) to make sure that clicks from twitter.com ended up being sent out to the rest of the web with referer information.<p>It would be a real shame if everyone in the world had to develop a similar process.<p>Part of me thinks that browsers should start sending referer information even when you click on links for SSL sites, though this change would bring with it other problems.<p>It is not at all obvious (to me at least) what that best thing to do here is.

It's too bad this refers to SSL. There are sometimes good reasons not to use SSL, but there is rarely a good reason to send emails that contain any business, financial or security information over plaintext. Anyone who gets mails that amount to more than "Hey what's up man" should provide you with a public key for mail crypto.<p>Also, it is very smart to use full-disk encryption and also encrypt sensitive info on that disk in a separate encrypted file (often preferably with something like TrueCrypt that allows plausible deniability via hidden volumes) if your computer is used for anything important.<p>Think of the extent of damage that would have hit HBGary or any of the many other companies that have found themselves in a similar quagmire if they had employed some of that computer security knowledge to encrypt mail and required digital signatures before doing anything important (hint: the answer is 0).<p>You may have a competitor hooked into your mail server for years before you know anything has happened, while you scratch your heads and wonder why they always beat you to the punch on new products and steal your big clients.<p>You may have a hostile government agency after you for completely innocuous things, like downloading public domain research article. In this case, lots of encryption is going to buy your lawyers lots of time even if the judge eventually orders you to decrypt all of it; hopefully the real goods are hidden somewhere where they won't find them (like in a TC hidden volume, perhaps "in the cloud" in an encrypted file on Tahoe-LAFS over I2P).

Sorry, off-topic, but as a fan it really bugs me that graphic halfway down appears taken without attribution from Hyperbole and a Half. <a href="http://hyperboleandahalf.blogspot.com/" rel="nofollow">http://hyperboleandahalf.blogspot.com/</a>

Funny that <a href="https://stackoverflow.com/" rel="nofollow">https://stackoverflow.com/</a> certificate is not valid.

Yes, please, encrypt all the things, but absolutely don't use HTTPS to do it.<p>See Daniel J. Bernsteins pet project CurveCP (<a href="http://curvecp.org/" rel="nofollow">http://curvecp.org/</a>). He also had a talk on 27C3 (<a href="http://events.ccc.de/congress/2010/Fahrplan/events/4295.en.html" rel="nofollow">http://events.ccc.de/congress/2010/Fahrplan/events/4295.en.h...</a>).

What's with the submission of the title here? Would be less meme-y if the blog article title was used.

Just Tuesaday, I sent an email around the company discussing SSL vulnerabilities, how they impact our product, and ways we can mitigate that. I've pulled out the parts specific to our product, but the rest may be interesting. I would love feedback on things I may have missed. FWIW, it doesn't instill great confidence in SSL, but it isn't completely horrible. ------------------------ 1. It is possible to pretend to be any site you want if you 1) find a sleezy CA (and they exist aplenty) or get the government involved and 2) can get between your browser and your final destination (like, for example, a wifi hotspot). There will be no way (reasonable) way to tell you aren't connected to whom you think you are.<p><a href="http://www.wired.com/threatlevel/2010/03/packet-forensics/" rel="nofollow">http://www.wired.com/threatlevel/2010/03/packet-forensics/</a><p>This could be addressed using <a href="http://convergence.io/" rel="nofollow">http://convergence.io/</a><p>2. Way easier, but leaving some tell-tale signs you can find is to simply put yourself between your victim's browser and his server and convert all the links that come back to be insecure links that go through you. You then encrypt them as you pass them on to their final destination, while being able to see everything that happens. This is trivial to set up, but can be gotten around simply by using bookmarks that specify HTTPS.<p><a href="http://www.thoughtcrime.org/software/sslstrip/" rel="nofollow">http://www.thoughtcrime.org/software/sslstrip/</a><p>This won't go away until everybody is using 100% SSL and HTTP (unencrypted web traffic) is turned off in browsers.<p>DOWNLOADING AND INSTALLING ANYTHING OVER AN UNSECURED NETWORK IS ALWAYS A BAD IDEA.<p>3. For the very determined, it is possible to determine the symmetric key a particular SSL session is using if you have some luck, some skill, and some time (about 30 minutes).<p><a href="http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html" rel="nofollow">http://www.schneier.com/blog/archives/2011/09/man-in-the-mid...</a><p>This requires a protocol change to SSL. We've known about (theoretical) vulnerabilities for 10 years, yet most sites still run old versions of SSL. Given how slowly people like banks update infrastructure technology, I don't see this one going away for a long time.<p>4. If a site is improperly configured, it may allow an attacker to gain access to the cookie representing your secure session by making an insecure request. This is another class of vulnerabilities made possible by using untrusted networks. The misconfiguration allows the browser to send your (supposedly) secure cookies in an unsecured request simply by making any request (typically done by inserting JavaScript into an unsecured page you are browsing). It is possible to mark cookies as "secure only", but services will choose not do that so you don't lose your session if you type <a href="http://example.com" rel="nofollow">http://example.com</a> instead of <a href="https://example.com" rel="nofollow">https://example.com</a>.<p><a href="http://fscked.org/blog/cookiemonster-core-logic-configuration-and-readmes" rel="nofollow">http://fscked.org/blog/cookiemonster-core-logic-configuratio...</a>

Adding SSL to a site sounds easy but it's very difficult in some instances.<p>Take for example a forum, we can force everyone on HTTPS quite easily but as soon as someone hotlinks an image in a post that's not HTTPS it'll throw security warnings up which are (in my opinion) overly dramatic and are very unfriendly to the user experience.<p>User submitted content and HTTPS can be a pain to get right, and on some platforms like common bb software it's basically so time consuming to modify it's just not worth doing.<p>SO solves this by using imgur as a proxy, a lot of sites don't have that luxury unfortunately or even the technical expertise to implement something similar. This is also a bit wobbly on the old copyright laws as well.

Sounds at first like an admirable concept, but unfortunately would be incredibly problematic.<p>What about the case where you're virtual-hosting many sites on one IP address? Since the SSL handshake occurs prior to any HTTP data being sent, and the browser will reject a server-certificate whose hostname does not match, you're normally restricted to one HTTPS domain per IP address.<p>I gather there are TLS extensions to suppport SSL vhosts, but I don't know how widespread they are. There are also methods of including more than one hostname per certificate, but I'm assuming that when you purchase a SSL cert from a registrar, you're going to be restricted to one host.

There was a discussion on HN a while back about why not all Internet traffic is encrypted:<p><a href="http://news.ycombinator.com/item?id=3115163" rel="nofollow">http://news.ycombinator.com/item?id=3115163</a>

Wouldn't it provide good additional security if there would be a possibility to define those HTTPS Pins [1] in the DNS, in TXT recods?<p>This would be fairly lightweight way for me to say which CA(s) I use for a particular domain.<p>[1] <a href="http://www.imperialviolet.org/2011/05/04/pinning.html" rel="nofollow">http://www.imperialviolet.org/2011/05/04/pinning.html</a>

Yes... why would any website that values privacy and security not use HTTPS for everything? We've been doing that from day one on <a href="https://postgres.heroku.com" rel="nofollow">https://postgres.heroku.com</a>.

When I'm on some kind of public wifi, I always surf through an SSH proxy so that my traffic is encrypted. That helps if you're hitting up sites that don't have https.

Yes: using IPv6 IPsec everywhere, a web-of-trust model and a distributed method for key exchange (DHT?).<p>I may be dreaming.

For content that is already public but needs to be protected from modification like images and scripts couldn't it be hashed and the hash just sent with the page your viewing. Then the browser could download extra assets from an insecure source like a proxy or cdn and know that it hasn't been modified?

"we need to" hey, what about you go ahead and do it yourself?<p>that's "simple"! you've to solve the certificate issues. Easy as pie. I'll be waiting.

There was an article posted a while back that seems like it might be relevant here (especially with the doubting of SSL being feasible to deploy for everyone). It discussed how many sites use OpenSSL improperly or in a poorly configured way that causes it to be more expensive than it needs to be. I hate doing this, but I also have been looking for the link for a while with no success.

gmail security is really only good between gmail accounts and is definitely stored in plain text in the googlesphere use PGP if you need to guarantee email privacy.

Scumbag CodingHorror<p>Says encrypt all the things...<p>isn't encrypted.

We use CloudFlare. $20/month and you get your whole site encrypted plus all their other really cool features. It is a no brainer for those of us who can do it without violating contracts.

&#62; <i>On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.</i><p>This is too good to be true.