Certificates and network security

(1)

Certificates and network security

Tuomas Aura

CSE-C3400 Information security

(2)

Outline

 X.509 certificates and PKI

 Network security basics: threats and goals

 Secure socket layer

2 Note: the SSL part of this lecture partly

overlaps with the now-terminated

T-110.2100 course

(3)

(4)

Key distribution problem

 Public keys make key distribution easier than it is for

secret keys, but it is still not trivial:

How to find out

someone’s authentic public key?

 Solution:

an authority or trusted third party issues

certificates that bind public keys to names

Certificate = Sign

_CA

(Name, PK, validity_period)

– Certificate is a message signed by an issuer, containing the

subject’s name and public key

 Questions:

– Who could the authority be?

– How does everyone know the public key of the authority?

– What is the difference between “authority” and “trusted

third party”?

(5)

X.509 PKI

 ITU-T/ISO X.509 standard, IETF RFC3280

 Certification authority (CA)

issues certificates

– CA can delegate its authority to another CA

→ CA hierarchy

 X.509 certificates are

identity certificates

i.e. bind

a principal name to a public key

 Users, computers and services are

end entities

 CAs and end entities are

principals

– Each principal has a key pair

– Key pair = public and private signature key

(RSA keys can also be used for encryption)

(6)

6

Certificate: Data: Version: 3 (0x2) Serial Number: d1:32:5b:f8:d7:09:02:37:50:57:93:55:84:c9:b2:4c Signature Algorithm: sha1WithRSAEncryption

Issuer: C=FI, O=Sonera, CN=Sonera Class2 CA

Validity

Not Before: Nov 19 12:02:09 2009 GMT Not After : Nov 19 12:02:09 2010 GMT

Subject: C=FI, O=TKK, OU=Computing Centre, CN=wwwlogin.tkk.fi/[email protected]

Subject Public Key Info:

Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit)

Modulus (1024 bit): 00:c7:94:9b:49:29:6f:2d:6d:32:70:97:73:39:1e: 04:20:89:ea:05:89:02:01:1a:d7:2d:ad:86:f6:99: 69:7e:13:19:f2:09:d0:e6:05:ca:93:13:a7:e2:7b: 3b:b6:68:e7:49:c7:3b:53:fd:b5:c1:bc:64:65:6c: 4d:89:37:ab:b5:6b:2a:38:2b:45:82:f6:99:97:21: 57:fc:ac:26:9b:04:3b:ad:13:26:8e:85:ff:44:ba: 4f:1e:27:cc:f2:fd:c1:47:c4:de:b6:d2:6c:2c:48: 6e:a3:cc:cd:0c:ed:75:4b:a2:c7:f0:c2:e1:9b:e9: d3:0c:1b:90:35:c8:ee:e7:01 Exponent: 65537 (0x10001) X509v3 extensions:

X509v3 Authority Key Identifier: keyid:4A:A0:AA:58:84:D3:5E:3C X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.271.2.3.1.1.2 X509v3 CRL Distribution Points: URI:ldap://194.252.124.241:389/cn=Sonera%20Class2%20CA,o=Sonera,c=FI?certificaterevocationlist;binary X509v3 Key Usage:

Digital Signature, Key Encipherment X509v3 Extended Key Usage:

TLS Web Server Authentication, TLS Web Client Authentication

X509v3 Subject Key Identifier:

86:4C:D0:93:1A:A4:C4:7C:94:A0:28:04:F3:DA:17:12:18:FF:23:D7

Signature Algorithm: sha1WithRSAEncryption

50:c3:94:71:b3:d2:1d:7f:be:71:5e:fe:ff:ec:09:50:68:f0: 27:54:cd:e8:f2:17:90:3e:ea:6c:e2:81:12:bf:e2:73:72:9e: 02:d3:b4:03:88:2a:6a:b1:00:ca:70:24:1b:3f:da:d6:30:46:

X.509 certificate

example

Save certificate into a file and pretty print:

% openssl x509 -in cert.pem -noout -text

Subject name

Subject public key

Issuer info

Validity dates

Key usage

CA signature…

(7)

Certificate: Data:

Version: 3 (0x2) Serial Number:

d1:32:5b:f8:d7:09:02:37:50:57:93:55:84:c9:b2:4c Signature Algorithm: sha1WithRSAEncryption

Validity

86:4C:D0:93:1A:A4:C4:7C:94:A0:28:04:F3:DA:17:12:18:FF:23:D7

