Information System Security AABFS-Jordan Web Security: SSL and Tls
Information System Security AABFS-Jordan Web Security: SSL and Tls
Summer 2006
Agend
Definition The idea SSL components Implementation How it work SSL hand shake protocol Confidentiality Certificate Authentication TLS VS SSL
2
applications (e.g., a web server and a browser) SSL was developed by Netscape SSL version 3.0 has been implemented in many web browsers (e.g., Netscape Navigator and MS Internet Explorer) and web servers and widely used on the Internet SSL v3.0 was specified in an Internet Draft (1996) it evolved into TLS specified in RFC 2246 TLS can be viewed as SSL v3.1
3
The Idea
Encrypt the web traffic between two sites,
Layer (SSL)
SSL components
SSL Handshake Protocol negotiation of security algorithms and parameters key exchange server authentication and optionally client authentication SSL Record Protocol fragmentation compression message authentication and integrity protection encryption SSL Alert Protocol error messages (fatal alerts and warnings) SSL Change Cipher Spec Protocol a single message that indicates the end of the SSL handshake
The Implementation
The secure web site includes a digital
certificate signed by some certificate authority. The certificate includes the server name, its public key, IP number, and an expiration date. It is typically signed with a 1024 bit key by the CA The list of certificate authorities that you trust to identify people is available in Netscape by clicking on the lock icon at top; in IE, Internet Options->Content
6
How It Works
The browser reads the site certificate; if it is
signed by one of the trusted certificate authorities, browser accepts the certificate as valid If the certificate is signed by some unknown certificate authority, Netscape will ask you if you want to trust the guy who signed it
7
How It Works
Step 1: your browser introduces itself to the
secure server Step 2: the server responds by sending back a message with the certificate included Step 3: Your browser tells the secure site to prove its identity, that it really is who it says it is.
9
How It Works
Step 4: The secure server proves who it is
by creating a message for the browser, generating a fingerprint of that message, and encrypting the fingerprint with the private key that is matched to the public key in the certificate. The browser generates the fingerprint for the message itself, then decrypts the fingerprint generated by the server using the public key provided in the certificate.
10
How It Works
At this point the browser is sure that the
server is how it says it is. It can send it secret messages encrypted with the public key provided in the certificate. The server (and only the server) can decrypt these messages, because only it has the private key.
11
How It Works
At this point what typically happens is that
the browser generates a session key using a completely different encryption algorithm. A new session key is generated for every connection; this does not have to be a public key algorithm. You can use any encryption algorithm you like; usually a faster conventional, non-PK algorithm is used. This is usually 40 or 128 bits long in Netscape.
12
How It Works
Youll use a completely different key for
encrypting traffic to the web site every time you connect. This makes cracking communication more difficult; you need to discover the keys for every session rather than just one key.
13
14
server_key_exchange sent only if the certificate does not contain enough information to complete the key exchange (e.g., the certificate contains an RSA signing key only) may contain
public RSA key (exponent and modulus), or DH parameters (p, g, public DH value), or Fortezza parameters
digitally signed
if DSS: SHA-1 hash of (client_random | server_random | server_params) is signed if RSA: MD5 hash and SHA-1 hash of (client_random | server_random | server_params) are concatenated and encrypted with the private RSA key 16
client_key_exchange always sent (but it is empty if the key exchange method is fix DH) may contain
RSA encrypted pre-master secret, or client one-time public DH value, or Fortezza key exchange parameters
certificate_verify sent only if the client sent a certificate provides client authentication contains signed hash of all the previous handshake messages
if DSS: SHA-1 hash is signed if RSA: MD5 and SHA-1 hash is concatenated and encrypted with the private key
MD5( master_secret | pad_2 | MD5( handshake_messages | master_secret | pad_1 ) ) SHA( master_secret | pad_2 | SHA( handshake_messages | master_secret | pad_1 ) )
18
Finished messages
finished sent immediately after the change_cipher_spec message first message that uses the newly negotiated algorithms, keys, IVs, etc. used to verify that the key exchange and authentication was successful contains the MD5 and SHA-1 hash of all the previous handshake messages:
MD5( master_secret | pad_2 | MD5( handshake_messages | sender | master_secret | pad_1 ) ) | SHA( master_secret | pad_2 | SHA( handshake_messages | sender | master_secret | pad_1 ) )
where sender is a code that identifies that the sender is the client 19 or the server (client: 0x434C4E54; server: 0x53525652)
Logistics
To set up a secure server you need to get a
certificate. Most people go to verisign (www.verisign.com). Verisign charges $350 for a certificate for one web site; it is tied to that web site name (eg www.nps.navy.mil). For commercial entities they do a search of Dun & Bradstreet to ensure who you are. This is good for one year. Other Certificate Authorities are www.thawte.com ($125), or any of those listed as signers in Netscape. You can set up your own CA and sign your own certificates.
21
default than normal web servers. A new instance of the program should listen on port 442 rather than port 80. To configure Apache: see http://www.modssl.org. The legality of the crypto package used is questionable if used for commercial purposes; the algorithms are encumbered with patent issues
22
Certificate Authorities
You can become your own certificate
authority. You can sign your own CA certificate and start handing out certificates yourself. (See certs for the CAS in netscape) There are products from MS and Netscape that automate this process; users send in requests, and you return signed certificates.
23
Certificate Authorities
You become your own certificate authority
mostly to hand out certificates to servers that are used internally, or to identify people inside the company. NPS could become a certificate authority and hand out certificates to web servers on campus, or hand out certificates to users for email that needed to be authenticated
24
Protocol
HTTP, IMAP, NNTP, Telnet, FTP, etc. SSL TCP IP
26
27
TLS VS SSL
version number
for TLS the current version number is 3.1
MAC
TLS uses HMAC the MAC covers the version field of the record header too
certificate_verify message
the hash is computed only over the handshake messages in SSL the hash contained the master_secret and pads
28
29
cryptographic computations pre-master secret is calculated in the same way as in SSL master secret:
PRF( pre_master_secret, master secret, client_random | server_random )
key block:
PRF( master_secret, key expansion, server_random | client_random )
padding before block cipher encryption variable length padding is allowed (max 255 padding bytes)
30
references
M. Bellare, R. Canetti, and H. Krawczyk, \Keying Hash Functions for Message Authentication," Advances in Cryptology|CRYPTO '96 Proceedings, Springer-Verlag, 1996, pp. 1{15.
S. Bellovin, \Problem Areas for the IP Security Protocols", Proceedings of the Sixth USENIX Security Symposium, Usenix Association, 1996, pp. A. Freier, P. Karlton, and P. Kocher, \The SSL Protocol Version 3.0", ftp://ftp.netscape.com/pub/review/ ssl-spec.tar.Z, March 4 1996, Internet Draft, work in progress. [Koc96] P. Kocher, personal communication,
1996.