
Unintended Affordances (or why I believe encrypting everything is a bad idea) - mtuncer
http://lucumr.pocoo.org/2015/4/28/unintended-affordances/
======
jasode
>There is the idea that “there is no such thing as insensitive web traffic”
and that the privacy of communication is absolute.

The essay seems to center on "privacy" and "hiding".

The other use for encryption is "authenticity". We want to have trust that the
pixels on the desktop monitor or iPhone are actually correct. Whether a user
is a city administrator looking at weather.com pixels to decide whether to
shutdown schools for the day, or a grandmother looking at NYT or Yahoo pixels
to check a stock price before selling, encryption helps ensure the veracity of
what their eyeballs see.

Grandma doesn't care if the government or Facebook knows she read the New York
Times. Someone on the subway can look over her shoulder to discover that same
datapoint. On the other hand, she does need to have confidence that what she
reads has not been tampered with.

One could attempt to write "data protection" protocols that send multiple
hashes to verify the payload. However, if the hashes are cleartext, you're
back to where you started with broken trust because the hashes can be spoofed.
The necessity of encryption (without regard for hiding or privacy) appears
again.

~~~
untitaker_
You can verify authenticity through signatures -- no need to encrypt the full
body for that. The fact that there's no (widespread) general-purpose solution
to sign arbitrary traffic is IMO problematic, people apparently are fine with
just paying the cost of encryption.

~~~
jasode
_> You can verify authenticity through signatures -- no need to encrypt the
full body for that._

If NYT or Yahoo Finance has a javascript widget to let a reader pick a stock
symbol, and dynamically choose start and end points of stock performance, what
"body of text" is relevant to compute a "signature"? What if the NYT has an
option to dynamically translate their stories into other languages, or rotate
different related stories on a sidebar? Are servers constantly regenerating
thousands of signatures for all unforseen combinations of dynamic text? And
how do these multiple signatures continuously travel from the server to the
browser? Presumably it would be an encrypted channel because cleartext
signatures would be vulnerable to tampering. Would a browser then have twin-
channels (2 ports) open for the NYT page? One channel is encrypted for the
signatures and the other channel is the cleartext? Why would this scheme be
"better"? You still have encryption _somewhere_.

