Fundamentals of Network Security
3. Network Security Protocols
CryptoWorks21 • September 24, 2014
Dr Douglas Stebila
Network Security Protocols
•
Public Key Infrastructure
•
Transport Layer Security (TLS)
•
Other protocols
–
Secure Shell (SSH)
–
IPsec
–
Tor
–
Kerberos
OSI network protocol stack
•
ApplicaTon to handle data
•
HTTP, FTP, SSH, SMTP, SNMP, …
ApplicaTon
•
Data representaTon, encrypTon
•
TLS (Transport Layer Security) / SSL (Secure Sockets Layer)
PresentaTon
•
Managing sessions
•
Tor??
Session
•
End-‐to-‐end connecTons, reliability, flow control
•
TCP (Transport Control Protocol), UDP (User Datagram Protocol)
Transport
•
Logical addressing
•
IPv4, IPv6; IPsec
Network
•
Physical addressing
•
802.3 (Ethernet)
Data Link
•
Media, signal, and binary transmission
•
802.3 (Ethernet), 802.11 (Wireless); WEP
PUBLIC KEY INFRASTRUCTURES
(PKI)
Using digital signatures for enTty
authenTcaTon
Bob sends a
random
challenge to
Alice
Alice signs
the challenge
using her
private key
Alice sends
signature to
Bob
Bob verifies
the signature
using Alice’s
public key
CerTficates and
cerTficate authoriTes
•
A
cer6ficate
is an asserTon by a trusted third party that a
parTcular public key belongs to a parTcular enTty.
•
The
cer6ficate authority
generates a cerTficate by
1.
Obtaining the user’s public key by some trust mechanism.
2.
Verifying that the user really is who she says she is.
3.
Signing (using the cerTficate authority’s public key) the user’s
public key and name.
•
This allows two parTes who have never met to establish
trust between them:
–
Exchange cerTficates.
–
Do authenTcaTon using digital signatures.
–
If they each trust the cerTficate authority that signed the other
party’s cerTficate, they can now be certain who the other party
is.
X.509 cer6ficates
CerTficate:
Data:
Version: 3 (0x2)
Serial Number:
16:24:26:2c:02:90:40:f5:31:47:9a:e6:9c:bb:3d:4d
Signature Algorithm: sha1WithRSAEncrypTon
Issuer: C=AU, O=AusCERT, OU=CerTficate Services, CN=AusCERT Server CA
Validity
Not Before: Jun 6 00:00:00 2011 GMT
Not Aker : Jun 5 23:59:59 2012 GMT
Subject: C=AU/postalCode=4001, ST=Queensland,
L=Brisbane/street=PO Box 2434 Brisbane,
O=Queensland University of Technology, OU=EIS IntegraTon Services,
CN=esoe.qut.edu.au
Subject Public Key Info:
Public Key Algorithm: rsaEncrypTon
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:e1:9c:3b:d7:5f:73:93:6f:2a:44:47:c0:cf:97:
...
b5:0c:8e:26:a6:91:db:ca:58:cb:dd:8f:e0:0c:b4:
4f:6f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key IdenTfier:
keyid:94:6B:23:B9:26:EA:82:B4:53:60:9D:89:5D:F7:02:C4:D9:29:5D:E9
X509v3 Subject Key IdenTfier:
23:D1:1D:4E:C0:E2:E0:1B:88:CC:7C:BB:B8:A1:C8:28:CA:D8:A2:4F
X509v3 Key Usage: criTcal
Digital Signature, Key Encipherment
X509v3 Basic Constraints: criTcal
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server AuthenTcaTon, TLS Web Client AuthenTcaTon
X509v3 CerTficate Policies:
Policy: 1.3.6.1.4.1.23485.5.1.1.0
X509v3 CRL DistribuTon Points:
URI:hnp://crl.cs.auscert.org.au/AusCERTServerCA.crl
Authority InformaTon Access:
CA Issuers -‐ URI:hnp://crt.cs.auscert.org.au/AusCERTServerCA.crt
OCSP -‐ URI:hnp://ocsp.cs.auscert.org.au
X509v3 Subject AlternaTve Name:
DNS:esoe.qut.edu.au, DNS:www.esoe.qut.edu.au
Signature Algorithm: sha1WithRSAEncrypTon
8b:f5:7e:92:24:31:32:38:2a:2e:0c:b8:37:aa:1b:0f:4a:ab:
...
30:97:76:eb:12:c0:54:a5:b1:e7:91:c5:7a:4f:b5:25:5d:34:
87:b7:ee:e8
A standardized format for cerTficates.
Uses a strange (old) format called ASN.
1 and a strange binary encoding.
Public key
CerTficate authority
Validity period
RevocaTon
informaTon
Domain name
CA’s signature on
everything above
+
CerTficate revocaTon
Cer6ficate Revoca6on Lists (CRLs)
•
Each CA can publish a file
containing a list of cerTficates that
have been revoked.
•
Have to download whole list.
•
CRL address oken included in
cerTficate.
•
Once a cerTficate’s been issued,
what happens if the user’s
private key has been
compromised?
•
We would like to be able to
revoke
the cerTficate, or indicate
that it should no longer be
trusted.
•
When revoking cerTficates that
were used for message
authenTcaTon, what does that
mean for documents signed using
that cerTficate? May need a
trusted Tmestamp server as well.
Online Cer6ficate Status Protocol
(OCSP)
•
An online service run by a CA for
checking in real-‐Tme if a cerTficate
has been revoked.
•
Don’t have to download whole list.
Public key infrastructure
A
public key infrastructure (PKI)
is
•
a set of systems (hardware, sokware, policies, procedures)
•
for managing (creaTng, distribuTng, storing, revoking)
•
digital cerTficates.
Includes:
•
one or more cerTficate authoriTes
•
users
•
relying parTes
•
possibly a Tmestamp server
•
possibly a directory server storing cerTficates (e.g., LDAP
DigiNotar breach
•
DigiNotar was a Dutch CA that issued
cerTficates under two main CAs, one
for public websites (“DigiNotar Root
CA”) and one for the Dutch
government.
•
The cerTficate for “DigiNotar Root CA”
was built in to all major browsers.
•
In July 2011, a cerTficate was
fraudulently issued for Google and was
used in Iran in August to conduct man-‐
in-‐the-‐middle anacks against Google
services.
•
Subsequently it was revealed that
many other fraudulent cerTficates had
been created, including for Yahoo!,
Mozilla, WordPress, and Tor. The full
list of fraudulently created cerTficates
was not known.
•
Microsok, Mozilla, Google, Apple, and
Opera all issued updates removing
DigiNotar from the list of trusted CAs.
•
DigiNotar declared bankruptcy on
September 20, 2011.
Extended validaTon cerTficates
•
CAs are meant to verify that the enTty requesTng
a cerTficate really is who they say they are.
•
Mechanisms previously in use were inconsistent:
–
Fax lener on company lener head.
–
Use company email address.
–
Has control of domain name in quesTon.
–
Pay VeriSign $399/year.
•
Extended valida6on (EV)
cerTficates have a
formal enTty verificaTon process.
–
And they cost more.
–
A lot more.
EV cer6ficates in web browsers
Browsers typically show the name of the business and use addiTonal UI elements
to emphasize this is a “more trustworthy” site, such as colouring the address bar
green.
Eye-‐tracking studies show that users do not noTce these addiTonal security
indicators.
Secure email
•
X.509 cerTficates can also be used to send secure email:
–
digitally signed
–
encrypted
•
S/MIME
(Secure/MulTpurpose Internet Mail Extensions):
–
Supported in most desktop mail programs.
–
Relies on a public key infrastructure.
•
PGP
(Preny Good Privacy):
–
Available as an add-‐on to most desktop mail programs.
–
Uses public keys, but doesn’t require CAs: users manually
distribute their keys in a “web of trust”
•
Not widely used:
–
Users must know how set up public keys and obtain S/MIME X.
509 cerTficate or distribute PGP public keys.
ApplicaTons of PKIs
•
Web site authenTcaTon (TLS)
•
Email authenTcaTon (S/MIME, PGP)
•
Domain names (DNSSEC)
•
Digital idenTTes
–
e.g., naTonal idenTty cards (Belgium, Spain,
Germany)
•
Business-‐to-‐business e-‐commerce
TRANSPORT LAYER SECURITY (TLS)
•
SSL: Secure Sockets Layer
•
Proposed by Netscape
–
SSLv2: 1995
–
SSLv3: 1996
•
TLS: Transport Layer
Security
•
IETF StandardizaTon of
SSL
–
TLSv1.0 = SSLv3: 1999
–
TLSv1.1: 2006
–
TLSv1.2: 2008
•
HTTPS: HTTP (Hypertext
Transport Protocol) over
SSL
Security goals of TLS
•
Provides
authen6ca6on
based on public key
cerTficates
–
server-‐to-‐client (always)
–
client-‐to-‐server (opTonal)
•
Provides
confiden6ality
and integrity of
message transmission
•
But only protects confidenTality if
Use of TLS
•
Primarily used to secure
applicaTons such as
HTTP, FTP, SMTP, IMAP
•
ApplicaTon to handle data
•
HTTP, FTP, SSH, SMTP, SNMP, …
ApplicaTon
•
Data representaTon, encrypTon
•
TLS (Transport Layer Security) / SSL (Secure Sockets
Layer)
PresentaTon
•
Managing sessions
•
Tor??
Session
•
End-‐to-‐end connecTons, reliability, flow control
•
TCP (Transport Control Protocol), UDP (User
Datagram Protocol)
Transport
•
Logical addressing
•
IPv4, IPv6; IPsec
Network
•
Physical addressing
•
802.3 (Ethernet)
Data Link
•
Media, signal, and binary transmission
•
802.3 (Ethernet), 802.11 (Wireless); WEP
•
5 protocol versions
•
vast array of standards
•
many implementaTons!
•
300+ combinaTons of
cryptographic primiTves
•
different levels of security
•
different modes of
authenTcaTon
•
addiTonal funcTonality:
–
alerts & errors
–
session resumpTon
–
renegoTaTon
–
compression
What is TLS?
1995
!
1996
!
1999
!
2006
!
2008
!
hnps://www.trustworthyinternet.org/ssl-‐pulse/
September 4, 2014
The current approved version of TLS is version 1.2, which is specified in:
•
RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”.
The current standard replaces these former versions, which are now considered obsolete:
•
RFC 2246: “The TLS Protocol Version 1.0”.
•
RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”.
as well as the never standardized SSL 3.0:
•
RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”.
Other RFCs subsequently extended TLS.
Extensions to TLS 1.0 include:
•
RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Specifies an extension to the IMAP, POP3 and ACAP services that allow the server and client to
use transport-‐layer security to provide private, authenTcated communicaTon over the Internet.
•
RFC 2712: “AddiTon of Kerberos Cipher Suites to Transport Layer Security (TLS)”. The 40-‐bit cipher suites defined in this memo appear only for
the purpose of documenTng the fact that those cipher suite codes have already been assigned.
•
RFC 2817: “Upgrading to TLS Within HTTP/1.1”, explains how to use the Upgrade mechanism in HTTP/1.1 to iniTate Transport Layer Security (TLS)
over an exisTng TCP connecTon. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, hnp: at 80 rather
than hnps: at 443).
•
RFC 2818: “HTTP Over TLS”, disTnguishes secured traffic from insecure traffic by the use of a different 'server port'.
•
RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Specifies an extension to the SMTP service that allows an
SMTP server and client to use transport-‐layer security to provide private, authenTcated communicaTon over the Internet.
•
RFC 3268: “AES Ciphersuites for TLS”. Adds Advanced EncrypTon Standard (AES) cipher suites to the previously exisTng symmetric ciphers.
•
RFC 3546: “Transport Layer Security (TLS) Extensions”, adds a mechanism for negoTaTng protocol extensions during session iniTalisaTon and
defines some extensions. Made obsolete by RFC 4366.
•
RFC 3749: “Transport Layer Security Protocol Compression Methods”, specifies the framework for compression methods and the DEFLATE
compression method.
•
RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-‐Ziv-‐Stac (LZS)”.
•
RFC 4132: “AddiTon of Camellia Cipher Suites to Transport Layer Security (TLS)”.
•
RFC 4162: “AddiTon of SEED Cipher Suites to Transport Layer Security (TLS)”.
•
RFC 4217: “Securing FTP with TLS”.
•
RFC 4279: “Pre-‐Shared Key Ciphersuites for Transport Layer Security (TLS)”, adds three sets of new cipher suites for the TLS protocol to support
authenTcaTon based on pre-‐shared keys.
Extensions to TLS 1.1 include:
•
RFC 4347: “Datagram Transport Layer Security” specifies a TLS variant that works over datagram protocols (such as UDP).
•
RFC 4366: “Transport Layer Security (TLS) Extensions” describes both a set of specific extensions and a generic extension mechanism.
•
RFC 4492: “EllipTc Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.
•
RFC 4507: “Transport Layer Security (TLS) Session ResumpTon without Server-‐Side State”.
•
RFC 4680: “TLS Handshake Message for Supplemental Data”.
•
RFC 4681: “TLS User Mapping Extension”.
•
RFC 4785: “Pre-‐Shared Key (PSK) Ciphersuites with NULL EncrypTon for Transport Layer Security (TLS)”.
•
RFC 5054: “Using the Secure Remote Password (SRP) Protocol for TLS AuthenTcaTon”. Defines the TLS-‐SRP ciphersuites.
•
RFC 5081: “Using OpenPGP Keys for Transport Layer Security (TLS) AuthenTcaTon”, obsoleted by RFC 6091.
Extensions to TLS 1.2 include:
•
RFC 5746: “Transport Layer Security (TLS) RenegoTaTon IndicaTon Extension”.
•
RFC 5878: “Transport Layer Security (TLS) AuthorizaTon Extensions”.
•
RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) AuthenTcaTon“.
•
RFC 6176: “ProhibiTng Secure Sockets Layer (SSL) Version 2.0”.
•
RFC 6209: “AddiTon of the ARIA Cipher Suites to Transport Layer Security (TLS)”.
hnp://en.wikipedia.org/wiki/
Transport_Layer_Security
Structure of TLS
NegoTaTon of cryptographic parameters
AuthenTcaTon (one-‐way or mutual) using public key cerTficates
Establishment of a master secret key
DerivaTon of encrypTon and authenTcaTon keys
Key confirmaTon
Bi-‐direcTon authenTcated encrypTon
OpTonal compression
HA
N
D
SHA
KE
P
RO
TO
CO
L
RE
CO
RD
LA
YE
R
ALERT PROTOCOL
Structure of TLS
ClientHello --->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<--- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
(derive session keys)
[ChangeCipherSpec]
Finished --->
(derive session keys)
[ChangeCipherSpec]
<--- Finished
Bi-‐direcTon authenTcated encrypTon
OpTonal compression
HA
N
D
SHA
KE
P
RO
TO
CO
L
RE
CO
RD
LA
YE
R
RSA k
ey tran
sport
staTc
Diffie–He
llman
ephem
eral Diffi
e–Hel
lman
staTc
/ ephe
meral
ECDH
SRP
Session key derivaT
on:
HMAC with
(MD-‐5‖SHA-‐1) or SHA
-‐256
DES/3DES CBC
AES CBC/GCM/CCM
RC4
TLS version
random nonce
session idenTfier
preferred ciphersuites
preferred compression method
extensions
RSA
DSA
ECDSA
RSA
DSA
ECDSA
Components of TLS
Crypto
primiTves
•
RSA, DSA, ECDSA
•
Diffie–Hellman,
ECDH
•
HMAC
•
MD5, SHA1,
SHA-‐2
•
DES, 3DES, RC4,
AES
Ciphersuite
details
•
Data structures
•
Key derivaTon
•
EncrypTon
modes, IVs
•
Padding
Advanced
funcTonality
•
Alerts & errors
•
CerTficaTon /
revocaTon
•
NegoTaTon
•
RenegoTaTon
•
Session
resumpTon
•
Key reuse
•
Compression
Libraries
•
OpenSSL
•
GnuTLS
•
SChannel
•
Java JSSE
ApplicaTons
•
Web browsers:
Chrome, Firefox,
IE, Safari
•
Web servers:
Apache, IIS, …
•
ApplicaTon SDKs
•
CerTficates
TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_WITH_IDEA_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DH_DSS_WITH_DES_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DH_RSA_WITH_DES_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA TLS_KRB5_WITH_DES_CBC_SHA TLS_KRB5_WITH_3DES_EDE_CBC_SHA TLS_KRB5_WITH_RC4_128_SHA TLS_KRB5_WITH_IDEA_CBC_SHA TLS_KRB5_WITH_DES_CBC_MD5 TLS_KRB5_WITH_3DES_EDE_CBC_MD5 TLS_KRB5_WITH_RC4_128_MD5 TLS_KRB5_WITH_IDEA_CBC_MD5 TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 TLS_KRB5_EXPORT_WITH_RC4_40_MD5 TLS_PSK_WITH_NULL_SHA TLS_DHE_PSK_WITH_NULL_SHA TLS_RSA_PSK_WITH_NULL_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_RSA_WITH_NULL_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_DH_DSS_WITH_AES_128_CBC_SHA256 TLS_DH_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA TLS_PSK_WITH_RC4_128_SHA TLS_PSK_WITH_3DES_EDE_CBC_SHA TLS_PSK_WITH_AES_128_CBC_SHA TLS_PSK_WITH_AES_256_CBC_SHA TLS_DHE_PSK_WITH_RC4_128_SHA TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA TLS_DHE_PSK_WITH_AES_128_CBC_SHA TLS_DHE_PSK_WITH_AES_256_CBC_SHA TLS_RSA_PSK_WITH_RC4_128_SHA TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
TLS_RSA_PSK_WITH_AES_128_CBC_SHA TLS_RSA_PSK_WITH_AES_256_CBC_SHA TLS_RSA_WITH_SEED_CBC_SHA TLS_DH_DSS_WITH_SEED_CBC_SHA TLS_DH_RSA_WITH_SEED_CBC_SHA TLS_DHE_DSS_WITH_SEED_CBC_SHA TLS_DHE_RSA_WITH_SEED_CBC_SHA TLS_DH_anon_WITH_SEED_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DH_RSA_WITH_AES_128_GCM_SHA256 TLS_DH_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_DH_DSS_WITH_AES_128_GCM_SHA256 TLS_DH_DSS_WITH_AES_256_GCM_SHA384 TLS_DH_anon_WITH_AES_128_GCM_SHA256 TLS_DH_anon_WITH_AES_256_GCM_SHA384 TLS_PSK_WITH_AES_128_GCM_SHA256 TLS_PSK_WITH_AES_256_GCM_SHA384 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 TLS_RSA_PSK_WITH_AES_128_GCM_SHA256 TLS_RSA_PSK_WITH_AES_256_GCM_SHA384 TLS_PSK_WITH_AES_128_CBC_SHA256 TLS_PSK_WITH_AES_256_CBC_SHA384 TLS_PSK_WITH_NULL_SHA256 TLS_PSK_WITH_NULL_SHA384 TLS_DHE_PSK_WITH_AES_128_CBC_SHA256 TLS_DHE_PSK_WITH_AES_256_CBC_SHA384 TLS_DHE_PSK_WITH_NULL_SHA256 TLS_DHE_PSK_WITH_NULL_SHA384 TLS_RSA_PSK_WITH_AES_128_CBC_SHA256 TLS_RSA_PSK_WITH_AES_256_CBC_SHA384 TLS_RSA_PSK_WITH_NULL_SHA256 TLS_RSA_PSK_WITH_NULL_SHA384 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 TLS_EMPTY_RENEGOTIATION_INFO_SCSV TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_NULL_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_anon_WITH_NULL_SHA TLS_ECDH_anon_WITH_RC4_128_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA
TLS_ECDH_anon_WITH_AES_256_CBC_SHA TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA TLS_SRP_SHA_WITH_AES_128_CBC_SHA TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA TLS_SRP_SHA_WITH_AES_256_CBC_SHA TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_PSK_WITH_RC4_128_SHA TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384 TLS_ECDHE_PSK_WITH_NULL_SHA TLS_ECDHE_PSK_WITH_NULL_SHA256 TLS_ECDHE_PSK_WITH_NULL_SHA384 TLS_RSA_WITH_ARIA_128_CBC_SHA256 TLS_RSA_WITH_ARIA_256_CBC_SHA384
TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256 TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384 TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256 TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384 TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256 TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384 TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256 TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384 TLS_DH_anon_WITH_ARIA_128_CBC_SHA256 TLS_DH_anon_WITH_ARIA_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384 TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256 TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384 TLS_RSA_WITH_ARIA_128_GCM_SHA256 TLS_RSA_WITH_ARIA_256_GCM_SHA384 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256 TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384 TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256 TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384 TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256 TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384 TLS_DH_anon_WITH_ARIA_128_GCM_SHA256 TLS_DH_anon_WITH_ARIA_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384 TLS_PSK_WITH_ARIA_128_CBC_SHA256 TLS_PSK_WITH_ARIA_256_CBC_SHA384 TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256 TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384 TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256 TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384 TLS_PSK_WITH_ARIA_128_GCM_SHA256 TLS_PSK_WITH_ARIA_256_GCM_SHA384 TLS_DHE_PSK_WITH_ARIA_128_GCM_SHA256
TLS_DHE_PSK_WITH_ARIA_256_GCM_SHA384 TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256 TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384 TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256 TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384 TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256 TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384 TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256 TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384 TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256 TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256 TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384 TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256 TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384 TLS_DHE_PSK_WITH_CAMELLIA_128_GCM_SHA256 TLS_DHE_PSK_WITH_CAMELLIA_256_GCM_SHA384
TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256 TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384 TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384 TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384 TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384 TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256 TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384 TLS_RSA_WITH_AES_128_CCM TLS_RSA_WITH_AES_256_CCM TLS_DHE_RSA_WITH_AES_128_CCM TLS_DHE_RSA_WITH_AES_256_CCM TLS_RSA_WITH_AES_128_CCM_8 TLS_RSA_WITH_AES_256_CCM_8 TLS_DHE_RSA_WITH_AES_128_CCM_8 TLS_DHE_RSA_WITH_AES_256_CCM_8 TLS_PSK_WITH_AES_128_CCM TLS_PSK_WITH_AES_256_CCM TLS_DHE_PSK_WITH_AES_128_CCM TLS_DHE_PSK_WITH_AES_256_CCM TLS_PSK_WITH_AES_128_CCM_8 TLS_PSK_WITH_AES_256_CCM_8 TLS_PSK_DHE_WITH_AES_128_CCM_8 TLS_PSK_DHE_WITH_AES_256_CCM_8
What should TLS do?
•
Server-‐to-‐client
authenTcaTon
•
Client-‐to-‐server
authenTcaTon (opTonal)
•
ConfidenTal communicaTon
with integrity protecTon
What doesn’t TLS do?
•
(Trusted creaTon of
cerTficates)
•
Password-‐based
authenTcaTon
•
Stop denial of service
anacks
•
Prevent web applicaTon
vulnerabiliTes
1996
SSL v3.0
standardized
2001
Something
kind of like
one
ciphersuite of
the TLS record
layer is a
secure
encrypTon
scheme
2002
Simplified
version of TLS
handshake
using RSA key
transport is a
secure
authenTcated
key exchange
protocol
2008
Simplified
version of TLS
handshake
using RSA key
transport or
signed Diffie–
Hellman is a
secure
authenTcated
key exchange
protocol
Is TLS secure?
“something kind of like”… “simplified version”…
limited ciphersuites
1996
SSL v3.0
standardized
2011
Some modes
of unaltered
TLS record
layer are
secure
authenTcated
encrypTon
schemes
2012
Unaltered full
signed Diffie–
Hellman
ciphersuite is
a secure
channel
2013
Most
unaltered full
TLS
ciphersuites
are a secure
channel
RenegoTaTon
is (in)secure
Is TLS secure?
Results on the provable security of TLS
Crypto
primiTves
•
RSA, DSA, ECDSA
•
Diffie–Hellman,
ECDH
•
HMAC
•
MD5, SHA1,
SHA-‐2
•
DES, 3DES, RC4,
AES
Ciphersuite
details
•
Data structures
•
Key derivaTon
•
EncrypTon
modes, IVs
•
Padding
Advanced
funcTonality
•
Alerts & errors
•
CerTficaTon /
revocaTon
•
NegoTaTon
•
RenegoTaTon
•
Session
resumpTon
•
Key reuse
•
Compression
Libraries
•
OpenSSL
•
GnuTLS
•
SChannel
•
Java JSSE
ApplicaTons
•
Web browsers:
Chrome, Firefox,
IE, Safari
•
Web servers:
Apache, IIS, …
•
ApplicaTon SDKs
•
CerTficates
Other recent work [BFKPS13,BFKPSZ14,…]
looks at several layers simultaneously.
"Cryptographic core"
sLHAE: TLS AES-‐GCM
Real-‐world anacks on TLS
Crypto
primiTves
•
RSA, DSA, ECDSA
•
Diffie–Hellman,
ECDH
•
HMAC
•
MD5
, SHA1,
SHA-‐2
•
DES
, 3DES,
RC4
,
AES
Ciphersuite
details
•
Data structures
•
Key derivaTon
•
EncrypTon
modes
, IVs
•
Padding
Advanced
funcTonality
•
Alerts & errors
•
CerTficaTon /
revocaTon
•
NegoTaTon
•
RenegoTaTon
•
Session
resumpTon
•
Key reuse
•
Compression
Libraries
•
OpenSSL
•
GnuTLS
•
SChannel
•
Java JSSE
ApplicaTons
•
Web browsers:
Chrome, Firefox,
IE, Safari
•
Web servers:
Apache, IIS, …
•
ApplicaTon SDKs
•
CerTficates
Heartbleed
Ray & Dispensa
renegoTaTon
anack
Debian
OpenSSL
entropy bug
Bleichenbacher
RSA PKCSv1
Lucky 13
Rizzo
& Du
ong
“BEA
ST” an
ack
Rizzo & Duong
“CRIME” anack
(Perfect) Forward secrecy
•
An adversary who later
learns the server's long-‐
term private key
shouldn't be able to
read previous
transmissions
•
RSA key transport:
no PFS
•
signed Diffie–Hellman:
•
Allows parTes to update
an exisTng TLS session to
get a new key or change
authenTcaTon
•
Anacker can inject a
packet before legiTmate
traffic
•
Nov. 2009
•
Fix: disable renegoTaTon
or upgrade
Esoteric features – renegoTaTon
•
TLS supports opTonal
compression
•
Message broken up into chunks,
each chunk compressed then
encrypted
•
Size of ciphertext
=> amount of compression
=> leaks plaintext info
•
“CRIME” anack, Sept. 2012
•
Fix: disable compression
Esoteric features – compression
•
DigiNotar in Jul. 2011
–
security breach, malicious cerTficates
for many domains issued
–
went out of business
•
TURKTRUST in Aug. 2011
–
issued intermediate CA with wildcard
signing capabiliTes
–
later used for man-‐in-‐the-‐middle proxy
filtering/scanning
–
no evidence for use in anack
–
detected only in Jan 2013
•
Digicert Malaysia in Nov. 2011
–
22 cerTficates with weak private keys or
missing revocaTon details issued
•
KPN/Getronics in Nov. 2011
–
suspended CA business aker detecTng
infecTon on its web server no evidence
of cerTficate malfeasance
•
Web browsers trust 650+
cerTficate authoriTes which
can issue cerTficates for any
domain on the Internet
•
Extended validaTon
cerTficates don’t solve the
problem
CerTficate authority breaches and
errors
•
Web service SDKs need
secure communicaTons
–
Amazon EC2 Java library
–
Amazon, PayPal
merchant SDK
•
Rely on standard crypto
libraries…
•
… but didn’t properly
use cerTficate
validaTon.
•
=> Any valid cerTficate
would be accepted as
“valid” by PayPal SDK
(any many others)
•
Most fixed
•
hnps://crypto.stanford.edu/~dabo/pubs/
abstracts/ssl-‐client-‐bugs.html
•
Many weaknesses found in record layer
symmetric encrypTon algorithms.
•
Usually require large amount of data to succeed.
•
Not urgent to fix, but cryptographic anacks only
get bener, never worse.
•
Can be confusing as knowledge evolves:
–
BEAST anack 2011 => AES-‐CBC mode insecure, use
RC4
–
Paterson et al. anack 2013 => RC4 insecure, use fixed
AES-‐CBC
TLSv1.3: The Next GeneraTon
•
Currently under development at the IETF
•
Primary goals:
–
remove ciphersuites without forward secrecy
–
remove obsolete / deprecated algorithms
–
provide low-‐latency mode with fewer round trips
–
encrypt more of the handshake to improve
OTHER PROTOCOLS
•
SSH used for secure
remote access (like
telnet, but secure)
•
Provides public key
authenTcaTon of
servers and clients and
encrypted
communicaTon
Use of SSH
•
Primarily used as an
applicaTon itself
(remote login)
•
Occasionally used as a
“poor man’s VPN”
•
ApplicaTon to handle data
•
HTTP, FTP, SSH, SMTP, SNMP, …
ApplicaTon
•
Data representaTon, encrypTon
•
TLS (Transport Layer Security) / SSL (Secure Sockets
Layer)
PresentaTon
•
Managing sessions
•
Tor??
Session
•
End-‐to-‐end connecTons, reliability, flow control
•
TCP (Transport Control Protocol), UDP (User
Datagram Protocol)
Transport
•
Logical addressing
•
IPv4, IPv6; IPsec
Network
•
Physical addressing
•
802.3 (Ethernet)
Data Link
•
Media, signal, and binary transmission
•
802.3 (Ethernet), 802.11 (Wireless)
Client authenTcaTon in SSH
•
SSH
(Secure Shell) is oken used for remote command-‐line access in
Unix and Mac OS X.
•
It supports public key authenTcaTon.
–
A security-‐conscious SSH installaTon would support
only
public key
authenTcaTon and disable password-‐based authenTcaTon.
•
Each account can have mulTple associated public keys.
–
MulTple users can login to a single account without having to be told
the password for that account. Easy to revoke one user’s access to
that account.
–
One user could have a different key from each local computer (laptop,
desktop, ...); if one of local computer is lost/compromised, easy to
revoke its access.
•
Users can associate the same key with mulTple accounts.
–
Yields a form of single sign-‐on.
IPsec (Internet Protocol Security)
•
Provides confidenTality
and authenTcaTon for
Internet communicaTons
•
Works at the IP layer of
the protocol stack
–
TLS works at higher levels,
so applicaTons have to be
designed to use TLS
–
IPsec can be used
transparently with any
applicaTon
•
Oken used for Virtual
Private Networks (VPNs)
•
ApplicaTon to handle data
•
HTTP, FTP, SSH, SMTP, SNMP, …
ApplicaTon
•
Data representaTon, encrypTon
•
TLS (Transport Layer Security) / SSL (Secure Sockets
Layer)
PresentaTon
•
Managing sessions
•
Tor??
Session
•
End-‐to-‐end connecTons, reliability, flow control
•
TCP (Transport Control Protocol), UDP (User
Datagram Protocol)
Transport
•
Logical addressing
•
IPv4, IPv6; IPsec
Network
•
Physical addressing
•
802.3 (Ethernet)
Data Link
•
Media, signal, and binary transmission
•
802.3 (Ethernet), 802.11 (Wireless)
Single sign-‐on
•
Single sign-‐on protocols
allow a user to use a
credenTal from one idenTty provider with
many relying parTes.
•
The user’s authenTcaTon to the idenTty
provider can be based on any form(s) of
authenTcaTon: password, public key,
biometric.
•
The idenTty provider gives an asserTon to the
Kerberos
•
Protocol for cryptographic
authenTcaTon of users and
services on distributed
systems
•
AuthenTcaTon based on
knowledge of shared secrets
•
Uses symmetric
authenTcaTon
•
Relies on a trusted third party
to mediate authenTcaTon
between parTes
•
Developed by MIT in the
1980s and 1990s
•
Kerberos version 5 published
in 1993
•
Kerberos used as default
authenTcaTon method in
Windows 2000 and later as
part of AcTve Directory
services
•
Most UNIX-‐based operaTng
systems (Linux, Solaris, Mac
OS X, FreeBSD) support
Kerberos autheTcaTon of
users and services
•
Kerberos also supports public
key (asymmetric)
•
Goal: provide anonymous
online communicaTon,
resistant to traffic analysis
•
Routes communicaTon
through mulTple relays
using onion rouTng
Used by 300000+ daily:
•
users in counTes with
censorship
•
human rights acTvists
•
whistleblowers
–
Edward Snowden
•
law enforcement
•
criminals
•
terrorists
•
black market
Tor
•
ApplicaTon to handle data
•
HTTP, FTP, SSH, SMTP, SNMP, …
ApplicaTon
•
Data representaTon, encrypTon
•
TLS (Transport Layer Security) / SSL (Secure Sockets
Layer)
PresentaTon
•
Managing sessions
•
Tor??
Session
•
End-‐to-‐end connecTons, reliability, flow control
•
TCP (Transport Control Protocol), UDP (User
Datagram Protocol)
Transport
•
Logical addressing
•
IPv4, IPv6; IPsec
Network
•
Physical addressing
•
802.3 (Ethernet)
Data Link
•
Media, signal, and binary transmission
•
802.3 (Ethernet), 802.11 (Wireless); WEP
No anonymity on the Internet
This came from
131.181.46.152
I saw 131.181.46.152
communicate with NYT
Tor anonymity network
A
B
C
131.181.46.152
A
B
C
I saw B=>NYT
I saw A=>B
(but can’t read the data)
= encrypted communicaTon
131.181.46.152
I saw C=>NYT
I saw 131.181.46.152=>B
(but can’t read the data)
+ can’t tell these two facts are linked
•
Each link requires establishing a secure
channel.
•
Each channel needs to be encrypted,
one-‐way authenTcated, one-‐way-‐anonymous,
and unlinkable.
•
2006–2012: Tor used an ad hoc, peculiar
cryptographic protocol with a non-‐standard
provable security analysis.
WIRED EQUIVALENT PRIVACY
(WEP)
Wired Equivalent Privacy (WEP)
•
Goal:
provide login authenTcaTon, message
authenTcaTon/integrity, and message
confidenTality for 802.11 wireless networks
–
standardized in 1999
–
uses RC4 for encrypTon
–
uses CRC-‐32 checksum for integrity
WEP
•
ApplicaTon to handle data
•
HTTP, FTP, SSH, SMTP, SNMP, …
ApplicaTon
•
Data representaTon, encrypTon
•
TLS (Transport Layer Security) / SSL (Secure Sockets
Layer)
PresentaTon
•
Managing sessions
•
Tor??
Session
•
End-‐to-‐end connecTons, reliability, flow control
•
TCP (Transport Control Protocol), UDP (User
Datagram Protocol)
Transport
•
Logical addressing
•
IPv4, IPv6; IPsec
Network
•
Physical addressing
•
802.3 (Ethernet)
Data Link
•
Media, signal, and binary transmission
•
802.3 (Ethernet), 802.11 (Wireless); WEP
WEP EncrypTon
•
64-‐bit WEP uses a 24-‐
bit IV and a 40-‐bit key
•
128-‐bit WEP uses a 24-‐
bit IV and a 104-‐bit key
•
Append CRC-‐32(m) to
message before
encrypTng
WEP Login AuthenTcaTon
To authenTcate to a 802.11
network using WEP shared key
authenTcaTon:
•
Access point sends 128-‐bit
challenge in plaintext
•
Client picks an IV, uses IV,K
to encrypt challenge (with
RC4)
•
Server decrypts challenge
and compares
Is this secure?
•
Anacker sees challenge
plaintext, ciphertext
•
Ciphertext = XOR of
keystream and
message,checksum
•
Anacker can derive
keystream from ciphertext
and plaintext challenge
•
Anacker can use keystream
to encrypt another
WEP Message AuthenTcaTon &
ConfidenTality
Message Authen6ca6on
•
WEP uses a linear checksum
funcTon for message
authenTcaTon
•
CRC(a) + CRC(b) = CRC(a+b)
•
Easy to modify ciphertexts
and compute a sTll-‐valid
checksum
Message Confiden6ality
•
WEP uses RC4
•
RC4 has a weak iniTalizaTon
procedure with known
biases
•
WEP uses small Ivs (24 bits)
•
PracTcal anacks: observing
40,000 packets allows key
recovery with probability
>50% in <3 seconds
Wireless Security
WEP
•
Login authen6ca6on
: completely
insecure; anacker can impersonate
aker seeing a single packet
•
Message authen6ca6on/integrity
:
completely insecure; anacker can
undetectably modify any packet with
100% success rate
•
Message confiden6ality:
completely
insecure; anacker can recover secret
key with high probability in just a
minute using readily available tools
•
In 2007, US retailer TJ Maxx had 45
million customer credit cards stolen
because their wireless network was
secured using WEP
•
WEP prohibited for use in credit card
processing (PCI-‐DSS) aker June 2010.
Wi-‐Fi Protected Access
•
Wi-‐Fi Protected Access
(WPA, WPA2) standardized
in 2003
•
WPA mostly sTll secure, as
long as strong passwords
are used
•
Wi-‐Fi Protected Setup 8-‐
digit PINs brute-‐forced in a
few hours
OSI network protocol stack
•
ApplicaTon to handle data
•
HTTP, FTP, SSH, SMTP, SNMP, …
ApplicaTon
•
Data representaTon, encrypTon
•
TLS (Transport Layer Security) / SSL (Secure Sockets Layer)
PresentaTon
•
Managing sessions
•
Tor??
Session
•
End-‐to-‐end connecTons, reliability, flow control
•
TCP (Transport Control Protocol), UDP (User Datagram Protocol)
Transport
•
Logical addressing
•
IPv4, IPv6; IPsec
Network
•
Physical addre
