The aim of authentication is to establish the identity of a party.
There are two components required for TLS authentication:
- A key
- A certificate
The bouncer analogy
The certificate is an authentication factor offered to the browser and is somewhat analogous to offering a card to a bouncer. First we establish that they have a card (certificate) and that the face/photo match (checking the key fingerprint). The bouncer is not going to accept a card that simply has your name and photo, it has to be a drivers license or passport as these are issued by a trusted authority.
TLS authentication works like this. We first check that the key's fingerprint matches, we then need to check that the subject (normally the domain name) matches the certificate
We then need to establish whether or not the certificate provided is trustworthy. This is the authentication of the certificate itself by checking that it has been issued by a certificate authority.
TLS authentication is commonly used by clients to authenticate servers, however, it can also be used by servers to authenticate clients. In any case, it either case, you offer a certificate as proof of your key.
A certificate is composed chiefly of three things.
- A public key
- A "fingerprint" of the private key.
- Metadata such as to whom the certificate is issued and for what it is valid for.
Looking at a certificate
openssl s_client -showcerts -connect etherarp.net:443 -servername etherarp.net 2>/dev/null <<<''| openssl x509 -text --noout Certificate: Data: Version: 3 (0x2) Serial Number: 06:d3:52:76:29:af:b0:d9:77:6d:58:67:bc:52:17:cc Signature Algorithm: sha256WithRSAEncryption Issuer: C = FR, ST = Paris, L = Paris, O = Gandi, CN = Gandi Standard SSL CA 2 Validity Not Before: Mar 9 00:00:00 2017 GMT Not After : Mar 9 23:59:59 2019 GMT Subject: OU = Domain Control Validated, OU = Gandi Standard SSL, CN = etherarp.net Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c4:1a:1b:b6:34:0a:5c:fb:4a:36:e2:31:11:fa: 31:58:b5:93:f8:f8:1f:f1:d6:4a:2f:73:f8:6c:fb: 9f:c7:fc:a7:33:3f:4f:24:35:61:05:fa:51:ba:86: e9:8b:e5:81:9c:a7:42:6e:ce:1a:ed:0b:ae:d0:e1: 75:ce:9a:c7:05:2a:15:ca:ff:ac:c0:19:19:86:b8: 7e:36:7d:78:e8:32:c3:69:87:24:0f:09:db:e8:64: f5:58:ce:32:8f:93:51:4c:f0:1a:89:2e:6b:c3:ad: 55:0a:ba:b9:b2:b4:62:0d:d1:ef:dd:ab:ae:5d:d5: 17:dd:dd:e1:5f:be:1f:80:ee:6d:88:9a:50:98:39: e6:e0:f0:8a:3c:30:7d:37:43:93:6a:11:19:af:ac: ce:66:f3:ce:0c:0f:02:cd:54:72:75:9d:f6:fd:e2: 45:b9:d6:fe:56:1d:75:76:8d:57:f0:d3:24:c0:6a: 8d:7e:ae:4f:c0:ec:dc:ee:88:1a:27:3e:a7:91:fd: eb:33:88:f0:6d:06:cd:f3:4e:50:b4:eb:85:ce:04: 0f:b6:fb:44:3b:0d:6a:80:2f:5e:34:48:4f:46:24: c9:3f:1c:dd:62:5a:a4:bb:3f:41:20:f9:b3:4a:83: 8f:59:c9:ef:00:e6:a7:d5:2c:f8:2b:8e:11:4d:40: e2:f9 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:B3:90:A7:D8:C9:AF:4E:CD:61:3C:9F:7C:AD:5D:7F:41:FD:69:30:EA X509v3 Subject Key Identifier: 48:CD:29:0A:DF:9C:89:6A:3E:5B:F3:2B:69:1E:29:4C:E0:C7:C2:32 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Certificate Policies: Policy: 220.127.116.11.4.1.6418.104.22.168.26 CPS: https://cps.usertrust.com Policy: 22.214.171.124.2.1 X509v3 CRL Distribution Points: Full Name: URI:http://crl.usertrust.com/GandiStandardSSLCA2.crl Authority Information Access: CA Issuers - URI:http://crt.usertrust.com/GandiStandardSSLCA2.crt OCSP - URI:http://ocsp.usertrust.com X509v3 Subject Alternative Name: DNS:etherarp.net, DNS:www.etherarp.net Signature Algorithm: sha256WithRSAEncryption 0b:88:04:e7:29:27:c6:3b:0d:de:43:1f:69:3d:62:73:cf:4e: 4c:3b:72:9c:2b:54:db:e1:00:98:9b:8e:12:05:62:e9:08:ef: 24:c4:ac:80:ae:31:42:a9:fb:7c:39:bf:f0:07:d4:71:0d:24: 61:3b:5d:4c:2a:ba:96:67:3b:f9:bd:c3:74:51:38:c2:e3:78: fc:da:cf:d9:50:6c:05:10:32:0c:28:6f:4f:a4:42:ac:6d:33: 39:63:5d:68:6f:bc:75:09:d2:08:7e:9c:de:3a:e9:bc:52:9c: 50:95:38:7c:ec:e1:bc:e1:e2:19:22:de:4d:c6:3e:8f:d4:cd: 95:67:9c:7a:f6:2d:9b:52:d2:ac:82:54:4e:1c:9a:3e:f1:24: 70:60:df:3b:3c:a6:3c:e1:07:41:23:ea:10:af:30:91:be:1e: 74:50:73:87:83:4f:81:b6:2b:89:26:71:f9:68:ec:6a:7a:e1: 61:88:75:3a:56:58:66:75:08:ef:54:66:77:7a:41:cf:60:25: ec:98:05:67:49:33:84:06:35:a9:56:82:eb:45:bf:a1:87:73: f5:55:cb:09:e9:94:3c:cd:7f:49:92:a4:35:ec:b5:08:07:14: 30:bf:b8:0b:6b:cf:3f:75:e0:32:66:e1:c8:87:76:16:25:da: b6:7f:e5:25
The core function of certificates is to prove an association between a public key and its corresponding private key.
The difference between certificates and public keys
Public keys on their own have virtually no security because we have no way of proving the identity of the receiving party x
If you send a message with a public key, only the owner of the corresponding private key can decrypt the message. But we need a way to authenticate this key so we can be sure we are sending the message to the owner of the private key.
So a certificate contains the private key and also a hash of the private key. Before a browser begins any communication, the server must provide a hash (usually
SHA256) of the private key, and the browser checks it matches the cert.
Now if you've ever set up a encrypted web server before, you know it's actually the server who provides the certifciate. So isn't this the same problem with using public keys?
Yes. There are two ways to authenticate the fingerprint.
- The browser actually has a copy of the certificate itself (this is the case when using self signed certs)
- Certificate authorities
The browser has a pre-bundled set of certificates that are trusted by default. We can also manually insert certificates on our own.
There are billions of web servers and we can't possibly include all of them in every web browser. So certificate authorities are needed.
These pre-bundled authority certificates are issued by "trusted" organizations, or more accurately, by trusted private keys.
With self-signed server certificates, it proves the fingerprint of the server itself. Unless you issued it yourself, and have a copy of the cert in your browser, you're taking it at their own word that they are trustworthy (have a valid key).
While server certificates validate the intgerity of public key with respect to a private key, what certificate authorities do is a bit different.
They validate whether or not the private key is actually reputable by seeing if they can establish that the requester actually has a legitimate relationship with the subject (generally domain name).
You send them a request containing a hash of your certificate (CSR) claiming to represent the CN
They will send you a token.Having this token is sufficient to establish that you were the one who sent the request (therefore possessing the server private key )
If they can receive the token by visiting the common name (via http or email) then that proves you actually have control of the domain. and if they are happy with it, they add the fingerprint of their own private key and therefore making your certifcate trustworhy to browsers.
Running your own certificate authority?
For certain internal operations, it's okay and sometimes even better to run your own CA.
However, browsers don't like this.
With my own CA, I can issue a very dubious certificate for Paypal.com. In fact, I may have even gotten it into their browser's "trustworthy" bundle making it a sketchy but technically "valid" certificate for Paypal.com.
Ideally, the browser will present a scary warning before allowing the connection to go through because it doesn't know who issued the cert. However, if I have gotten my CA cert into their browser, it will only present the warning once. (We will see how to combat this with CAA records and Public key stapling)