X.509 certificate

example

Save certificate into a file and pretty print:

% openssl x509 -in cert.pem -noout -text

Subject name

Subject public key

Issuer info

Validity dates

Key usage

Revocation list URL

Subject: C=FI, O=TKK, OU=Computing Centre,

(8)

8

Certificate: Data: Version: 3 (0x2) Serial Number: d1:32:5b:f8:d7:09:02:37:50:57:93:55:84:c9:b2:4c Signature Algorithm: sha1WithRSAEncryption

Validity

86:4C:D0:93:1A:A4:C4:7C:94:A0:28:04:F3:DA:17:12:18:FF:23:D7

Signature Algorithm: sha1WithRSAEncryption

50:c3:94:71:b3:d2:1d:7f:be:71:5e:fe:ff:ec:09:50:68:f0: 27:54:cd:e8:f2:17:90:3e:ea:6c:e2:81:12:bf:e2:73:72:9e: 02:d3:b4:03:88:2a:6a:b1:00:ca:70:24:1b:3f:da:d6:30:46:

X.509 certificate

example

Save certificate into a file and pretty print:

% openssl x509 -in cert.pem -noout -text

Subject name

Subject public key

Issuer info

Validity dates

Key usage

CA signature…

Revocation list URL

X509v3 Key Usage:

Digital Signature, Key Encipherment

X509v3 Extended Key Usage:

TLS Web Server Authentication,

TLS Web Client Authentication

(9)

X.509 certificate fields (1)

Mandatory fields:

 Version

 Serial number

— together with Issuer, uniquely

identifiers the certificate

 Signature algorithm

— for the signature on this

certificate; usually sha1RSA; includes any parameters

 Issuer

— name (e.g. CN = Microsoft Corp Enterprise CA

2)

 Valid from

— usually the time when issued

 Valid to

— expiry time

 Subject

—

distinguished name

of the subject

(10)

X.509 certificate fields (2)

Common

extension fields

:

 Key usage

— bit field indicating usages for the subject key

(digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment,

keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly)

 Subject alternative name — email address, DNS name, IP address, etc.

 Issuer alternative name

 Basic constraints — (1) is the subject a CA or an end entity, (2) maximum

length of delegation to sub-CAs after the subject

 Name constraints — limit the authority of the CA

 Certificate policies

— list of OIDs to indicate policies for the certificate

 Policy constraints — certificate policies

 Extended key usage — list of OIDs for new usages, e.g. server

authentication, client authentication, code signing, email protection, EFS

key, etc.

 CRL distribution point — where to get the CRL for this certificate, and who

issues CRLs

 Authority info access

— where to find information about the CA and its

policies

(11)

Certificate chain

 Typical certificate chain:

1. Root CA

self-signed certificate

2. Root CA issues a

CA certificate

to a sub-CA

3. Sub-CA issues

end-entity certificate

to a user, computer or

web server

 Chain typically has 0..2 sub-CAs (Why?)

 Self-signed certificate

is an X.509 certificate issued by CA to

itself;

not really a certificate, just a way to store and

transport the CA public key

(12)

CA hierarchy

 One

root CA

 Each CA can delegate its

authority to

sub-CA

s

 All end-entities trust all CAs to

be honest and competent

 Original X.500 idea:

– One global hierarchy

 Reality:

– One CA or CA hierarchy per

organization

(e.g. Windows

domain hierarchy)

– Competing

commercial root

CAs without real hierarchy

(e.g. Verisign, TeliaSonera)

– Cross-certification between

hierarchies rare

12

Contoso Root CA PKCA

Bob,

PK

B

Charlie,

PK

C Contoso Sales CA PKSales Contoso Sales Asia CA, PKUS Contoso Sales Euro CA PKEuro Contoso Dev CA PKDev

CA certificate

End-entity

certificate

Alice,

PK

A

David,

PK

D

Root CA

Sub-CA

End entity

Here arrows depict

the certificates i.e.

signed messages

(13)

Certificate path

 End-entities (e.g. Bob)

know the root CA

– Root CA’s PK stored as a

self-signed certificate

 To verify Alice’s

signature:

– Bob needs the entire

certificate path from root

CA to Alice

(self-signed

root certificate + 2 CA

certificates +

end-entity certificate)

– The root CA must be in

Bob’s list of

trusted root

CA

s

Contoso Root CA PKCA

Alice,

PK

A

