Network Security Issues,Part 2

EE 122 - Networking

Prof. Vern PaxsonNovember 16, 2011

Game Plan

• Address any pending questions regardingMonday’s lecture on network securitythreats

• 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-endchannels– TLS/SSL ⇒ HTTPS

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 ofattacks towards an overarching goal– E.g. use eavesdropping (confidentiality) to construct a

spoofing attack (integrity) that tells a server to drop animportant connection (denial-of-service)

Building Secure End-to-End Channels

• End-to-end = communication protectionsachieved all the way from originating clientto 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)– Impersonation?

• SignaturesWhat’s missing?Availability …( )

Cryptographic Toolkit: Encryption

• Encryption: algorithms that encode information in aform undecipherable unless one possesses thecorresponding key

• Suppose Alice wants to send a message M to Bob,such that an eavesdropper, Eve, can’t read it

• Alice sends Bob a function 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 anddecrypt.– 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 messageM sent to Bob isn’t altered by a Man-in-the-Middle(MITM) along the way

• Alice computes and also sends a MessageAuthentication Code (MAC) using a separate keyshared 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 validMAC 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

• 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 messageshe 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

Signatures, con’t

• Important: note that digital signatures are bound to agiven 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 abilityto 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 give 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 Charliebelieves Alice’s key is Apub ⇒ Bob confidently obtains Apub

Building A Secure End-to-EndChannel: 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

Application

Transport

(Inter)Network

Link

Physical

743

2

1

Transport (TCP)

(Inter)Network

Link

Physical

SSL / TLS743

2

1

Application7

Building A Secure End-to-EndChannel: 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: all of these images, etc.,also fetched via https: URLs(or at least they should be!)

Doing so gives the web page fullintegrity, in keeping with end-to-end security.

Building A Secure End-to-EndChannel: 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 regularnetwork programming– Fairly easy to convert an app to be secured

HTTPS Connection (SSL / TLS)

• Browser (client) connectsvia TCP to Amazon’sHTTPS server

• Client sends over list ofcrypto protocols it supports

• Server picks protocols touse for this session

• Server sends over itscertificate with public key

• (all of this is in the clear)

• Client now validates cert

SYN

SYN ACK

ACK

Browser Amazon

Hello. I support(TLS+RSA+AES128+SHA1) or

(SSL+RSA+3DES+MD5) or …

Let’s use

TLS+RSA+AES128+SHA1

Here’s my cert / pub. key

~2-3 KB of d

ata

For MACs

HTTPS Connection (SSL / TLS), conʼt• Browser constructs a long

(2048 bits) random string R

• Browser sends R encrypted usingAmazon’s public key APub

• From R, browser & server derivepairs of symm. cipher keys (CB, CS)and MAC integrity keys (IB, IS)– One pair to use in each direction

• Browser & server exchange MACscomputed over entire dialog so far

• If good MAC, Browser displays

• All subsequent communicationencrypted w/ symmetric cipher(e.g., AES128) cipher keys, MACs– Messages also numbered to thwart

replay attacks

Browser Amazon

Here’s my cert / pub. key

~2-3 KB of d

ata

{R}APub

R

R

{M1, MAC(M1,IB)}CB

{M2, MAC(M2,IS)}CS

MAC(dialog,IS)

MAC(dialog,IB)

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 ofcert, expiration time)

• Name of certificate’s issuer (e.g., Verisign)

• Optional URL to revocation center to check forrevoked 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

• Browser accesses issuer’s public key–This is hardwired into the browser - trusted!

• Browser applies issuer’s public key to invertsignature S, makes sure it matches Amazon’s cert

• Assuming hashes match, now have highconfidence it’s indeed Amazon …– assuming signatory is trustworthy

= assuming issuer or Amazon didn’tlose private key; assuming issuer didn’tsign purported cert thoughtlessly

End-to-End ⇒ Powerful Protections

• Attacker runs a sniffer to capture our WiFisession?– Encrypted communication is unreadable

• No problem!

• DNS “cache poisoning”?– Client goes to wrong server– Client detects impersonation

• No problem!

• Attacker hijacks our connection, injects new traffic– Data receiver rejects it due to failed MAC integrity

check• No problem!

Powerful Protections, con’t

• DHCP spoofing?– Client goes to wrong server– Detects impersonation

• No problem!

• Attacker manipulates routing to run us by aneavesdropper or take us to the wrong server?– They can’t read; we detect impersonation

• No problem!

• Attacker slips in as a Man In The Middle?– 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 sitehas not been verified–Note, can still proceed, just without authentication

• Q: Which end-to-end security properties do we loseif 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 end-

to-end protections

• So why not use it for everything??

• Issues:–Cost of public-key crypto

o Can buy hardware to accelerate, but $$o Note: symmetric key crypto on modern hardware is non-issue

–Hassle of buying/maintaining certs (fairly minor)

(Circa April 2008)

SSL / TLS Limitations• Properly used, SSL / TLS provides powerful end-

to-end protections

• So why not use it for everything??

• Issues:–Cost of public-key crypto

o Can buy hardware to accelerate, but $$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 operationso 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!)

• Exploitable bugs in clients or servers

• Exploitable bugs in users–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 areunwilling to take money. That turns out to be wrong; theydon't even do that much.” - Matt Blaze, circa 2010