Secure encryption in a wiretapped future

Netways OSDC9th of April 2014

Michael Renner@terrorobe

My name is...

Worked in the IT for the last 15 yearsStrong focus on operationsAlways interested in security, never took it up professionallyPlease take the details with a grain of saltTight program, note questions down for the end of the talk

Quick poll

Who has Forward Secrecy enabled on their servers?Who was affected by the heartbleed bug and has already patched it?

Probably can skip the talk, for the rest - let's get started!

I. The internet is a scary place

I expect most people want to communicate in private, be sure that only they and the intended recipient can read the content.

Be safe from manipulation, trickery, imposters. Since the internet is the culmination of human society, it didn't take long to have people with malicious intent join the online communities.

They invented SSLThings were good.

So in 1994...

and everybody rejoiced.

"Safe online shopping""Safe online banking""Safe exchange of naughty pictures with your significant other"Things were good for some time

Implementations are not forever

But the fortress of cryptography got it's first cracks

• SSL 2.0: Broken

•MD5: Broken

• RC4: Broken

• SSL 3.0: Unfixable flaws

Over the last 20 years quite a few implementations were broken beyond repair and eventually phased out

Along comes TLS

So in 1999

TLS 1.0 standardized as successor to SSL 3.0

Took 5 years of experience in hostile internet environments to fix most glaring issues

And we thought we nailed it

• TLS based attacks:

• Renegotiation

• BEAST

•CRIME & BREACH

• Lucky thirteen

• Even SHA1 has first cracks in the armor

But we learned that we could only delay the inevitable

in the last five years there have been:

So we update openssl and hope for the best

And all these attacks mean "wait for vendor update, install updated library, _maybe_ restart daemons using those libraries, hope for the best"

And then the damn IPv4 space runs out

we're done installing the updates, and the damn IPv4 space runs out

and people go like "I WOULD REALLY LIKE MY SSL CERTIFICATE ON THIS WEBHOST!1"

...so we getServer Name Indication

Server Name Indication sends the Hostname the client is interested in to the server, so he can offer the right certificate to the client even when using namebased virtualhosting

Sounds like a good idea, supported since almost 5 years (so even RHEL6 has it)

...and we ask the customer if he has customers using Windows XP

...and we hope that the browser bar shows a cute little lock symbol

but in the end we're just interested in the lock symbol in the browser bar ...because that's all that counts.To hold all those eastern european mobsters and nigerian scammers away.

And we hope that the little lock symbol will hold them at bay

Until we read about APT

and I don't mean the Debian Package Manager there...

Advanced Persistent Threat (APT) is a set of stealthy and continuous hacking processes often orchestrated by human targeting a specific entity. APT usually targets organizations and or nations for business or political motives.

See http://en.wikipedia.org/wiki/Advanced_persistent_threat

Suddenly our little lock symbol doesn't look so mighty anymore.

Baddies, right?

And when reading this we think - that must be real bad people.

We think: "It hast to be the chinese! or maybe russians" - and certainly our network is most likely not too interesting for the chinese, amirite?

But then this guy comes along

...and tells us that it's probably not the Chinese and Russians we should be worried the most when it comes to Advanced Persistent Threats...

FVEY: Eavesdropping World Champions

See: http://en.wikipedia.org/wiki/Five_Eyes

...but the people on our side of the former iron curtain!

He worked for a subcontractor of the NSA and took a few documents with him giving us a few years old progress report.

Turns out the former crown colonies of great britain formed a eavesdropping group called FVEY, consisting of USA, Canada, Great Britain, Australia and New Zealand

This caused a huge ruckus, lots of fingerpointing, US telling the rest of the world that they shouldn't get too excited, since the rest of the governments is doing it too!

Runner ups

See: http://www.theguardian.com/uk-news/2013/nov/01/gchq-europe-spy-agencies-mass-surveillance-snowden

...and one by one cooperation agreement after cooperation agreement was publicized

Often unveiling how NSA & GCHQ helped other european countries to get legal and technical hurdles solved so that they can finally sniff their citizens data

...and since this monday

See: http://www.format.at/articles/1414/524/374054/nsa-oesterreich

...and you know, the Austrian cybercrime doctrine ("There is no cybercrime") didn't work for us either. This monday documents were leaked from our ministry of interior outlining cooperation agreements between the NSA and Austria

