1 / 38

HTTP over SSL

HTTP over SSL. RFC 2818 RFC 2817. Introduction. Prototypical web security application: User browses site and places items in his shopping cart Server hands of the user when he is ready to check out User submits his credit card number User receives confirmation of his operation.

venus
Download Presentation

HTTP over 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. HTTP over SSL RFC 2818 RFC 2817

  2. Introduction • Prototypical web security application: • User browses site and places items in his shopping cart • Server hands of the user when he is ready to check out • User submits his credit card number • User receives confirmation of his operation

  3. Basic Technologies • HTTP (Hypertext Transfer Protocol) • First protocol to use SSL • Request/Response structure • Most browsers speak http protocol • HTML (Hypertext Markup Language) • Offers the ability to structure the document • Provide links to move to another documents • URL (Uniform Resource Locator)

  4. HTTP request Request line Connection header • GET / HTTP/1.0 • Connection: Keep-Alive • User-Agent: Mozilla/4.7 [en] (X11; U; FreeBSD 3.4-STABLE i386) • Host: www.rtfm.com • Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* • Accept-Encoding: gzip • Accept-Language: en • Accept-Charset: iso-8859-1,*,utf-8 • (blank line)

  5. HTTP request • 7 request methods: Get, Post, Head, … • Format of http request line • Method Request-URI HTTP-version • Post may have message body and Get not • Connection header • Client wants server to keep the connection open, after sending the request • All information the client transmits is his request • Ensure that client’s request is encrypted

  6. HTTP response • HTTP/1.1 200 OK • Date: Sat, 15 Jan 2000 05:15:54 GMT • Server: Apache/1.3.1 (UNIX) • Last-Modified: Tue, 22 Apr 2003 19:25:14 GMT • Accept-Ranges: bytes • Content-Length: 1650 • Keep-Alive: timeout=15, max=100 • Connection: Keep-Alive • Content-Type: text/html • <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> • <HTML> … • </HTML>

  7. Goals so Far • Confidentiality of the data • Request/Response safe from attackers • Viewing • Changing • User connected to the right server • Prevent attacker from posing as a server

  8. Notes • Images on the page • Encrypt or not? • Browser should clearly indicate if the security properties are different from that of the page it was embedded • In GET method values of the form (or parameters) attached to URI • In POST parameters are sent in message body

  9. URLS and URIS • URL • Provides single short string to identify network-accessible resource • <scheme>://<host>[:<port>]/<path>[?<query>] • http://www.ebay.com/local/foo.html?item=3 • URI (Uniform Resource Identifier) • Short string that refers to given resource • A superset of URLs • URL is URI that contains instruction how to fetch this page (without “http”) • www.example.com • http request line contains a non-URL URI

  10. Practical Considerations • Firewalls and proxies • How to process encrypted traffic? • Primary issue for SSL/proxy interaction: traffic can pass through proxy without damage • Filtering of data, is it possible? • Virtual hosts • Many sites on the same machine • Each site has separate name (domain name) • One web server receives requests for multiple virtual hosts • Connection behavior

  11. HTTP connection behavior • HTTP 1.0 • Close connection after each response • Images: require response/request pair • HTTP 1.1 • Connection : Keep-Alive (persistent connection) • Some browsers still open number of connections to load page with images in parallel • Large number of parallel connections is optimized by SSL session resumption.

  12. Security Considerations • Protocol Selection • Separate port strategy is the only workable (https 443) • Client authentication • In practice, most sites authenticate users with passwords or their credit card • Web security solution should support certificates for clients • Reference integrity • User connects to server that he intended to • Match URL reference to server’s hostname in certificate • Connection semantics • SSLhandshake is more expensive than TCPhandshake

  13. HTTPS overview • We examine simple request over https • Carefully examine technical points: • Connection closure • Reference integrity • Interaction with network devices (proxies, virtual hosts) • HTTPS attacks • Advantages/ Disadvantages • SET

  14. History • HTTP - first application layer secured with SSL • First implementation of HTTP over SSL was issued in 1995 by Netscape • Netscape was prevented from choosing shttp • S-HTTP another protocol for securing messages • Treats each request – response pair as a single unit • Allows protect different messages between server-client differently • Only in 2000 RFC 2818 was published • RFC 2818 describes HTTP over TLS

  15. HTTPS approach Client hello Server hello Server Certificate Handshake serverHelloDone ClientKeyExchange E(Kserv, PK) ChangeCipherSpec FIN Handshake (MAC) ChangeCipherSpec FIN Handshake (MAC) Application_data http request Data Application_data http response Alert : close_notify Close Alert : close_notify

  16. Overview • Client makes connection to the server • Handshakes SSL • Transmits data over SSL channel • IANA assigned port 443 • Special configuration of the server needed (mod_ssl), possible to configure another port • No client data is sent until SSL connection established • Long web pages require spanning multiple SSL records

  17. HTTPS Records (same as SSL) • Content types: • ChangeCipherSpec • Handshake • Application Data • Alert (signaling error and closure) SSL version Record Length Content type Encrypted Data and Mac Record Header Data

  18. Connection closure • When one side initiates closure • Must send close_notify • Optionally withholds its TCP FIN until close_notify received from other side. • If TCP FIN received without close_notify this may indicate possible attack

  19. End-point Authentication • When user’s browser receives certificate • CA is a known CA • Browser compares: • Name of the site that it intended to connect with • Hostname in certificate

  20. Session Resumption • Session resumption • Minimizes the number of SSL handshakes, within the same session • sides speak with already established keys • If the close was premature in no case SSL implementation should resume session

  21. Error Handling • Servers logs errors. Later maybe examined by administrator • Clients receive via dialog boxes • SSL implementation should: • Report legitimate errors • Not overwhelm the user (hide unimportant)

  22. Virtual hosts • SSL connection established before any data transmitted • Server should determine which certificate to be sent to the client Server Client www.first.com www.second.com

  23. Virtual Hosting solution 1 • Single network interface has multiple ip addresses • Each virtual host assign different ip www.first.com 10.2.2.2 Server www.second.com 10.2.2.3 Client may TCP connect with 10.2.2.2 and server Knows this way which certificate to fetch • Server should manager multiple certificates • + Each host may have different security level

  24. Virtual Hosting Solution 2 • Allow one certificate to serve multiple hosts • Netscape supports wildcarding, • RFC 2818 wildcarding : * (anything), ? (one char), [A-Z] any character between A and Z • Netscape uses more complicated wildcarding than RFC • Explorer allows also certificate to contain multiple domain names: www.my.com, www.your.com • + certificate maybe issued to unrelated domains • - if new virtual host added, certificate must be totally reissued • Another approach: client should signal in ClientHello which server he wants to talk (proposed change in next TLS version

  25. Proxies • Proxy examines the client request to determine which server to connect • In https request is passed encrypted • RFC 2817 new proxy method CONNECT • CONNECT instructs proxy to initiate TCP connection to specified server • Proxy then passes data without examining it • Client transmits SSL data to proxy as it was the server • Client sends to proxy: CONNECT www.my.com:443 HTTP/1.1

  26. Proxies Proxy ebay.com • Clients may punch a security hole using CONNECT but sending open data. • Restrict client to port 443 Client Connect 443 HTTP 1.0 200 ClientHello ClientHello . . . Server certificate, Server Hello

  27. Man-in-the-Middle Proxies Proxy ebay.com Proxy has certificate with “*” as hostname Client Connect 443 HTTP 1.0 200 ClientHello ClientHello Server certificate Proxy certificate name= * ClientKeysExchange Using proxy’s Key ClientKeyExchange Using Server’s key Get using client-Proxy key Get using Proxy-Server Key HTTP 1.0 OK using proxy-Client key HTTP 1.0 OK using proxy-Server key

  28. Man-in-the-Middle Proxies • Proxy has certificate with “*” as hostname • Client will accept its certificate no matter which host he wants to connect • Obviously no legitimate CA would issue such certificate, because such certificate allows its holder impersonate any server • Such scenario is possible if: • Hacker-administrator runs its own CA • Installs this CA into the browser • Browsers that are not under control of such administrator won’t have this CA in their list and thus can’t be fooled by this dangerous certificate

  29. Referrer Attack • Referrer header in request contains URL of the previous page • Referrer header contains URL that the user was viewing when he clicked the link referenced the current page • Forms with GET method • arguments are concatenated to URL: www.ebay.com/confirm.htm?visa=123&item=7 • When user click on the page resulting from the form submission, this string will appear in referrer header in request to next page • Arguments will be passed in referrer header: • If it is HTTP link arguments will be passed in clear • If the link is HTTPS but to another site this site will received arguments intended for the previous site • Solution: Post passes arguments in the body of request. Use only method POST in FORMS

  30. Substitution Attack • The reference to https://amazone.com replaced with the reference to https://evil.com • In html: <html>… <a href=https://evil.com> Click here to go to https://amazone.com </a>… </html> User clicks the link , request was sent for https://evil.com Attacker has certificate for https://evil.com Certificate matches the requested host Client’s integrity check will be bypassed

  31. Substitution Attack • Possible if attacker may replace the page • User may examine the URL with “view source” • The attacker may act more tricky: <html>… <a href=https://amaz0ne.com> Click here to go to https://amazone.com </a>… </html> Attacker may obtain certificate to the site https://amaz0ne.com that has name very similar to the original site Hard for user to notice the difference

  32. Multiple clients • Session caching is important when processing multiple clients. • Many pages require multiple SSL connections • Cache should be synchronized or locked • Servers must share data between processes if server uses multi-process model.

  33. Summary • SSL was designed for HTTP and it works relatively well • HTTPS relatively simply to implement • HTTPS uses hostname for reference integrity • Using HTTPS brakes proxies • No caching • Special method CONNECT required to work with HTTPS

  34. Limitations of SSL • Bob makes purchase from Alice • Merchant authorization • Is Alice authorized to accept credit card payments? • Is Alice a reliable merchant? • Customer authorization • Maybe Bob uses stolen credit card? • Law dictates: merchant is liable for fraud SSL transaction (unless he can prove that customer ordered and received the goods)

  35. SET (Secure Electronic Transactions) • Designed to encrypt specific payment related messages only • Involves merchant, bank, customer • Customer and Merchant certificates issued by their banks thereby assuring that these players are permitted to operate payment cards • Customers payment card number is passed to merchant’s bank without the merchant seeing the number in plain text

  36. Set uses three software components • Merchant server • Processes transactions • Communicates with merchant’s bank • Acquirer gateway • Software component at merchant’s bank • Processes transactions • Browser wallet • Application that integrated with the browser • Provides customer with storage and management of payment cards

  37. Key Features of SET • Confidentiality of information • Payment information is sent encrypted over network • Prevents merchant learning card number of the customer • Integrity of data • Payment information sent includes all details of the transaction, signed with RSA digital signature • Cardholder account authentication • Enables to verify that cardholder is legitimate user of his card • Merchant authentication • Merchant is reliable

More Related