
The network is hostile - pmh
http://blog.cryptographyengineering.com/2015/08/the-network-is-hostile.html
======
x5n1
> hostile to the core values of Western democracies.

It seems the governments have a very different idea of what those values are
than the people. Until those ideas are aligned, governments are out to get the
people. There is no point in any of this. Because ultimately, no matter what
technical solutions you can come up with, force and law always trump those.

Perhaps at some point you could make the argument that we don't explicitly
know what the government does and that's why it's doing it and getting away
with it. That's no longer the case. We know exactly what the government does,
we don't think that it's right, and yet we can do nothing to stop it. So
either we need to overhaul government or accept the status quo and quit
bitching about it or trying to create technical solutions to fix social
problems.

If the government can mandate networks spy on computers, it can mandate
manufacturers spy on users. As they are already doing this, fixing the network
solves nothing. As for foreign adversaries spying on users, well if you are
not in the US avoiding that is impossible as most of your computing experience
is under regulatory capture by the US government.

~~~
acabal
> Because ultimately, no matter what technical solutions you can come up with
> force and law always trump those.

That's a very important point that I think many who champion technical
solutions conveniently set aside. Remember that in the US in the 90s--in other
words, not that long ago-- _PGP was illegal and Phil Zimmerman was criminally
investigated for developing and distributing it._

Today PGP and GPG are some of the most powerful encryption tools we have
available to us--tools that Snowden says we can still trust. If someone makes
a better tool, or if these tools start to bother governments again, then
governments could just declare them illegal. Then you're faced with the
question of: "Do I encrypt my mail and risk a SWAT team blowing up my front
door and shooting my dog, then spending hundreds of thousands of dollars in a
protracted legal battle against the full might of the US government, or do I
just forget about it?"

The tech genie is out of the bottle, and the answer isn't more tech--it's
getting people, and thus governments, to understand and champion these tools
just like we do.

~~~
Decade
_The tech genie is out of the bottle, and the answer isn 't more tech--it's
getting people, and thus governments, to understand and champion these tools
just like we do._

No, the answer _includes_ better tech. OpenSSH and LibreSSL are doing good
work in removing insecure codecs. HTTP/2 looks like it should do well, because
no client implementation accepts plaintext. I’m hoping that protocols like OTR
and Darkmail become more widespread.

PGP is basically unusable. You can use it to dump secrets on journalists,
after you have trained the journalist. You can’t use it to lead a quiet,
private life. I tried. It’s not integrated with anything, and nobody else uses
it. It’s fatally flawed.

Being riddled with fatal flaws is an aspect PGP shares with the lucrative
Certificate Authority system, with S/MIME, with the DNS security system, with
IPsec, with cell phone encryption.

Worse, actual solutions are orthogonal to big business interests.
Decentralized trust? Google has no need for this; Google has its own
intermediate CA (which, through the totally broken CA model, means Google can
issue valid TLS and S/MIME certificated for any domain in the world).
Federated content sharing? Facebook has no need for this; Facebook needs all
your data to keep it safe for you, and also to analyze and monetize it.

What we need is to follow the article’s plea: Truly understand that the
network is hostile, and design our systems to make security the easy default.
And drop insecure protocols already, wherever there is a viable alternative.

~~~
simoncion
> It’s not integrated with anything...

It's integrated with Thunderbird via Enigmail. It works _at least_ as well as
MS Outlook's integrated message signing. If your reply to that is something
like "Everyone uses webmail.", I say "I've been using IMAP to access Gmail
since five minutes after the feature was added to Gmail.".

~~~
Decade
_Ahem_ [https://lwn.net/Articles/584542/](https://lwn.net/Articles/584542/)

~~~
simoncion
Noted. And, yeah, that sucks... a _lot_. However, my habit of _always_
composing plain-text messages and exclusively using attached signatures seems
to have inadvertently shielded me from those issues. :) It has been more than
a year since that article; I wonder if those bugs have been cleaned up.

This[0] seems to indicate that the only email client that has real problems
with attached signatures is Outlook Express. I can't bring myself to care much
about Outlook Express users. (Is OE even _installed_ on Windows 7 and later?)

