This document discusses the importance of using more encryption on the Internet to increase privacy and security. It makes the following key points: 1) The Internet has become too easy to monitor as we have built it without sufficient security protections by default. More encryption needs to be implemented across Internet services and protocols to make eavesdropping more difficult. 2) Developers should enable encryption by default for all new Internet protocols. Opportunistic encryption techniques can provide some protections even without full authentication. 3) Individuals can help push for more encryption by requiring encrypted connections when using services and enabling tools like HTTPS Everywhere on their browsers. Transitioning to encrypted connections wherever possible raises the bar for surveillance.

1. #MoreCrypto
A small step to make it harder
to listen to IP based activity.
V2.2 TLS - oej@edvina.net - slideshare.net/oej - Twitter @oej
Ⓒ Olle E. Johansson, Stockholm, Sweden 2014-2015
This work is licensed under
2015-01-02

2. The problem
We have built an information network
that is too easy to monitor. We simply
trusted everyone too much in a naive way.
Sadly, we can’t do
that any more.

3. #MoreCrypto
The Internet mirrors society
When the Internet was small, there was a select group
of people using it. They felt is was a safe place.

4. #MoreCrypto
As the Internet grew and reflects more of society,
we forgot to harden it. It’s time now.

5. #MoreCrypto
The developers sets new
directions
All new Internet protocols should
have crypto turned on by default.
IAB November 2014
Internet is under attack. We need to
respond.
IETF 2013

6. What’s the problem?

7. #MoreCrypto
Changing the Internet
is too hard.
We are not using the
security tools we have in the
way they are meant to be
used today. In some cases, like e-mail and
IP telephony, most of us do not
use any security tools at all.

8. #MoreCrypto
How do we change?
The users must require change. Otherwise,
very few things happen. It is up to you and me.

9. #MoreCrypto
What needs to be done?
A lot of changes needs to be done in how we build
services, operate them and use them.
More crypto Easy to use authentication
Enhanced privacy Stronger confidentiality
…and much more

10. NEW!
OPPORTUNISTIC
SECURITY
Secure network traffic, regardless of what the user says.
Do whatever you can to make it harder to listen in.

11. Rethink.
Do we always need to combine authentication with
encryption? Really?

12. #MoreCrypto
Some encryption
most of the time
“Protocol designs based on
Opportunistic Security use encryption
even when authentication is not
available, and use authentication when possible,
thereby removing barriers to
the widespread use of encryption
on the Internet"
IETF RFC 7435
Viktor Dukhovni

13. #MoreCrypto
All or nothing?
“Historically, Internet security protocols have emphasized
comprehensive "all or nothing" cryptographic protection against both
passive and active attacks. With each peer, such a protocol achieves
either full protection or else total failure to communicate (hard
fail). As a result, operators often disable these security protocols
when users have difficulty connecting, thereby degrading all
communications to cleartext transmission.”
Full
protection
Failure????
Is there an alternative
between full protection and
failure?
RFC 7435 Viktor Dukhovni

14. #MoreCrypto
A secure session
Never show a lock to the user
for opportunistic crypto
🔒 Failure????
Authentication
and confidentiality

15. #MoreCrypto
TLS is an important tool
TLS
Transport
Layer
Security
TLS provides confidentiality, identity
and integrity to Internet communication.
TLS is used in HTTPS:// web pages, but can also be
used from applications on a computer as well as a cell
phone.
TLS is based on SSL, that was a provider-specific
technology. TLS is maintained by the IETF and is still
being improved.
The second part
covers this!

16. #MoreCrypto
…but not the only one
IPsec
DNSsec
SSH
DNS privacy
Encrypt TCP
New stuff
PGP

17. #MoreCrypto
Start simple.
Use connection encryption
wherever possible.
Use HTTPS and serve
information over HTTPS
In short:
#MoreCrypto

18. #MoreCrypto
Why?
More crypto on the Internet
raise the cost of listening in to
our information flows, our
conversations. It does not solve all the issues,
we have a lot of work
ahead of us.
Using more TLS is not very
complicated and can be used in
most applications today.

19. #MoreCrypto
Starting points.
Enable HTTPS for Facebook,
Google and other services
when you can.
Use EFF HTTPS ANYWHERE
in your web browser.
If you are a sysadmin, enable
TLS and follow new advice on
choice of algorithms.

