Secure Sockets Layer and Related Infrastructure

1. Secure Sockets Layer and Related Infrastructure Tom Horton Alfred C. Weaver

2. Outline • Requirements • PKIs, CAs, etc. • Secure Sockets Layer • Overview of SSL and Apache

3. Secure Electronic Commerce • How does the world work? • Identification • Trust • Privacy • Anonymity • Simultaneity • Auditable records • Adjudicators for disputes • Common business and social practices

4. Secure Electronic Commerce • Internet security services required • Authentication - whereby an individual, an organization or computer with which you communicate can prove its identity • Authorization - the ability of the system, once identity is verified, to control access to specific resources • Confidentiality - the ability to maintain the secrecy of the contents of transmission between authorized parties

5. Secure Electronic Commerce • Integrity - the capability of ensuring that transmission arrives at its destination exactly the same as it was sent • Nonrepudiation of Origin - the sender cannot later deny that he sent the message • Nonrepudiation of Receipt - the receiver cannot later deny that he received the message • Timestamp - enables one to verify the time when the message was created, sent, and received

6. Authentication and Certificates • Public key encryption seems sufficient. But… • What if someone else publishes/distributes a public-key that appears to be my key? • Attacker trying to fool others into thinking they’re sending to me securely • But it’s directed to the attacker who can read it

7. Public Key Certificates • Solutions: Use a Public Key Certificate • Bundle a user’s public-key with: • Name, organization, address, validity period, etc. • When a user is given this, the user asks a trusted third party (TTP) to vouch that this is correct. How? • Certificate includes a digital signature from the TTP. Based on TTP’s private key. • Anyone can check to make sure the certificate hasn’t been altered from what was registered with the TTP. • Must use info from the TTP of course

8. Use of Certificates • You need my public-key • I give you (or you get) my certificate • You verify the digital certificate with a TTP that you know and trust • What if I registered with a different TTP? • The TTP has its own key, signed by a “higher level” TTP, and so on (a hierarchy of TTPs) • So there are certificate chains • You accept that the key really belongs to me • Based on your trust of your TTP • Also: certificate revocation • My private key “escapes”. Cancel my certificate! • TTPs provide a revocation list (CRL)

9. PKIs and CAs • Certificate Authority (CA) • Another term for a TTP • Public Key Infrastructure (PKI) • An “arrangement” of interworking parties and technology • Procedures; Clients and servers; CAs; certificates • Note: PGP uses an alternative arrangement: “web of trust” • An enterprise Directory • LDAP • Keep user info of all kinds, and so why not a user’s certificate?

10. CAs in the Real World • Needs software if you want to be a CA: • Microsoft’s Active Directory • Part of Windows Server • OpenCA (and OpenSSL) for Linux • Other solutions • Again, often linked in with LDAP etc. • As done at UVa for wireless, UVaAnywhere, etc. • Companies that do this: • Verisign (58% share of certificates as of 2007) • Comodo (8%) -- free services • GoDaddy (6%) • See Wikipedia on CAs for more info

11. Secure Sockets Layer • SSL runs above TCP/IP and below high-level applications HTTP LDAP IMAP Application Layer Transport Layer Secure Sockets Layer Transport Control Protocol

12. SSL • SSL Server Authentication • SSL-enabled client can use PKC to check that the server’s certificate and public ID are valid, and that the CA is trusted • SSL Client Authentication • SSL-enabled server can check that a client’s certificate and public ID are valid, and that the CA is trusted • Secure connection – client/server transmissions are encrypted, plus tamper detection

13. SSL • SSL exchanges messages that permit: • client to authenticate the server (always) • server to authenticate the client (optional) • client and server negotiation of crypto algorithms that they both support • using PKC to encrypt and exchange shared secrets • establishing an encrypted SSL connection

14. SSL Ciphers Also has a FORTEZZA mode for U.S. government

15. SSL Handshake 1 Client Server Client makes a request and sends: 1. client’s SSL version number 2. cipher settings 3. randomly generated data 4. other info that the server needs to communicate with the client

16. SSL Handshake 2 SSL Handshake 2 Client Server Server sends: 1. server’s SSL version number 2. cipher settings 3. randomly generated data 4. other info that the client needs to communicate with the server 5. server’s certificate 6. requests client’s certificate (if client is requesting a server resource that requires client authentication)

17. SSL Handshake 3 Client Server 1. Uses server info to authenticate the server (to be explained) 2. If server can not be authenticated, client is warned and no connection is established

18. SSL Handshake 4 Client Server 1. Client creates the premaster secret 2. Encrypts it with server’s public key (from server’s certificate) 3. Send encrypted premaster secret to server

