SSL

1. threats

  • On-line identity theft by which credentials or any other valuable information are obtained
    • Spoofing/phishing attacks
      • tricking users onto the fake website
    • DNS-based attacks
      • altering the DomainName-IP address mappings in the DNS server or the entries in a desktop’s Hosts file to direct users to a fraudulent server (also referred to as pharming).
    • Keyloggers
      • e.g. a browser helper object that detects changes to URL and logs information when a URL is at a designated credential collection site.

2. Web Traffic Security Requirements

  • Authentication
    • Using Web authN methods
  • Authorisation
    • done by authorisation decision engine in the web container
  • Confidentiality and Integrity
    • using SSL

2.1. Web authN

HTTP basic authentication

  • With/without SSL.
  • Username/password are collected via a browser dialog box, and sent to the web server in the HTTP Authentication Header.
    Digest(摘要) authentication scheme
  • Password is transmitted as an MD5 digest.
  • No need to use confidentiality protection.
    Form-based authentication
  • With/without SSL.
  • Username/password along with other data(区别于basic，可收集更多可用于身份认证信息) are collected via a web application provided login page, and sent to the web server as part of the form data.
    Certificate-based authentication
  • Must use SSL.
  • Can support both client and server authN.

3. SSL(Secure Sockets Layer, 安全套接层)

3.1. ports

  • Https
    • 443/tcp
    • http protocol over ssl/tls

3.2. components

  • SSL Handshake Protocol
    • negotiation of security algorithms and parameters
    • key exchange
    • server authentication and optionally client authentication
  • SSL Change Cipher Spec Protoc
    • a single message that indicates the end of the SSL handshake
  • an SSL session is an association between a client and a server
  • the session state includes security algorithms and parameters
  • a session may include multiple secure connections between the same client and server
  • connections of the same session share the session state
  • sessions are used to avoid expensive negotiation of new security parameters for each connection

3.3. SSL Record protocol

  • Content Type (8 bits)
    • Application_data
    • Handshake
    • Change_cipher_spec
      • indicates a change in the encryption and authentication of records
    • Alert
  • Major Version (8 bits)
  • Minor Version (8 bits)
    • the length in bytes of plaintext fragment (or compressed fragment if compression is used).

3.4. SSL ChangeCipherSpec protocol

  • it causes a pending state to be the current state
  • 1 byte

3.5. SSL Alert protocol

  • Errors are signalled via Alert Protocol
  • it is used to convey SSL-related alerts to the peer entity.
  • 2 bytes

3.6. SSL Handshake Protocol

  • negotiate a common cipher suite;
  • authenticate the server;
  • (optionally) authenticate the client;
  • establish cryptographic keys;
  • Type (1 byte)
  • Length (3 bytes)
  • Content (≥ 0 bytes)

3.6.1. Client hello message

– client_version

  • the highest version supported by the client
    – client_random
  • current time (4 bytes) + pseudo random bytes (28 bytes)
    – session_id
  • empty if the client wants to create a new session, or
  • the session ID of an old session within which the client wants to create the new connection
    – cipher_suites
  • list of cryptographic options supported by the client ordered by preference
  • a cipher suite contains the specification of the
    – key exchange method(Key establishment algorithms), the encryption(Symmetric encryption algorithms) and the MAC algorithm
    – the algorithms implicitly specify the hash_size, IV_size, and key_material parameters (part of the Cipher Spec of the session state)
  • KeyExchange_with_SymmetricEncryption_hash
    • exmaple: SSL_RSA_with_3DES_EDE_CBC_SHA
      – compression_methods
  • list of compression methods supported by the client

3.6.2. Server hello message

  • server_version
  • server_random
  • session_id
    • session ID chosen by the server
  • cipher_suite
    • single cipher suite selected by the server from the list given by the client
  • compression_method

3.6.3. Supported key exchange methods

With regard to the exchange of pre_master_secret(not master_key), the following methods are supported

  • RSA
    • client generates a 48-byte pre_master_secret and encrypts it with server�s public key
  • fixed Diffie-Hellman
  • ephemeral Diffie-Hellman
  • anonymous Diffie-Hellman
  • …

3.7. Server authentication vs Client authentication

certificate

  • S: required for every key exchange method except for anonymous DH
  • C: sent only if requested by the serve

3.8. pre master key vs maste key

Simplified SSLv3/TLS

