1. Web Security and Secure Socket Layer (SSL)

2. Web Security Issues r The Web has become the visible interface of the Internet m Many corporations now use the Web for advertising, marketing and sales r Web servers might be easy to use but… m Complicated to configure correctly and difficult to build without security flaws m They can serve as a security hole by which an adversary might be able to access other data and computer systems ThreatsConsequencesCountermeasures IntegrityModification of Data Trojan horses Loss of Information Compromise of Machine MACs and Hashes ConfidentialityEavesdropping Theft of Information Loss of Information Privacy Breach Encryption DoSStopping Filling up Disks and Resources Stopped Transactions AuthenticationImpersonation Data Forgery Misrepresentation of User Accept false Data Signatures, MACs

3. So Where to Secure the Web? r There are many strategies to securing the web 1. We may attempt to secure the IP Layer of the TCP/IP Stack: This may be accomplished using IPSec, for example. 2. We may leave IP alone and secure on top of TCP: This may be accomplished using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) 3. We may seek to secure specific applications by using application-specific security solutions: For example, we may use Secure Electronic Transaction (SET) r The first two provide generic solutions, while the third provides for more specialized services r We will focus on SSL

4. A Quick Look at Securing the TCP/IP Stack TCP IP/IPSEC HTTPFTPSMTP TCP IP HTTPFTPSMTP SSL/TLS TCP IP S/MIMEPGP UDP KerberosSMTP SET HTTP At the Network Level At the Transport Level At the Application Level

5. Overview of SSL r The Secure Sockets Layer was originally developed (1994) by Netscape in order to secure http communications r Version 3 of SSL was released in 1995 m It is what we think of when we say SSL m Slight variation became Transport Layer Security (TLS) and was accepted by the IETF in 1999 m TLS is backward compatible with SSLv3 r TCP provides a reliable end-to-end service r SSL consists of two sublayers: m SSL Record Protocol (where all the action takes place) m SSL Management: (Handshake/Cipher Change/ Alert Protocols)

6. SSL Preliminaries r An SSL Session is an association between a client and a server (created by the Handshake Protocol). There are a set of security parameters associated with each session r An SSL Connection is a peer-to-peer relationship, and is transient. There may be many connections associated with one session. The same security parameters may apply to many connections. r Session Security Parameters: m Session Identifier m Peer Certificate: X.509v3 certificate of the peer m Compression: Optional algorithm used to compress data m Cipher Specs: Encryption Algorithm (3DES, AES, etc.) and hash algorithm (MD5, SHA-1) m Master Secret: 48-byte secret shared between client and server

7. Protocol Structure

8. SSL Record Protocol r The SSL Record Protocol uses the keys derived from the Handshake Protocol to securely deliver data r Two functions: m Confidentiality and Message Integrity Data Shrunk Compression Shrunk MAC Encrypted Encrypt Encrypted Prepend Header Chunk Fragmentation

9. SSL Record Protocol r SSL Record protocol allows protocols above SSL to be secured m Example: HTTP delivers packets that are fragmented and securely delivered m SSL does not handle retransmissions… it does not have to! TCP provides that functionality m This is quite the opposite of IPSec, which only secures IP! r Messages are broken into blocks of at most 16384 bytes r The compression is optional and, due to message size/type, it might not even be desirable to use! r Encryption may be stream or block mode. This is negotiated through the Handshake protocol m If block encryption, padding is necessary in order to fill out a block length Padding is a sequence of padding bytes (random junk will do) followed by 1 byte that describes length of the pad (up to 255).

10. SSL Handshake Protocol r This is the beast… Its where all the action really takes place! r Basically, the Handshake protocol is used before any application data is transmitted. m It is used to allow the server and client to authenticate each other m To negotiate on an encryption and MAC algorithm m Establish keys to be used r The Handshake Protocol consists of messages consisting of three fields: m Type (1 byte): Indicates type of the message. There are 10 types. m Length (3 bytes) m Content: The payload exchanged in each message

11. Other SSL Management Functions r There are two other Management Functions provided by SSL: m Change Cipher Spec: A single byte is sent after new cipher parameters have been agreed upon (aka. Handshake). “Pending” parameters become activated. m SSL Alert Protocol: Signals that unusual conditions have been encountered. Each message consists of two bytes. First byte is a (1) if a warning or a (2) if a fatal error. If error is fatal, the connection is terminated (other connections may continue…). Second byte says the type of error. Unexpected_Message: Fatal Bad_Record_MAC: Fatal Decompression_Failure: Fatal Handshake_Failure: Fatal And many more…

12. Wrap-Up r Many other parameters are generated from the master secret: m ClientWrite MAC Secret and ClientWrite Key m ServerWrite MAC Secret and ServerWrite Key m Client and Server IVs m Parameters are generated via hashing… MS is basically a seed to a pseudorandom function. r TLS is very similar to SSL m TLS uses HMAC instead of the concatenation-MAC m TLS does not support Fortezza m Minor differences in padding requirements