20. #MoreCrypto
What does TLS give you?
Browser ServerConfidential path
Other people in the same network (or IT management)
can see where you go (server address), but not what you do.
Example:
Hotel staff can’t see what you write
or read on Facebook.

21. #MoreCrypto
What about VPN tunnelling?
Computer Confidential path
Example: Other people in the same
network (or IT management)
can see that you are using a VPN,
but not what you do.
Web
Server
Mail
Server
VPN = Virtual private network
On the other side of the VPN
server your connections
become visible again -
unless you are using TLS.
VPN
server
Example:
Hotel staff can’t see which web
sites you are connecting to.

22. #MoreCrypto
The work ahead of us
Mobile
apps
Web
IP
Telephony
E-mail
Cloud
Services
Internet of
things
The Digital
home
Chat
Video
Services
Require
#MoreCrypto!

23. Introduction to TLS
#MoreCrypto
Transport Layer Security
SSL
Authentication Confidentiality Integrity

24. #MoreCrypto
Identity
Security basics.
Confidentiality
Authorization
Integrity
Non-repudiation

25. #MoreCrypto
TLS is an important tool
TLS
Transport
Layer
Security
TLS provides confidentiality, identity
and integrity to Internet communication.
TLS is used in HTTPS:// web pages, but can also be
used from applications on a computer as well as a cell
phone.
TLS is based on SSL, that was a provider-specific
technology. TLS is maintained by the IETF and is still
being improved.

26. #MoreCrypto
Encryption
Using the same key for
encryption and decryption
Using two different keys for
encryption and decryption
SYMMETRIC ASYMMETRIC
Simple for the CPU,
supports streaming data
More computations,
easier for data blocks

27. Using a private
and a public key
• TLS use a keypair to set up a secure connection
• The server sends the public key at connection
setup
• The client challenges the server to verify that it
has the private key
• The server responds to the challenge using the
server private key
• Now the client knows that the server has the
private key that matches the public key
private
Step 1.

28. TLS Usage
• TLS is used for
• authentication of servers and
clients
• initiating encryption of a session
• digital signatures on messages to
ensure integrity and provide
authentication
Authentication"
Who are you? Prove it!
Encryption"
Providing confidentiality
Integrity"
Making sure that the receiver get
what the sender sent

29. #MoreCrypto
Crypto
TLS is a framework for
crypto
TLS & DTLS
TCP or UDP
IP, Internet Protocol - v4 & v6
KEY EXCHANGE ALGORITHM CHECKSUMS

30. #MoreCrypto
TLS & DTLS
Who’s there, really?
TCP or UDP
IP, Internet Protocol - v4 & v6
Digital
ID
Digital
ID
Real"
ID
Real"
ID
Person
Phone
Server
Person
Phone
Server
PKI, Certificate infrastructure
Bare keys, certs in DNSsec
Orga-
nization
Orga-
nization

31. Adding a certificate
to the mix
• A certificate is nothing more complicated than a
passport or an ID card
• It contains the public key and some administrative
data
• And is signed (electronically) by someone you
might trust ... or not.
• This is part of the complex structure called PKI,
which you might want or just disregard
• A PKI is not needed to get encryption for the
signalling path!
• You can however use a PKI to only set up
connections that you trust
Digital
ID
Real"
ID

32. The PKIX certificate
• An PKIX certificate is the standardised way to
bind a public key to an identity
• The certificate is issued and signed by a
Certification Authority (CA)
• A PKIX (also called X.509v3) certificate is an
electronic document with a specific layout
• Standard: documented in IETF PKIX RFC:s
Version
Serial number
Issuer identity
Validity period
User identity
Public key
Extension fields

33. X509.v3
contents
• Version number
• Certificate serial number
Used for validation
• Identity of the issuer
• Validity period
• Identity of the public key owner
• Public key
• Extension fields
• A digital signature, created by the issuer
Internet
Explorer
Certificate
Manager

34. Example: SIP certificates
• SubjectAltName contains a list of
identities that are valid for this
certificate - SIP domains
• RFC 5922 outlines a SIP event package
to distribute and manage certificates
• The domain cert is used to sign the
NOTIFY payload
TLS is more than the
world wide web!

