SSL

1
SSL

• Serguei Mokhov
• SOEN321, Fall 2004

2
Contents

• Background
• SET
• SSL
• origins
• protocol

3
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.

4
SET, Secure Electronic Transactions protocol

• A joint effort of IBM, Microsoft, Visa, and
  MasterCard
• Failed. Actually, never took off to fail.
• Why?
• Too complex (gt700 pages spec)
• Quality suffered.
• Meanwhile.

5
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?

6
ISO Stack

• Recall the 7-layer OSI model from the networks
  course

7
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) -gt
  secure_read(socketd)

8
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.

9
Transport Layer (3)

• Advantages?
• Its 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.

10
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 wont help (SET could have
  prevented this, but it didnt make it).
• As the result, some companies started to issue
  one-time credit cards, linked to your main
  credit account.

11
SSL Protocol - Server

• Server (e.g. a web site) owners have to go
  through these steps to support SSL
• Generate servers 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 its a
  web server Apache, then for example, mod_ssl has
  to be enabled and configured to use the
  certificate you obtained in httpd.conf).

12
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.

13
The SSL Protocol

• 1) C -gt 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 -gt 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 -gt 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 -gt S SessionKeyMaterialks
• S decrypts SessionKeyMaterial and derives the
  encryption and MAC keys.
• 5) S -gt C -gt S MAC of the dialog so far
• Both parties have the correct keys
• 6) Use the encryption key and MACs send
  application data.

14
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 dont
  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.