~~~
untitaker_
I suppose you have some encryption in this (I'm no expert), I'm only arguing
against encrypting the full body, because for larger downloads, full-body
encryption might cause extreme overhead (think Netflix or Steam)

~~~
vtlynch
Except even Netflix has recently announced they are going to be performing
"Full Body" encryption on their video streams and that it was financially
worth it for them to do so.

You can make value based arguments for/against pervasive encryption, but
technical arguments against it continue to be debunked.

~~~
untitaker_
Not sure where you get the idea that anecdotes count as "technical arguments",
but let's stay with the Netflix example: According to another comment in this
thread, Netflix measured severe performance drops with SSL:
[https://news.ycombinator.com/item?id=9465553](https://news.ycombinator.com/item?id=9465553)

~~~
vtlynch
Not sure how one of the largest sites on the internet with intensive bandwidth
successfully implementing encryption is anecdotal. Performance drop or not,
they implemented it because they find the benefits to outweigh the costs.

Netflix, and many others before them, have demonstrated it is possible to do
so. Obviously there is an impact.

But many people like to immediately say, "its too resource intensive! it cant
be done! its not practical". Those people are wrong. It's expensive. It may
take engineers. But it can be done.

------
JoshTriplett
Having read the entire article, I'd say that while it's good to _consider_ the
implications of encrypting all traffic (including those mentioned in the
article), it's perfectly reasonable to have done so and still come to the
conclusion that every single one of those implications are _entirely by
design_ features, rather than bugs.

"Lawful intercept": sure, you have the right, good luck with that. We're not
going to make the Internet less secure for the benefit of government
interception; if anything, we're making it more secure _because_ of the
possibility of government interception. This one is a very old argument, and
easily debunked: assuming you allow any encryption at all, just having _less_
of it doesn't make lawful interception any easier, because of course all the
illicit traffic will be encrypted. The only thing it does is make encrypted
traffic seem more suspicious, which isn't good for _anyone_.

SNI works just about everywhere these days, and it's quite safe for most
services to just turn it on and write off the few systems (IE on XP, and truly
ancient mobile devices) that can't cope.

People don't get used to clicking certificate warnings away because browsers
have gone out of their way to make that painful, and it _should_ be.

If you don't understand TLS, learn, or count on other people to have learned.
That's no excuse for not using it.

There are many folks working on fixing the CA problem, but even without that
completely fixed, SSL is still better than cleartext.

All that said, I do think the first section of the article, about unintended
affordances (such as emergencies) is worth considering in _other_
technological contexts. That point was made years ago: [http://code-is-
law.org/](http://code-is-law.org/)

~~~
the_mitsuhiko
> "Lawful intercept": sure, you have the right, good luck with that. We're not
> going to make the Internet less secure for the benefit of government
> interception; if anything, we're making it more secure because of the
> possibility of government interception.

Government censorship is happening if you want it or not. The main difference
is now that there is a lot more collateral damage with SSL deployed.

> If you don't understand TLS, learn, or count on other people to have
> learned. That's no excuse for not using it.

I agree in the sense that anyone who runs a security critical website should
deploy SSL and there is no excuse for not doing it. However what triggered the
whole article was that more and more websites become completely impossible to
use in the absence of SSL even for anonymous data access.

~~~
JoshTriplett
> Government censorship is happening if you want it or not. The main
> difference is now that there is a lot more collateral damage with SSL
> deployed.

Good. Censorship and other _attacks_ should be as noisy, obtrusive, and
damaging as possible, so that we have more incentive to stop it (by both legal
and technical means). Such attacks should not pass silently.

> However what triggered the whole article was that more and more websites
> become completely impossible to use in the absence of SSL even for anonymous
> data access.

Why do you need to use them in the absence of SSL?

Many ridiculously tiny devices still have enough power to run a simple TLS
stack. And if you're really trying to access web services from some potato-
powered device that can't run a TLS stack, you have much the same problems as
a device that can't run a fully capable network stack at all. In either case,
speak a simpler encrypted protocol (e.g. Bluetooth Low Energy, 6LoWPAN) to a
local device, that can either provide the services you need or access them on
your behalf.

~~~
positivejam
> Good. Censorship and other _attacks_ should be as noisy, obtrusive, and
> damaging as possible

Agreed. It's human nature to not bother to speak up when a group you're not a
part of is attacked. If widespread encryption means that more people will be
affected when governments try to censor traffic, then I'd say we have one more
argument for widespread encryption. [http://hmd.org.uk/resources/poetry/first-
they-came-pastor-ma...](http://hmd.org.uk/resources/poetry/first-they-came-
pastor-martin-niemoller)

------
Lawtonfogle
The author seems to be calling a lot of things effectively bugs of encryption
that I see as features.

>Unfortunately, SSL prevents this. Unfortunately because it means that if a
website hosts partially illegal shared content, then the whole website is down
and not just the subsets of it which are legally problematic.

>But not everybody is entitled to privacy in all situations. For instance
convicted criminals are not. Likewise many lawful professions need to be
heavily surveyed for security.

>a pilot hid his psychological problems from his employer and intentionally
caused a plane to crash.

In my view this is all valid reasons to encrypt everything. When prisoners are
made such based on unjust laws, I say that anything that gives them their
rights is good. Forcing a government to be very overt about its censorship of
websites is good. Allowing people to hide their mental disorders in a world
where a mental disorder is still seen as a moral failing is good.

Encrypting everything enforces a positive change on society. Governments have
to be more open about their censorship, allowing for greater discussion.
Dissidents can communicate in secret, allowing for greater freedom. Critical
systems have to be built so that a single individual cannot cause a large loss
of life. Groups that are required to be surveyed must directly incorporate it
into their systems

As for the cost of using SSL, my understanding is that they are much
overstated.

------
jpgvm
I take issue with these arguments.

I respect the author but this doesn't read well reasoned.

Firstly CAs not being equipped to scale and the inevitable mistakes that will
happen in a highly manual process. Thankfully this has already been resolved,
we have DNS - if you are in control of DNS you are authenticated. This is is
the system to be used in the EFF automated certificate issuing protocol.

As for CPU cycles we have Moore's law (which is still in full effect for
things like SSL decryption). That and many many motivated engineers.

The next bit is where things get sour.

It seems the argument is because law enforcement has the "right" to read your
traffic that anything you do to dissuade them will only result in further
systematic destruction of privacy, i.e MITM attacks on SSL.

The final points around complexity do make some sense but those are against
SSL, not against encryption IMO. SSL and TLS are both hugely complicated but
this need not be the case.

As for my point of view.

We need encryption. Why? Because communication has changed.

Communication used to be manual and as such the attacks against it were manual
and unable to be orchestrated at scale. Government surveillance was better
understood because communication was simpler so lawmakers couldn't destroy all
privacy accidentally.

Now almost all communication is digital, it's become economical to simply
subvert -everyones- privacy. Lawmakers are at a loss to understand even basic
computer science let alone what motivated and technically sophisticated "law
enforcement" agencies can do with such massive amounts of information.

We need encryption to save privacy before it's lost forever.

~~~
the_mitsuhiko
> We need encryption. Why? Because communication has changed.

I never said that we don't need encryption, far form it. I said we do not need
to encrypt _everything_ and I firmly stand by that. If we do want to encrypt
the entirety of the internet traffic then I believe we need to consider all
the consequences this causes. That was my point, not more, not less.

~~~
fche
"I said we do not need to encrypt everything"

... as justified by many arguments from ignorance, like "I don't think
everyone ...", and "There is no technical reason..." over and over. Even one
counterexample for those (some helpfully supplied in comments hereabouts)
makes the arguments invalid.

~~~
the_mitsuhiko
> ... as justified by many arguments from ignorance, like "I don't think
> everyone ...", and "There is no technical reason..." over and over. Even one
> counterexample for those (some helpfully supplied in comments hereabouts)
> makes the arguments invalid.

I gave one very practical example of encryption being applied to file
transfers without a technical reason why that has to be. The same applies to
the majority of resources fetched from CDNs. The only reason we use SSL for
that is because there is no other method that browsers currently support for
guaranteeing the integrity of the loaded information.

~~~
Nursie
Authentication and Integrity are just as much part of SSL/TLS as secrecy is.
For code I'm going to run on my system, I quite like the idea that I can tell
where it comes from and if it's correct.

When it comes down to it, it's nobody else's business what python code-modules
I'm downloading, it might give them enough information to attack my servers,
so secrecy isn't a bad thing either.

~~~
the_mitsuhiko
> When it comes down to it, it's nobody else's business what python code-
> modules I'm downloading, it might give them enough information to attack my
> servers, so secrecy isn't a bad thing either.

There is much bigger issue there: nobody verifies package signatures. Most
packages do not even have ones. So you fundamentally have no way to verify
that what you downloaded is what you wanted. Someone could have stolen my PyPI
access credentials and uploaded a broken package under one of my releases.

Or I'm just a bad person and would ship you bad code.

SSL does not solve that problem.

~~~
Nursie
>> There is much bigger issue there: nobody verifies package signatures. Most
packages do not even have ones.

This is bad practice, and is not solved by _less_ integrity and authenticity
checking!

>> Or I'm just a bad person and would ship you bad code.

Nobody said it solves everything, but it does help prevent unrelated third
parties getting in on the act, actively or passively.

~~~
grincho
I'll just leave this here:
[https://pypi.python.org/pypi/peep/](https://pypi.python.org/pypi/peep/). (It
verifies Python package downloads against local hashes.)

~~~
Nursie
That certainly helps repeatability of install, but it doesn't (so far as I can
tell) help if you've been MITM'd on first download. So it's a bit like a self-
signed certificate at that point.

------
rakoo
> There is no technical reason for this unless you want to hide from someone
> that you are downloading a specific Python package which seems pointless.

"Oh, I see you're downloading this package in a slightly old version that is
still vulnerable. I guess you're going to install it, which means you'll be
vulnerable in the next 10 mins"

This is one of the main obstacles of things like apt-p2p or debtorrent (i.e
downloading your system packages in a p2p fashion): you don't wan't to tell
the whole world what are the packages on your machine.

~~~
falcolas
Agreed. There is a very technical reason for wanting to encrypt downloads.

There's a political reason as well: "I see you just downloaded pycrypto -
we're going to throw you on a watchlist since you obviously want to hide
something". This speculation is based on past actions doing this very thing
with Tor.

------
fennecfoxen
> The greatest impact on user's safety would have been the development of per
> user encryption for public Wifi access points. Instead what happened is that
> now every larger website has to implement SSL

Assuming that, once it's off the wifi, it's _utterly unrealistic_ that an
attacker could be anywhere else in the packet path? That -- even outside of
ecommerce -- there's no way any icky ISP could be doing deep packet inspection
to sell your data out for ads, or any virus on a cheap consumer-grade router
interested in hijacking your profile to turn into a spambot? And assuming,
moreover, that this New Technological Capability would be deployed in a
consistent and timely fashion? Sure, I agree it'd be an excellent deterrent to
many attacks on its own, but end-to-end encryption easily wins. (And if you're
really an interesting "larger website" then you have the resources to make SSL
happen.)

~~~
the_mitsuhiko
Of course the ISP could fiddle with your data. But likewise a post man could
open your mail. That fiddling with data is not a crime is first and foremost a
policy and law problem.

~~~
zAy0LfpBZLC8mAC
Given that encryption also solves the problem, and solves it much more
reliably than policy and law ever could, how do you justify the statement that
it's first and foremost a policy and law problem?

------
Nursie
This article takes the position the government has the right to shut down
communication it dislikes and spy on communication as it sees fit, as this is
legal in some places and the author does not want to get into whether or not
it should be legal.

This is a fundamental disconnect with how many people on the pro-encryption
side think - the government has no right to do this, regardless of the law,
and therefore we will do all we can to get in the way.

>> Cryptography is black magic.

It's maths.

>> As of recently the Python package installer downloads every package via
SSL. Why? There is no technical reason for this unless you want to hide

There are multiple reasons.

One might be to ensure integrity of the file, and authenticity of the source.
TLS gives you this, plaintext not so much.

Another is that the more uninteresting stuff there is getting encrypted, the
better, as it means it's less noteworthy.

~~~
sanxiyn
I think you are misrepresenting the position opposed to you. My position is
like this: pro-encryption people distrust government, which is fundametally
mistaken position. Government has rightful authority justified by democratic
process. Policy change should be done by democratic process, not by decree
from elites using technology such as encryption. Such policy-change-by-
technology bypasses democratic process and is dangerous. Trust is human
construct, so "trust math, not government" is position that is not only wrong,
but also is confused.

~~~
Nursie
>> Government has rightful authority justified by democratic process. Policy
change should be done by democratic process, not by decree from elites using
technology such as encryption.

This is demonstrably false in light of releases like Snowden's stuff. There is
little to no democratic oversight, and at every turn the people are denied the
knowledge of what their government is doing and are therefore denied the
ability to voice any opposition.

How can you democratically oppose something if nobody will even tell you it's
going on?

>> Such policy-change-by-technology bypasses democratic process and is
dangerous.

Democracy is being bypassed everywhere here.

------
maerF0x0
Not a fan of this argument. It applies the small economic negatives w/o
counting the value of the positives.

Pro: Democracy is more stable and more guaranteed Pro: Lower level criminals
are thwarted and the cost of attacks prohibit profitability of small attacks.
Pro: Increasing value of transactions are becoming possible online. No one in
their right (or educated) mind would sign into a $10k+ account if their
password/traffic wasnt protected.

------
icehawk
>From an economical perspective a few years ago nobody would have thought
about building a SSL MITM proxy for these purposes.

sslsniff was released over a decade ago.

~~~
the_mitsuhiko
From my limited testing Anti-virus solutions did not start to scan SSL
connections by default until last year.

~~~
icehawk
There have been security appliances that have had the ability to MITM and scan
SSL traffic since at least 2010.

------
makmanalp
I like this essay, not because I agree with most of its arguments, but because
it raises interesting ones. What's frustrating about it, to me, is that the
main thrust seems to be "There are problems with TLS, and especially using it
everywhere", which is very valid.

But then the message / proposed solution is "let's just give up on TLS except
for what I arbitrarily define as important". What I would have hoped for is
"let's try to make it better".

------
Zmetta
Encrypting everything promotes individual agency, the freedom of an individual
to communicate solely (encryption) and certainly (MAC) with whomever that
individual chooses. Cryptographic protocols do not inherently cause
performance or logistics complications (Resource usage, content isolation) as
these are side effects of other underlying issues with the technology upon
which we implement cryptography and can be fixed without compromising the
security of cryptography.

The only argument against pervasive solid encryption with potential validity
is external-party bypassing; where the external-party is outside the intended
group of involved parties (Bob & Alice) and wishes to access or manipulate the
secured communications. The most obvious situation being some external
authority wishing to prevent or prosecute a crime.

Traditionally, in the US, you (and your property) have agency until a warrant,
subpena, or probable cause arises. At this point, and no sooner, the acting
authority suspends some part of that agency for the assumed greater good of
the society and begins collecting evidence through an established process.
Without this suspension of agency the authority, traditionally, cannot and
should not be treating you or your property with reduced agency; the authority
should not be preemptively diminishing your agency by starting that evidence
collection process (compromising protections) with zero probably cause.

It is the problem and responsibility of that authority, as set out by the
social contract of free agents comprising our society, to reduce agency and
collect evidence AFTER probably cause arises and NOT as the default against
every citizen.

------
sqeaky
This article ignores the complexity of not encrypting everything.

What is the recourse for the average Joe when his social network doesn't
encrypt logins? Facebook did this for years, the average user just ignored it
and logged in, no amount of training or convincing could dissuade many.

What will the user interface look like for a site that is not encrypted but
verified secure? It is hard enough to get people verify the lock icon is green
or gold. Many ignore and just assume that online shopping is so fraught with
hackers that it cannot be done safely. This will not help that situation.

Why do we care about the cost of CPU cycles? No matter how good the encryption
is a human still needs to make a decision. Settling on a simple one helps the
human make it faster. CPU cycles get cheaper every year but the brain hasn't
improved in thousands.

Encrypting everything is simple and can be made to work even for less
technical people.

~~~
sqeaky
As a secondary point even if don't get simplicity isn't incorrectly setup
encryption, better than none? For one example: Self signed certificates don't
protect you from a man in the middle perpetrated by the government or ISP, but
they will stop neighbors with packet sniffers.

If we forgo simplicity I will still encrypt what I can. Having only some
protection is not the same as my protection being an illusion.

------
im3w1l
I agree with the point about CDN's. Cloudflare is a single point of failure,
that could tamper with connections to a large part of the web.

------
the_mitsuhiko
In case someone reads the cached version, I added a note about my point about
Wifi after it was brought up that the attacker could be the Wifi provider
itself so refresh the page.

------
unreal37
An interesting read.

Perhaps he should have said "Using SSL is like using antibiotics. If everyone
is using it all the time, the attackers just find ways around it that are
impossible to defend against and you're screwed."

Not sure I get the analogy about having gates on the subway are bad when
people need to use the subway in an emergency. Like, if you have a stab wound
and are taking the subway to the hospital, its better not to have to fumble
around for change in your pocket and line up for a ticket? Seems like there
are actually very few or no emergencies where someone needs to ride the subway
for free.

Also, I'm no SSL expert, but even if the certificate is expired and the user
acknowledges the error, isn't the communication still encrypted? They don't
lose the encryption just because of an expired certificate do they? I honestly
don't know, but I just assumed that's how it worked.

The one thing I agree with is that the trust model for SSL is opaque to most
users. I have no idea who my browsers trust by default, and I have no idea who
those guys trust, and even if there is a 3rd degree of trust beyond that, and
so ultimately there are thousands of people around the world who could spin up
an SSL certificate that my browser would trust without question. Strange
system.

~~~
zAy0LfpBZLC8mAC
> Perhaps he should have said "Using SSL is like using antibiotics. If
> everyone is using it all the time, the attackers just find ways around it
> that are impossible to defend against and you're screwed."

Except no such mechanism exists. If you build proper crypto, it's secure,
attackers can not simply make it insecure by wishing it were.

> Also, I'm no SSL expert, but even if the certificate is expired and the user
> acknowledges the error, isn't the communication still encrypted?

But it might be using a compromised key, for example. Also, one problem is
people getting used to clicking "OK" on SSL warnings, which might backfire
when confronted with an actual attack.

~~~
unreal37
> Except no such mechanism exists. If you build proper crypto, it's secure,
> attackers can not simply make it insecure by wishing it were.

It's like the XKCD cartoon.[1] The best crypto can be defeated by a wrench and
a guy willing to hit you with it. Or more likely, by passing laws requiring
all the major companies of the world to give the government access to the
servers whenever they wish. Or by building backdoors into routers that allow
them into networks.

The way to defeat good crypto is to go around it.

[1] [https://xkcd.com/538/](https://xkcd.com/538/)

------
sgdread
I want to point another thing: more and more ISPs are moving away network
neutrality. Latest example: Verizon is injecting cookies into users request to
be able track their activities and then sell gathered info to advertisers [1]
I don't have problems with 3-letter agencies doing what they have to do
(though, I would prefer to have proper governance over data access procedures
and SSL might help there too), but ISPs should not be altering your traffic.
Especially if you pay for the service. SSL prevents cookies injection.

[1] [https://www.eff.org/deeplinks/2014/11/verizon-x-
uidh](https://www.eff.org/deeplinks/2014/11/verizon-x-uidh)

~~~
the_mitsuhiko
ISPs should most likely not be allowed by law to intercept traffic for such
purposes.

------
krig
As I understand it, your argument on a technical level is basically that SSL
and the CA system as-is sucks, and I think most people would agree with that.
That's something that can be fixed (at least according to djb).

On a social level, I don't find any of the arguments convincing. The positives
of ensuring private communication far outweigh the negatives.

------
jerf
So, I've upvoted the article because these are things that need to be
discussed. And I don't have good answers necessarily, all I really have is a
sort of counterpoint to add to the pile of confusing issues.

Consider the two-dimensional graph of difficulty of hostile interception of
traffic vs. the value of hostile interception of traffic to the intercepting
entity. ("Interception" including both attacking authenticity and privacy of
the connection.) In the low/low side, you have, say, my blog posts.
Deliberately public, of interest to pretty much nobody "official",
unencrypted, unauthenticated HTTP. On the high/high side, well-encrypted
inter-colo traffic between two computers owned by a bank, or perhaps an arms
manufacturer.

10 years ago, this was a rich graph with lots of interesting nuances. Who even
cares about the easy/easy cases? Of course the hard/hard cases justify
encryption. And there's a lot of in between and useful cost/benefit analysis
that could be done. I think the original article is written based on this
mental conception of the landscape.

However, recently between technological advances and increased discovery about
what is being done by governments (and remember, _not just_ the US government,
_many_ have been caught doing things and many more are presumably getting away
with things we still have not heard about) and a variety of corporations (and
remember all this Superfish stuff and such _predates_ the mandatory
encryption!) has revealed that the previously-rich 2D landscape really isn't
2D after. It turns out that there is no "difficulty" dimension. It's all very
easy to intercept, at scale, if not downright trivial. Governments hoover
(both the vacuum and as in J. Edgar) up entire fiber optic trunks. Companies
and spyware get a footprint on a machine and basically nuke all SSL flat for
thousands of machines or entire major corporations at a time.

In the other dimension, it has become pretty clear that even "trivial
metadata" allows far more information to be exposed about someone than any but
a handful of computer scientists would have believed 10 years ago [1].
Everything has a great deal more value than we thought.

The net effect of all of this is that it collapses the entire previously-two-
dimensional landscape to a nearly a single point. Everything is trivial to
collect, and everything leaks a shocking amount of information, and
information is power.

Consequently, regardless of the fact that both answers suck in their own way,
we really only have one choice: Require encryption, or not. There's no middle
ground anymore. We used to have one, but it's collapsed away.

And, frankly, acknowledging everything in the original article and with the
amplification that there's probably even some stuff missing that could be
added, I'm pretty sure that in the end, there's still only one reasonable
choice, which is the direction we're currently headed in. Yeah, it sucks. But
a root cause analysis of the problem isn't that it's the encryption's fault...
it's the companies, spyware, and government that have put in so very, very
much effort into collapsing this landscape. Blame _them_ for the measures we
have to take to protect everybody.

Though, even as you do so, bear in mind that in the rich, complex ecosystem of
the Internet, parasites are ultimately inevitable, so it's also no use
pretending that if we just fix the current companies and governments we could
somehow change the problems. The only answer is that, yeah, we have to rewrite
how the "laws of physics" of this ecosystem work. The only other alternative
is the overproliferation of parasites and a resulting value collapse of the
ecosystem to humanity as it becomes too untrustworthy to use for a variety of
things we'd really like to use it for. (That is, I'm not claiming that the
Internet would become entirely useless, but we'd really _like_ to be able to
use it for important things, not just Buzzfeed and cat videos.)

[1]: [http://33bits.org/about/](http://33bits.org/about/)

~~~
adricnet
This is a really interesting argument you've advanced. The chart you describe
is illustrative and the changes wrought on it certainly disturbing.

Unfortunately, I think you have over-simplified a complex issue to a dichotomy
(encrypt everything or nothing) that is perhaps more confusing than helpful.

Encryption is a broad and diverse subject, as well as a field of expertise
(not mine). I doubt parties in the debate have axioms that align here as there
are so many interpretations and levels of detail to disagree about. Put more
clearly I don't think any three people reading this would agree on what you
mean by encryption in your post.

If you instead said "protect" "everything" / all traffic / all data/ all
browsing /... , and gave some details as to the threats you are concerned
about, it might strengthen the argument you are making.

EG : "protect" the "names of sites I visit" from sousveillance ... "protect"
the "integrity of software packages I download" from "evilgrade" attacks ...
protect "the pseudo-anonymity" of "journalists posting to social networks"
from "state sponsored malware injection" ... and so on. Encryption techniques
could be (are) used against all of these problems, but in different ways.

There is a lot to discuss and try to understand in these issues. Thank you for
contributing positively to the discussion ( and I hope I am as well).

------
thomashabets2
Tell this to Github. They are being Javascript DDoSed thanks to non-encrypted
connections.

And no, it's not "the same thing" if China forced baidu to do it directly, or
if they made CNNIC forge an SSL cert.

------
JulianMorrison
Nice bit of assuming the government's self-granted permissions are "rights"
and then hand wringing they can't access them, there. I find myself
unconvinced.

------
adricnet
Thank you for posting and discussing on HN. More discussion and more
viewpoints can only help as we all struggle with these political and technical
issues.

------
Skunkleton
> But not everybody is entitled to privacy in all situations.

Most people are entitled to privacy on the machines that they own. Having to
log or monitor internet traffic is the special case, and should not be the
default.

> That privacy and safety stand in a big conflict was recently quite
> dramatically demonstrated when a pilot hid his psychological problems from
> his employer and intentionally caused a plane to crash.

You claim a background in psychology, you should be able to recognise this as
fear mongering.

> The trust there is acquired by giving someone at a specific (private!)
> institution money and a copy of a passport. This system does not scale, and
> the number of SSL hosts is exploding.

A technological limitation in the current state of internet crypto is not a
reason to abandon the concept. Everyone agrees that the concept of a CA isn't
great. Someone will solve the problem eventually.

> SSL is bloody expensive compared to not doing it.

SSL is largely implemented in hardware these days. This is no longer true.

> SSL scales really badly intentionally.

I find it hard to accept that someone sat down and designed a system to not
scale intentionally. Especially hard to believe when you look at the scale of
SSL deployment today.

> A big cost of encryption however is lawful interception. This is not the
> place to discuss if governments should have the ability to intercept your
> internet traffic or not but in many cases they have that right.

A big cost of any societal construct is law enforcement. You can make the same
argument about cars, or wigs, or plastic surgery. Most of the world strives to
not limit personal freedoms out of fear.

> Unfortunately because it means that if a website hosts partially illegal
> shared content, then the whole website is down and not just the subsets of
> it which are legally problematic.

It is up to the website owners to manage this risk, with or without
encryption.

> A shocking amount of Windows users run software that MITMs SSL connections
> to scan for viruses, malware etc. Even Ad providers (Superfish cough)
> started to destroy SSL traffic because it became so widespread that it was
> necessary. I'm firmly of the opinion that none of that would have happened
> if SSL traffic was less common.

MITM is the default with unsecured traffic. Again, TLS isn't perfect, but why
give up?

> To give you an example of how ridiculous our love for SSL has become: PyPI.
> It's the Python package service. As of recently the Python package installer
> downloads every package via SSL. Why? There is no technical reason for this
> unless you want to hide from someone that you are downloading a specific
> Python package which seems pointless.

NO!!!!! Package managers are a huge target! What better way to sneak malicious
code into someone work than through package management traffic? TLS mitigates
this! This is a situation in which a trusted connection is a must.

~~~
tekacs
You need to edit this comment to add additional newlines after the quotes -
your responses are otherwise merged with them.

~~~
Skunkleton
Thanks. Updated.

------
bonjarber
>"this system is even larger than in the past and as such slip-ups are only
going to increase.”

Yes, the system is certainly larger (as is the internet as a whole) and slip-
ups are natural. Luckily these 'slip ups' are typically simple things like
certs expiring or supporting outdated cipher suites. These are just minor
configuration fixes that things like Lets Encrypt aim to fix (both
distribution and configuration of TLS). The thing is, even the worst 'slip
ups' don't make you any more insecure than only supporting HTTP. _Any_ amount
of TLS is better than none. That is a weak argument to start with.

>"SSL is bloody expensive compared to not doing it."

No it’s not. Certs are not expensive (another thing improved by Let’s
Encrypt). This opinion exists from people spreading these kinds of rumors.
It’s 2015 and the minor difference in processing power is negligible. If your
web hosting can’t handle the difference in processing costs, you need to look
for a better hosting platform.

>"Not only does that mean that you are downloading a really big certificate,
but also that the SSL encryption is a bit of a lie for you as a user.”

'Really big certificate' when has this been an issue for anyone ever? A CDN
providing SSL is still better than no SSL. That "lie" _still_ protects the
user at their host->Local Router->ISP->CDN. This is massive value not offered
via just HTTP.

>"The cost of deploying SSL should not be underestimated, and forcing SSL on
people out of principle should consider that.”

The cost raised by implementing SSL vs the cost of hosting a web application
is negligible. It's pennies on the dollar to ensure your users can have a
safer experience using your site. Security comes at a cost, this is part of
life.

>"The second method is to go to the local ISP and tell them to disable access
to it. The rather is the better option in the sense that it only affects the
citizens of that country and it isolates the problem. Unfortunately, SSL
prevents this.”

Yep it's a real shame that it's harder to censor websites. Joe Shmoe the
intended reader shouldn't use SSL just in case the government wants to
blacklist his domain.

>"Even Ad providers (Superfish cough) started to destroy SSL traffic because
it became so widespread that it was necessary. I'm firmly of the opinion that
none of that would have happened if SSL traffic was less common. “

THE WHOLE REASON THESE AD PROVIDERS ARE BREAKING SSL IS BECAUSE THEY CAN NO
LONGER WILLY NILLY READ/INJECT YOUR TRAFFIC. This exactly what Version +
AT&T's "super cookie" was doing to HTTP traffic. SSL _prevents_ shit like this
from happening. SSL being less common in no way equals less ads
reading/injecting your content.

>"The greatest impact on user's safety would have been the development of per
user encryption for public Wifi access points.”

This exists. It's called IPSec and it's a way bigger hassle than SSL, so we
all agreed in the 90's that it made more sense to prioritize SSL over IPSec.

>"Instead what happened is that now every larger website has to implement SSL
to protect against the only realistic attack vector which is someone surfing
at Starbucks.”

This is absolutely false. I would argue the _most_ users are at risk further
down the pipeline, not at Starbucks. We know for a fact that ISP's like
Verizon have injected cookies into HTTP traffic leaving their networks and we
know for a fact that Governments have done dragnet collections of HTTP
traffic. SSL protects users at every step of their internet journey,
suggesting half ass encryption is bullshit.

>"I now no longer claim I have any understanding of SSL at all.”

This is the most accurate statement he makes in the entire article.

>"Cryptography is black magic.”

Here in lies the problem. It's not. It's actually the opposite, it's open
source and it's inner workings can be explained by a multitude of resources.
The various features you call 'bugs' in SSL/TLS are things the security
community has refined over many years. Crypto is hard, and a lot of things
that seem intuitive are not. TLS exists in it's current state because it
accomplishes what we want crypto to do. Saying "everyone fuck this thing I'm
frustrated with" is counter productive to the whole process. ANY amount of SSL
is better for the user than none.

>"but the truth is that the most popular cryptography library (OpenSSL) is an
old and complex mess. Even if the library itself would be okay, there are so
many ways to misuse it and it's really badly documented.”

Oh boi let's jump on the OpenSSL hate wagon. We know OpenSSL has had it's
issues and there are lots of people helping to make it better
([https://cryptoservices.github.io/…/2015/03/09/openssl-
audit…](https://cryptoservices.github.io/…/2015/03/09/openssl-audit…)). The
fact that OpenSSL has the occasional implementation error doesn't make the
SSL/TLS protocol any worse.

>"Gone are the days where you could fully understand how a web application
works.“

This has gone from trying to make some kind of point to full whine fest. Yes,
web applications have become complicated. So have all parts of technology. As
things grow their internals become more intricate and complicated. Also gone
are the days where you can fully understand the inner workings of your car
engine. Doesn't mean we shouldn't use airbags.

>"As of recently the Python package installer downloads every package via SSL.
Why? There is no technical reason for this unless you want to hide from
someone that you are downloading a specific Python package which seems
pointless."

Or you know, you don't want packages injected/swapped out with malware when
you download them. If I'm downloading code I'm about to run on my system, you
better be sure as hell I'm going to want to want integrity and confidentiality
of said code. TLS is a standardized way of ensuring both of those things.

>"It's plenty to download the package over an untrusted connection and to then
verify the checksum with one you downloaded from a secure place."

WHERE IS THIS MAGICALLY SECURE PLACE? HOW DOES ONE COMMUNICATE WITH THIS
SECURE PLACE? For a guy who considers SSL to be too much effort, I'm to
believe that everything he downloads is checked against checksums received via
his 'secure place'