35. x.509 cert for SIP
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
01:08:00:79:00:15:00:43
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=SipitTest Certificate Authority
Validity
Not Before: Sep 16 17:17:00 2009 GMT
Not After : Sep 15 17:17:00 2012 GMT
Subject: C=US, ST=California, L=San Jose, O=sipit, CN=tls6.test.sipit.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a7:96:65:6e:b6:ba:3a:48:a1:bd:a3:ae:21:dc:
a8:92:97:3c:43:ea:24:e6:9f:93:2f:61:7e:d3:2d:
30:1e:21:42:b9:d6:59:87:f1:b1:f8:c8:39:8e:43:
64:9a:31:2c:18:3d:cd:d8:03:64:bb:14:38:44:05:
20:30:d8:e1:db:a7:4d:c3:47:a2:49:73:d1:10:ed:
2f:cf:74:26:57:91:64:af:b0:f2:5d:3f:88:9f:df:
65:6c:ba:65:3f:66:99:52:6b:20:d2:0e:e3:65:18:
b1:8e:3d:ca:f2:4a:45:c5:4d:85:ef:82:54:f8:54:
54:db:96:90:9b:c5:1b:2a:1e:60:3c:43:71:55:60:
30:93:8f:fd:d8:d9:3d:a1:32:e3:56:4b:e2:73:b6:
cc:18:93:8a:d8:8b:68:81:c7:fd:cd:d5:dc:4c:a2:
86:61:9f:ad:d0:b1:d3:3c:4c:6c:07:54:b2:43:b4:
a7:0a:0a:f2:e3:6d:12:43:16:70:63:c9:e9:1a:78:
66:9d:ee:30:94:7b:ab:f2:e9:67:4a:66:6d:8c:ed:
a8:a4:98:51:77:0b:a7:60:55:73:85:87:4a:57:6b:
24:fe:27:00:02:79:70:da:5a:45:ad:aa:3d:d5:40:
5b:5c:85:63:93:56:af:c7:e8:e3:b6:1a:25:b6:a2:
2d:37
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:test.sipit.net, DNS:tls6.test.sipit.net, URI:sip:tls6.test.sipit.net
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
27:F7:A9:96:F5:B2:8F:0B:5E:A9:C7:F5:0F:AC:3D:AB:3D:8D:F0:30
Signature Algorithm: sha1WithRSAEncryption
1a:fe:1f:af:86:99:82:e5:14:97:8d:64:9a:d1:5c:ea:6c:96:
f5:c6:0c:7d:20:5f:4e:70:05:24:3a:de:b5:b9:cf:66:8d:4c:
74:d5:6a:a9:52:74:17:bc:b4:79:a0:58:32:78:a9:70:7c:6a:
15:ac:07:29:77:13:06:55:53:3f:0b:4c:3d:da:55:6e:ad:74:
56:01:55:c8:4c:19:8d:06:0b:f3:4c:04:d5:9a:6f:44:ad:7a:
fd:3b:aa:e8:4b:84:6e:f1:c4:34:f4:a0:6a:f6:81:ae:74:b4:
46:6e:b9:2f:a6:59:f1:02:e9:58:7c:a1:8d:08:31:2b:39:ee:
eb:7e
Subject: C=US, ST=California, L=San Jose, O=sipit, CN=tls6.test.sipit.net
X509v3 Subject Alternative Name:
DNS:test.sipit.net, DNS:tls6.test.sipit.net, URI:sip:tls6.test.sipit.net
Notice the URI in the certificate!

36. Process for a server
Generate
Keys
Pack public key
in CSR
Send CSR
to CA
CA validation
process
CA issues
Certificate
Install cert
in server with
private key
The private key
should never leave your hands.

37. Client connection
Open
connection
Server sends
certificate
Client
challenge server
Server answers
challenge
Client validates
certificate
Server can issue
cert request
Client and server
produce session key
Symmetric encryption
starts

38. Checking the cert
Get cert Ask CA if cert is valid
If revoked, close
connection
continue
Way too slow…
(In SIP we measure milliseconds at
call setup).

39. OCSP stapling
Get cert
Get certificate validity
statement, signed by CA continue
The signed validity statement needs to
be refreshed by server.

40. Protocol specifics
• Given a protocol request - how do we match the
request address to a certificate
• SIP Uri, E-mail address, HTTPS
• Make sure this validation happens when a
secure connection is requested.
sip:oej@namn.se https://edvina.se
mailto:info@iis.se Your protocol

41. #MoreCrypto
TLS and SSL
SSL v1.0 - 2.0
Created by Netscape
Communications
Deemed insecure.
SSL v3.0
Last version. No support for
extensions and not for modern
crypto algorithms. Deemed
insecure.
TLS 1.x
Open standard defined by the
IETF. Keeps being updated.
It’s time to try to stop
using SSL.

