1 Copyright 2007 Alfred C. Weaver & T. Horton Secure Sockets Layer and Related Infrastructure Tom Horton Alfred C. Weaver.

1Copyright 2007 Alfred C. Weaver & T. Horton

Secure Sockets Layer and Related Infrastructure

Tom HortonAlfred C. Weaver


Outline

Requirements PKIs, CAs, etc. Secure Sockets Layer

Overview of SSL and Apache


Secure Electronic Commerce

How does the world work? IdentificationTrustPrivacyAnonymitySimultaneityAuditable recordsAdjudicators for disputesCommon business and social practices



Internet security services requiredAuthentication - 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



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


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 securelyBut it’s directed to the attacker who can

read it


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


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)


PKIs and CAs

Certificate Authority (CA)Another term for a TTP

Public Key Infrastructure (PKI)An “arrangement” of interworking parties

and technologyProcedures; Clients and servers; CAs; certificates

Note: PGP uses an alternative arrangement: “web of trust”

An enterprise DirectoryLDAPKeep user info of all kinds, and so why not

a user’s certificate?


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


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


SSL

SSL Server AuthenticationSSL-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 AuthenticationSSL-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


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 supportusing PKC to encrypt and exchange shared

secretsestablishing an encrypted SSL connection


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)

Weak RC4 (40 bits) & MD5 (1012 keys)RC2 (40 bits) & MD5 (1012 keys)

Weakest no encryption, MD5 only

Also has a FORTEZZA mode for U.S. government


SSL Handshake 1

Client Server

Client makes a request and sends:1. client’s SSL version number2. cipher settings3. randomly generated data4. other info that the server needs to communicate with the client


SSL Handshake 2SSL Handshake 2

Client Server

Server sends:1. server’s SSL version number2. cipher settings3. randomly generated data4. other info that the client needs to communicate with the server5. server’s certificate6. requests client’s certificate (if client is requestinga server resource that requires client authentication)


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 warnedand no connection is established


SSL Handshake 4

Client Server

1. Client creates the premaster secret2. Encrypts it with server’s public key (from server’s certificate)3. Send encrypted premaster secret to server


SSL Handshake 5

Client Server

Optional (if server requests client authentication):1. Client signs data unique to this handshake butknown by both client and server2. Client sends signed data and client’s own certificate to server, along with the encrypted premaster secret


SSL Handshake 6

Client Server

Optional, if server has requested client authentication:1. Server attempts to authenticate the client2. If client can not be authenticated, session terminates3. If client can be authenticated, server uses its private key to decrypt the premaster secret4. Performs a series of steps (that the client will also perform) to generate the master secret5. Note that the master secret was never transmitted;it was computed


SSL Handshake 7

Client Server

Both client and server use the master secret to generate the symmetric session keys


SSL Handshake 8

Client Server

1. Client tells server that future messages will be encrypted with the session key2. Client sends encrypted message saying thatclient portion of handshake is finished

(future messages will be encrypted with session key)

(client portion of handshake complete)


SSL Handshake 9

Client Server

1. Server informs client that future messages will be encrypted with session key2. Server sends separate encrypted messagesaying that server portion of handshake is complete

(future messages will be encrypted with session key)

(server portion of handshake is complete)


SSL Handshake 10

Client Server

1. SSL handshake now complete2. SSL session begins3. Every transmission is encrypted with the session key


Digital Signature

Sender’s data

Hash algorithm (SHA-1, MD5)

Hash code (message digest)

PKC encryption Sender’s private key

Digital signature Validate with sender’s public keyTimestamp

Timestamp


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 candecrypt that data.

3. For client authentication, client encrypts somedata 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.


Server Authentication

Server’s Certificate

Server’s public key

Certificate’s validity

Server’s domain name

Issuer’s domain name

Issuer’s digital signature

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?

4. Does the domain name in the server’s certificate match the domain name of the server itself?


Man-in-the-Middle Attack

Client Server

Man-in-the-Middle

Application must check the server domain name


SSL In Action

Again: when you connect to a secure webpageServer 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 connectNext two slides: (1) The warning, and (2)

Details if you ask to examine the certificate


Warning: Untrusted Certificate


Warning: Examine Certificate


Check it Out!

In Firefox:Preferences->Advanced->Encryption-

>View CertificatesLook at your certificatesLook at the authorities listed there


SSL and Apache

So consider what must be happening inside Apache for SSL and HTTPS to workYou have to have an SSL module installedMust make Apache listen on the right port

(usually 443 not 80) for HTTPS requestsMake Apache look for docs requested on port

443 in a certain location on the webserverWe need a certificate for this server

Need a public key to be part of thatNeed to get it “signed”, i.e. validated by a TTP as a

officially trusted certificate Possible to sign our own for testing, limited use


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 useContents described in next slide

Take a CSR and generate a certificate (a .crt file)We only do this for temporary or limited useClients may not trust this since only we signed it

See images earlier


Creating a CSR and Getting it Signed

When creating a CSR in OpenSSL etc., it asks for informationYour organization; web hostname; location;

email; etc. Submit this CSR to a CA with proof-of-

identity infoThawte: SSL Web Server Certificates, $699, 3

yrsComodo: Enterprise SSL Certificates, $249, 2

yrs Identity info required:

Proof of ownership of organizationProof of ownership of domain nameProof person requesting certificate is authorized


Summary (1)

CertificatesA public key that’s been bundled

and“signed”, i.e. certified by a TTP/CA that it really belongs to given identity

Certificate AuthoritiesA TTP that verifies and signs certificatesYou pay to have your certificate signed

Web browsersCan contact CA’s and retrieve/store info

that allows them to verify a certificate supplied by a server


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 clientClient and server negotiate settings for

secure transactionsClient and server can communicate

securely Establishing SSL connections

Client requires server certificateBoth sides create same symmetric session

key (without transmitting it)

1 Copyright 2007 Alfred C. Weaver & T. Horton Secure Sockets Layer and Related Infrastructure Tom Horton Alfred C. Weaver.

Documents