[0]
[https://www.phildev.net/pgp/pgp_clear_vs_mime.html](https://www.phildev.net/pgp/pgp_clear_vs_mime.html)

~~~
Decade
That issue has been in the Thunderbird/Enigmail Rube Goldberg setup forever,
and publicly discussed since at least 2006. Always, the response is, Don’t use
Enigmail with HTML email. At this point, it would be bigger news if they
manage to fix it, so I expect to be informed if it happens.

The bigger problems are that it’s not integrated and it’s not effective for
shielding metadata. With difficulty and being mindful of the sharp edges, you
can use OpenPGP on desktop. You need a clunky third-party email client to get
it on mobile. Best case scenario, you send lots of extra data that gets
ignored. Worst case, all those attached signatures get downloaded as files,
causing confusion and anger. And there’s no interoperability with S/MIME,
which actually is supported by most proprietary email clients.

OpenPGP does not protect metadata. It piggybacks on SMTP, which publishes the
sender, recipient, and subject line in the clear, along with the identity and
timing of each server in the transport path from when you send the email to
when it lands in your recipient’s mailbox. PGP was originally conceived as the
“envelope” to protect your message contents, but in this era of unlimited
surveillance we need to do better.

~~~
simoncion
If we're concerned about metadata and timing analysis, we could use something
like a Mixmaster, along with TLS-only connections between email servers and
between the server and its clients. This would essentially be Tor for SMTP,
with the recipient's email server as the "exit node".

"Why aren't we doing this now?" Probably for the same reasons that we're going
back to the 1990's world of Instant Messaging walled gardens; techies and
cypherpunks are winning _some_ battles but not most of them, and non-technical
users don't understand what they give up when they choose a centralized Web
and ISPs that make them incapable of acting as a peer on The Internet. [0]

To the rest of your comment:

To the best of my knowledge, I've _never_ had Enigmail or Thunderbird mangle
my PGP signatures. I participate in a few technical mailing lists; the folks
there absolutely would tell me if my signatures were getting fucked up. For
mail that doesn't go to these lists, I can double-check the message copied to
my sent mail folder. :)

Installation of Enigmail on Windows, Linux and -I presume- Mac is trivial.
Based on reports, the sharp edges that you speak of _appear_ to be there; send
only plaintext email and attach -rather than inline- your signature and you
will -in my experience- avoid all of them.

The world of mobile software is largely a cesspool. Maybe I'm ignorant, but it
seems like the only folks doing good privacy protection mobile software are
Open Whisper Systems, the Tor Foundation (by way of Orbot), and Whatsapp. (The
Whatsapp folks are in this list because of the work that Open Whisper Systems
did to integrate TextSecure's near-zero-effort crypto into Whatsapp's
software.)

[0] Yes, I totally understand that almost no one in the US has a real choice
in ISP. Even here in Silicon Valley, I find myself prevented at every turn
from giving my money to local, independent ISPs. There's a little comfort in
the fact that Comcast allocates and routes up to a /60, and performs very,
very little inbound filtering.

------
krallja
This blog post isn't served over HTTPS, either:

    
    
        Secure Connection Failed
    
    
        The connection to blog.cryptographyengineering.com was interrupted while the page was loading.
    
        The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
        Please contact the website owners to inform them of this problem.

------
nly
> Anyone who has taken a network security class knows that the first rule of
> Internet security is that there is no Internet security.

True, but not a useful observation because we're stuck with the core of what
we have. I think it's more worrying atm that nobody can be bothered to even
deploy what we _do have_ : TLS, OCSP stapling, HSTS, HPKP, DNSSEC. This stuff
isn't difficult to deploy at the individual level. Especially for this crowd.
You can make a difference.

> We don't encrypt nearly enough

Ironic from a security conscious cryptographer and blogger who isn't
protecting his readers or himself with TLS. Ok, Matt isn't using WordPress,
but many do, and I wonder how many of them ever log in to moderate, or edit a
post, over networks they don't entirely trust? WordPress has a built-in file
editor and stores its config file in the docroot by default for crying out
loud... if someone gets your admin session cookie you're toast. They're one
patch away from your password, _and_ your commentators passwords and email
addresses, if they trust you with such, _and_ can plant as much malware on
your site as they please.

> It's the metadata, stupid

Yet Matt Green and Troy Hunt both use Blogger, effectively allowing their
readers interests and comments to be further pervasively catalogued by Google.

