SSL Serguei Mokhov SOEN 321 Fall 2004

SSL Serguei Mokhov SOEN 321, 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 Master. Card • 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 Presentation Session Transport Network Link Physical SSL is on Transport

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 2246. – 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 (Open. SSL), 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 https: // and port 443 by default. – https: //mail. encs. concordia. ca/ • 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 Client. Hello} – Client. Hello contains SSL params, like crypto algos and their params supported on the client, called a ciphersuit, compression algo, SSL version. – Server matches the Client. Hello 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 : {Choosen. Suit, session. ID} – Session. ID 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 Choosen. Suit – Session key material used to generate encryption and MAC keys for securing packet payload when communicating to the server. • 4) C -> S : {Session. Key. Material}k+s – S decrypts Session. Key. Material 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.