And we should've known better, with all the CEE headquarters and the United Nations office.

So what did we learn?

If you send data over links that

carry a lot of dataorcarry "interesting data"

your communication will be compromised.

Program Name Jeopardy

To give this abstract threat a bit more substance - let's do a quick round of Intelligence Community eavesdropping program name jeopardy

Tempora

Let's start out with tempora

Wiretapping by GCHQ - cooperation with

British Telecom, Interoute, Level 3, Verizon, Global Crossing, Viatel and Vodafone

Source: http://www.washingtonpost.com/world/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html

and Tempora enabled this:

Part of the MUSCULAR program

NSA noticed that they could see all the traffic in the public internet. But it was all encrypted. Which made things complicated. So they just started to tap the links between the Google Datacenters

Is anybody of you using MPLS across datacenters? Without encryption?

QUANTUM Suite

The QUANTUM suite is a series of tools used to exploit internet users by doing MAN ON THE SIDE attacks on their computers

See: https://firstlook.org/theintercept/article/2014/03/12/nsa-plans-infect-millions-computers-malware/

Lets assume this guy over here has a browser window to facebook.com open. Most modern web applications use long-polling techniques to be able to send status updates to their users.

Since the intelligence community has access to THE INTERNET thanks to Tempora, they know this.

So what happens is that they're using a program called TRAFFICTHIEF to select "interesting" users and then send back an answer that looks like it's coming from facebook, correct source/destination IPs, correct TCP sequence numbers

And put malicious payload in there. Suddenly the user is yours.

DISCOROUTE

Whom of you know rancid? Router & Switch config backup utility.

Turns out if you do a "show running-config" over an cleartext connection on a tempora-monitored link, NSA is keeping a backup of your config as well!

Part of the "I hunt sysadmins" blog post series

BULLRUN & TURMOIL

Bullrun is a program to:

* Break weak encryption* Introduce Weak encryption in software and products (Routers, Mobile Devices etc.)

Turmoil:

* Steal private keys* Use these keys to decrypt internet communication

See: https://firstlook.org/theintercept/article/2014/03/12/nsa-plans-infect-millions-computers-malware/

Part of their IPsec busting program

HAMMERSTEIN are router implants to sniff out trafficHands traffic of to TurmoilTurmoil, given that the key has already been stolen or is weak enough, can decrypt the data and save it awayOr if the agents want to be frisky they can even launch their on MITM attacks from there, impersonating servers in the VPN

are they allowed to do that?

What we know so far is that intelligence agencies operate within legal frameworks to do their work. And that they don't give a single fuck about the spirit of the law, constitution, Grundgesetz, Verfassung, etc.

If they've got access to data via an "official" interface which isn't monitored for usage & proportionality - consider your data compromised.

and we're even paying them for it!

Since it's all tax payer money and they're on a mission to hunt terrorists, communists, or whatever the scapegoat du jour is, they're not being stopped any time soon.

They've got lots of time, money and a cozy government job to do all these things which make our privacy and lives worse.

This is bad.

This is bad...

but situation is not entirely hopeless. A repeated occurrence in all the revelations was that proper crypto is still hard/impossible to break in a feasible manner. So our task at hand is to improve our cryptographic stance. But for that we need to know...

II. Crypto in a Nutshell

...to know how Cryptography works in the first place.

What should Cryptography do for me?

• privacy

• integrity

• identification

• non-repudiation

If we're taking a high-level look at cryptography we want it to fulfill four main tasks

Privacy: Nobody else is listening inIntegrity: Nobody can modify our communication without us knowingIdentification: I know who I am communicating withnon-repudiation: Neither side can deny that communication has taken place

Building Blocks

•Ciphers (e.g. AES)

• Private/Session keys

• Key Exchange (e.g. DH)

• Identification (e.g. DNS & X509)

• Signatures (e.g. RSA)

•Hash functions (e.g. SHA1 as HMAC)

...but since we can't just wave a magic wand and hope that the right thing happens we need to build such systems.

For this reason there're quite a few building blocks you'll find in any cryptographic system, be it kerberos, ipsec or ssh

...in the real world?SSL = TLS

...so much for theory, how do things look like in the real world?TLS is the prevalent secure socket communication layer.

Developed as SSL back in 1994 by Netscape, continuously improved over the last twenty years