Bob,

PK

B

Charlie,

PK

C Contoso Sales CA PKSales Contoso Sales Asia CA, PKUS Contoso Sales Euro CA PKEuro Contoso Dev CA PKDev

David,

PK

D

CA certificate

End-entity

certificate

Self-certificate

(14)

14 Certificate revocation

 When might CA need to revoke certificates?

– If the conditions for issuing the certificate no longer hold

– If originally issued in error

– If the subject key has been compromised

– Upgrading cryptographic algorithms

 Certificate revocation list (CRL)

= signed list of certificate

serial numbers

 In X.509, only certificates are revoked, not keys

– No mechanism for revoking the root key

– Different from PGP

 Who issues the CRL? How to find it?

– By default, CRL is signed by the CA that issued the certificate

– CRL distribution point and issuer can be specified in each

(15)

X.509 CRL fields

 Signature algorithm

 Issuer

— name

 This update

— time

 Next update

— time

For each revoked certificate:

– Serial number

– Revocation date

— (how would you use this

information?)

– Extensions

— reason code etc.

(16)

16 Setting up a PKI

 Potential root CAs:

– Commercial CA such as

Verisign

usually charges per

certificate

– Windows root domain controller

can act as an

organizational CA

– Anyone can set up their own CA using Windows Server or

OpenSSL

 The real costs:

– Distributing the root key

(self-signed certificate)

– Certificate enrolment

— need to issue certificates for each

user, computer, mobile device etc.

– Administering a secure CA and CRL server

 Cannot really ask users outside your own organization

(17)

Name and identity

 With certificates, it is possible to authenticate the

name

or

identifier

of an entity

– e.g. person, computer, web server, email address

 What is the

right name

anyway?

– wwwlogin.tkk.fi, security.tkk.fi, leakybox.cse.tkk.fi

– George Bush, George W. Bush, George H. W. Bush

– [email protected], [email protected], [email protected], [email protected],

[email protected]

 Who decides

who owns the name

?

– [email protected], Ville Valo on Facebook

 Identity proofing

= verification of the subject identity before

certification

– Email to registered domain owner

– Extended validation certificates

– Electronic ID cards and mobile certificates in Finland

 Does knowing the name imply

trust

?

– Should I order a second-hand camera from buycam.fi?

– Should they post the camera to Tuomas Aura?

(18)

18