I'm not saying these minor hypocrisies are even 1 millionth as grievous as
failing to prevent the NSA from wiretapping the UN, or even terribly important
at all, but damnit... there are things we can all do instead of just pining
for a privacy utopia that isn't going to come. If you want privacy to be the
norm then protect _everything_ in your power, and aggressively, _NOW_ ,
everyway you know how.

~~~
Decade
_I think it 's more worrying atm that nobody can be bothered to even deploy
what we_ do have: _TLS, OCSP stapling, HSTS, HPKP, DNSSEC. This stuff isn 't
difficult to deploy at the individual level._

That’s because this stuff _is_ difficult.

TLS: The Let’s Encrypt[1] ceremonies seem to be going apace, perhaps to be
finally launched a month from now, but in the meanwhile you get only 1 free
certificate per year that actually works with most clients: The StartSSL
product.[2]

Which means you can encrypt only 1 hostname. Have multiple domains? Too bad,
you pay money. Have multiple hosts? Same thing. One of the things that made
tech so accessible is that you didn’t need to pay to start playing, and TLS
breaks that.

Also, want to support Android Gingerbread clients? Then you need an IP address
per TLS certificate. No SNI for you. You do know we’re in an IPv4 address
space crunch, right?

OCSP, HSTS, HPKP: Need a functioning TLS, first.

DNSSEC: Have you actually tried to implement DNSSEC? My personal domain is
validated using DNSSEC. A whole lot of pain for dubious gain.

And these security technologies are not set and forget. Microsoft seems fond
of getting TLS maintenance wrong, causing failures in cloud services[3] or the
basic security model[4]. DNSSEC also is supposed to do regular key rotations.
Which individual has time for all of that?

That’s if you even have access to enable security. A whole lot of content is
now published in centralized silos: Twitter, Facebook, Google, Wordpress. No
federation, no outside control: no need for individuals and organizations to
care about privacy. You are totally free to set up or join a diaspora* pod,[5]
but you will find yourself forever alone.

I think technology can be developed to make privacy easier, and I think
insecure defaults and fallbacks should be eliminated, but I am convinced that
it will not be easy.