pre-master secret

  • The point of a premaster secret is to provide greater consistency between TLS cipher suites
  • In the figure above, the premaster secret is S(in message 3). In this case, it is randomly generated.
    master secret
  • In the figure above, the master secret is K. Shown on the sides, it is a function of the pre-master secret and the two random values sent in the first two messages.
    shared secret / session key
  • This is what is referred to in the last step of the figure. The session key is referred to as “keys derived from K”. Many keys are actually derived from K. This could be the encryption key, integrity protection keys (for say HMAC), IVs for the ciphers, etc. And, it is usually a different set for each direction.

3.9. Server Authentication

  • Server sends client its digital certificate (or certificate chain)
  • Client
    • verifies the certificate, extracts its RSA public key
    • generates a 48-bytes pre_master_secret, encrypts it using this public key and sends the ciphertext to the server
    • Client and server independently compute the key block - MAC keys, encryption keys, IVs - from the pre_master_secret (+ another two random numbers)

3.10. Data transfer

  • the data is broken and transmitted as a series of protected records.
    • Everything can be protected excepts the fact that a particular browser is talking to a particular server
  • Data transfer is done by using the Record protocol
  • It is used to exchange application layer (e.g. SSL Handshake Protocol or HTTP) data
  • At sending side, application messages are
    • fragmented into blocks (called records);
    • (optionally) compressed;
    • appended by a MAC;
    • then encrypted;
    • appended with the SSL Record Header and transmitted.
  • At receiving side, records are
    • received and decrypted;
    • MAC is verified;
    • decompressed and reassembled; and
    • delivered to the application protocol

3.11. Session states

Session identifierArbitrary(任意) byte sequence chosen by server to identify the session state
Peer certificateX509.v3 certificate of the peer (may be null)
Compression methodAlgorithm used to compress data prior to encryption
Cipher specSpecifies bulk data encryption (null, DES, AES, etc) and hash algorithms used for encryption and MAC calculation; other attributes, eg. hash_size, may also be included
Master secret48 byte secret shared between the client and server
IsResumableIndicates whether the session can be used to initiate new connections

3.12. Connection state

server and client randomrandom byte sequences chosen by the server and the client for every connection
server write MAC secretsecret key used in MAC operations on data sent by the server
client write MAC secretsecret key used in MAC operations on data sent by the client
server write keysecret encryption key for data encrypted by the server
client write keysecret encryption key for data encrypted by the client
initialization vectorsan IV is maintained for each encryption key if CBC mode is used. initialized by the SSL Handshake Protocol. final ciphertext block from each record is used as IV with the following record
sending and receiving sequence numberssequence numbers are 64 bits long. reset to zero after each Change Cipher Spec message

4. attack

Eavesdropping

  • all application data is encrypted with a short term connection key
    • even if connection keys are compromised the master secret remains intact
  • different keys are used in each connection and in each direction of the connection
    Traffic analysis
  • SSL doesn’t attempt to protect against traffic analysis
  • if SSL is used to protect HTTP traffic, then an attacker
    • can learn the length of a requested URL
    • can learn the length of the HTML data returned
    • could find out which URL was requested with high probability
  • Replay attacks
    • SSL protects against replay attacks by including an implicit（隐式的） sequence number in the MAC computation
  • Padding oracle attack (reminder)
    • SSL uses a HMAC-like MAC
    • CBC encryption with padding in SSL/TLS
      • if the last byte is n, then verify if the last n+1 bytes are all n
    • 更多可参考: 加密算法与随机数
  • Key-exchange algorithm rollback
  • a fix:
    • hash all messages exchanged before the server_key_exchange
      message
    • include the hash in the signature in server_key_exchange message

5. Identification vs Verification vs Authentication

  • Identification: I claim to be someone.
  • Verification: You verify that I am that person by validating my official ID documents. You pair my valid ID with one of my biometrics.
  • Authentication: I access your platform and you compare my current, live identity to the biometrics of me you already have on file.

6. TSL vs SSL

version number
– for TLS 1.1 the version number is 3.2
cipher suites
– TLS doesn’t support Fortezza key exchange and Fortezza encryption
padding
– variable length padding is allowed (max 255 padding bytes)
MAC
– TLS uses the latest version of HMAC
– the MAC covers the version field of the record header too
certificate_verify message
– in SSL, the hash contains the master_secret
– in TLS, the hash is computed only over the handshake messages
more alert codes

7. 更多参考