HTTP over SSL RFC 2818 RFC 2817 Introduction

Introduction l Prototypical web security application: l User browses site and places items in

Basic Technologies l HTTP (Hypertext Transfer Protocol) l First protocol to use SSL l

HTTP request GET / HTTP/1. 0 Request line l Connection: Keep-Alive Connection l User-Agent:

HTTP request l 7 request methods: Get, Post, Head, … l Format of http

HTTP response l l l HTTP/1. 1 200 OK Date: Sat, 15 Jan 2000

Goals so Far l Confidentiality of the data l Request/Response safe from attackers l

Notes l Images on the page l Encrypt or not? l Browser should clearly

URLS and URIS l URL l Provides single short string to identify networkaccessible resource

Practical Considerations l l l Firewalls and proxies l How to process encrypted traffic?

HTTP connection behavior l l HTTP 1. 0 l Close connection after each response

Security Considerations l Protocol Selection l l Client authentication l l l In practice,

HTTPS overview We examine simple request over https l Carefully examine technical points: l

History HTTP - first application layer secured with SSL l First implementation of HTTP

HTTPS approach Client hello Server Certificate server. Hello. Done Handshake Client. Key. Exchange E(Kserv,

Overview Client makes connection to the server l Handshakes SSL l Transmits data over

HTTPS Records (same as SSL) SSL version Record Length Content type Record Header l

Connection closure l When one side initiates closure l Must send close_notify l Optionally

End-point Authentication l When user’s browser receives certificate l CA is a known CA

Session Resumption l Session resumption l Minimizes the number of SSL handshakes, within the

Error Handling l Servers logs errors. Later maybe examined by administrator l Clients receive

Virtual hosts SSL connection established before any data transmitted l Server should determine which

Virtual Hosting solution 1 Single network interface has multiple ip addresses l Each virtual

Virtual Hosting Solution 2 l l Allow one certificate to serve multiple hosts Netscape

Proxies Proxy examines the client request to determine which server to connect l In

Proxies Proxy Client ebay. com Connect 443 HTTP 1. 0 200 Client. Hello .

Man-in-the-Middle Proxies Proxy has certificate with “*” as hostname Proxy Client ebay. com Connect

Man-in-the-Middle Proxies Proxy has certificate with “*” as hostname l Client will accept its

Referrer Attack l Referrer header in request contains URL of the previous page l

Substitution Attack The reference to https: //amazone. com replaced with the reference to https:

Substitution Attack Possible if attacker may replace the page l User may examine the

Multiple clients l Session caching is important when processing multiple clients. l Many pages

Summary SSL was designed for HTTP and it works relatively well l HTTPS relatively

Limitations of SSL Bob makes purchase from Alice l Merchant authorization l Is Alice

SET (Secure Electronic Transactions) l l Designed to encrypt specific payment related messages only

Set uses three software components l Merchant server l Processes transactions l Communicates with

Key Features of SET l Confidentiality of information l Payment information is sent encrypted

Slides: 38

Download presentation

HTTP over SSL RFC 2818 RFC 2817

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

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

HTTP request GET / HTTP/1. 0 Request line l Connection: Keep-Alive Connection l User-Agent: Mozilla/4. 7 [en] header (X 11; U; Free. BSD 3. 4 -STABLE i 386) l Host: www. rtfm. com l Accept: image/gif, image/x-xbitmap, image/jpeg, image/png, */* l Accept-Encoding: gzip l Accept-Language: en l Accept-Charset: iso-8859 -1, *, utf-8 l (blank line) l

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

HTTP response l l l 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 "-//W 3 C//DTD HTML 3. 2 Final//EN"> <HTML> … </HTML>

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

Notes l Images on the page l Encrypt or not? l 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 l In POST parameters are sent in message body l

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

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

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

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

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

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

HTTPS approach Client hello Server Certificate server. Hello. Done Handshake Client. Key. Exchange E(Kserv, PK) Change. Cipher. Spec FIN Handshake (MAC) Application_data http request Application_data http response Alert : close_notify Data Close

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

HTTPS Records (same as SSL) SSL version Record Length Content type Record Header l l l Content types: Change. Cipher. Spec Handshake Application Data Alert (signaling error and closure) Encrypted Data and Mac Data

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

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

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

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

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

Virtual Hosting solution 1 Single network interface has multiple ip addresses l Each virtual host assign different ip l www. first. com 10. 2. 2. 2 www. second. com 10. 2. 2. 3 Server 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

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

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

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

Man-in-the-Middle Proxies Proxy has certificate with “*” as hostname Proxy Client ebay. com Connect 443 HTTP 1. 0 200 Client. Hello Proxy certificate name= * Client. Keys. Exchange Using proxy’s Key Client. Hello Server certificate Client. Key. Exchange 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

Man-in-the-Middle Proxies Proxy has certificate with “*” as hostname l Client will accept its certificate no matter which host he wants to connect l Obviously no legitimate CA would issue such certificate, because such certificate allows its holder impersonate any server l Such scenario is possible if: l l Hacker-administrator runs its own CA l Installs this CA into the browser l 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

Referrer Attack l Referrer header in request contains URL of the previous page l l Forms with GET method l l l 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: l l l Referrer header contains URL that the user was viewing when he clicked the link referenced the current page 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

Substitution Attack The reference to https: //amazone. com replaced with the reference to https: //evil. com l 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 l

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

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

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

Limitations of SSL Bob makes purchase from Alice l Merchant authorization l Is Alice authorized to accept credit card payments? l Is Alice a reliable merchant? l l Customer authorization l Maybe l 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)

SET (Secure Electronic Transactions) l l 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

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

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