Network Security Issues, Part 2 EE 122 - Networking Prof. Vern Paxson November 25, 2013
Game Plan • Address any pending questions regarding last Monday's lecture on network security threats • Introduce basic tools of cryptography – A lot of abstraction! • Will go light on a few details
– Ask questions if properties not clear
• Discuss building secure end-to-end channels – TLS/SSL ⇒ HTTPS – Reduces most threats discussed last week to DoS
Revisiting Types of Security Goals • Attacks can subvert each type of goal – Confidentiality: eavesdropping / theft of information – Integrity: altering data, manipulating execution (e.g., code injection) – Availability: denial-of-service
• Attackers can also combine different types of attacks towards an overarching goal – E.g. use eavesdropping (confidentiality) to construct a spoofing attack (integrity) that tells a server to drop an important connection (availability)
Building Secure End-to-End Channels • End-to-end = communication protections achieved all the way from originating client to intended server – With no need to trust network intermediaries
• Dealing with threats: – Eavesdropping? • Encryption (symmetric key; public key)
– Manipulation (injection, MITM)? • Integrity (use of a MAC = Message Authentication Code)
– Impersonation? • Signatures
(
What's missing? Availability …
)
Cryptographic Toolkit: Encryption • Encryption: algorithms that encode information in a form undecipherable unless one possesses the corresponding key • Suppose Alice wants to send a message M to Bob, such that an eavesdropper, Eve, can't read it • Alice sends Bob a value E(M) computed from M • Bob then applies an inverse function D(E(M)) = M – Eve knows D, E but not key ⇒ can't recover M from E(M)
• Two basic types of such functions: – Symmetric key: same key K used to encrypt & decrypt. – Asymmetric or public-key: one key, KE, used to encrypt. A different (but related) key, KD, used to decrypt.
Symmetric-Key Encryption • Symmetric key: the same key K used to encrypt and decrypt. – Alice sends E(M, K) to Bob. – Bob applies D(E(M, K), K) = M. – Eavesdropper Eve observes E(M, K), knows E & D, but can't figure out how to get M from it unless she knows K
• Requirements: – Alice and Bob have to agree on K in advance – K must be kept secret
• Example algorithms: AES, DES, 3DES – Typical key lengths today: 128 or 256 bits – Encryption & decryption can be computed very efficiently
Cryptographic Toolkit: Integrity • Suppose Alice wants to make sure her message M sent to Bob isn't altered by a Man-in-the-Middle (MITM) along the way • Alice computes and also sends a Message Authentication Code (MAC) using a separate key shared between Alice & Bob – I.e., Alice sends both E(M, K1) and MAC(M, K2)
• Upon receipt, Bob verifies that MAC(D(E(M, K1), K1), K2) = MAC(M, K2) • MITM doesn't know K2, so can't construct valid MAC to match their altered message – If MITM alters message, Bob detects this & discards
Asymmetric / Public-Key Encryption • Asymmetric: one key KE used to encrypt; different, related key KD used to decrypt. – Alice sends E(M, KE) to Bob. – Bob applies D(E(M, KE), KD) = M. – Eavesdropper Eve can't recover M unless knows KD.
• Knowing KE doesn't help! Infeasible to figure out KD from KE.
• Requirements: – Alice needs KE, but it doesn't have to be secret Bob can tweet it or stick it on Bob's web page! – KD must be kept secret; only Bob knows it. (Alice doesn’t!)
• Example algorithms: RSA, El Gamal – Typical key lengths today: 1024 or 2048 bits – Computations not nearly as efficient as for symmetric-key
Cryptographic Toolkit: Signatures • Suppose Alice wants people to trust that some message she wrote, M, was indeed generated by her – In the physical world, she would add her signature to a paper document with the statement
• Suppose Alice uses public-key cryptography and has a public/private key pair, APub and APrivate – APub is well known as being Alice's – Alice keeps APrivate secret
• Recall that E(•, APub) and D(•, APrivate) are inverses • Alice now includes* with M the value S = D(M, APrivate) • Anyone who wants to verify the signature for M computes E(S, APub) = E(D(M, APrivate), APub) = M – If result of computation indeed yields M, whomever constructed S must know APrivate, so presumably it must have been Alice
Cryptographic Toolkit: Signatures • Suppose Alice wants people to trust that some message she wrote, M, was indeed generated by her – In the physical world, she would add her signature to a paper document with the statement
• Suppose Alice uses public-key cryptography and has a public/private key pair, APub and APrivate – APub is well known as being Alice's – Alice keeps APrivate secret
• Recall that E(•, APub) and D(•, APrivate) are inverses • Alice actually includes with M the value S = D(H(M), APrivate) – H is a cryptographically strong (non-invertible) hash function • Well-known, no key
– Thus, verifying E(S, APub) = E(D(H(M), APrivate), APub) = H(M) doesn’t leak information about M – (we’ll now leave this out for simplicity)
Signatures, con't • Important: note that digital signatures are bound to a given document – Unlike physical signatures, which might be “lifted” and applied elsewhere
• If Eve possesses a particular digital signature generated by Alice for message M, that doesn't give Eve any ability to forge other messages seemingly from Alice – And in general, possession of APub doesn't let one do anything other than:
• Verify signatures purportedly generated by Alice • Encrypt messages that only Alice can read
• However: if Eve gets copy of APrivate,then all bets are off – Eve can forge Alice's signature for any document Eve wishes – Eve can read any messages meant to be just for Alice
(Digital) Certificates • One prominent use of digital signatures: attesting to someone else's public key • Suppose Bob wants to communicate securely w/ Alice, but doesn't have Alice's public key APub – Alice can't just transmit APub to Bob (why not?)
• Suppose Bob knows & trusts Charlie, and has CPub • Previously, Alice got Charlie to sign a message: “Alice's public key is APub” (a “certificate”)
• Alice can now send Bob her public key APub along w/ M = “Alice's public key is APub”, S = D(M, CPrivate)
• If Bob trusts Charlie, he can verify that Charlie believes Alice's key is Apub ⇒ Bob confidently obtains Apub
(Digital) Certificates • Suppose Bob knows & trusts Charlie, and has CPub • Previously, Alice got Charlie to sign a message: “Alice's public key is APub” (a “certificate”)
• Suppose instead Alice got Daphne to sign the “cert” – Using Daphne’s public/private key pair DPrivate / DPub – But: Bob doesn’t know Daphne. What to do?
• If Charlie knows Daphne, then Alice could give Bob M1 = “Daphne’s public key is DPub” M2 = “Alice’s public key is APub” S1 = D(M1, CPrivate), S2 = D(M2, DPrivate)
• Bob first verifies S1 (since knows CPub and trusts Charlie) … then S2 (since now has/trusts DPub) ⇒ Bob confidently obtains Apub
Building A Secure End-to-End Channel: SSL/TLS • SSL = Secure Sockets Layer (predecessor) • TLS = Transport Layer Security (standard) – Both terms used interchangeably
• Notion: provide means to secure any application that uses TCP
SSL/TLS In Network Layering 7
Application
7
Application
7
SSL / TLS
4
Transport
4
Transport (TCP)
3
(Inter)Network
3
(Inter)Network
2
Link
2
Link
1
Physical
1
Physical
Building A Secure End-to-End Channel: SSL/TLS • SSL = Secure Sockets Layer (predecessor) • TLS = Transport Layer Security (standard) – Both terms used interchangeably
• Notion: provide means to secure any application that uses TCP – Secure = encryption/confidentiality + integrity + authentication (of server, but not of client) – E.g., puts the 's' in “https”
Regular web surfing - http: URL
But if we click here …
Web surfing with TLS/SSL - https: URL
Note: Amazon makes sure that all of these images, etc., are now also fetched via https: URLs. Doing so gives the web page full integrity, in keeping with end-to-end security. (Browsers do not provide this “promotion” automatically.)
Building A Secure End-to-End Channel: SSL / TLS • SSL = Secure Sockets Layer (predecessor) • TLS = Transport Layer Security (standard) – Both terms used interchangeably
• Notion: provide means to secure any application that uses TCP – Secure = encryption/confidentiality + integrity + authentication (of server, but not of client) – E.g., puts the 's' in “https”
• API similar to socket interface used for regular network programming – Fairly easy to convert an app to be secured
HTTPS Connection (SSL / TLS)! • Browser (client) connects via Browser TCP to Amazon's HTTPS server • Client picks 256-bit random number RB, sends over list of crypto protocols it supports • Server picks 256-bit random number RS, selects protocols to use for this session • Server sends over its certificate • (all of this is in the clear) • Client now validates cert
SYN C SYN A
Amazon Server
K
A CK Hell o (TLS . My rn d (SSL +RSA+A # = R . For MACs B I +RS E A+3 S128+S suppor DES t +MD HA1) or 5) or … t's use e L . d # = R S S128+SHA1 n r y M A+AE S R + S TL y cert m s ' e r He
data f o KB 3 2 ~
HTTPS Connection (SSL / TLS), con't! • For RSA, browser constructs long (368 bits) “Premaster Secret” PS
Browser
• Browser sends PS encrypted using Amazon's public RSA key KAmazon PS • Using PS, RB, and RS, browser & server derive symm. cipher keys (CB, CS) & MAC integrity keys (IB, IS) – One pair to use in each direction
cert y m s ' e Her
Amazon Server
ta a d f B o K 3 ~2 {PS} KAma zon
PS
HTTPS Connection (SSL / TLS), con't! • For RSA, browser constructs long (368 bits) “Premaster Secret” PS
Browser
• Browser sends PS encrypted using Amazon's public RSA key KAmazon PS • Using PS, RB, and RS, browser & server derive symm. cipher keys (CB, CS) & MAC integrity keys (IB, IS)
cert y m s ' e Her
Amazon Server
ta a d f B o K 3 ~2 {PS} KAma
– One pair to use in each direction
These seed a cryptographically strong pseudo-random number generator (PRNG). Then browser & server produce CB, CS, etc., by making repeated calls to the PRNG.
zon
PS
HTTPS Connection (SSL / TLS), con't! • For RSA, browser constructs long (368 bits) “Premaster Secret” PS
Browser
• Browser sends PS encrypted using Amazon's public RSA key KAmazon PS • Using PS, RB, and RS, browser & server derive symm. cipher keys (CB, CS) & MAC integrity keys (IB, IS) – One pair to use in each direction
• Browser & server exchange MACs computed over entire dialog so far • If good MAC, Browser displays • All subsequent communication encrypted w/ symmetric cipher (e.g., AES128) cipher keys, MACs – Messages also numbered to thwart replay attacks
cert y m s ' e Her
Amazon Server
ta a d f B o K 3 ~2 {PS} KAma zon
MAC( dialog ,IB )
PS
,I S) g o l a i MAC(d
{M , M 1 AC(M 1 ,IB )} C
B
,I S)} C S M ( 2 C , MA
{M 2
HTTPS Connection (SSL / TLS)! • Browser (client) connects via Browser TCP to Amazon's HTTPS server • Client picks 256-bit random number RB, sends over list of crypto protocols it supports • Server picks 256-bit random number RS, selects protocols to use for this session • Server sends over its certificate • (all of this is in the clear) • Client now validates cert
SYN C SYN A
Amazon Server
K
A CK Hell o (TLS . My rn d (SSL +RSA+A # = R . B I +RS E A+3 S128+S suppor DES t +MD HA1) or 5) or … t's use e L . d # = R S S128+SHA1 n r y M A+AE S R + S TL y cert m s ' e r He
data f o KB 3 2 ~
Certificates • Cert = signed statement about someone's public key – Note that a cert does not say anything about the identity of who gives you the cert – It simply states a given public key KAlice belongs to Alice…
• … and backs up this statement with a digital signature made using a different public/private key pair, say from Alice
• Alice then can prove her identity to you by you sending her something encrypted with KAlice … – … which she then demonstrates she can read
• … or by signing something she demonstrably uses • Works provided you trust that you have a valid copy of cert signer Charlie’s (or Daphne’s) public key … – … and you trust Charlie to use prudence when he signs other people's keys, such as Alice’s
Inside the Server's Certificate! • Domain name associated w/ cert – e.g., amazon.com
• Amazon's public key (e.g., 2048 bits for RSA) • A bunch of auxiliary info (physical address, type of cert, expiration time) • Name of certificate's issuer (e.g., Verisign) • Optional URL to revocation center to check for revoked certificates • A public-key signature of all of this – Constructed using the issuer's private RSA key – Call this signature S
Validating Amazon's Identity! • Browser compares domain name in cert w/ URL – Note: this provides an end-to-end property (as opposed to say a cert associated with an IP address)
• Browser accesses separate cert belonging to issuer – These are hardwired into the browser - trusted! – There could be a chain of these …
• Browser applies issuer's public key to verify signature S indeed valid for Amazon’s cert • Assuming a match, now have high confidence it's indeed Amazon … – assuming signatory is trustworthy
= assuming private key not stolen; assuming didn't sign thoughtlessly
End-to-End ⇒ Powerful Protections • Attacker runs a sniffer to capture our WiFi session? – (maybe by breaking crummy WEP security) – But: encrypted communication is still unreadable • No problem!
• DNS “cache poisoning”? – Client goes to wrong server – But: detects impersonation • No problem!
• Attacker hijacks our connection, injects new traffic – But: data receiver rejects it due to failed integrity check • No problem!
Powerful Protections, con't • DHCP spoofing? – Client goes to wrong server – But: detects impersonation • No problem!
• Attacker manipulates routing to run us by an eavesdropper or take us to the wrong server? – But: they can't read; we detect impersonation • No problem!
• Attacker slips in as a Man In The Middle? – But: they can't read, they can't inject – They can't even replay previous encrypted traffic – No problem!
Validating Amazon's Identity, con't! • Browser retrieves cert belonging to the issuer – These are hardwired into the browser - trusted!
• What if browser can't find a cert for the issuer?
Validating Amazon's Identity, con't! • Browser retrieves cert belonging to the issuer – These are hardwired into the browser - trusted!
• What if browser can't find a cert for the issuer? • If it can't find the cert, then warns the user that site has not been verified – Note, can still proceed, just without authentication
• Q: Which end-to-end security properties do we lose if we incorrectly trust that the site is whom we think?
• A: All of them! – Goodbye confidentiality, integrity, authentication – Attacker can read everything, modify, impersonate
SSL / TLS Limitations! • Properly used, SSL / TLS provides powerful endto-end protections • So why not use it for everything?? • Issues: – Cost of public-key crypto o Takes non-trivial CPU processing (but today a minor issue) o Note: symmetric key crypto on modern hardware is non-issue
– Hassle of buying/maintaining certs (fairly minor)
SSL / TLS Limitations! • Properly used, SSL / TLS provides powerful endto-end protections • So why not use it for everything?? • Issues: – Cost of public-key crypto o Takes non-trivial CPU processing (but today a minor issue) o Note: symmetric key crypto on modern hardware is non-issue
– Hassle of buying/maintaining certs (fairly minor) – Denial-of-service vulnerability o Client can force server to undertake public key operations o But: requires established TCP connection, and given that, there are other juicy targets like back-end databases
– Integrating with other sites that don't use HTTPS – Latency: extra round trips ⇒ pages take longer to load
SSL / TLS Limitations, con't! • Problems that SSL / TLS does not take care of ? • TCP-level denial of service – SYN flooding – RST injection o (but does protect against data injection!)
• SQL injection / XSS / server-side coding/logic flaws • Vulnerabilities introduced by server inconsistencies
Regular web surfing - http: URL So no integrity - a MITM attacker can alter pages returned by server …
And when we click here … … attacker has changed the corresponding link so that it's ordinary http rather than https! We never get a chance to use TLS's protections! :-(
“sslstrip” attack
SSL / TLS Limitations, con't! • Problems that SSL / TLS does not take care of ? • TCP-level denial of service – SYN flooding – RST injection o (but does protect against data injection!)
• SQL injection / XSS / server-side coding/logic flaws • Vulnerabilities introduced by server inconsistencies
• Browser coding/logic flaws • User flaws – Weak passwords – Phishing
• Issues of trust …
TLS/SSL Trust Issues, con't • “Commercial certificate authorities protect you from anyone from whom they are unwilling to take money” – Matt Blaze, circa 2001
• So how many CAs do we have to worry about, anyway?
TLS/SSL Trust Issues • “Commercial certificate authorities protect you from anyone from whom they are unwilling to take money” – Matt Blaze, circa 2001
• So how many CAs do we have to worry about, anyway? • Of course, it's not just their greed that matters …
TLS/SSL Trust Issues • “Commercial certificate authorities protect you from anyone from whom they are unwilling to take money” – Matt Blaze, circa 2001
• So how many CAs do we have to worry about, anyway? • Of course, it's not just their greed that matters … • … and it's not just their diligence & security that matters … – “A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much.” - Matt Blaze, circa 2010
Note: the cert is “forged” in the sense that it doesn't really belong to Gmail, PayPal, or whomever. But it does not appear forged because it includes a legitimate signature from a trusted CA.
TLS/SSL Trust Issues • “Commercial certificate authorities protect you from anyone from whom they are unwilling to take money” – Matt Blaze, circa 2001
• So how many CAs do we have to worry about, anyway? • Of course, it's not just their greed that matters … • … and it's not just their diligence & security that matters … – “A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much.” Matt Blaze, circa 2010
• You also have to trust the developers of libraries … – Both for clients when validating certs …
TLS/SSL Trust Issues • “Commercial certificate authorities protect you from anyone from whom they are unwilling to take money” – Matt Blaze, circa 2001
• So how many CAs do we have to worry about, anyway? • Of course, it's not just their greed that matters … • … and it's not just their diligence & security that matters … – “A decade ago, I observed that commercial certificate authorities protect you from anyone from whom they are unwilling to take money. That turns out to be wrong; they don't even do that much.” - Matt Blaze, circa 2010
• You also have to trust the developers of libraries … – Both for clients when validating certs … – and servers when generating certs
Survey found bug affected ~1.5% of HTTPS web server certs