C e rt if ic at e: D a ta : V e rs io n : 3 (0 x2 ) Se ri a l N um b er : 1 f: d b :f 9 :f 0 :b c: 21 :c b: 66 :1 9: b 5: b a: 6b :2 9: fa :c 8: 97 Si gn a tu re A lg o ri th m : s ha 1W it h RSA En cr yp ti o n Is su e r: C =U S, O =V e ri Si gn , I nc ., O U =V e ri Si gn T ru st N et w o rk , O U =T e rm s o f u se a t h tt p s: // w w w .ve ri si gn .c om /r pa (c )0 6, C N =V e ri Si gn C la ss 3 E xt en d e d V a li d a ti o n SS L SG C C A V a li d it y N o t Be fo re : J u n 2 0 0: 00 :0 0 2 01 0 G M T N o t A ft e r : J u n 4 2 3: 5 9: 59 2 01 1 G M T Su b je ct : 1 .3 .6 .1 .4 .1 .3 11 .6 0. 2. 1. 3= FI /2 .5 .4 .1 5 =V 1. 0, C la us e 5 .(b )/ se ri al N um be r= 1 68 02 3 5-8 , C =F I/ p o st a lC od e= 0 01 00 , S T= U U SI M A A , L =H el si n ki /s tr ee tA d d re ss =A le ks an te ri n ka tu 3 6B, O =N o rd e a Ba n k Fi n la nd A b p , O U =E le ct ro n ic Ba n ki n g, C N =s o lo 1. no rd e a. fi Su b je ct P u b lic K ey In fo : P u b li c K ey A lg o ri th m : r sa En cr yp ti o n RSA P u b li c K e y: (2 04 8 b it ) M o d u lu s (2 0 48 b it ): 0 0 :e 6 :e 2: 5c :a e: a5 :d 4: b c: 2 6: 1a :c c: f3 :d 4: e b: 82 : 9 d :b 9 :4 3: 68 :5 4: 09 :5 7: 60 :2 2: 20 :a e :a 3: ea :3 2: 8d : 1 d :3 0 :2 8 :d 5: 7 3: 5d :9 7: 45 :4 9: b c: 3a :3 f: b e: db :d a: c4 :3 b :5 5 :2 b :b 0: 9 c: 44 :0 5: b 7: ed :8 5: 87 :e b :6 8: 6b : 4 7 :e 7 :f e: 7b :b e: 75 :0 b: ae :e 1: 78 :1 8: 69 :1 0: fe :d 8: 2 0 :6 4 :e e: 08 :f 3: 5d :0 8 :0 d: 0 5: c4 :a 6: ca :f e :c 5 :2 4: 3 a :1 0 :6 1: e9 :4 5: 98 :e 1: 11 :f9 :a 5: 5 f: 80 :c b: 9 f: 86 : 0 a :1 f: d e: f3 :a 8: 61 :9 4: c1 :6 c: c9 :4 8 :3 4: 47 :5 b :e e: 1 4 :3 5 :7 a: e1 :0 e: f2 :8 1: 5a :8 f: dc :8 9: e 6: ba :8 8: fb : 4 1 :4 f: f0 :2 6 :d 0 :5 6: a7 :0 4: 1b :f 7: 2a :6 a: d1 :f 0: 97 : c6 :6 3 :5 4: 0 5: 2a :0 f: 9 3: a0 :8 5: ad :5 d :9 c: 26 :a 6: 57 : 5 b :d 4 :b 2: 41 :0 e: a0 :fe :d 0: ab :5 3: a5 :6 4: c8 :b 1: b e: 2 4 :a c: 45 :e c: 54 :5 5: 5c :e 3: ac :5 d: 9 4: 1f :b b :8 2: 32 : cd :f 7 :5 4 :8 0: 37 :0 1: a7 :2 8: d c: b 2: 2d :c e: f6 :9 4: cd : 6 7 :4 e :e d :5 b: d e: 33 :b d :c a: 3 6: cc :5 e: b 3: 0f :a 7: 58 : ce :7 5 :8 1: 6 9: 26 :e 2: 29 :a 6 :2 5: 99 :0 f: 60 :6 8: 45 :f a: a 5 :6 b :a b :fd :e 0: 6e :9 2: be :f 1: 8a :8 c: f3 :d a: 6 f: ce : 2 b :5 3 Ex p o n e n t: 6 55 37 (0 x1 0 00 1 ) X 5 0 9 v3 e xt en si on s: X 5 0 9 v3 Ba si c C o ns tr ai n ts : C A :F A LS E X 5 0 9 v3 S ub je ct K ey Id en ti fie r: D D :D A :E D :3 5 :8 B: A A :A 9: 15 :B 2 :1 1: 06 :C 6 :7 C: 5 A :8 D :2 F: C B: ED :0 8 :F 1 X 5 0 9 v3 K e y U sa ge : D ig it a l S ig na tu re , K ey En ci p h er m e nt X 5 0 9 v3 C er ti fic at e P ol ic ie s: P o li cy: 2 .1 6 .8 40 .1 .1 1 37 3 3. 1. 7. 23 .6 C P S: h tt p s: // w w w .ve ri si gn .c o m /r p a X 5 0 9 v3 C RL D is tr ib ut io n P oi nt s: U RI :h tt p :/ /E V In tl -c rl .ve ri si gn .c o m /E V In tl 20 0 6. cr l X 5 0 9 v3 E xt e nd ed K ey U sa ge : TL S W e b S e rve r A u th en ti ca ti on , T LS W e b C lie nt A u th en ti ca ti on , N et sc a pe S er ve r G at e d C ryp to X 5 0 9 v3 A u th o ri ty K ey Id en ti fi er : ke yi d :4 E: 4 3: C 8: 1D :7 6: EF :3 7 :5 3: 7A :4 F: F2 :5 8: 6F :9 4: F3 :3 8: E2 :D 5: BD :D F A u th o ri ty In fo rm at io n A cc es s: O C SP -U RI :h tt p :/ /E V In tl -o cs p .ve ri si gn .c o m C A Is su e rs -U RI :h tt p :/ /E V In tl -a ia .ve ri si gn .c o m /E V In tl 20 06 .c e r 1 .3 .6 .1 .5 .5 .7 .1 .1 2 : 0 `. ^. \0 Z0 X 0 V ..i m a ge /g if 0! 0. 0. ..+ .. ... .Kk .(. .. ..R8 .) .K ..! ..0 & .$ h tt p: // lo go .ve ri si gn .c om /vs lo go 1. gi f Si gn a tu re A lg or it h m : s h a1 W it h R SA En cr yp ti o n 2 d :d 3 :9 c: 45 :b d :d 4 :4 9: 0e :5 2: 9e :5 4: 98 :8 f: 36 :e 1: 00 :6 c: 38 : 5 8 :1 a :4 7: f2 :7 7: d c: 15 :4 5: 85 :d a: 5d :3 f: 6 0: 03 :9 a: ab :7 f: 6a : f8 :5 e :3 d :3 2: 41 :9 3: 80 :b 9: d 7: b b: 6 a: e0 :7 9 :4 0: f7 :7 7: 2c :a f: 1 9 :3 a :1 6: 5e :1 4: 83 :4 a: 99 :f 2 :f 1: 9 0: ab :e d: b 3: 31 :0 3: 50 :a 5: 6 2 :0 3 :3 7: b 7: 73 :7 7: 59 :1 d: 6 e: f8 :c 5: 20 :1 7: 61 :9 a: 9a :3 f: 9 3: a c: fa :9 3: ea :5 2: 29 :4 5: 78 :5 0: 56 :9 4: 79 :a 0 :a 6: 94 :a 5: 93 :f c: 1 f: 0 4 :2 f: d b: cf :9 c: f3 :c 8: 0b :2 e: 44 :a 5: ce :6 f: 94 :2 7: b c: 0e : fc :9 e :8 1: 0 3: 15 :9 d: b 6: 5f :7 5: 67 :4 4: 12 :4 c: d 8: 5e :3 e: 8f :2 1: 0 b :d 9 :c b: f1 :5 9: ab :b 0: 42 :1 9: a9 :9 9 :d 5 :a b: 0e :b 7 :4 4: 06 :c 0: e 8 :1 5 :b 4 :a 8: 54 :0 6: 61 :0 9: 1a :3 a :7 1: 3a :8 a: 17 :d a: ac :a c: c5 : cf :8 3 :2 c: 8 5: d d: 51 :a e: 92 :d e: d f: af :5 a: a1 :3 8 :6 3: d c: ee :b d : 1 5 :0 f: c9 :b b :6 f: ee :4 5: 92 :4 0: b b: 08 :5 1: 3a :6 7: 10 :a 6: c7 :8 7: 7 f: a b :d a :a c: 0a :0 c: 38 :a 5: a2 :3 5 :6 c: 5 9: 5a :6 5 :d 9 :9 1: 35 :c 1: a 3 :0 9 :f6 :4 a: c8 :6 4 :7 6: 86 :a 4: f2 :3 a: e5 :1 2 :5 9: 9f :d 9 :0 3: ed : cb :0 2 :d 2: 9d