13. HTTP Over SSL r The HTTPS approach is very simple: m The client makes a connection to the server, negotiates an SSL connection, and then transmits its HTTP data over the SSL application data channel. m The only other piece of information that you need to have in order to create an interoperable (through not necessarily secure) HTTPS implementation is the port number. Because we’re using a separate port strategy, HTTPS connections need their own port. IANA assigned HTTPS port 443, so by default HTTPS connections happen on that port.

14. HTTP Session Management r HTTP is a sessionless protocol. Each GET request is handled by m Open a connection to the Web server m Download the document m Drop the connection m This is expensive for multi-document pages such as those with image or frames: each URL is handled by a separate request. r HTTP 1.1 attempts to solve some problems caused by this m An open connection may be kept open instead of closed m Requests from the same browser may reuse this connection instead of starting another one m The connection is closed after a short period of inactivity e.g. 30 seconds m This can double transfer times for some pages m It doesn't answer the session management problem

15. Session Management r Applications maintain state r Distributed applications may maintain state in each distributed component r Web applications are expected to maintain state r Typical Web application: shopping cart, where the server is expected to keep a list of items in the cart, and present this list on demand r Web support for state is poor

16. State Information r A browser can keep state information in m Cookies m Hidden form fields m URL rewriting m Challenge/response

17. Cookie m Cookie are passed at the HTTP layer m HTTP format is Set-Cookie: cookie-value m Cookies are sent from the server to browser and returned from browser to server m Cookies have a lifetime a domain a flag to return on secure or non-secure channels m Problems with cookies Some users turn off cookies for privacy reasons Cookies expire after a while

18. Hidden Form Fields r Hidden Form Fields r Pass the session key through in a named hidden field m... r Retrieve the session key through its name

19. Attacking Session Tracking Mechanism r If the attacker changes the session ID to a value currently assigned to another user, the application will think the attacker’s session belongs to that other user. In this way, the attacker usurps the legitimate user’s session ID. r An application with this vulnerability will allow an attacker to do anything a legitimate user can do.

20. Attacking Session Tracking Mechanism r Derive session ID m An attacker first needs to determine another user’s session ID. To accomplish this, the attacker will: login to the application using an account assigned to the attacker, and observe the session ID assigned to that session. The attacker will look at how long the session ID is and the types of characters that make it up. m Attacker will then write a script to login again and again, gathering hundreds of session IDs to determine how they change over time. Then, applying some statistical analysis to the sampled session Ids, the attacker will attempt to predict future session IDs that belong to other users.

21. Attacking Session Tracking Mechanism r Manipulate session ID m The attacker will login to the application using his/her own account to be assigned a session ID. m Then, the attacker will attempt to modify this session ID to take over the session of another user. The attacker simply types over the session ID in the URL line of the browser. If hidden form elements are used to track sessions, the attacker will: –save the web page sent by the server to the local file system. –The attacker will then edit the session ID in the hidden form elements of the local copy of the web page, and –reload the local page into the browser. –By simply submitting the form back to the server, the attacker will send the new session ID and could become another user.

22. Manipulate session ID (continued) r If the sessions are tracked using persistent cookies, the attacker can simply: m Edit the local cookie file. In Netscape browsers, all persistent cookies are store in a single file called “cookies.txt”. On my windows laptop it is at “C:\Documents and Settings\dhuang\Application Data\Mozilla\Profiles\default\ihd8jl39.slt”. On my Linux machine it is allocated at “/home/dhuang/.mozilla/default/xu20s1bh.slt/”. For Internet Explorer, cookies from different servers are stored in their own individual files in the Cookies directory. m To exploit a session ID based on a persistent cookie, the attacker will log into the application to get a session ID, close their browser to write the cookie file, edit the cookies user their favorite text editor, and re-launch the browser, now using the new session ID.

23. Manipulate session ID (continued) r Per-session cookie: The attacker cannot directly edit per-session cookies in the browser’s memory. m However, a proxy sitting between the browser and the server can edit these cookies easily by grabbing onto them in the raw communication stream between browser and server. m The attacker will configure a browser to send all HTTP and HTTPS data to and from the target web server through Achilles (tool for editing per-session cookies). m Achilles will let the attacker edit the raw HTTP/HTTPS fields and HTML information including per-session and persistent cookies, hidden form elements, URLs, frame definitions, and so on.

24. Defending against web application session-tracking attacks r Digitally sign or hash session-tracking information using a cryptographic algorithm r Encrypt the information in the URL, hidden form element, or cookie; don’t just rely on SSL r Make sure your session IDs are long enough to prevent accidental collision r Consider making your session IDs dynamic, changing from page to page throughout your web application r Apply a timestamp within the session ID variable and encrypt it