19. SSL Handshake 5 Client Server Optional (if server requests client authentication): 1. Client signs data unique to this handshake but known by both client and server 2. Client sends signed data and client’s own certificate to server, along with the encrypted premaster secret

20. SSL Handshake 6 Client Server Optional, if server has requested client authentication: 1. Server attempts to authenticate the client 2. If client can not be authenticated, session terminates 3. If client can be authenticated, server uses its private key to decrypt the premaster secret 4. Performs a series of steps (that the client will also perform) to generate the master secret 5. Note that the master secret was never transmitted; it was computed

21. SSL Handshake 7 Client Server Both client and server use the master secret to generate the symmetric session keys

22. SSL Handshake 8 (future messages will be encrypted with session key) Client Server (client portion of handshake complete) 1. Client tells server that future messages will be encrypted with the session key 2. Client sends encrypted message saying that client portion of handshake is finished

23. SSL Handshake 9 (future messages will be encrypted with session key) Client Server (server portion of handshake is complete) 1. Server informs client that future messages will be encrypted with session key 2. Server sends separate encrypted message saying that server portion of handshake is complete

24. SSL Handshake 10 Client Server 1. SSL handshake now complete 2. SSL session begins 3. Every transmission is encrypted with the session key

25. Digital Signature Sender’s data Hash algorithm (SHA-1, MD5) Hash code (message digest) Timestamp PKC encryption Sender’s private key Validate with sender’s public key Digital signature Timestamp

26. SSL Authentication 1. For server authentication, the client encrypts the premaster secret with the server's public key. 2. Only the server’s private key can decrypt that data. 3. For client authentication, client encrypts some data known to client and server with client’s private key (i.e., creates a digital signature). Public key in client’s certificate will validate the digital signature only if it was encrypted with the client’s private key.

27. Server Authentication Server’s Certificate • Is today’s date within validity • period? Server’s public key Certificate’s validity 2. Is issuing CA a trusted CA? Server’s domain name 3. Does issuing CA’s public key validate the issuer’s digital signature? Issuer’s domain name Issuer’s digital signature 4. Does the domain name in the server’s certificate match the domain name of the server itself?

28. Man-in-the-Middle Attack Application must check the server domain name Client Server Man-in-the-Middle

29. SSL In Action • Again: when you connect to a secure webpage • Server sends its certificate (Step 5 on Handshake 2 slide above) • Client uses this to authenticate server (Step 1 on Handshake Slide 3 above) • Again: if certificate can’t be vouchsafed by a TTP, user is warned and asked if OK to connect • Next two slides: (1) The warning, and (2) Details if you ask to examine the certificate

30. Warning: Untrusted Certificate

31. Warning: Examine Certificate

32. Check it Out! • In Firefox: • Preferences->Advanced->Encryption->View Certificates • Look at your certificates • Look at the authorities listed there

33. SSL and Apache • So consider what must be happening inside Apache for SSL and HTTPS to work • You have to have an SSL module installed • Must make Apache listen on the right port (usually 443 not 80) for HTTPS requests • Make Apache look for docs requested on port 443 in a certain location on the webserver • We need a certificate for this server • Need a public key to be part of that • Need to get it “signed”, i.e. validated by a TTP as a officially trusted certificate • Possible to sign our own for testing, limited use

34. SSL and Apache (2) • Apache can use the OpenSSL software package. OpenSSL has commands to: • Generate a key (a .key file) • Take a key and generate a Certficate Signing Request (.csr file) • Designed to be sent to the TTP/CA for them to verify and create a certificate for you to use • Contents described in next slide • Take a CSR and generate a certificate (a .crt file) • We only do this for temporary or limited use • Clients may not trust this since only we signed it • See images earlier

35. Creating a CSR and Getting it Signed • When creating a CSR in OpenSSL etc., it asks for information • Your organization; web hostname; location; email; etc. • Submit this CSR to a CA with proof-of-identity info • Thawte: SSL Web Server Certificates, $699, 3 yrs • Comodo: Enterprise SSL Certificates, $249, 2 yrs • Identity info required: • Proof of ownership of organization • Proof of ownership of domain name • Proof person requesting certificate is authorized

36. Summary (1) • Certificates • A public key that’s been bundled and“signed”, i.e. certified by a TTP/CA that it really belongs to given identity • Certificate Authorities • A TTP that verifies and signs certificates • You pay to have your certificate signed • Web browsers • Can contact CA’s and retrieve/store info that allows them to verify a certificate supplied by a server

37. Summary (2) • SSL provides these services in a client/server connection (e.g. web) • Client can authenticate that server really is who it claims to be • (Optional) Server can authenticate client • Client and server negotiate settings for secure transactions • Client and server can communicate securely • Establishing SSL connections • Client requires server certificate • Both sides create same symmetric session key (without transmitting it)