WEBVTT 1 00:00:00.000 --> 00:00:01.440 In this lesson, 2 00:00:01.440 --> 00:00:04.530 we will learn about certificate validation. 3 00:00:04.530 --> 00:00:08.280 Certificate validation with the public key infrastructure, 4 00:00:08.280 --> 00:00:10.650 or PKI architecture, 5 00:00:10.650 --> 00:00:14.670 ensures that a digital certificate remains trustworthy, 6 00:00:14.670 --> 00:00:18.120 is unexpired and has not been revoked. 7 00:00:18.120 --> 00:00:20.670 Certificate validation concepts 8 00:00:20.670 --> 00:00:25.020 include online certificate status protocol stapling, 9 00:00:25.020 --> 00:00:27.360 the certificate revocation list, 10 00:00:27.360 --> 00:00:29.310 and certificate pinning. 11 00:00:29.310 --> 00:00:31.830 Online certificate status protocol 12 00:00:31.830 --> 00:00:36.450 or OCSP stapling is a method of validation 13 00:00:36.450 --> 00:00:40.680 that requires a server to provide a digitally signed proof 14 00:00:40.680 --> 00:00:44.640 of its certificate's validity directly to the client. 15 00:00:44.640 --> 00:00:47.100 Next, the certificate revocation list 16 00:00:47.100 --> 00:00:51.780 or CRL is a list maintained by a certificate authority 17 00:00:51.780 --> 00:00:54.630 that contains the serial numbers of certificates 18 00:00:54.630 --> 00:00:58.590 that have been revoked before their expiration dates. 19 00:00:58.590 --> 00:01:02.430 Finally, certificate pinning involves storing a known 20 00:01:02.430 --> 00:01:06.810 valid certificate or public key in an application. 21 00:01:06.810 --> 00:01:07.980 Let's learn more 22 00:01:07.980 --> 00:01:11.730 about online certificate status protocol stapling, 23 00:01:11.730 --> 00:01:14.040 the certificate revocation list 24 00:01:14.040 --> 00:01:15.720 and certificate pinning. 25 00:01:15.720 --> 00:01:20.100 First, we have the online certificate status protocol, 26 00:01:20.100 --> 00:01:24.360 or OCSP and OCSP stapling. 27 00:01:24.360 --> 00:01:27.090 The online certificate status protocol 28 00:01:27.090 --> 00:01:30.450 or OCSP is a protocol used 29 00:01:30.450 --> 00:01:33.030 to verify the revocation status 30 00:01:33.030 --> 00:01:36.660 of a digital certificate using its serial number. 31 00:01:36.660 --> 00:01:39.750 Unlike checking the certificate revocation list 32 00:01:39.750 --> 00:01:42.900 or CRL, which is a comprehensive list 33 00:01:42.900 --> 00:01:44.700 of revoked certificates, 34 00:01:44.700 --> 00:01:47.910 OCSP efficiently checks the status 35 00:01:47.910 --> 00:01:51.360 of a specific certificate without needing to download 36 00:01:51.360 --> 00:01:54.750 and parse an entire revocation list. 37 00:01:54.750 --> 00:01:56.940 Instead, the server responsible 38 00:01:56.940 --> 00:01:59.130 for providing this status update 39 00:01:59.130 --> 00:02:01.710 is called the OCSP responder, 40 00:02:01.710 --> 00:02:04.950 and it replies with whether the certificate is valid, 41 00:02:04.950 --> 00:02:07.020 revoked, or unknown. 42 00:02:07.020 --> 00:02:10.830 To demonstrate this, imagine you are visiting a website 43 00:02:10.830 --> 00:02:13.140 and your browser needs to ensure 44 00:02:13.140 --> 00:02:16.890 that the website's security certificate is still valid 45 00:02:16.890 --> 00:02:18.780 and it hasn't been revoked. 46 00:02:18.780 --> 00:02:22.830 Traditionally, it would check a certificate revocation list, 47 00:02:22.830 --> 00:02:25.500 which is essentially a long deny list 48 00:02:25.500 --> 00:02:26.970 of invalid certificates. 49 00:02:26.970 --> 00:02:29.280 However, this approach can be slow 50 00:02:29.280 --> 00:02:31.260 because your browser has to download 51 00:02:31.260 --> 00:02:35.010 and then search through a potentially very large list. 52 00:02:35.010 --> 00:02:39.960 Instead, with OCSP, your browser sends a quick request 53 00:02:39.960 --> 00:02:43.830 to the OCSP responder asking specifically 54 00:02:43.830 --> 00:02:47.070 about the certificate for the website you're visiting. 55 00:02:47.070 --> 00:02:51.150 The OCSP responder checks the certificate status 56 00:02:51.150 --> 00:02:54.150 and responds with whether it is valid, revoked, 57 00:02:54.150 --> 00:02:58.860 or unknown, making the verification process much faster 58 00:02:58.860 --> 00:03:00.030 and more efficient. 59 00:03:00.030 --> 00:03:04.050 Next, OCSP stapling enhances this process 60 00:03:04.050 --> 00:03:07.920 by allowing the server rather than the client browser 61 00:03:07.920 --> 00:03:10.590 to handle the certificate status checks. 62 00:03:10.590 --> 00:03:14.250 Day to day, the web server periodically retrieves 63 00:03:14.250 --> 00:03:19.230 a digitally signed response from the OCSP responder 64 00:03:19.230 --> 00:03:21.390 about the certificate status, 65 00:03:21.390 --> 00:03:23.310 and includes this response 66 00:03:23.310 --> 00:03:27.840 during the secure socket layer transport layer security, 67 00:03:27.840 --> 00:03:30.840 or SSLTLS handshake. 68 00:03:30.840 --> 00:03:34.260 This stapled response improves the security 69 00:03:34.260 --> 00:03:37.410 and speed of the connection setup 70 00:03:37.410 --> 00:03:39.690 by eliminating the need for the client 71 00:03:39.690 --> 00:03:42.630 to make a separate OCSP request. 72 00:03:42.630 --> 00:03:43.860 To demonstrate this, 73 00:03:43.860 --> 00:03:46.650 imagine you're visiting the same website, 74 00:03:46.650 --> 00:03:50.730 but this time with OCSP stapling in use. 75 00:03:50.730 --> 00:03:54.780 Instead of your browser making a separate OCSP request 76 00:03:54.780 --> 00:03:56.970 to the OCSP responder, 77 00:03:56.970 --> 00:03:59.040 the web server hosting the site 78 00:03:59.040 --> 00:04:01.770 takes care of this step in advance. 79 00:04:01.770 --> 00:04:04.830 The server periodically fetches a status update 80 00:04:04.830 --> 00:04:09.120 about its own certificate from the OCSP responder 81 00:04:09.120 --> 00:04:11.820 and obtains a digitally signed response 82 00:04:11.820 --> 00:04:14.160 confirming the certificate's validity. 83 00:04:14.160 --> 00:04:16.140 When you connect to the website, 84 00:04:16.140 --> 00:04:19.740 the server staples this assigned response 85 00:04:19.740 --> 00:04:22.500 to the SSLTLS handshake, 86 00:04:22.500 --> 00:04:25.350 essentially presenting the proof of validity 87 00:04:25.350 --> 00:04:27.810 directly to your browser. 88 00:04:27.810 --> 00:04:30.780 This process means your browser does not need 89 00:04:30.780 --> 00:04:35.070 to make a separate request to verify the certificate status, 90 00:04:35.070 --> 00:04:37.950 speeding up the secure connection setup, 91 00:04:37.950 --> 00:04:39.750 and enhancing privacy, 92 00:04:39.750 --> 00:04:42.840 since the browser isn't making separate calls 93 00:04:42.840 --> 00:04:45.750 that could reveal which sites you are visiting. 94 00:04:45.750 --> 00:04:50.497 Next, HTTP Strict Transport Security or HSTS 95 00:04:51.360 --> 00:04:56.220 is another mechanism used to secure web traffic. 96 00:04:56.220 --> 00:05:00.810 HSTS configures the web server to instruct browsers 97 00:05:00.810 --> 00:05:05.810 to connect only using the secure HTTPS protocol, never HTTP. 98 00:05:09.030 --> 00:05:11.610 When a browser initially connects, 99 00:05:11.610 --> 00:05:16.110 the server responds with a strict transport security header, 100 00:05:16.110 --> 00:05:20.790 specifying that the browser should only use HTTPS 101 00:05:20.790 --> 00:05:23.610 for all future connections to that site 102 00:05:23.610 --> 00:05:25.200 for a set period of time. 103 00:05:25.200 --> 00:05:28.110 This protects against attackers who may attempt 104 00:05:28.110 --> 00:05:31.650 to exploit insecure HTTP connections 105 00:05:31.650 --> 00:05:33.750 through on-path attacks. 106 00:05:33.750 --> 00:05:37.650 Although some websites use a 301 redirect 107 00:05:37.650 --> 00:05:42.210 to transition from HTTP to HTTPS, 108 00:05:42.210 --> 00:05:45.720 this approach is less secure than HSTS. 109 00:05:45.720 --> 00:05:48.810 This is because a 301 redirect 110 00:05:48.810 --> 00:05:52.170 allows an initial HTTP connection, 111 00:05:52.170 --> 00:05:56.550 whereas HSTS directly enforces secure connections 112 00:05:56.550 --> 00:06:00.870 without intermediate steps, providing stronger protection. 113 00:06:00.870 --> 00:06:05.670 Additionally, browsers can maintain an HSTS preload list 114 00:06:05.670 --> 00:06:09.930 of domains that should always be accessed securely, 115 00:06:09.930 --> 00:06:13.320 ensuring these sites are only ever reached out to 116 00:06:13.320 --> 00:06:17.220 via HTTPS enhancing overall security. 117 00:06:17.220 --> 00:06:22.170 Second, we have the certificate revocation list or CRL. 118 00:06:22.170 --> 00:06:26.160 When a digital certificate is issued in the PKI system, 119 00:06:26.160 --> 00:06:28.140 it comes with an expiration date, 120 00:06:28.140 --> 00:06:30.030 just like a driver's license, 121 00:06:30.030 --> 00:06:32.970 which is valid for a certain number of years. 122 00:06:32.970 --> 00:06:36.360 Once your driver's license reaches its expiration date, 123 00:06:36.360 --> 00:06:39.360 it's automatically considered invalid. 124 00:06:39.360 --> 00:06:42.630 But what happens if you get too many speeding tickets 125 00:06:42.630 --> 00:06:43.770 before that date? 126 00:06:43.770 --> 00:06:46.980 Your license could be suspended or revoked, 127 00:06:46.980 --> 00:06:50.010 even though the physical license in your wallet 128 00:06:50.010 --> 00:06:53.280 still shows it's valid until 2029 129 00:06:53.280 --> 00:06:55.740 or whatever the expiration date is. 130 00:06:55.740 --> 00:06:56.730 To handle this, 131 00:06:56.730 --> 00:06:59.490 police don't just check the expiration date 132 00:06:59.490 --> 00:07:01.770 on your license when they pull you over, 133 00:07:01.770 --> 00:07:06.300 instead, they check your license against a central database 134 00:07:06.300 --> 00:07:09.120 to see if it has been suspended or revoked. 135 00:07:09.120 --> 00:07:11.250 If it has, you could be arrested 136 00:07:11.250 --> 00:07:13.080 and your car might be towed, 137 00:07:13.080 --> 00:07:16.380 because you are driving without a valid license. 138 00:07:16.380 --> 00:07:19.290 Digital certificates work in a similar way. 139 00:07:19.290 --> 00:07:21.450 They have a set expiration date, 140 00:07:21.450 --> 00:07:24.270 but they can also be revoked at any time 141 00:07:24.270 --> 00:07:27.240 before that date by the certificate authority 142 00:07:27.240 --> 00:07:30.750 that issued the certificate for various reasons. 143 00:07:30.750 --> 00:07:33.870 For example, if you work for Dion Training 144 00:07:33.870 --> 00:07:36.690 and we issue you a digital certificate, 145 00:07:36.690 --> 00:07:39.480 but then you leave the company for another job, 146 00:07:39.480 --> 00:07:41.400 we would revoke your certificate 147 00:07:41.400 --> 00:07:44.700 because you no longer need access to our systems. 148 00:07:44.700 --> 00:07:48.180 Or if you digital certificate was compromised, 149 00:07:48.180 --> 00:07:52.110 we would also revoke it, but we would issue you a new one. 150 00:07:52.110 --> 00:07:54.990 Common reasons for certificate revocation 151 00:07:54.990 --> 00:07:57.510 include cessation of operation 152 00:07:57.510 --> 00:07:59.730 or the business stops operating, 153 00:07:59.730 --> 00:08:02.130 a certificate authority compromise, 154 00:08:02.130 --> 00:08:05.640 a key compromise, certificates being superseded, 155 00:08:05.640 --> 00:08:07.320 or other reasons. 156 00:08:07.320 --> 00:08:11.790 Also, sometimes instead of fully revoking a certificate, 157 00:08:11.790 --> 00:08:14.280 it could be temporarily suspended. 158 00:08:14.280 --> 00:08:18.840 For example, suppose we issued smart cards to each employee 159 00:08:18.840 --> 00:08:22.620 with their digital certificates embedded into the card. 160 00:08:22.620 --> 00:08:25.470 If an employee reported that their card was lost, 161 00:08:25.470 --> 00:08:28.350 but thought it might just be misplaced at home, 162 00:08:28.350 --> 00:08:32.100 we could suspend their card for let's say 72 hours 163 00:08:32.100 --> 00:08:33.810 to give them time to find it. 164 00:08:33.810 --> 00:08:36.060 During the suspension, the card 165 00:08:36.060 --> 00:08:38.430 and its certificates won't work. 166 00:08:38.430 --> 00:08:41.280 If they find the card within 72 hours, 167 00:08:41.280 --> 00:08:43.740 we would reinstate the certificates 168 00:08:43.740 --> 00:08:46.380 and they could continue working with that card. 169 00:08:46.380 --> 00:08:49.110 If not, we will revoke certificates 170 00:08:49.110 --> 00:08:51.990 and issue new ones along with a new card. 171 00:08:51.990 --> 00:08:54.840 So the key difference between suspension 172 00:08:54.840 --> 00:08:58.890 and revocation is that suspension can be reversed, 173 00:08:58.890 --> 00:09:00.900 but revocation cannot. 174 00:09:00.900 --> 00:09:02.700 To manage revocation 175 00:09:02.700 --> 00:09:05.190 and keep track of certificate statuses, 176 00:09:05.190 --> 00:09:08.940 certificate authorities use a certificate revocation list 177 00:09:08.940 --> 00:09:10.410 or a CRL. 178 00:09:10.410 --> 00:09:12.780 The CRL is an online list 179 00:09:12.780 --> 00:09:14.970 that shows all certificates revoked 180 00:09:14.970 --> 00:09:17.010 by that certificate authority, 181 00:09:17.010 --> 00:09:19.950 whether it was due to compromise, suspension, 182 00:09:19.950 --> 00:09:21.630 or some other reason. 183 00:09:21.630 --> 00:09:24.750 This list is distributed to all subordinate 184 00:09:24.750 --> 00:09:26.940 and intermediate certificate authorities 185 00:09:26.940 --> 00:09:28.470 within the hierarchy. 186 00:09:28.470 --> 00:09:32.100 When your device tries to validate a digital certificate, 187 00:09:32.100 --> 00:09:35.610 it first checks the expiration date of the certificate. 188 00:09:35.610 --> 00:09:37.530 If the certificate has expired, 189 00:09:37.530 --> 00:09:39.930 it's automatically considered invalid. 190 00:09:39.930 --> 00:09:41.760 If it hasn't expired, 191 00:09:41.760 --> 00:09:45.030 the system can check the certificate revocation list 192 00:09:45.030 --> 00:09:47.670 to ensure the certificate is still valid 193 00:09:47.670 --> 00:09:51.270 and hasn't been revoked, assuming of course 194 00:09:51.270 --> 00:09:54.390 that the certificate revocation list is up to date. 195 00:09:54.390 --> 00:09:58.020 Third and last, we have certificate pinning. 196 00:09:58.020 --> 00:10:01.410 Certificate pinning is a security technique used 197 00:10:01.410 --> 00:10:05.700 to protect applications and users from on-path attacks. 198 00:10:05.700 --> 00:10:07.650 Certificate pinning involves 199 00:10:07.650 --> 00:10:10.350 storing a known valid certificate 200 00:10:10.350 --> 00:10:14.070 or public key directly within an application. 201 00:10:14.070 --> 00:10:17.280 When the application tries to establish a connection 202 00:10:17.280 --> 00:10:20.790 with a server, it compares the stored certificate 203 00:10:20.790 --> 00:10:24.630 or key with the one presented by the server. 204 00:10:24.630 --> 00:10:27.930 If they match, the connection is considered safe 205 00:10:27.930 --> 00:10:30.060 and the certificate is accepted. 206 00:10:30.060 --> 00:10:33.030 The key idea behind certificate pinning 207 00:10:33.030 --> 00:10:37.050 is to bypass the usual certificate authority hierarchy 208 00:10:37.050 --> 00:10:39.360 and the standard chain of trust. 209 00:10:39.360 --> 00:10:42.660 Normally, when you connect to a secure website, 210 00:10:42.660 --> 00:10:46.680 your browser or application relies on a chain of trust 211 00:10:46.680 --> 00:10:49.050 involving the server certificate, 212 00:10:49.050 --> 00:10:50.610 intermediate certificates 213 00:10:50.610 --> 00:10:53.070 and a root certificate authorities. 214 00:10:53.070 --> 00:10:54.390 Without pinning, 215 00:10:54.390 --> 00:10:58.620 an attacker could exploit this chain by inserting a fake 216 00:10:58.620 --> 00:11:03.210 but technically valid certificate into the connection 217 00:11:03.210 --> 00:11:07.050 using it on-path or man-in-the-middle attack. 218 00:11:07.050 --> 00:11:11.340 This means that even though your connection appears secure, 219 00:11:11.340 --> 00:11:13.380 an attacker could be listening in 220 00:11:13.380 --> 00:11:16.710 or manipulating the data that's being exchanged. 221 00:11:16.710 --> 00:11:21.480 For example, imagine your connecting to your bank's website. 222 00:11:21.480 --> 00:11:25.290 Normally, your browser checks their website's certificates 223 00:11:25.290 --> 00:11:28.770 against trusted authorities to ensure it's genuine. 224 00:11:28.770 --> 00:11:33.180 However, if an attacker manages to insert a fake certificate 225 00:11:33.180 --> 00:11:37.410 that looks valid, your browser might unknowingly accept it, 226 00:11:37.410 --> 00:11:38.700 allowing the attacker 227 00:11:38.700 --> 00:11:42.720 to intercept your sensitive information like usernames, 228 00:11:42.720 --> 00:11:45.480 passwords, or credit card details. 229 00:11:45.480 --> 00:11:49.140 Certificate pinning was one of the first methods developed 230 00:11:49.140 --> 00:11:50.640 to prevent this 231 00:11:50.640 --> 00:11:54.270 by hard-coding the correct certificate public key 232 00:11:54.270 --> 00:11:56.700 into the application itself. 233 00:11:56.700 --> 00:12:00.900 Next, HTTP Public Key Pinning or HPKP, 234 00:12:02.070 --> 00:12:05.250 is a form of digital certificate pinning 235 00:12:05.250 --> 00:12:06.900 that was used by websites 236 00:12:06.900 --> 00:12:10.170 to tell browsers which public key should be trusted. 237 00:12:10.170 --> 00:12:14.010 The website, which send a list of its trusted public keys 238 00:12:14.010 --> 00:12:17.610 as part of the HTTP header to the client. 239 00:12:17.610 --> 00:12:20.970 If the client's browser then connected to the website 240 00:12:20.970 --> 00:12:22.650 and the presented public key 241 00:12:22.650 --> 00:12:25.080 didn't match any of the stored ones, 242 00:12:25.080 --> 00:12:28.380 the browser would know the connection was compromised 243 00:12:28.380 --> 00:12:30.120 and would alert the user. 244 00:12:30.120 --> 00:12:32.730 This added an extra layer of security 245 00:12:32.730 --> 00:12:36.240 by ensuring that only specific trusted keys 246 00:12:36.240 --> 00:12:39.690 could be used even if a certificate authority 247 00:12:39.690 --> 00:12:42.780 was tricked into issuing a fraudulent certificate. 248 00:12:42.780 --> 00:12:46.380 However, over time, attackers discovered ways 249 00:12:46.380 --> 00:12:48.300 to exploit vulnerabilities 250 00:12:48.300 --> 00:12:51.840 in the HTTP public key pinning process, 251 00:12:51.840 --> 00:12:54.390 and it became clear that this technique 252 00:12:54.390 --> 00:12:58.290 could cause significant problems if misconfigured, 253 00:12:58.290 --> 00:13:02.400 like permanently blocking users from accessing a website 254 00:13:02.400 --> 00:13:06.390 if the pinned keys were lost or rotated incorrectly. 255 00:13:06.390 --> 00:13:10.140 So HPKP has been deprecated. 256 00:13:10.140 --> 00:13:13.920 So remember, certificate validation 257 00:13:13.920 --> 00:13:16.920 in the public key infrastructure system 258 00:13:16.920 --> 00:13:20.760 ensures that digital certificates remain trustworthy, 259 00:13:20.760 --> 00:13:23.700 unexpired, and not revoked. 260 00:13:23.700 --> 00:13:26.100 This involves several techniques 261 00:13:26.100 --> 00:13:29.670 including online certificate, status protocol, 262 00:13:29.670 --> 00:13:32.370 or OCSP stapling, 263 00:13:32.370 --> 00:13:35.880 certificate revocation lists, or CRLs, 264 00:13:35.880 --> 00:13:37.800 and certificate pinning. 265 00:13:37.800 --> 00:13:40.890 OCSP stapling allows a server 266 00:13:40.890 --> 00:13:43.740 to provide a digitally signed proof 267 00:13:43.740 --> 00:13:47.580 of its certificate status directly to the client, 268 00:13:47.580 --> 00:13:52.050 making the validation process faster and more secure. 269 00:13:52.050 --> 00:13:55.740 Next, the certificate revocation list is maintained 270 00:13:55.740 --> 00:13:59.370 by certificate authorities to keep track of certificates 271 00:13:59.370 --> 00:14:00.450 that have been revoked 272 00:14:00.450 --> 00:14:02.790 before their expiration dates, 273 00:14:02.790 --> 00:14:05.730 ensuring that devices can identify 274 00:14:05.730 --> 00:14:08.910 and reject invalid certificates. 275 00:14:08.910 --> 00:14:12.690 And finally, certificate pinning enhances security 276 00:14:12.690 --> 00:14:15.510 by storing a known valid certificate 277 00:14:15.510 --> 00:14:19.320 or public key within an application. 278 00:14:19.320 --> 00:14:22.590 So, directly comparing it to the one presented 279 00:14:22.590 --> 00:14:27.590 during a connection, a browser can prevent on-path attacks.