Network Security (Part #1)
SFL @ TU Dortmund
Network Security
Copyright By PowCoder代写 加微信 powcoder
• Cryptography forms the basis for secure communication • Cryptography guarantees integrity and confidentiality
• But cryptography on its own does not meet all security goals
• How can we…
• …reliably authenticate our communication partners? (authenticity)
• …prevent others to learn about our identity? (anonymity)
• …prevent unauthorized parties to access network services?
(network-based access control)
• …protect against attackers aiming to render services offline? (availability)
• …obtain these guarantees even in existing protocols such as HTTP and DNS?
Transport Layer Security (TLS)
HTTP/FTP/IMAP/DNS/
SMTP/FTP/TPLOS P/IMAP/…
IPv4 / IPv6
Application Layer
Transport Layer Internet Layer Link Layer
What is TLS?
• TLS: Transport Layer Security
• Former versions called Secure Sockets Layer (SSL), up to SSL 3.x
• De facto standard for secure communication
• “The primary goal of the TLS protocol is to provide privacy and data integrity
between two communicating applications”
• Deployed in
• Web browsers
• Virtual Private Networks (VPNs)
• Payment terminals
• Internet-of-Things devices (fridge, washing machine, coffee machine, …) • Distributed systems
TLS Guarantees
• End-to-end secure comm. in the presence of a network attacker
• Attacker completely owns the network: controls name resolution (DNS), all Internet communication, can listen to any packet, modify packets in transit, inject their own packets into the network, …
• Scenario: You are reading your email from an Internet café connected via a compromised WiFi access point powered by a dodgy ISP in a hostile authoritarian country.
TLS Basics
• NOTE: We discuss TLS 1.2 (the most popular version as of now)
• TLS consists of several (partially ordered) protocols; we discuss two:
• Handshake protocol
• Uses public-key cryptography to establish several shared secret keys between
the client and the server • Record protocol
• Uses the secret keys (→ handshake protocol) to protect confidentiality, integrity, and authenticity of data exchanges between client and server
TLS Record Protocol (1/2)
• TLS Record Protocol en-/decrypts and validates data integrity • Confidentiality: Symmetric encryption with private key
(derived from hashed master secret in TLS Handshake Protocol)
• Integrity: Verify data integrity via HMAC using another private key
(also derived from hashed master secret) • Other tasks
• (De)compression (optional, and usually a bad idea as it leaks info about plaintext)
• Application data (de)fragmentation
TLS Record Protocol (2/2)
• First encrypt (confidentiality) and then MAC (integrity), or vice versa?
• MAC-then-encrypt:
– Provides integrity of plaintext
– MAC is encrypted, and again, does not reveal information about plaintext
– But: We have to decrypt to check integrity
– Allowed for several attacks such as POODLE or Lucky 13
• Encrypt-then-MAC:
– Provides integrity of ciphertext (and implicitly over plaintext)
– MAC is over encrypted content and does not leak information about plaintext
– Allows to verify integrity before decryption (no timing side channels)
• Authenticated Encryption
– The way forward in TLS 1.3 (remember AES’s GCM?)
TLS Handshake Protocol
• Negotiate version of the protocol and the set of cryptographic algorithms to be used
• Interoperability between different implementations and TLS versions • Authenticate server and client (optional)
• Use digital certificates to learn each other’s public keys and to verify each other’s identity
• E.g., in HTTPS, client usually authenticates server, but not vice versa • E.g., in a VPN, mutual authentication is typically enforced
• Establish a shared secret
TLS Handshake Protocol
• Structured in 4 phases
1. Establish Security Capabilities
2. Server auth. & key exchange
3. Client auth. & key exchange
Client Hello
ServerCertificate ServerKeyExchange ClientCertificateRequest ServerHelloDone
ClientCertificate ClientKeyExchange CertificateVerify
ChangeCipherSpec Finished
ChangeCipherSpec Finished
Server Hello
TLS Handshake Protocol: Phase 1
• Phase 1: Security Capabilities • C and S generate nonces
• Agreement on TLS version
• Client Hello: C sends…
• (Highest supported) TLS version
• Client nonce
• Session ID (zero if new session)
• Server Hello: S replies with…
• Chosen TLS version
• Server nonce
• Session ID (copied from client,
or new session if client chose 0)
Client Hello
ServerCertificate ServerKeyExchange ClientCertificateRequest ServerHelloDone
ClientCertificate ClientKeyExchange CertificateVerify
ChangeCipherSpec Finished
ChangeCipherSpec Finished
Server Hello
TLS Handshake Protocol: Phase 2
• ServerCertificate:
S authenticates against C with a X509 server certificate
• ServerKeyExchange: Part 1 of key exchange
– DHKE: server parameters
– RSA: omitted
• ClientCertificateRequest:
S asks for C’s certificate
(only required for client auth.)
Client Hello
ServerCertificate ServerKeyExchange ClientCertificateRequest ServerHelloDone
ClientCertificate ClientKeyExchange CertificateVerify
ChangeCipherSpec Finished
ChangeCipherSpec Finished
Server Hello
TLS Handshake Protocol: Phase 3
• ClientCertificate:
C authenticates against S with a X509 client certificate
• ClientKeyExchange: Part 2 of key exchange
– DHKE: client parameters
– RSA: 48B pre-master secret, encrypted with pub key of S
• CertificateVerify:
C proves to S that it owns certificate by signing handshake
Client Hello
ServerCertificate ServerKeyExchange ClientCertificateRequest ServerHelloDone
ClientCertificate ClientKeyExchange CertificateVerify
ChangeCipherSpec Finished
ChangeCipherSpec Finished
Server Hello
TLS Handshake Protocol: Phase 4
• Cipher handshake finished
• Now change cipher specification • Tell partner cipher information
• Two messages (bidirectional): • ChangeCipherSpec messages
– Indicate cipher specification
• Finished is encrypted with updated cipher and verifies that key exchange and mutual authentication was successful
Client Hello
ServerCertificate ServerKeyExchange ClientCertificateRequest ServerHelloDone
ClientCertificate ClientKeyExchange CertificateVerify
ChangeCipherSpec Finished
ChangeCipherSpec Finished
Server Hello
TLS Handshake Protocol: FAQ (1/2)
• How is the master secret generated?
• Master secret is key used for confidential communication later on
• Its generation depends on the underlying key exchange mechanism
• RSA: permutation of client-chosen pre-master secret becomes master secret
(i.e., master secret = F(pre-master secret, NS, NC); to compute this, S can decrypt pre-master secret encrypted with S’s public key)
• DHKE: both C and S generate master secret from exchanged DH parameters
• Why use DHKE if we can use RSA?
• If private RSA key leaks, the entire communication can be decrypted • Instead, DHKE provides forward secrecy
• Why do we need session IDs?
• Multiple TLS connections can share a session (and its cipher) • Less effort to resume a session or add another connection
TLS Handshake Protocol: FAQ (2/2)
• How can we use TLS to realize HTTPS? Client Web
• Core TLS Handshake (e.g., using RSA) • Client validates server certificate
• Client determines and sends key • (Usually) No client cert exchange
• Session resumption
• HTTPS usually requires many
TCP connections to same server
• TLS session spans several TCP
connections (cf. SessID)
• Reuse master secret of session
to avoid expensive public-key
crypto to derive master secret
Client Hello
(NC, SuitesC, VersionC, SessID)
Server Hello (NS, VersionS, SuiteS, certS)
ClientKeyExchange
( {k = PreMasterSecret}KS )
ChangeCipherSpec + Finished
SSL 2.0 Weaknesses (1/2)
• SSL 2.0 uses padding when computing MAC in block cipher modes, but padding length field is not authenticated
• Attacker can delete bytes from the end of messages
• No support for certificate chains or non-RSA algorithms
SSL 2.0 Weaknesses (2/2): Downgrade Attack
• MITM may downgrade ciphersuites or version to provoke weak crypto • Server has no choice than choosing strongest suite / newest version among
the deliverable weak suites and vulnerable versions (interoperability!) • Finished messages (handshake integrity) not present in SSL 2.0 yet
Client Hello
(NC, SuitesC, VersionC, SessID)
Server Hello (NS, VersionS, SuiteS, certS)
ClientKeyExchange
( {k = PreMasterSecret}KS )
ChangeCipherSpec + Finished
• Countermeasures
• Client can include its version and suite in encrypted data sent in ClientKeyExchange
• Enforce Finished message that MACs entire handshake (as in SSL 3.0 and later)
Further SSL/TLS Vulnerabilities
• POODLE (2014)
• Padding in SSL 3.0 could have arbitrary content
• Attack against CBC if last padding byte is identical to second-to-last byte
• Better: require certain padding payload and validate it (TLS 1.0+)
• https://www.openssl.org/~bodo/ssl-poodle.pdf
• https://www.iacr.org/cryptodb/archive/2002/EUROCRYPT/2850/2850.pdf
• CRIME (2012)
• Assumption: content compressed prior to encryption; attacker can send
many crafted requests towards attack target and observes their ciphertexts
• Idea: Infer plaintext information from size of ciphertext after compression
• Goal was to leak a secret cookie
• https://nvd.nist.gov/vuln/detail/CVE-2012-4929
• Similar attacks may work even if TLS compression is disabled (→ BREACH)
TLS Traffic Analysis
• Traffic analysis as an attack against encrypted communication • We assumed that ciphertexts do not reveal anything about plaintexts • This is not entirely true: ciphertext length hints at plaintext length
• Example: Assume you know the library of a movie streaming server • You are interested in finding out which movie(s) a user watched
Client Server
Cats and dogs.avi (42 MB)
Tune your car.mpeg (83 MB)
History of BVB09.avi (1909 MB)
(400 bytes)
(87,825,215 bytes)
• Countermeasure: Padding
• Perfect solution requires all plaintexts be padded to equivalent lengths
– In our example: All movies would have been to be padded to 1909 MB → overhead! • Non-perfect solution pads only individual records (in TLS: 16 KiB records)
Certificates & PKI
Certificates – Introductory Motivation
• Server (and optionally client) authenticity can be verified using a certificate
• Inherently important scheme for TLS
• But what exactly is such a certificate, who issues it, and what guarantees does it give?
Client Hello
(NC, SuitesC, VersionC, SessID)
Server Hello (NS, VersionS, SuiteS, certS)
ClientKeyExchange (k = PreMasterSecret)
ChangeCipherSpec + Finished
Certificates: Why?
• We wish two important features from a certificate
• Provide a way to authenticate our communication partner
• Obtain our partner’s public key s.t. we can privately/securely negotiate a key
• In HTTPS (HTTP over TLS), this means
• Nobody can fake the Web server identity
• We know the server’s public key such that we can securely send our pre-master secret
• Common Name (CN) determines domain validity for a certificate
• Explicit name: www.foo.com
• Wildcard: *.foo.com or www*.foo.com
PKI / Certificate Hierarchy (1/2)
• Public Key Infrastructure (PKI) allows for transitive trust
• Key concept: Certificate authorities (CAs) sign certificates
• Root CAs: Fully trusted by everyone and known by systems – About 100-200 root CAs in common OSes or browsers
• Intermediary CAs: Trusted by transition; their certs are signed by root CAs – Authorities trusted by the root CAs that can also issue certificates
• End entities: Trusted by transition; their certs are signed by intermediary CAs – Billions of users / devices / systems to which certificates are issued
DFN CA Telesec ServerPass CA
DFN Issuing CA
Intermediary CAs
… tu-dortmund.de telekom.de … End entities
PKI / Certificate Hierarchy (2/2)
• A Root CA signs certificates for intermediate CAs, they sign certificates for lower-level CAs, etc.
• Certificate “chain of trust”
• CA has to verify the identities of certificate requestors and domain ownership
End-entity certificate
Intermediary CA cert.
Root CA certificate
Issuer’s name
Issuer’s signature
pubkeyinterm
Issuer’s name
Issuer’s signature
pubkeyrootCA
root CA signature
TLS Man-in-the-Middle Attacks
• With proper certificates (validation), TLS is not prone to MITM attacks • But self-signed (or maliciously signed) certs impose a security risk
Client MITM
• MITM attack possible if self-signed certs are accepted by client, but can be observed by client
• Also possible for anonymous key exchange (e.g., ADH)
→ clients should disable them
(NC, SuitesC, VersionC, SessID)
(NM[, VersionM‘, SuiteM‘, certs(self))
(NM, SuitesM, VersionM, SessIDM) (NS, VersionS, SuiteS, certS)
• Certification authorities issue new certificates upon request • Validation prior issuance differs
• Domain validation
• Requester has to prove that they control a domain
• Extreme example: Let’s Encrypt issues certificate completely automated after Web-based or DNS-based validation
• Extended validation (EV)
• Stricter issuance and verification policies
• Protects users against valid certificates of similar-looking phishing domains that did not pass EV
Certificate Revocation Mechanisms
• Online revocation service
• When a certificate is presented, recipient goes to a special online service to
verify whether it is still valid
• Certificate revocation list (CRL) • CA periodically issues a signed
list of revoked certificates
• Can issue a “delta CRL” containing only updates
Anonymous Communication
Anonymous Communication
• “Anonymity is the state of being not identifiable within a set of subjects (the anonymity set). The anonymity set is the set of all possible subjects.” [Pfitzmann/Hansen-2005]
• Anonymity goals
• Sender anonymity: Sender is non-identifiable in sender anonymity set
• Recipient anonymity: Recipient is non-identifiable in recipient anonymity set
• Unlinkability: Attacker cannot distinguish whether two messages or subjects are related or not.
• Non-goal: hide the fact that communication happens
Virtual Private Networks for Anonymity
• Anonymous communication
• Hide identities of communication partners • Client and/or server anonymity
• Virtual Private Networks offer weak anonymity
• Idea: proxy all traffic via single intermediary (client anonymity) • Anonymity is compromised if single proxy is compromised
• VPN provider can observe communication
VPN Proxies
Introduction to Onion Routing
• Onion routing
• Client establishes a circuit that spans N (typically N=3) onion routers
• Multilayer TLS encryption of messages along this circuit • Routers “peel” one layer of encryption (onion principle)
Onion Routers
middle node
entry node
Onion Routing Security Guarantees (1/2)
• Risk analysis of compromises
• Middle node: sees neither client nor server (sender and recipient anonymity)
• Entry node: sees client, but neither data nor server (recipient anonymity) • Exit node: sees data and server, but not the client (sender anonymity)
• Critical combination: Entry and Exit node controlled by adversary • In combination, they see both data and client
• Traffic correlation attacks are possible (see next slide)
Onion Routing Security Guarantees (2/2)
• Traffic correlation attacks against onion routing
• Entry node and exit node (or server) collude
• Similar traffic patterns likely belong to same client
• Traffic analysis: timing analysis, number of packets, etc.
Onion Routers
S. Murdoch and G. Danezis: “Low-Cost Traffic Analysis of Tor”, IEEE S&P 2005.
Tor Hidden Services (1/2)
• Hidden services (HS) realize server anonymity in Tor
• Property: Operate a service without anyone knowing where and who you are
• Hidden service registration and advertisement:
1. Choose and establish circuits to introduction points (here: InP1 / InP2)
2. Advertise HS descriptor (public key, list of InPs) in HS directory (HSDir)
3. Client downloads descriptor from HSDir by 16-char .onion address identifier
Onion Routers
(abc.onion)
abc.onion:
K+ = 9gz…
Tor Hidden Services (2/2)
• Establishing a circuit to hidden service
1. Client picks random nodes as rendezvous point (RP) and establishes circuit
2. Client establishes circuit to a randomly-picked InP
3. Client asks InP to forward a request to HS to establish a circuit to RP
4. HS establishes a circuit to RP; then, RP connects the two circuits C↔ORC1 ↔ORC2 ↔RP↔ORHS3 ↔ORHS2 ↔ORHS1 ↔HS
5. Client and HS communicate over this 6-hop circuit
Onion Routers
(abc.onion)
abc.onion:
K+ = 9gz…
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com