(19)

(20)

Network-security threat model

 Traditional network-security model:

trusted end nodes,

unreliable network

 End nodes send messages to the network and receive

messages from it; the network may deliver, delete, modify

and spoof messages

 Metaphors: unreliable postman, bulletin board, dust bin

20 Network

=

Attacker

Alice

Bob

(21)

Network security threats

 Traditional threats:

– Sniffing

= attacker listens to network traffic

– Spoofing

= attacker sends unauthentic messages

– Data modification (

man in the middle

) = attacker

intercepts and modifies data

 Corresponding security requirements:

– Data

confidentiality

– Data-origin

authentication

and data

integrity

– Q: Can there be integrity without authentication or

authentication without integrity?

 Other treats: denial of service, server

compromise, worms etc.

(22)

SECURE SOCKET LAYER

(23)

Secure web site (https)

HTTPS connections are

encrypted and

authenticated to

prevent sniffing and

spoofing

(24)

SSL/TLS in the protocol stack

 SSL implements

cryptographic encryption

and authentication for

TCP connections

 SSL offers a secure socket

API, similar to the TCP

socket API, to applications

 TLS

is the standardized

version of SSL

– similar but not quite

compatible

24 Applications: HTTP

Transport layer: TCP

Network layer: IP

Data link layer

(25)

SSL/TLS protocol

 SSL provides a secure connection over the insecure network

 Two stages:

– Handshake i.e. authenticated key exchange

creates a shared

session key between the browser and the server

– Session protocol

protects the confidentiality and integrity of the

session with symmetric encryption, message authentication

codes, and the session key

 Handshake may use digital signatures or RSA encryption

 Basic idea of the

RSA-based handshake

