Certificates and network security Tuomas Aura CSE-C3400 Information security Aalto University, autumn 2014
Outline X.509 certificates and PKI Network security basics: threats and goals Secure socket layer Note: the SSL part of this lecture partly overlaps with the now-terminated T-110.2100 course 2
X.509 CERTIFICATES 3
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? 4
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) ISO notation for a certificate: CA<<Alice>> 5
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/emailAddress=webmaster@tkk.fi 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: Issuer info Validity dates 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: 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: X.509 certificate example Save certificate into a file and pretty print: % openssl x509 -in cert.pem -noout -text Subject name Subject public key Revocation list URL CA signature 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/emailAddress=webmaster@tkk.fi 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: Issuer info Validity dates Subject: C=FI, O=TKK, OU=Computing Centre, CN=wwwlogin.tkk.fi/emailAddress=webmaster@tkk.fi Subject name 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: 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: X.509 certificate example Save certificate into a file and pretty print: % openssl x509 -in cert.pem -noout -text Subject public key Revocation list URL 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 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/emailAddress=webmaster@tkk.fi Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Issuer info Validity dates 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: 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: 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: X.509 certificate example Save certificate into a file and pretty print: % openssl x509 -in cert.pem -noout -text Subject name Subject public key X509v3 Key Usage: 6e:a3:cc:cd:0c:ed:75:4b:a2:c7:f0:c2:e1:9b:e9: Digital d3:0c:1b:90:35:c8:ee:e7:01 Signature, Key Encipherment Exponent: 65537 (0x10001) X509v3 extensions: Extended Key Usage: X509v3 Authority Key Identifier: keyid:4a:a0:aa:58:84:d3:5e:3c TLS Web Server Authentication, X509v3 TLS Certificate Web Policies: Client Authentication Revocation list URL CA signature 8
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 Public key public key of the subject 9
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 10
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 11
CA hierarchy One root CA Each CA can delegate its authority to sub-cas 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 Contoso Sales Asia CA, PK US Bob, PK B Contoso Sales CA PK Sales David, PK D Contoso Root CA PK CA Contoso Sales Euro CA PK Euro Alice, PK A CA certificate End-entity certificate Root CA Contoso Dev CA PK Dev Charlie, PK C Sub-CA End entity Here arrows depict the certificates i.e. signed messages 12
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 CAs Contoso Sales Asia CA, PK US Bob, PK B Contoso Sales CA PK Sales David, PK D Contoso Root CA PK CA Contoso Sales Euro CA PK Euro Alice, PK A Self-certificate CA certificate End-entity certificate Contoso Dev CA PK Dev Charlie, PK C 13
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 certificate 14
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. Signature 15
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 to install your root key to their browsers (why?) 16
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 tuomas.aura@aalto.fi, aura@cs.hut.fi, aaura@hut.fi, taura@cse.tkk.fi, aura@cse.tkk.fi Who decides who owns the name? xyz@aalto.fi, 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? 17
Certificate: Data: Version: 3 (0x2) Serial Number: 1f:db:f9:f0:bc:21:cb:66:19:b5:ba:6b:29:fa:c8:97 Signature Algorithm: sha1withrsaencryption Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extende d Validation SSL SGC CA Validity Not Before: Jun 2 00:00:00 2010 GMT Not After : Jun 4 23:59:59 2011 GMT Subject: 1.3.6.1.4.1.311.60.2.1.3=FI/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=1680235-8, C=FI/postalCode=00100, ST=UUSIMAA, L=Helsinki/stree taddress=aleksanterinkatu 36B, O=Nordea Bank Finland Abp, OU=Electronic Banking, CN=solo1.nordea.fi Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:e6:e2:5c:ae:a5:d4:bc:26:1a:cc:f3:d4:eb:82: 9d:b9:43:68:54:09:57:60:22:20:ae:a3:ea:32:8d: 1d:30:28:d5:73:5d:97:45:49:bc:3a:3f:be:db:da: c4:3b:55:2b:b0:9c:44:05:b7:ed:85:87:eb:68:6b: 47:e7:fe:7b:be:75:0b:ae:e1:78:18:69:10:fe:d8: 20:64:ee:08:f3:5d:08:0d:05:c4:a6:ca:fe:c5:24: 3a:10:61:e9:45:98:e1:11:f9:a5:5f:80:cb:9f:86: 0a:1f:de:f3:a8:61:94:c1:6c:c9:48:34:47:5b:ee: 14:35:7a:e1:0e:f2:81:5a:8f:dc:89:e6:ba:88:fb: 41:4f:f0:26:d0:56:a7:04:1b:f7:2a:6a:d1:f0:97: c6:63:54:05:2a:0f:93:a0:85:ad:5d:9c:26:a6:57: 5b:d4:b2:41:0e:a0:fe:d0:ab:53:a5:64:c8:b1:be: 24:ac:45:ec:54:55:5c:e3:ac:5d:94:1f:bb:82:32: cd:f7:54:80:37:01:a7:28:dc:b2:2d:ce:f6:94:cd: 67:4e:ed:5b:de:33:bd:ca:36:cc:5e:b3:0f:a7:58: ce:75:81:69:26:e2:29:a6:25:99:0f:60:68:45:fa: a5:6b:ab:fd:e0:6e:92:be:f1:8a:8c:f3:da:6f:ce: 2b:53 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: DD:DA:ED:35:8B:AA:A9:15:B2:11:06:C6:7C:5A:8D:2F:CB:ED:08:F1 X509v3 Key Usage: Digital Signature, Key Encipherment X509v3 Certificate Policies: Policy: 2.16.840.1.113733.1.7.23.6 CPS: https://www.verisign.com/rpa X509v3 CRL Distribution Points: URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, Netscape Server Gated Crypto X509v3 Authority Key Identifier: keyid:4e:43:c8:1d:76:ef:37:53:7a:4f:f2:58:6f:94:f3:38:e2:d5:bd:df Authority Information Access: OCSP - URI:http://EVIntl-ocsp.verisign.com CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer 1.3.6.1.5.5.7.1.12: 0`.^.\0Z0X0V..image/gif0!0.0...+...Kk.(...R8.).K..!..0&.$http://logo.verisign.com/vslogo1.gif Signature Algorithm: sha1withrsaencryption 2d:d3:9c:45:bd:d4:49:0e:52:9e:54:98:8f:36:e1:00:6c:38: 58:1a:47:f2:77:dc:15:45:85:da:5d:3f:60:03:9a:ab:7f:6a: f8:5e:3d:32:41:93:80:b9:d7:bb:6a:e0:79:40:f7:77:2c:af: 19:3a:16:5e:14:83:4a:99:f2:f1:90:ab:ed:b3:31:03:50:a5: 62:03:37:b7:73:77:59:1d:6e:f8:c5:20:17:61:9a:9a:3f:93: ac:fa:93:ea:52:29:45:78:50:56:94:79:a0:a6:94:a5:93:fc: 1f:04:2f:db:cf:9c:f3:c8:0b:2e:44:a5:ce:6f:94:27:bc:0e: fc:9e:81:03:15:9d:b6:5f:75:67:44:12:4c:d8:5e:3e:8f:21: 0b:d9:cb:f1:59:ab:b0:42:19:a9:99:d5:ab:0e:b7:44:06:c0: e8:15:b4:a8:54:06:61:09:1a:3a:71:3a:8a:17:da:ac:ac:c5: cf:83:2c:85:dd:51:ae:92:de:df:af:5a:a1:38:63:dc:ee:bd: 15:0f:c9:bb:6f:ee:45:92:40:bb:08:51:3a:67:10:a6:c7:87: 7f:ab:da:ac:0a:0c:38:a5:a2:35:6c:59:5a:65:d9:91:35:c1: a3:09:f6:4a:c8:64:76:86:a4:f2:3a:e5:12:59:9f:d9:03:ed: cb:02:d2:9d Example: extended validation certificate 18
NETWORK SECURITY BASICS 19
Network-security threat model Alice Network = Attacker Bob 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 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. 21
SECURE SOCKET LAYER 22
Secure web site (https) HTTPS connections are encrypted and authenticated to prevent sniffing and spoofing 23
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 Applications: HTTP Socket API Secure socket API Transport layer: TCP Network layer: IP Data link layer 24
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!! 25
TLS handshake Client Server ClientHello --------> Certificate = Sign CA (server name, server PK, validity_period) Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone E PK (secret session key material) [ChangeCipherSpec] <-------- Finished Application Data <-------> A pplication Data 26
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 Host name shown to user in the browser address bar 27
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 28
What does SSL achieve? Issuer is Sonera Class2 CA Thanks to the trust chain, the I know that this server really is webmail3.tkk.fi Certificate of the web server webmail3.tkk.fi 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 How do I know that the webmail server should have the name webmail3? 29
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 30
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 31
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/ https://bugzilla.mozilla.org/show_bug.cgi?id=647959 32
Related reading Stallings and Brown: Computer security, principles and practice, 2008, chapters 21-22 other Stallings books have similar sections Stallings, Network security essentials, 4th ed. chapters 4.4 4.5, 5 Dieter Gollmann: Computer Security, 2nd ed., chapter 12-13; 3rd ed. chapters 15.5, 16 17 Matt Bishop: Introduction to computer security, chapter 13 Online: Survival guides - SSL/TLS and X.509 (SSL) Certificates, http://www.zytrax.com/tech/survival/ssl.html 33