DOC PREVIEW
Berkeley COMPSCI 161 - Securing Internet Communication

This preview shows page 1-2-19-20 out of 20 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 20 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Securing InternetCommunicationCS 161 - Computer SecurityProfs. Vern Paxson & David WagnerTAs: John Bethencourt, Erika Chin, MatthewFinifter, Cynthia Sturton, Joel Weinbergerhttp://inst.eecs.berkeley.edu/~cs161/March 15, 2010Today’s Lecture• Applying crypto technology in practice• Goal #1: overview of the most prominentInternet security protocols– SSL/TLS: transport-level (process-to-process)ala’ TCP– DNSSEC: securing domain name lookups– (Others: SSH, and to a lesser extent, IPSEC)– Issues that arising in securing these• Goal #2: cement understanding of cryptobuilding blocks & how they’re used togetherBuilding Secure End-to-End Channels• End-to-end = communication protectionsachieved all the way from originating clientto intended server– With no need to trust intermediaries• Dealing with threats:– Eavesdropping?• Encryption (including session keys)– Manipulation (injection, MITM)?• Integrity (use of a MAC); replay protection– Impersonation?• SignaturesEnd-to-End ⇒ Powerful Protections• Attacker runs a sniffer to capture our WiFisession?– (maybe by breaking crummy WEP security)– Encrypted communication is unreadable• No problem!• DNS cache poisoning?– Client goes to wrong server– Detects impersonation• No problem!• Attacker hijacks our connection, injects new traffic– Data receiver rejects it due to failed 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!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 applicationthat uses TCPSSL/TLS In Network LayeringApplicationTransport(Inter)NetworkLinkPhysical74321Transport (TCP)(Inter)NetworkLinkPhysicalSSL / TLS74321Application7Building 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 applicationthat uses TCP– Secure = encryption/confidentiality + integrity + authentication (of server, but not of client)– E.g., puts the ‘s’ in “https”Regular web surfing - http: URLBut if we click here …Web surfing with TLS/SSL - https: URLNote: all of these images, etc., arenow also fetched via https: URLs.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 applicationthat 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 securedHTTPS 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• (all of this is in the clear)• Client now validates certSYNSYN ACKACKBrowser AmazonHello. I support(TLS+RSA+AES128+SHA1) or(SSL+RSA+3DES+MD5) or …Let’s useTLS+RSA+AES128+SHA1Here’s my cert~2-3 KB of dataHTTPS Connection (SSL / TLS), conʼt• Browser constructs a long(2048 bits) random string R• Browser sends R encrypted usingAmazon’s public key KA• 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• Browser displays• All subsequent communicationencrypted w/ symmetric cipher(e.g., AES128) cipher keys, MACs– Messages also numbered to thwartreplay attacksBrowser AmazonHere’s my cert~2-3 KB of data{R}KARR{M1, MAC(M1,IB)}CB{M2, MAC(M2,IS)}CSMAC(dialog,IS)MAC(dialog,IB)Inside the Serverʼs Certificate• Name associated with cert (e.g., www.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 certs• A public-key signature of a hash (SHA-1) of all this– Constructed using the issuer’s private RSA key– Call this signature SValidating Amazonʼs Identity• Browser compares name in cert with that in 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 theissuer– These are hardwired into the browser - trusted!• Browser applies issuer’s public key to invertsignature S, obtaining hash of what issuer signed– Compares with its own SHA-1 hash of Amazon’s cert• Assuming hashes match, now have highconfidence it’s indeed Amazon …– assuming signatory is trustworthy= assuming didn’t loseprivate key; assumingdidn’t sign thoughtlesslyValidating 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, impersonateSSL / TLS Limitations• Properly used, SSL / TLS provides powerful end-to-end protections• So why not use it for everything??• Issues:– Cost of public-key cryptoo Can buy hardware to accelerate, but $$o Note: symmetric key crypto


View Full Document

Berkeley COMPSCI 161 - Securing Internet Communication

Documents in this Course
Rootkits

Rootkits

11 pages

Load more
Download Securing Internet Communication
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Securing Internet Communication and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Securing Internet Communication 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?