protocol:

– The server sends its certificate to the client, which thus learns

the server name and public RSA key

– The browse generates random bytes, encrypts them with the

servers RSA key, and sends to the server

 Usually only the server authenticated

!

(26)

TLS handshake

26 Client

Server

ClientHello --->

ServerHello

Certificate

*

ServerKeyExchange*

CertificateRequest*

<--- ServerHelloDone

Certificate*

ClientKeyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished --->

[ChangeCipherSpec]

<--- Finished

Application Data <---> A pplication Data

Certificate =

Sign

_CA

(server name, server PK, validity_period)

(27)

Trust chain

 In the handshake, browser receives a certificate chain

from the server

 Browser checks that the chain start with a (self-signed)

certificate that is in its

trusted CA list

 Browser checks the certificate chain:

– Each certificate is signed with the subject key of the

previous one

– All but the last certificate are CA certificates

– Some other details, e.g. CRL, key usage, constraints

 If the certificate chain is valid, the last certificate binds

together the host name and public key of the server

– Public key is used for server authentication in the SSL

handshake

(28)

Certificate checking details

1. Browser has a

list of self-signed certificates for trusted root CAs

2. In the SSL handshake, the browser receives a certificate chain from the server

3. Browser checks that the root certificate in the received chain is in the trusted list

4. Browser checks the validity of the certificate chain

A. Issuer of each certificate matches the subject of the previous certificate

B. Signature of each certificate is verified with the subject public key of the previous certificate

C. All certificates are CA certificates, except for the last one, which is an end-entity certificate

D. Browser downloads and checks the CRL for every certificate that specifies one, unless cached

5. Extended key usage field of the end-entity certificate must specify SLL server

authentication:

check that the certificate has been issued for this purpose

6. Any

constraints

in the certificates must also be checked

7. Browser checks that the

host name in the address bar matches the subject name

of

the end-entity certificate

8. Browser uses the subject key from the end-entity certificate in the authenticated

key exchange with the server (SSL handshake)

9. The created session key is used to encrypt and authenticate data between the

browser and server (SSL session)

 The web page shown in the browser comes from the server

whose name is in the address bar

(29)

Certificate of

the web server

webmail3.tkk.fi

Issuer is

Sonera Class2 CA

Thanks to the trust

chain, the I know that

this server really is

webmail3.tkk.fi

How do I know that

the webmail server

should have the

name webmail3?

Sonera root CA was

not pre-installed in

the browser; so

I downloaded the

self-signed

certificate from the

web (insecurely) and

added it to the list of

trusted root CAs

(30)

30 SSL vulnerabilities in practice

 Recently, SSL has been found to be vulnerable to many kinds of

attacks

 Implementation bugs in certificate validation

have been found (and

fixed) regularly

– Earlier in desktop browsers, recently in mobile apps

 Heartbleed

: bug in the OpenSSL library enables theft of private keys

from server

– More general question about flaws in security-critical software, even in

widely reviewed open-source code

 Hash collisions

in the outdated MD5 function have been used to

create malicious certificate requests: CA signs one certificate and

the signature is used for another

 Incompetent CAs

have issued fraudulent certificates

 Application software cannot always know which name there should

be in the client or server certificate, and some don’t care

(31)

SSL/TLS session protocol

 After the handshake, data is protected with

the session protocol

 Data confidentiality is protected with

symmetric encryption

, e.g. AES in CBC mode

 Data integrity is protected with

message

authentication codes (MAC)

 Secret

session keys

are created from the

encrypted key material (random bytes) sent by

the client to the server

(32)

Exercises

 Set up your own CA with OpenSSL (or a commercial CA implementation if

you have access to one) and try to use it for protecting web access; what

were the difficult steps?

 What are extended validation certificates and how do they improve

security?

 Find several web and user certificates and compare the names and

certification paths on them

 Why do almost all web sites have certificate chains with two CAs and not

just one?

 What information does the signature on the root certificate convey?

 Why is the front page of a web site often insecure (HTTP) even if the

password entry and/or later data access are secure (HTTPS)? What

security problems can this cause?

 What actions are required from the user when logging into a secure bank

web site?

 What is the Heartbleed vulnerability and how has it been exploited?

 How should a browser creator select the default root CAs? See e.g.

–

http://nakedsecurity.sophos.com/2011/03/24/fraudulent-certificates-issued-by-comodo-is-it-time-to-rethink-who-we-trust/