1 / 24

Web Security and Secure Socket Layer (SSL)

Web Security and Secure Socket Layer (SSL). Web Security Issues. The Web has become the visible interface of the Internet Many corporations now use the Web for advertising, marketing and sales Web servers might be easy to use but…

patch
Télécharger la présentation

Web Security and Secure Socket Layer (SSL)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Security and Secure Socket Layer (SSL)

  2. Web Security Issues The Web has become the visible interface of the Internet Many corporations now use the Web for advertising, marketing and sales Web servers might be easy to use but… Complicated to configure correctly and difficult to build without security flaws They can serve as a security hole by which an adversary might be able to access other data and computer systems

  3. So Where to Secure the Web? There are many strategies to securing the web We may attempt to secure the IP Layer of the TCP/IP Stack: This may be accomplished using IPSec, for example. 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) We may seek to secure specific applications by using application-specific security solutions: For example, we may use Secure Electronic Transaction (SET) The first two provide generic solutions, while the third provides for more specialized services We will focus on SSL

  4. A Quick Look at Securing the TCP/IP Stack HTTP FTP SMTP HTTP FTP SMTP SSL/TLS TCP TCP IP/IPSEC IP At the Network Level At the Transport Level S/MIME PGP SET Kerberos SMTP HTTP UDP TCP IP At the Application Level

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

  6. SSL Preliminaries 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 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. Session Security Parameters: Session Identifier Peer Certificate: X.509v3 certificate of the peer Compression: Optional algorithm used to compress data Cipher Specs: Encryption Algorithm (3DES, AES, etc.) and hash algorithm (MD5, SHA-1) Master Secret: 48-byte secret shared between client and server

  7. Protocol Structure

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

  9. SSL Record Protocol SSL Record protocol allows protocols above SSL to be secured Example: HTTP delivers packets that are fragmented and securely delivered SSL does not handle retransmissions… it does not have to! TCP provides that functionality This is quite the opposite of IPSec, which only secures IP! Messages are broken into blocks of at most 16384 bytes The compression is optional and, due to message size/type, it might not even be desirable to use! Encryption may be stream or block mode. This is negotiated through the Handshake protocol 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 This is the beast… Its where all the action really takes place! Basically, the Handshake protocol is used before any application data is transmitted. It is used to allow the server and client to authenticate each other To negotiate on an encryption and MAC algorithm Establish keys to be used The Handshake Protocol consists of messages consisting of three fields: Type (1 byte): Indicates type of the message. There are 10 types. Length (3 bytes) Content: The payload exchanged in each message

  11. Other SSL Management Functions There are two other Management Functions provided by SSL: Change Cipher Spec: A single byte is sent after new cipher parameters have been agreed upon (aka. Handshake). “Pending” parameters become activated. 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 Many other parameters are generated from the master secret: ClientWrite MAC Secret and ClientWrite Key ServerWrite MAC Secret and ServerWrite Key Client and Server IVs Parameters are generated via hashing… MS is basically a seed to a pseudorandom function. TLS is very similar to SSL TLS uses HMAC instead of the concatenation-MAC TLS does not support Fortezza Minor differences in padding requirements

  13. HTTP Over SSL The HTTPS approach is very simple: The client makes a connection to the server, negotiates an SSL connection, and then transmits its HTTP data over the SSL application data channel. 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 HTTP is a sessionless protocol. Each GET request is handled by Open a connection to the Web server Download the document Drop the connection This is expensive for multi-document pages such as those with image or frames: each URL is handled by a separate request. HTTP 1.1 attempts to solve some problems caused by this An open connection may be kept open instead of closed Requests from the same browser may reuse this connection instead of starting another one The connection is closed after a short period of inactivity e.g. 30 seconds This can double transfer times for some pages It doesn't answer the session management problem

  15. Session Management Applications maintain state Distributed applications may maintain state in each distributed component Web applications are expected to maintain state 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 Web support for state is poor

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

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

  18. Hidden Form Fields Hidden Form Fields Pass the session key through in a named hidden field <form> ... <input type="hidden" name="session_key" "value="..."> </form> Retrieve the session key through its name

  19. Attacking Session Tracking Mechanism 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. An application with this vulnerability will allow an attacker to do anything a legitimate user can do.

  20. Attacking Session Tracking Mechanism Derive session ID 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. 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 Manipulate session ID The attacker will login to the application using his/her own account to be assigned a session ID. 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) If the sessions are tracked using persistent cookies, the attacker can simply: 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. 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) Per-session cookie: The attacker cannot directly edit per-session cookies in the browser’s memory. 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. 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). 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 Digitally sign or hash session-tracking information using a cryptographic algorithm Encrypt the information in the URL, hidden form element, or cookie; don’t just rely on SSL Make sure your session IDs are long enough to prevent accidental collision Consider making your session IDs dynamic, changing from page to page throughout your web application Apply a timestamp within the session ID variable and encrypt it

More Related