Analysis of the SSL 3.0 Protocol

Let's think about why SSL might be secure.
  Too hard to *prove* security.
  Easier to analyze why particular attacks aren't possible.

Remember SSL goals:
  Confidentiality.
  Authenticity.
  No replay.

The basics:
  Why can't a passive observer decrypt data?
    Because pre_master is random and encrypted with server's public key,
    and server private key is secret.
  How does the client know where a data record came from?
    Need a provable path back to server certificate.
    Server proves it owns certificate, client can think about it.
  How does the server know who it is talking to?
    It doesn't in our examples.
    Unless perhaps the client includes a password in data.

Replay key exchange.
  Why can't attacker replay client's entire session?
    And e.g. order a second identical item from a web catalog?
  Each side needs to contribute a nonce to master key.

Fake server, providing real server's public key?
  Can't read pre_master_secret...

Totally fake server.
  Provide attacker's certificate as ServerCertificate?

Replay encrypted data record.
  Caught by MAC, sequence #.
  Details?

Why doesn't RC4 suffer from an attack if plaintext known?
  Explain that RC4 xor's random stream with plain text.
  I.e. xor msg with known plain text, then xor with bogus text?
  Because that's an authenticity attack!
  And SSL3 has a separate plan for authenticity.
  What is it?
    Each record's MAC includes (implicit) sequence #.

Cipher roll-back.
  Attacker deletes strong algorithms from cipher_suites.
    Then must modify the MAC in the finished message?
    But it includes the master_secret!
  Why allow choice of key lengths?
  Why allow choice/selection of ciphers? (separate issue...)

CBC cut and paste attack.
  Encrypt: Ci = Encrypt(Mi xor Ci-1)
    i.e. xor each plain text block with previous cipher block.
    So a change in plain text (or IV) ripples through whole subseq ciphertext.
  Decrypt: Mi = Decrypt(Ci) xor Ci-1
    So a change in Ci affects Mi, Mi+1, but no more!

Example of needing to send+authenticate all context?
  Does auth cover record length field?
    Yes in SSL 3.0, no in SSL 2.0.
    Bad interaction with padding in block ciphers.
    Otherwise could make real data be treated like padding.

Attack by deleting "change cipher" message?
  (Why doesn't Finish MAC cover the change cipher message?)
  Remember each side *sent* the message, so is sending in new cipher.
  Remember finish message is sent in new cipher (i.e. probably encrypted).
    So other side would be confused.
  Only works if peers negotiated auth-only, no encryption.

Forward secrecy?
  I.e., record a conversation, then later steal server's private key.
  SSL 3.0 does not appear to have it.
  How could we fix this?
    Could generate a session public/private key pair?