42. Issues
Certificate can validate correctly
with the CA store, but still be the
wrong certificate.
Certificate private key can be
copied and certificate
revocated.
DNS was spoofed, so we
reached the wrong service
Something new and even more
scary than Heartbleed and
Poodle…

43. Man in the middle
• How do we prevent and discover TLS proxys?
• Quite commonly used
Client ServerMITM

44. #MoreCrypto
Certificate Fingerpinning
Certificates have a fingerprint, a
checksum of the cert and key.
Embed last, current and next
certificate fingerprint in the code
Verify that you are talking with
the expected server.
TLS verification may work with a
bad server cert too.
Client ServerMITM
Client Server

45. #MoreCrypto
Trust on first use
Save certificate fingerprint on
first connection
If another certificate shows up,
warn the user
Don’t block, the first connection
could be bad
Certificates gets updates
so save expiry time and
accept new.
Client ServerMITM
Client Server

46. #MoreCrypto
DANE - using DNSsec
Save cert in DNS, signed by
DNSsec
If another certificate shows up,
do not continue. Disconnect.
Certificates that expired or was
revoked has no NS records
Client ServerMITM
Client Server
Client DNS
DNS query
TLS connection

47. DANE step by step
I want to speak with edvina.net using
http
Query DNS for a public key, fingerprint
or certificate
If response is validated using DNSsec,
trust it for verification
Connect and get cert from server
CA: Make sure cert is from the CA in
DNS, verify as before
Key/fingerprint: Make sure the cert or
key given by the server matches.
1.
2.
3.
4.
5. 5.

48. ?
User specifics
• Which CAs do we trust?
• How do we check validity of certificate, even if
we trust the CA?
• Do we have time for validation?

49. Toward new solutions
• Anchoring the certificate in DNS
• Validating the certificate in DNS
• No certificate - bare keys
• Opportunistic Security with TLS
DNSsec

50. Heartbleed
• Programming error in OpenSSL
• OpenSSL is used in too many
places
• Opened up for private key
distribution and a lot of other
in-memory data.

51. Security is a process
• There will be other issues with
TLS libraries, protocols and
implementations
• Surviving these is better than
having no security, integrity,
privacy or confidentiality

52. Enabling #MoreCrypto

53. #MoreCrypto
Enabling #MoreCrypto
So why don’t we use
more TLS?
Certificates are hard to
get and cost money.

54. #MoreCrypto
https://letsencrypt.org
Free certificates
Automated
certificates
Collaborative
Q1 2015

55. SUMMARY
#MoreCrypto

56. Advice:
• Use encrypted communication with TLS and
DTLS by default
• Authenticated sessions are more secure than
non-authenticated
• If you really need confidentiality, check ciphers
and checksum algorithms
#MoreCrypto

57. #MoreCrypto
The new solution
Opportunistic security
Separate identity and confidentiality
Some network sessions are better
without identity (OTR)
Make it harder to listen in
Always try crypto - regardless if
certificate validates
Never show a lock to the user
for opportunistic crypto 🔒

58. #MoreCrypto
To-do list
New projects:
Always build secure platforms. Encrypt all communication.1.
Users:
Use EFF HTTPS Everywhere, Require TLS sessions. Ask web site owners.2.
When buying new services/products:
Require use of TLS/DTLS. You will help us developers.3.

59. The way forward:
#MoreCrypto
Everyone can help!
Users
Developers
System admins
Network admins

60. #MoreCrypto
More information
ISOC: http://www.internetsociety.org/deploy360/tls/
https://bettercrypto.org
IESG: http://tools.ietf.org/html/rfc7258 - Internet is under attack.
IAB: https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/
https://www.eff.org/https-everywhere
Let’s Encrypt! https://letsencrypt.org
This presentation: slideshare.net/oej

61. Join us!
• IETF peerpass mailing list, UTA working group
and more.
• Hashtag #MoreCrypto
• http://internetsociety.org

62. Feedback?
• Feedback and suggestions for improvements to this presentation is
more than welcome! Send to oej@edvina.net!
• Feel free to use this presentation yourself - Notice the Creative
commons license on this presentation!
• Please tell me if you use it! It’s always fun to know.
#MoreCrypto
Author: oej@edvina.net - slideshare.net/oej
Ⓒ Olle E. Johansson, Stockholm, Sweden 2014-2015.
This work is licensed under
Olle E. Johansson