Used for most TCP-based applications, e.g. HTTP, SMTP, IMAP, etc. pp.

TLS Handshake is done before application data can be transmitted, almost completely invisible to underlying application

On Cipher suites

•DHE-RSA-AES256-SHA256

• Key exchange protocol: DHE

•Authentication: RSA

•Cipher: AES256

•MAC: SHA256

and when dealing with crypto most people have seen a cipher suite at least once

defines which building blocks are going to be used for the specific communication

When we look at this we notice four components

Key Exchange: Used to establish a Session keyAuthentication: Used to authenticate the remote server Cipher: What's actually used to encrypt the data on the wireMAC: Message authentication - ensures that the data hasn't been modified

both server and client need to agree on a cipher suite to be able to communicate

and to do that there's a TLS handshake

ClientHello: Sends wanted TLS version and suggested CipherSuites

ServerHello: Sends selected TLS version & Ciphersuite. Sends back Certificate. Cert contains public key of server

ClientKeyExchange: Client sends required key material to server

ChangeCipherSpec: Everything beyond this message is authenticated & encrypted by chosen CipherSuite

Finished: Is authenticated & encrypted, finalizes TLS handshake

On X.509 certificates

X509 Certificates are issued & signed by a certificate authority.They bind a public key to an "Common Name" & other attributes

CAs can be nested, but TLS client has to trust the respective root CA, otherwise raises an TLS alert

Usually managed by your Browser and OS vendor

Typical example of a certificate

Has one intermediate CA which is signed by StartCom - operator of startssl.comPublic Key of this server valid for CN www.bettercrypto.org and aaron@lo-res.orgThose are mostly legacy

Additional DNS alternative names further down in the certificate, e.g. bettercrypto.org

Extensions Galore

• Server Name Indication

• To offer proper TLS VirtualHosting

• Secure Renegotiation

•Mitigates implementation flaws

•New cipher suites

•AES-GCM, Camellia, etc.

TLS also offers lots of extensions, here's a list of a few notable ones

Resumed TLS Handshakes

• Session IDs

• TLS state saved on server

• Session Tickets

• TLS state on client, encrypted by server key

Allow for faster TLS connection establishment

HTTP examples

Comparison:Unencrypted: One roundtrip to send HTTP requestW/ resuming: Two roundtrips to send HTTP requestW/o resuming: Three roundtrips to send HTTP request

...and that's it for the details

III. The world responds

Picking up where we left off, with all the governments gobbling up our communications data

So the situation is not only horrible..

...but also horribly complex

Fortunately we are not alone

But luckily we aren't alone in this, around the globe there've been many people who were as outraged as we were when they learnt about this new situation

High level papers

•Hallam-Baker: PRISM-Proof Security Considerations

• Farell, Tschofenigg: Pervasive Monitoring is an Attack

Drafts by IETF and others, stating that constant monitoring of traffic is an attack on the internet, which needs to be adressed in protocol design

Lots of work on protocols

• TLS 1.3

•Gets rid of all insecure Ciphers

•XMPP

•Mandatory encryption of all data

• STARTTLS vulnerabilities

• IMAP, XMPP, etc.

Tightening up of protocols

Lots of research & audits

• projectbullrun.org

•Government-independent crypto competitions

• e.g. http://competitions.cr.yp.to/

•Critical errors fixed in 2014:

• gnutls, Apple OS X & iOS, curl...

• heartbleed anyone?

And the science community was also active.

We've got Project Bullrun which documents the attempts of NSA to subvert random number generators

Dan Bernstein is doing lots of work organizing state-sponsor free crypto contests

And there's lots of focus on implementations, in the last 6 months we had major flaws fixed in gnutls, OS X, curl etc.

The X.509 PKI model is doomed

On a side note:

I'd like to mention that the x.509 PKI model is not secure against government actors and will need to be augmented or replaced.

From: "You Won't Be Needing These Any More: On Removing Unused Certificates From Trust Stores"

Analyzed which certificates were in the trust stores of OS and browsers

Looked how many of those were unused

Analyzed two months of Campus TLS traffic as well as did a ZMAP scan of the Internet to see which CA were in use

Of the 431 unique CAs present in all systems 148 were completely unused. Of those 148, 140 were not present in _ALL_ trust stores. The remaining 8 were installed in all systems but no certificate was ever seen.

X.509 Alternatives & Supplements

