SSL Serguei Mokhov SOEN321, Fall 2004

Contents Background SET SSL –origins –protocol

Online Financial Transactions Do you buy stuff online? Do you bank online? What are threats? Using credit cards over the net  seem dangerous. –Need to avoid sniffers –Domain name spoofing to pass the transactions through you Big problem: –Merchant storing your credit cards in their web-linked database, for convenience of the shoppers. Convenience maybe is costly.

SET, Secure Electronic Transactions protocol A joint effort of IBM, Microsoft, Visa, and MasterCard Failed. Actually, never took off to fail. Why? –Too complex (>700 pages spec) –Quality suffered. Meanwhile….

SSL Meanwhile Netscape has been developing a simpler protocol for online transactions. They called it Secure Socket Layer. Which level of ISO model the SSL sits on?

ISO Stack Recall the 7-layer OSI model from the networks course: Application SSL is on Transport Presentation Session Transport Network Link Physical

Transport Layer Between an app and networking Refers to TCP and UDP Transport layer security sits on top of the Transport Layer: –Does not alter TCP/UPD headers –Security is maintained when apps perform socket calls, which being replaced by their secure versions, i.e. read(socketd) -> secure_read(socketd)

Transport Layer (2) SSL –Secure Socket Layer, SSL; was introduced by Netscape, then standardized, became TLS – Transport Layer Security, RFC –Typical example: Web browsers, and other Client sever architectures (RDBMS, for example). –Provides encryption and authentication. –Services can easily be configured on top of SSL, w/o requiring much knowledge of it.

Transport Layer (3) Advantages? –It’s easier just upgrade your browser to have SSL, then reinstall OS than say replacing insecure version of an IP stack. Disadvantages? –If no standard socket routines that map to the secure version, the apps have to be altered or provide two code paths, with and without the SSL.

SSL Idea Create a secure “pipe” between a browser and a server. Encrypted, possibly compressed (OpenSSL), with MACs, etc. Adequate enough for credit cards and online transactions. Recall the problem: merchants often store the card info in their databases, so if an attacker breaks in there, SSL won’t help (SET could have prevented this, but it didn’t make it). As the result, some companies started to issue one-time credit “cards”, linked to your main credit account.

SSL Protocol - Server Server (e.g. a web site) owners have to go through these steps to support SSL: –Generate server’s private/public key pair using RSA –Get a certificate for the public key from a root authority (to sign the key, usually costs money). A certificate contains identity and the public key of the merchant, signed, in some specific format for SSL protocol. –Install SSL support on the server site (if it’s a web server Apache, then for example, mod_ssl has to be enabled and configured to use the certificate you obtained in httpd.conf).

SSL Protocol - Client Most typical a browser. For web sites, use and port 443 by default. – A browser typically contains a collection (50-100) of root authorities’ public keys to verify signatures of the web server. So, it is practically transparent to the browser user when visiting secure sites.

The SSL Protocol 1) C -> S : {SSL ClientHello} –ClientHello contains SSL params, like crypto algos and their params supported on the client, called a ciphersuit, compression algo, SSL version. –Server matches the ClientHello to its own collection of ciphersuits and compression alogs and picks the most secure combo (SSL Version 2 had a bug picking of least secure one). 2) S -> C : {ChoosenSuit, sessionID} –SessionID serves to avoid key regeneration on every transaction. –Racal, there is NO permanent session/link maintained on the web via HTTP/HTTPS, only request-response. 3) S -> C: {cert} –C verifies the cert and if succeeds, extracts public key from it. –C generates session key material (symmetric, random) based on the ChoosenSuit –Session key material used to generate encryption and MAC keys for securing packet payload when communicating to the server. 4) C -> S : {SessionKeyMaterial}k +s –S decrypts SessionKeyMaterial and derives the encryption and MAC keys. 5) S -> C -> S {MAC of the dialog so far} –Both parties have the correct keys 6) Use the encryption key and MACs send application data.

Security Conclusions SSL is generally good. SSL as good as underlying crypto protocols used. Browsers are half-friendly: the tell there is an SLL mode going on (lock image), but don’t immediately tell with which server… Is the server serving the certificate actually the entity in the certificate?? Browsers usually issue a warning, but who reads them? DNS attacks (cache poisoning) effective against SSL. Not to neglect social aspect. User is responsible for verifying the identity of the server. Client caches. Performance (just with server certificates there two public key operations, high load on busy websites, what if we authenticate the clients as well?). SSL is not magical solution for web, but good enough.