
Should All Web Traffic Be Encrypted? - hartleybrody
http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html
======
TomGullen
Lesser known HTTP feature that I love, instead of linking to resources like
follows:

<link rel="shortcut icon" href="<http://static4.scirra.net/images/favicon.ico>
/>

You should link as follows:

<link rel="shortcut icon" href="//static4.scirra.net/images/favicon.ico" />

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!

~~~
ohashi
That is a neat trick, does it work on all browsers?

~~~
tghw
It does, although IE 7 (and possibly 6) have a bug where they will double
request the resource. But, honestly, if they're on IE6 or IE7, the web isn't
fast for them anyways.

~~~
speleding
The double request on IE only happens on stylesheets, all other requests
(including javascript) are fine.

------
sp332
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.
<https://www.eff.org/https-everywhere> 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.)
<https://addons.mozilla.org/en-US/firefox/addon/https-finder>

~~~
AgentConundrum
Thanks for mentioning this.

I've been using HTTPS Everywhere for a while now, but it's been almost
entirely a vanilla install since I got it. The only exception so far has been
HN itself, and only because someone put the new rule in a comment. I then had
to use Google to find out how to actually install the rule, as it was pretty
non-obvious to me.

~~~
AgentConundrum
It seems I've been downvoted, and I think I know why. I can't edit my original
comment so a reply will have to do.

My comment was meant to be a sincere thanks for mentioning the HTTPS Finder
extension. Reading my comment now, without that clarification, I can
understand how it could read as a criticism of the HTTPS Everywhere extension
instead. That was not my intention. I merely wanted to express my thanks for
making me aware of a complimentary extension which adds useful functionality
to an extension I already use.

If the downvote was for another reason, please let me know what was the reason
for it so I can try to avoid committing the same error in the future.

------
harryh
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.

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.

It would be a real shame if everyone in the world had to develop a similar
process.

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.

It is not at all obvious (to me at least) what that best thing to do here is.

~~~
mike-cardwell
If HTTP referrers never existed, the web would still be huge and would still
be full of amazing content.

Why should we care about retaining referrers? I think the only reason that
people dislike the idea of losing them, is because they've got used to them
being there.

I don't particularly like the fact that sites which I click through to can see
where I'm coming from, or what I was searching for, so I've installed a
Firefox addon called RefControl to get around it. The majority of people don't
know anything about referrers though.

I'm sure that brick and mortar shops would also love to know how I was
referred to them when I walk through their door. They don't get this
information unless I consciously decide to give it to them though. And even
though they don't get this information, they still manage to sell products.

~~~
rplnt
> If HTTP referrers never existed, the web would still be huge and would still
> be full of amazing content.

While we're at it, let's get rid of User-Agent. No sarcasm intended, I'm
serious. It only does bad things.

~~~
pavel_lishin
I disagree - it's nice to be able to serve a mobile layout to a mobile device.
If I'm trying to load, say, CNN or ESPN on an older mobile phone, I don't need
all the cruft that comes with the desktop version.

(We can get into all the evils suggested by <http://xkcd.com/869/> , but for
the purposes of this argument I'm assuming that web developers and sysadmins
are competent and not evil.)

~~~
Zirro
What about media queries?

(<https://developer.mozilla.org/En/CSS/Media_queries>)

~~~
pavel_lishin
Those don't really affect the HTML that gets sent.

    
    
        # wget --user-agent="Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3" http://www.cnn.com/ -O cnn.mobile.html
        # wget http://www.cnn.com/ -O cnn.standard.html
        # ls -lhrt | grep cnn 
        -rw-r--r--    1 pavel  staff    29K Feb 24 13:12 cnn.mobile.html
        -rw-r--r--    1 pavel  staff   104K Feb 24 13:13 cnn.standard.html
    

I don't need 100K worth of stuff on BlackBerry 1.half's browser that can't
render most of it.

------
cookiecaper
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.

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.

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).

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.

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).

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