•DANE: DNS distributed & DNSSEC authenticated Certificates

• TACK(.io): Key pinning extension for TLS

•Certificate Transparency projects

Luckily there are a few alternatives or extensions of the current PKI model

DANE uses DNS data to basically say "these certificate fingerprints are fine for this domain" or "this CA is fine for this domain", DNSSEC authenticates this information. Still a government-operated PKI

TACK wants to get rid of PKI eventually, allowing authenticated TLS servers to hand out TACKs authoritatively stating which private keys are valid for this specific hostname.

And then there're the certificate transparency project which tries to address "rogue" certificates. For example - Google collects a list of "valid" public certificates in a long list, website operators can then send out pointers to that list for browsers to verify

IV. Doing your part

So these are the things other people are doing for you

but you also need to get moving to make sure that you provide a safe communication environment

1. Use TLS in the first place

We've learned that it's not only reckless but dangerous to use plaintext communication

Programs like the QUANTUM attack suite as well as DISCOROUTE show that DPI is part of the adversaries toolbelt

If you use secure encryption you make their lives much much harder

2. Use not only maintained but

recent software

To be able to use the strongest available ciphers you need to have fresh software.Just because your RHEL4 system is still maintained doesn't mean that it's actually a secure platform.

3. Use sufficiently sized keys and

hashes

Thirdly - use sufficiently large keys and hash sizes

The best cipher is pointless when the key used is far too small - which was the base of the US crypto export embargo 15 years ago

Source: http://keylength.com

Unfortunately "right size" is a hot topic when it comes to cryptography

Many people setting different standards, keylength.com aggregates all of these in a nice table.

This list was created with "safe by 2020" in mind

In a nutshell: Symmetric Ciphers: 128 bitAsymmetric Ciphers (SSL Certs et al): 2048 bitHashes: 256 bit

4. Use clients that only accept strong

cipher suites

Recent browsers are mostly fine, lots of focus on them.

Mail Clients, CLI tools like wget get much less attention.Custom applications and URL libraries? All bets are off.urllib2 for python for example does no validation at allruby ssl allowed cipher suites that were unauthenticated -> MITM

5. Configure servers so that they only offer strong cipher suites

Because if you only offer strong crypto, older/broken clients can't talk to you, preventing information leaks

Best orient on the guidelines on bettercrypto.org - have got a few examples later one

6. Use forward secure cipher suites

were possible

And last but not least - use forward secure cipher suites

• EDH/DHE or ECDHE Key Exchange

• Implies "Ephemeral" session key

• Forward Secrecy

Source: http://www.wired.com/2013/10/lavabit_unsealed/

These are cipher suites where the actual cipher doesn't use a key derived from the private key of the server but a completely ephemeral one, created individually for each TLS session.

With non-forward secure cipher suites you can decrypt all recorded traffic if you get ahold of the private key of the server. Forward secure ciphers prevent that.

A notable example was lavabit, mail provider of edward snowden.

Considerations for daemons

And if you adhere to these six rules, you shouldn't have to worry too much about anybody intercepting your communication.

I've prepared a few examples based around real world daemons, all based off.

bettercrypto.org

• Gathers best practices

• Peer reviewed by cryptographers, sysadmins and software maintainers

• Defined "Cipher String B"

• Focuses on strongest available ciphers on common set of platforms

• Does not support Windows XP and Java6 clients

off bettercrypto.org

apacheSSLCertificateFile server.crtSSLCertificateKeyFile server.keySSLProtocol All -SSLv2 -SSLv3SSLHonorCipherOrder OnSSLCompression off

# Add six earth month HSTS header for all users...Header add Strict-Transport-Security "max-age=15768000"# If you want to protect all subdomains, use the following header# ALL subdomains HAVE TO support HTTPS if you use this!# Strict-Transport-Security: max-age=15768000 ; includeSubDomains

SSLCipherSuite 'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'

honor cipher order: SSLv3 and TLSv1: Client chooses cipher

Compression: Prevents CRIME and BREACH attacks

HSTS: Instructs browsers to _ALWAYS_ use HTTPS for specific domains. Prevents HTTPS stripping attacks where MITM offers HTTPS site over HTTP

Postfixmain.cf:

smtpd_tls_cert_file = /etc/postfix/server.pemsmtpd_tls_key_file = /etc/postfix/server.key

