Secure Sockets Layer and
Related Infrastructure
Tom Horton
Alfred C. Weaver
Copyright 2007 Alfred C. Weaver & T. Horton
1
Outline
Requirements
PKIs, CAs, etc.
Secure Sockets Layer
 Overview of SSL and Apache
Copyright 2007 Alfred C. Weaver & T. Horton
2
Secure Electronic Commerce
How does the world work?
 Identification
 Trust
 Privacy
 Anonymity
 Simultaneity
 Auditable records
 Adjudicators for disputes
 Common business and social practices
Copyright 2007 Alfred C. Weaver & T. Horton
3
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
Copyright 2007 Alfred C. Weaver & T. Horton
4
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
Copyright 2007 Alfred C. Weaver & T. Horton
5
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
Copyright 2007 Alfred C. Weaver & T. Horton
6
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
Copyright 2007 Alfred C. Weaver & T. Horton
7
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)
Copyright 2007 Alfred C. Weaver & T. Horton
8
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?
Copyright 2007 Alfred C. Weaver & T. Horton
9
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
Copyright 2007 Alfred C. Weaver & T. Horton
10
Secure Sockets Layer
SSL runs above TCP/IP and below highlevel applications
HTTP
LDAP
IMAP
Application Layer
Transport Layer
Secure Sockets Layer
Transport Control Protocol
Copyright 2007 Alfred C. Weaver & T. Horton
11
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
Copyright 2007 Alfred C. Weaver & T. Horton
12
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
Copyright 2007 Alfred C. Weaver & T. Horton
13
SSL Ciphers
Strongest
Triple-DES (168 bits) & SHA-1 (1050
keys)
Strong
RC4 (128 bits) and MD5 (1038 keys)
RC2 (128 bits) & MD5 (1038 keys)
DES (56 bits) & SHA-1 (1016 keys)
RC4 (40 bits) & MD5 (1012 keys)
RC2 (40 bits) & MD5 (1012 keys)
Weak
Weakest
no encryption, MD5 only
Also has a FORTEZZA mode for U.S. government
Copyright 2007 Alfred C. Weaver & T. Horton
14
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
Copyright 2007 Alfred C. Weaver & T. Horton
15
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)
Copyright 2007 Alfred C. Weaver & T. Horton
16
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
Copyright 2007 Alfred C. Weaver & T. Horton
17
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
Copyright 2007 Alfred C. Weaver & T. Horton
18
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
Copyright 2007 Alfred C. Weaver & T. Horton
19
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
Copyright 2007 Alfred C. Weaver & T. Horton
20
SSL Handshake 7
Client
Server
Both client and server use the master secret
to generate the symmetric session keys
Copyright 2007 Alfred C. Weaver & T. Horton
21
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
Copyright 2007 Alfred C. Weaver & T. Horton
22
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
Copyright 2007 Alfred C. Weaver & T. Horton
23
SSL Handshake 10
Client
Server
1. SSL handshake now complete
2. SSL session begins
3. Every transmission is encrypted with
the session key
Copyright 2007 Alfred C. Weaver & T. Horton
24
Digital Signature
Sender’s data
Hash algorithm (SHA-1, MD5)
Hash code (message digest)
Timestamp
PKC encryption
Sender’s private key
Digital signature
Validate with sender’s
public key
Timestamp
Copyright 2007 Alfred C. Weaver & T. Horton
25
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.
Copyright 2007 Alfred C. Weaver & T. Horton
26
Server Authentication
Server’s Certificate
Server’s public key
Certificate’s validity
Server’s domain name
Issuer’s domain name
1. Is today’s date within validity
period?
2. Is issuing CA a trusted CA?
3. Does issuing CA’s public key
validate the issuer’s digital
signature?
Issuer’s digital signature
4. Does the domain name in the
server’s certificate match the
domain name of the server itself?
Copyright 2007 Alfred C. Weaver & T. Horton
27
Man-in-the-Middle Attack
Application must check the server domain name
Client
Server
Man-in-the-Middle
Copyright 2007 Alfred C. Weaver & T. Horton
28
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
Copyright 2007 Alfred C. Weaver & T. Horton
29
Warning: Untrusted Certificate
Copyright 2007 Alfred C. Weaver & T. Horton
30
Warning: Examine Certificate
Copyright 2007 Alfred C. Weaver & T. Horton
31
Check it Out!
In Firefox:
 Preferences->Advanced->Encryption->View
Certificates
 Look at your certificates
 Look at the authorities listed there
Copyright 2007 Alfred C. Weaver & T. Horton
32
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
Copyright 2007 Alfred C. Weaver & T. Horton
33
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
Copyright 2007 Alfred C. Weaver & T. Horton
34
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-ofidentity 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
Copyright 2007 Alfred C. Weaver & T. Horton
35
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
Copyright 2007 Alfred C. Weaver & T. Horton
36
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)
Copyright 2007 Alfred C. Weaver & T. Horton
37