~~~
jmitcheson
You know it's become a huge internet meme right?
[http://www.google.com.au/search?q=x+all+the+things&oq=x+...](http://www.google.com.au/search?q=x+all+the+things&oq=x+all+the+things).

~~~
ketralnis
Does rampant theft make theft any more acceptable?

~~~
fl3tch
Apparently, yes.

[https://en.wikipedia.org/wiki/Generic_trademark#Trademark_er...](https://en.wikipedia.org/wiki/Generic_trademark#Trademark_erosion)

~~~
martey
IANAL, but since the content in question is not a trademark, I do not think
that genericization applies.

Since Hyperbole and a Half is Creative Commons licensed (CC-NC-ND), it looks
like its licensing requirements would be satisfied by attributing the original
source ( _"Proper credit includes a prominent, easily visible link to the
source of the material you want to use..."_ )[1].

I think making sure that images in your blog post are properly licensed is
difficult [2], but on the same level of difficulty and importance as
determining a license for a software project [3].

[1]: <http://hyperboleandahalf.blogspot.com/p/faq_10.html>

[2]: I have personally had issues with this, which I wrote about at
<http://www.marteydodoo.com/2011/01/19/licensing-is-hard/>

[3]: [http://www.codinghorror.com/blog/2007/04/pick-a-license-
any-...](http://www.codinghorror.com/blog/2007/04/pick-a-license-any-
license.html)

~~~
lambada
You should balance that against the fact that the license also forbids
Derivative Works (the ND in the CC-BY-NC-ND) - which likely means that the
images themselves, even with attribution, are breaking the license.

------
patrickaljord
Funny that <https://stackoverflow.com/> certificate is not valid.

~~~
jacktoole1
To be fair, Jeff Atwood recently left Stack Exchange (amicably, of course):
[http://www.codinghorror.com/blog/2012/02/farewell-stack-
exch...](http://www.codinghorror.com/blog/2012/02/farewell-stack-
exchange.html)

~~~
jfoutz
I thought is last day was March 1?

or... have i been working on this bug for way to long?

------
revelation
Yes, please, encrypt all the things, but absolutely don't use HTTPS to do it.

See Daniel J. Bernsteins pet project CurveCP (<http://curvecp.org/>). He also
had a talk on 27C3
([http://events.ccc.de/congress/2010/Fahrplan/events/4295.en.h...](http://events.ccc.de/congress/2010/Fahrplan/events/4295.en.html)).

~~~
marshray
How do you propose to use CurveCP to encrypt "all the" HTTP without involving
HTTPS?

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

------
SoftwareMaven
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.

<http://www.wired.com/threatlevel/2010/03/packet-forensics/>

This could be addressed using <http://convergence.io/>

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.

<http://www.thoughtcrime.org/software/sslstrip/>

This won't go away until everybody is using 100% SSL and HTTP (unencrypted web
traffic) is turned off in browsers.

DOWNLOADING AND INSTALLING ANYTHING OVER AN UNSECURED NETWORK IS ALWAYS A BAD
IDEA.

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).

[http://www.schneier.com/blog/archives/2011/09/man-in-the-
mid...](http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html)

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.

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
<http://example.com> instead of <https://example.com>.

[http://fscked.org/blog/cookiemonster-core-logic-
configuratio...](http://fscked.org/blog/cookiemonster-core-logic-
configuration-and-readmes)

~~~
agl
1) You can address it in Chrome with pinning [1]. Built in pins require that
you be a significant site, but you can also set them with HTTP headers [2].

[1] <http://www.imperialviolet.org/2011/05/04/pinning.html> [2]
<http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01>

This is a rather poor solution. The longer term one is Certificate
Transparency: <http://www.links.org/?p=1219>

2) is solved with HSTS [3]. You can contact me (@chromium.org) to be built in.
There isn't a notability requirement.

[3] <http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security>

3) The BEAST attack was tough to pull off and is fixed with Chrome, FF10 and
IE.

<http://www.imperialviolet.org/2012/01/15/beastfollowup.html>

4) Yep, cookies must be marked secure. HSTS can also fix this my eliminating
the insecure requests. Even with secure cookies (but without HSTS), a MITM can
also _set_ the cookie. (i.e. to log you in to their account before you hit
'send' and then to log you back into yours before you notice the problem.)

~~~
skrebbel
_2) is solved with HSTS [3]. You can contact me (@chromium.org) to be built
in. There isn't a notability requirement._