# review smtp(d)_tls_loglevel settings

# enable opportunistic TLS support in the SMTP server and clientsmtpd_tls_security_level = maysmtp_tls_security_level = may

# if you have authentication enabled, only offer it after STARTTLSsmtpd_tls_auth_only = yes

# if supported by all clientssmtpd_tls_mandatory_protocols = !SSLv2, !SSLv3smtpd_tls_mandatory_ciphers=hightls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:[..]

master.cf:

587 inet n - - - - smtpd -o smtpd_tls_security_level=encrypt-o tls_preempt_cipherlist=yes

MSA (Mail Submission Agent) your mailserver receives mail from your clients MUAsMTA (Mail Transmission Agent, MX)sending MTA (SMTP client)

MSA:• listen on submission port 587 w/ mandatory TLS• enforce SMTP AUTH even for local networks• do not allow SMTP AUTH on unencrypted connections• optionally use the recommended cipher suites if supported by all clients

MTA: * use opportunistic encryption (If available - use it)* do not use self-signed certificates

dovecot

#dovecot defaults already require TLS and prohibit plaintext authentication over insecure links

ssl_cipher_list = 'EDH+CAMELLIA:EDH+aRSA:[..]'

...another important part when validating security of your network is to see if you've missed any services

Scanning for services

$ nmap -sV example.org

[..]Not shown: 988 closed portsPORT STATE SERVICE VERSION21/tcp open ftp ProFTPD 1.3.4a22/tcp open ssh OpenSSH 6.0p1 Debian 4+deb7u1 (protocol 2.0)25/tcp open smtp Postfix smtpd80/tcp open http Apache httpd143/tcp open imap Dovecot imapd443/tcp open ssl/http Apache httpd587/tcp open smtp Postfix smtpd993/tcp open ssl/imap Dovecot imapd

unfortunately there's no comprehensive scanner suite

nmap is a good start - it comes with scripting support, and somebody already implemented Protocol scanning

Lists SSL for implicit TLS only, no STARTTLS support yet

SSLyze

• Python based SSL scanner

• Project from iSECPartners

• Supports XML output for automation

•GPLv2

sslyze is a great python based ssl scanner

comes with bundled openssl

$ ./sslyze.py --regular example.org:443

SCAN RESULTS FOR EXAMPLE.ORG:443 ---------------------------------------------------------------------

* Compression : DEFLATE Compression: Disabled

* Session Renegotiation : Client-initiated Renegotiations: Rejected Secure Renegotiation: Supported

* TLSV1_2 Cipher Suites :

Rejected Cipher Suite(s): Hidden

Preferred Cipher Suite: DHE-RSA-AES256-GCM-SHA384 256 bits HTTP 200 OK

Accepted Cipher Suite(s): DHE-RSA-CAMELLIA256-SHA 256 bits HTTP 200 OK DHE-RSA-AES256-SHA256 256 bits HTTP 200 OK DHE-RSA-AES256-SHA 256 bits HTTP 200 OK DHE-RSA-AES256-GCM-SHA384 256 bits HTTP 200 OK CAMELLIA256-SHA 256 bits HTTP 200 OK AES256-SHA 256 bits HTTP 200 OK DHE-RSA-CAMELLIA128-SHA 128 bits HTTP 200 OK DHE-RSA-AES128-SHA256 128 bits HTTP 200 OK DHE-RSA-AES128-SHA 128 bits HTTP 200 OK DHE-RSA-AES128-GCM-SHA256 128 bits HTTP 200 OK CAMELLIA128-SHA 128 bits HTTP 200 OK AES128-SHA 128 bits HTTP 200 OK

[..]

Typical output for a sslyze run...

Web Services Galore

•HTTP: https://www.ssllabs.com/ssltest

•XMPP: https://xmpp.net/

• SMTP: https://checktls.com/

• Browser: https://www.howsmyssl.com/

There are also various webservices which help with auditing

Unfortunately there's no modern ssldump

Would be nice to have tool to run at network edgessniffs out all TLS handshakescomplains when weak cipher suites are offered or chosen.

Thanks to

• The bettercrypto.org team

•Aaron Zauner - @a_z_e_t 

•All the people devoting their time to security research

• You, for listening

And that's it for the material I prepared...

I'd like to say thanks to...

https://tinyurl.com/cryptolinks

Questions?

You can find links to all material and references at...