[1][https://letsencrypt.org](https://letsencrypt.org)
[2][https://www.startssl.com](https://www.startssl.com)
[3][http://blogs.msmvps.com/peterritchie/2013/03/01/azure-
table-...](http://blogs.msmvps.com/peterritchie/2013/03/01/azure-table-
storage-and-the-great-certificate-expiry-of-2013/)
[4][http://arstechnica.com/security/2015/03/microsoft-
takes-4-ye...](http://arstechnica.com/security/2015/03/microsoft-
takes-4-years-to-recover-privileged-tls-certificate-addresses/)
[5][https://diasporafoundation.org](https://diasporafoundation.org)

~~~
nly
Excuses.

Wosign are giving away gratis SHA256 certs valid for up to 3 years, and
supporting up to 100 AltNames[0]. They're in all the major trust stores, and
cross-signed by Startcom (StartSSL).

I believe free basic wildcard certs will come. Someone will eventually break
formation.

> want to support Android Gingerbread clients?

No. Gingerbread is down to <5% of the Android user share and lots of apps
already don't support it. XP is arguably more of a problem at 10-12%.

IPv4 exhaustion is still mostly a problem of allocation. Big vendors already
have a glut of IPs. Even the budget VPS providers don't seem to care if you
spin up a dozen VMs just for the IP space, which isn't much more expensive
than the $2/mo many charge for additional IPs.

> Have you actually tried to implement DNSSEC?

Yes, I have. It's one easy command with PowerDNS.

[0] [https://buy.wosign.com/free/](https://buy.wosign.com/free/)

~~~
andrewflnr
I didn't know about that cert deal, and I was looking just a couple days ago.
It's not that easy. Anyway, I'll take a good look at it. Thanks!

------
windexh8er
Such a simple thought: "the network is hostile". Yet when you consider the
implications of that statement across the board you see stop-gap after stop-
gap to fill the void. And as Green points out - the state of the state is
bleak when it comes to the surveillance state.

His closing point is very open ended. But, thinking about this as to how
"network security" sells products in today's landscape if Green's suggestion
that these new systems would fulfill the goal of not having to worry about the
network because the systems are designed with an inherent zero-trust model,
how does the landscape of "network security" change? If the data path is
immune from protections (firewall, IPS, URL, etc.) then does the endpoint
radically change? Do we all end up with a containerized laptop with a front-
end NGFW/UTM/security blob with which is locally routed within to my guest
operation system of choice? And are the general functions broken out into
secure segments so that I can work and play while minimizing risk of a
malicious actor exfiltrating corporate data while I browse the questionable
reaches of the Internet?

Thought provoking, although - as Green states, I don't see many moving the
ball quickly (yet?).

~~~
bostik
One piece of what you wrote highlights a big part of the problem. My apologies
for lifting just four words out of your longer sentence, but the point is, I
believe, critical:

> _" network security" sells products_

Because people desire fire-and-forget solutions. We in the field know that
security is not a product, or even (pun intended) a product of products. It's
an ongoing process, where a term like "arms race" fails to convey the full
meaning or scope.

And above all, it's hard. If you want network and communications security at
scale, you will need to solve how to deploy a fairly large set of keys. Secure
key distribution depends on auditable trust. Bootstrapping trust relationships
is HARD.

Let's take an easy example. The entire CA industry is built around the premise
of seeking rent on trust. And then, to work around the problems that arose
from having a CA system in place, we came up with solutions like certificate
pinning. Which really boils down to imposing _distrust_ upon the very system
that exists because they sell trust.

While people want secure solutions, they really want to buy a product.
Precisely they want something that "just works", and in effect make the
complexities of security someone else's problem.

------
Zigurd
This should be completely clear to the people running mass-market internet
communication and storage services. And yet none of them encrypt payloads.

Ephemeral keys and forward secrecy are a solved problem for real time and
near-real-time communication. Why don't we have a Hangouts or Skype or Yahoo
Messenger that are secure against the state-actor threat?

At some point we have to assume the companies providing these services have
been persuaded to sell us all out.

~~~
at-fates-hands
>> At some point we have to assume the companies providing these services have
been persuaded to sell us all out.

Therein lies the problem.

Money controls everything. It's scary sometimes how fast people forget the
moral obligation to their clients and sell them out as soon as someone drops a
few million dollars in their laps.

~~~
nine_k
If these were paying customers, selling out would look much less attractive.

But we enjoy and expect certain services for free. In this case, as we all
know, we are necessarily the product being sold.

~~~
Zigurd
I don't want to detract from the valid point that if you are not paying for a
service, you are the product, not the customer.But I do pay for online
services from Google and Amazon and others, and would happily pay for secure
communication. None of them encrypt real time communication, and none encrypt
my data at rest with my key. Any portal that has directories or a social graph
is very well placed to implement a web-of-trust that would not rely on CAs.
But there's nothing like that out there.

------
panarky
All networks are hostile, not just the internet or "external" network.

Google's BeyondCorp [1] initiative recognizes this and treats the internal
network as untrusted.

Instead of trusting a privileged network or VPN, securely identify devices and
users assuming untrusted networks.

[1]
[http://static.googleusercontent.com/media/research.google.co...](http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/43231.pdf)
[PDF]

~~~
Gibbon1
I keep coming back to the idea that one should assume the computer is
untrusted. Which leads to two unpopular suggestions, keyboards that encrypt
typed characters to prevent spoofing by entities without physical access.
Displays with a separate side channel overlay system to bypass the core CPU
for certain security operations like entering pins.

~~~
spin
I've often thought about this, but came to the opposite conclusion: a laptop
is the smallest thing you can trust. The keyboard sends data to the CPU. The
CPU sends data to the screen. The CPU does encryption and talks to the
network.

I feel like there's no point in trying to chop it down any smaller than that.
All you're doing is shifting trust from "system A" to "system B", without
really changing anything.

~~~
Gibbon1
The keyboard has a CPU that can do encryption and signing, in addition to
decoding for key presses. Ditto for touch screens.

The reason for putting the encryption in system B AKA the keypad and display
controllers is, if you want end to end encryption, the keypad decoder and the
display controller are the closest to the end points you can get. And they are
single purpose devices that don't run arbitrary code nor accept arbitrary
input.

Compare that with laptop CPU's and complex operating systems with their huge
attack surfaces. Running software written by completely untrustworthy
corporations and individuals.

~~~
leni536
> And they are single purpose devices that don't run arbitrary code nor accept
> arbitrary input.

But be careful designing firmware upgrades though. Also I really don't see
what kind of attack it prevents when you have a trusted keyboard and display
but otherwise compromised OS.

------
zeveb
The thing is, as Prof. Green points out, _we 've all always known this, but
we've ignored it_. If the protocol one uses isn't secure when used over Tor
(because some Romanian exit node is able to snarf your password), then it's
not secure enough to use across the Internet in general.

XPKI simply isn't enough: it's a worst-of-all-worlds solution in which there's
not just _one_ global trust root, there are _hundreds_.

Using the blockchain as a globally-verifiable data store is interesting, but
comes with an incredible cost (and may still be vulnerable to manipulation).

Better, I think, would be to embrace the reality that human beings are
citizens of states, and to leverage that: if the governments of the United
States, Iran, Germany, Russia, Australia, Uzbekistan, Chad, Chile and Peru all
agree to a statement, then it's very probably true. We could use that kind of
unanimous (or supermajority) agreement as a trust root for identity, since
it's extraordinarily unlikely that ever state in the world would agree to the
same lie.

Once we have a global trust root, it's easy enough to carve off namespaces
within it. States could have authorised textual namespaces (e.g. '( _global-
root_ us)' for the United States: in a very real sense, '( _global-root_ us
foo)' _is_ whatever the US government wants it to be).

With this scheme, anyone would still be free to have his own, additional,
alternate roots; an assertion of '( _global-root_ uk british-airways)' would
not apply to '(billy-joe random-orgs ba)' unless the objects thus named shared
the same key.

------
sekasi
One glaringly obvious problem with this concept is that this very article
requires some basic insight in security engineering, and even for people that
are interested, it can be hard to digest.

How do we (blanket statement) try to address the overall level of
understanding that people have around this topic and make them understand that
the problem is real, serious and needs significant thought?

I've thought about this a fair bit. Think about your average non-super-
technical co-worker. How do we get them to see the problem in a clear way, and
how do we rally people around the problem? I don't know how to, but I try and
fail and try again. It's a tough gig. I do have an enormous man crush on
Matthew Green though.

------
exabrial
Yet half of everyone on HN _actually_ wants IPv6 so we can have less
privacy...

~~~
blfr
IPv6 gives you no less privacy. An IPv6 /64 identifies you just as much as a
regular /32 IPv4.

~~~
exabrial
Disagree, respectfully. With IPV4, it's extremely common, especially on
consumer home routers to be behind a NAT. IPv6 destroys your privacy because
it's now very easy for Google, click networks, NSA? to track a device behind a
firewall. There's a reason Google is pushing IPv6 so hard.

~~~
Decade
It would be nice to agree to disagree, but we really need IPv6 to displace
IPv4.

Google is pushing IPv6 so hard because IPv4 just can’t expand enough to
fulfill our needs. And not just Internet of Things, your light bulb needs to
be online, that sort of silliness. IPv4 can’t expand enough to raise each
community and each organization to a current first-world level of Internet
usage.

Want to build a Chinese Facebook? Can’t get enough IPv4 address space for all
the servers. Want to build Facebook in _America,_ can’t get enough IPv4
address space for all the servers.[1] Vint Cerf doesn’t need to be employed by
Google to say that IPv4 just wasn’t intended for the Internet of 2015. He made
IPv4. He knows.[2]

Using your MAC address for your IPv6 host address is now obsolete. Privacy
Extensions[3] are the current best practice. IPv6 address space is so
astonishingly vast, that it’s possible though not common to have a separate IP
address for each host you would want to contact during a single session. IPv6
is not inherently less private than IPv4.

[1][http://www.internetsociety.org/deploy360/blog/2014/06/facebo...](http://www.internetsociety.org/deploy360/blog/2014/06/facebook-
moving-to-an-ipv6-only-internal-network/)
[2][http://www.networkworld.com/article/2227543/software/why-
ipv...](http://www.networkworld.com/article/2227543/software/why-ipv6--vint-
cerf-keeps-blaming-himself.html)
[3][https://tools.ietf.org/html/rfc4941](https://tools.ietf.org/html/rfc4941)

------
rmc
> hostile to the core values of Western democracies.

The US Gov, and the NSA, act hostile to the core values of Western
democracies.

------
wavefunction
2 tru, all networks are hostile until you takeover

then they're frienly, to a pt.

by that I mean witness the fitness of network evolution in a hostile
environment