I don't understand that. If I serve <http://example.com/mypage> which has a
link to <http://mint.com/justin>, you won't convert that to
<https://mint.com/justing>, right? Even if example.com has HSTS enabled? Cause
that would assume that mint.com has https, or else the whole thing breaks.

Cause in that case a man in the middle can just insert links to other domains
(say, <http://examp1e.com/myotherpage> when I was serving a link to
<http://example.com/myotherpage>) and still have the attack work. Like the GP
said, only _starting_ at an HTTPS page would solve this.

But you're the expert and I'm not, so what am I missing? :-)

~~~
coderrr
as long as mint.com has HSTS and either the user has been there once before or
it was hard coded into the browser as an HSTS domain then the browser will
never visit <http://mint.com>, it will immediately go to <https://mint.com>

EDIT: and well it doesn't seem that mint.com even has HSTS enabled... so bad
example :P

------
TomGullen
Adding SSL to a site sounds easy but it's very difficult in some instances.

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.

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.

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.

------
strags
Sounds at first like an admirable concept, but unfortunately would be
incredibly problematic.

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.

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.

------
chrisaycock
There was a discussion on HN a while back about why not all Internet traffic
is encrypted:

<http://news.ycombinator.com/item?id=3115163>

------
jpalomaki
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?

This would be fairly lightweight way for me to say which CA(s) I use for a
particular domain.

[1] <http://www.imperialviolet.org/2011/05/04/pinning.html>

~~~
jpalomaki
With second thought this does not make sense.

False certificates would be only problem in man-in-the-middle attacks of if
the attacker can alter information in dns. In both cases the attacker could
also fake the information about valid ca's.

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

------
lee
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.

------
dhx
Yes: using IPv6 IPsec everywhere, a web-of-trust model and a distributed
method for key exchange (DHT?).

I may be dreaming.

------
asdfaoeu
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?

~~~
wmf
So then the browsers have to implement two security systems.

~~~
alexchamberlain
Not entirely, as SSL already includes a hash. That said, I don't agree with
doing it.

However, I do believe that we should investigate ways of authenticating larger
downloads automatically.

------
zobzu
"we need to" hey, what about you go ahead and do it yourself?

that's "simple"! you've to solve the certificate issues. Easy as pie. I'll be
waiting.

------
drivebyacct2
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.

------
iRobot
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.

~~~
pnathan
> is definitely stored in plain text in the googlesphere

have a source for that?

~~~
JoshTriplett
By definition, since Google can index email and mine it for keywords, they
have access to the contents of it, which makes it isomorphic to plaintext.

~~~
falling
That could be done on the client side, reading the text on the page, like I
assume they do for every other AdSense-enabled page.

~~~
snowwrestler
AdSense detection is not done on the client side. AdSense knows which ads to
serve on which page because it leverages the search index cache and content
analysis of that page. In the same way, Google serves contextual ads in Gmail
by indexing the content of each email as it comes in.

Of course, every other major public email provider in the world stores email
in plaintext too, do I don't get how this is a knock against Google
specifically.

------
eloisius
Scumbag CodingHorror

Says encrypt all the things...

isn't encrypted.

~~~
lukifer
Did you notice that he was referring specifically to sites with accounts?
There's little point in encrypting public data, especially if tracking cookies
aren't involved.

------
latchkey
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.

~~~
ceejayoz
It really isn't a no brainer. Passing our users' data through CloudFlare would
violate our contracts with a number of clients. I'm also dubious about the
privacy implications - they're presumably getting _something_ out of those
terabytes of free traffic they're handling.

------
pooriaazimi
> _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._

This is too good to be true.

~~~
agl
I assure you that it's true. I haven't reprofiled in that much detail since
but I suspect that the numbers look even better now. Partly because computers
are faster and partly because of software improvements.

~~~
match
It largely depends up the nature of your web service. If you are running a
user-interactive site theb i may buy it. However if you are offering a high-
tps, high-throughput web service I assure you the costs of switching 100% of
your users to SSL is not negligable and has a real impact on the customer
experience.

~~~
marshray
I think agl is familiar with both kinds. His company tends to serve both the
HTML and the APIs through the same set of load balancers.

~~~
match
That's a little dismissive. Perhaps we're just talking about different levels
of scale.

