WEBVTT 00:04.810 --> 00:10.920 In the last lesson of the previous performance section of this course we generated some self scientific 00:10.920 --> 00:14.670 ads and sure how to an able SSL connections. 00:14.910 --> 00:21.680 That said our implementation was just about as basic as it can get and yielded nothing more than a default. 00:21.680 --> 00:28.740 H T T P S connection in this lesson then the first of the new security section will continue with that 00:28.770 --> 00:36.510 SSL configuration by discussing a few key SSL specific configuration directives and see how to optimize 00:36.570 --> 00:40.110 our HTP s connections before we begin. 00:40.110 --> 00:46.980 However I'll just remove this index stock patch p value from the index directive allowing us to access 00:46.980 --> 00:49.650 that demo site from the root you are. 00:50.130 --> 00:51.590 And to keep things simple. 00:51.600 --> 00:59.100 I'll also remove these Bush directives keeping the htb to connection however save this. 00:59.910 --> 01:07.350 Reload the engine configuration and check this is working as expected in the browser by removing this 01:07.380 --> 01:09.320 index dot htl request. 01:09.330 --> 01:10.220 You are right. 01:10.530 --> 01:11.770 And that works. 01:11.850 --> 01:15.360 We get the demo side loading from the root you are L.. 01:15.360 --> 01:23.190 Step 1 then when dealing with an H T T P S request is providing some or other fallback or handler for 01:23.220 --> 01:31.690 insecure HTP connections at the moment we have H T T P S specified in the request but should I remove 01:31.690 --> 01:32.330 this. 01:32.400 --> 01:33.520 Making this request. 01:33.540 --> 01:34.860 H T T P. 01:36.040 --> 01:37.780 We get a connection error. 01:38.110 --> 01:46.300 This being as the request is going to our IP address on port 80 for HTP and our server not having any 01:46.300 --> 01:52.410 lesson directives on port 80 to prevent this from happening then we have two options. 01:52.420 --> 01:59.260 Number one is to also listen on port 80 or in other words making our server available over an insecure 01:59.260 --> 02:00.260 connection. 02:00.260 --> 02:07.480 Now whilst this might have been fine just a couple of years ago htb s has become a standard and really 02:07.480 --> 02:11.210 there's no legitimate reason to use HTP any longer. 02:11.380 --> 02:17.950 And on top of security and search engine optimization reasons you'll also sacrifice the added performance 02:17.950 --> 02:24.210 of HTP too as it's only available over SSL option number two then. 02:24.220 --> 02:33.050 And by far the best option is to redirect all hgt requests to the equivalent HTP s request. 02:33.130 --> 02:38.830 There's a few ways of achieving this but again the most reliable and easiest is going to be creating 02:38.830 --> 02:44.670 a dedicated virtual host or server context in the h.t. dbe context. 02:44.670 --> 02:50.310 Then I'll add a new server which listens on port 80. 02:50.350 --> 02:57.380 So HTP with this same server name as we're listening on the same IP or domain. 02:57.730 --> 03:07.180 I'll copy this and all the server needs to do regardless if the request is redirect with a 3 0 1 status 03:07.180 --> 03:12.290 code which is moved permanently to HTP s. 03:12.340 --> 03:17.440 So port for Forth 3 server name being this variable. 03:17.740 --> 03:26.050 But this can also be host as the request host must be this IP or even a hard coded domain or IP as we 03:26.050 --> 03:26.690 have a year. 03:26.800 --> 03:32.910 All the same I'll stick to a host as it's the most descriptive and the request. 03:32.920 --> 03:33.990 You are right. 03:34.240 --> 03:35.500 That's it. 03:35.500 --> 03:44.370 Save this reload configuration refresh this HTP request and this time we get redirected to the H T T 03:44.360 --> 03:45.970 P S equivalent. 03:45.970 --> 03:47.800 So everything works. 03:47.800 --> 03:52.900 We can also double check this on the command line call their headers. 03:53.140 --> 03:55.540 Allowing that self science to difficult. 03:55.710 --> 04:07.510 H t D P and the server I b enter and again 3 0 1 moved permanently redirecting to H T T P S So that's 04:07.510 --> 04:14.980 our requests sorted and we can be assured that all requests will end up in this SSL server next then. 04:15.010 --> 04:22.710 Let's see how to improve upon this as Al encryption and make our server more secure in the server context. 04:22.720 --> 04:30.580 The first thing we'll do is disable S S L or more specifically the S S L protocol C whilst we still 04:30.580 --> 04:39.760 refer to and write this as s s l the SSL protocol or secure sockets layer has been outdated and replaced 04:39.790 --> 04:44.630 for the most part by the newer and better t o s or transport. 04:44.630 --> 04:54.400 Lay a security protocol which to an able leaving the SSL protocol out we can do by specifying SSL protocols 04:55.000 --> 05:06.560 t l s v one or Version 1 t l es version one point one and T O S version one point two there were hgt 05:06.560 --> 05:10.540 be connections now being encrypted using t o s only. 05:10.540 --> 05:13.720 Rather than the older s s l protocol. 05:13.720 --> 05:21.580 Next we can set which cipher suite should be used by the t o s protocol to encrypt our connection. 05:21.580 --> 05:28.070 First we need to tell engine X that we are going to do this by setting the SSL prefer Servat siphesihle 05:28.100 --> 05:33.850 directive 2 on then using the SSL scifres directive. 05:34.060 --> 05:38.640 We can set a string of suites to use and ones which should not be used. 05:38.770 --> 05:47.590 Like so each suite year being separated by a colon and the want not to use being prefixed with an exclamation 05:48.040 --> 05:49.430 like this simple m.d.. 05:49.440 --> 05:49.830 5. 05:49.830 --> 05:51.040 Sweet. 05:51.100 --> 05:57.400 Now the selection of preferred cipher suite isn't a very definite selection and you'll most likely find 05:57.400 --> 06:00.250 a number of these combinations on the Internet. 06:00.280 --> 06:06.250 This one here is very solid but might also become outdated as some of these suites become vulnerable 06:06.250 --> 06:08.390 due to exploits etc.. 06:08.680 --> 06:10.520 Feel free to use this combination. 06:10.540 --> 06:15.630 Or alternatively a quick search will provide some up to date combinations. 06:15.640 --> 06:20.520 Just make sure you get your preferred sweet combination from a reputable source. 06:20.860 --> 06:29.980 Next with our cipher suites optimized will enable diffie hellman key exchange or in short d h parameters 06:30.610 --> 06:35.460 how this works is far beyond the scope of this course but basically having D. 06:35.760 --> 06:42.750 Parameters in abled allows your server to perform key exchanges meaning between the client and the server 06:43.020 --> 06:45.220 with perfect secrecy. 06:45.250 --> 06:49.030 I've linked to a couple of in-depth articles in the list and resources. 06:49.050 --> 06:51.760 Should you want to find out how this works exactly. 06:51.930 --> 07:00.070 But a very good addition to any hgt be a server then to enable the age parameters we can add SSL underscored. 07:00.070 --> 07:00.660 D h. 07:00.660 --> 07:06.210 Paran and specify where our generator d.h. parameters can be found. 07:06.330 --> 07:15.150 We've not yet created these but I'll say slash it see slash engine X slash S S L So with those certificates 07:15.420 --> 07:20.490 slash d h Paran dot P E M save this. 07:20.670 --> 07:26.160 But before we can reload in generics let's generate those d parameters. 07:26.310 --> 07:33.060 Again using the open SSL command line tools that we used earlier to generate our certificates say open 07:33.060 --> 07:42.480 s s l d h per ram specifying the size which very importantly must match that of our private key as we 07:42.480 --> 07:44.550 set it when generating the key. 07:45.530 --> 07:52.540 So two thousand and forty eight writing this file out to that location we specified in the engine X 07:52.550 --> 08:03.470 configuration slash C slash engine X slash s s l d h boram Dot P E M enter and as per this message this 08:03.470 --> 08:05.490 can take a few minutes to complete. 08:05.750 --> 08:08.780 I'll just fast forward and done. 08:08.780 --> 08:13.150 List the contents of that SSL directory and there we have it. 08:13.280 --> 08:20.090 Meaning we should now be able to reload this configuration without any errors reload of form a call 08:20.090 --> 08:23.450 request again and everything works. 08:24.050 --> 08:26.600 Back to the configuration and the next. 08:26.600 --> 08:35.240 Very simple configuration to improve an exclusively SSL enabled side is enabling h s t s or strict transport 08:35.240 --> 08:36.570 security. 08:36.620 --> 08:40.950 This is a header that tells the browser not to load anything of HDD. 08:40.950 --> 08:46.630 Be meaning we can minimize redirects from Port 80 to board for 4 3. 08:46.760 --> 08:54.230 Just a very small but valuable tweak add a header with the name strict transport security. 08:55.130 --> 09:00.960 And the value of Max age equals one year in seconds. 09:01.040 --> 09:02.210 Always. 09:03.080 --> 09:07.500 Next we can enable a simple cash for our SSL sessions. 09:07.700 --> 09:13.250 If you recall from a previous lesson I mentioned that the SSL connection involves a handshake between 09:13.250 --> 09:18.170 the client and the server in order to be able to read each other's encrypted data. 09:18.370 --> 09:24.220 This session cash then allows the server to cash those handshakes for a set amount of time. 09:24.470 --> 09:34.010 Thus improving SSL connection times so to configure a session cache zone say SSL session cash the default 09:34.050 --> 09:41.020 cashed I've been bowled in but this is limited to a specific worker process and really not very useful. 09:41.180 --> 09:48.830 So instead then we'll set this to a cash type of shared meaning the session cash is kept in memory and 09:48.830 --> 09:51.490 can be accessed by any worker process. 09:51.530 --> 09:53.080 A much better option. 09:53.330 --> 10:01.940 If there's memory zone and name s s l and a size Auty Meg should be ample for most sites worth an S 10:01.940 --> 10:08.860 S L session time out meaning how long to keep a session cashed for off for hours. 10:08.880 --> 10:14.150 Again this not being a strict setting but four hours provides a decent amount of time for returning 10:14.150 --> 10:15.130 users. 10:15.500 --> 10:21.950 And lastly in order to use this session cache with out actually having the server access the cache we 10:21.950 --> 10:22.730 can enable. 10:22.730 --> 10:23.490 S s l. 10:23.510 --> 10:25.090 Session tickets. 10:25.850 --> 10:31.580 This basically means provide the browser with a ticket which validates the SSL session. 10:31.850 --> 10:38.480 This ticket is issued by the server so it's trusted and allows us to bypass reading from the session 10:38.510 --> 10:39.600 cache. 10:39.620 --> 10:44.990 It does however mean we can disable the memory cache as we cannot be sure the client holds a ticket 10:45.410 --> 10:52.700 but it optimize server resources in reducing SSL session lookups that covers the very most important 10:52.700 --> 10:56.710 parts of fine tuning and optimizing your SSL connection. 10:56.810 --> 11:00.870 So let's make sure this is all still working before finishing up. 11:00.890 --> 11:05.810 Save all this check the current configuration for any errors. 11:05.810 --> 11:13.070 Everything is fine reload and when I perform a call request we get that expected indexed. 11:13.100 --> 11:17.630 HDL page over an optimized HTP connection.