Document Sample
ssl Powered By Docstoc

 Serguei Mokhov
SOEN321, Fall 2004
• Background
  – origins
  – protocol
  Online Financial Transactions
• Do you buy stuff online? Do you bank online?
• What are threats?
• Using credit cards over the net  seem
  – 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
• Failed. Actually, never took off to fail.
• Why?
  – Too complex (>700 pages spec)
  – Quality suffered.
• Meanwhile….
• 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:

   Transport       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)
  – 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 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
• 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.
• 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
•   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.

niusheng11 niusheng11
About Those docs come from internet,if you have the copyrights of one of them,tell me by mail,and i will delete it on the first time. I just want more peo learn more knowledge. Thank you!