Download presentation
Presentation is loading. Please wait.
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: Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso ,*,utf-8 (blank line) Request line Connection header Post may have message body and Get not
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 This slide maybe skipped because knowing http required for understanding, So it will be explained quickly
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 :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 URI (Uniform Resource Identifier)
Provides single short string to identify network-accessible resource <scheme>://<host>[:<port>]/<path>[?<query>] 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”) 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
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 Maybe skipped
15
HTTPS approach Handshake Data Close 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)
version Record Length Content type Encrypted Data and Mac Record Header Data Content types: ChangeCipherSpec Handshake Application Data Alert (signaling error and closure)
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) This slide maybe skipped
22
Virtual hosts SSL connection established before any data transmitted
Server should determine which certificate to be sent to the client Server Client
23
Virtual Hosting solution 1
Single network interface has multiple ip addresses Each virtual host assign different ip Server Client may TCP connect with 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 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: + 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 HTTP/1.1
26
Proxies Proxy ebay.com Client . . .
Connect 443 HTTP ClientHello . . . ClientHello Server certificate, Server Hello Clients may punch a security hole using CONNECT but sending open data. Restrict client to port 443
27
Man-in-the-Middle Proxies
Proxy has certificate with “*” as hostname Proxy ebay.com Client Connect 443 HTTP 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: 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 replaced with the reference to In html: <html>… <a href= Click here to go to </a>… </html> User clicks the link , request was sent for Attacker has certificate for 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= Click here to go to </a>… </html> Attacker may obtain certificate to the site 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 Optional (if we have time)
36
Set uses three software components
Merchant server Processes transactions Communicates with merchant’s bank Acquirer gateway Software component at merchant’s bank Browser wallet Application that integrated with the browser Provides customer with storage and management of payment cards Optional slides (if we have time)
37
Key Features of SET Confidentiality of information Integrity of data
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
Similar presentations
