1 00:00:01,140 --> 00:00:09,240 SSL anti-aliased use all the cryptographic technology we have gone through already including the symmetric 2 00:00:09,240 --> 00:00:17,070 and asymmetric algorithms hashes digital signatures Message Authentication codes to make a working security 3 00:00:17,070 --> 00:00:24,600 protocol SSL and tier class or cryptographic protocols designed to provide communications security over 4 00:00:24,600 --> 00:00:26,610 a network or the Internet. 5 00:00:26,610 --> 00:00:30,760 Now SSL is the old encryption protocol. 6 00:00:30,840 --> 00:00:39,380 NTFS is a new form but people still call them both SSL which is a little bit annoying and misleading. 7 00:00:39,630 --> 00:00:46,700 Many sites still use the older SSL for compatibility reasons even their security issues. 8 00:00:46,710 --> 00:00:52,950 An example of Tellez use is when you see Haseeb CPS in the RL of a Web site. 9 00:00:54,260 --> 00:00:55,130 Such is here. 10 00:00:56,040 --> 00:01:04,850 But till as can be used with any other protocol like FGP or virtual private networks it isn't just use 11 00:01:04,850 --> 00:01:11,570 with haste ETP and the web browsing Tellez is very important for Internet security and privacy because 12 00:01:11,990 --> 00:01:17,060 it is the most used method of encrypting data on the internet. 13 00:01:17,230 --> 00:01:24,280 Provides privacy because encrypts data and data integrity because it uses Message Authentication codes 14 00:01:24,290 --> 00:01:28,370 on Macs and communicating between two applications. 15 00:01:28,370 --> 00:01:35,270 So for example when your Web browser the application when you communicate with your online bang their 16 00:01:35,270 --> 00:01:42,890 application communication is encrypted from end to end from your application their application using 17 00:01:42,890 --> 00:01:51,040 tty LS tailless supports the security services of confidentiality or privacy authentication and integrity. 18 00:01:51,080 --> 00:01:57,830 The connection is private because a symmetric algorithm such as a s which you've discussed is used to 19 00:01:57,830 --> 00:02:05,120 encrypt the data transmitted the keys for this symmetric encryption are generated uniquely for each 20 00:02:05,120 --> 00:02:10,420 connection and all based on a secret negotiation at the start of the session. 21 00:02:10,540 --> 00:02:16,940 The server and client negotiate the details of which encryption algorithm in cryptographic keys to use 22 00:02:16,940 --> 00:02:19,750 before the first part of data is transmitted. 23 00:02:19,760 --> 00:02:26,570 The negotiation of a shared secret cannot be read by eavesdroppers even by an attack who placed himself 24 00:02:26,570 --> 00:02:27,940 in the middle of the connection. 25 00:02:27,950 --> 00:02:34,910 The connection is all so reliable that no attacker can modify the communication during the negotiation 26 00:02:35,030 --> 00:02:36,310 without being detected. 27 00:02:36,410 --> 00:02:43,220 The identity of the communicating parties can be authenticated using public key cryptography certificates 28 00:02:43,250 --> 00:02:44,650 and digital signatures. 29 00:02:44,660 --> 00:02:51,120 This authentication can be made optional but it is generally required for at least one of the parties. 30 00:02:51,140 --> 00:02:56,750 Usually the server so the web sites you visit and I'll show more on this when we talk about certificates. 31 00:02:56,960 --> 00:03:04,490 The connection is reliable because each message transmitted includes a message integrity check using 32 00:03:04,490 --> 00:03:12,410 a message authentication code Omak to prevent undetected loss alteration of the data during transmission. 33 00:03:12,420 --> 00:03:20,030 Still I suppose many different methods for exchanging keys encrypting data authenticating message integrity. 34 00:03:20,030 --> 00:03:26,360 Many of the algorithms and technologies which we've already discussed as a result though secure configuration 35 00:03:26,360 --> 00:03:33,590 of Tellez involves many configurable parameters and not all choices provide the security services or 36 00:03:33,600 --> 00:03:37,310 privacy authentication and integrity. 37 00:03:37,310 --> 00:03:45,500 Now if we look on the Wikipedia site for Transport Security which is actually a really insight or describing 38 00:03:45,830 --> 00:03:54,680 T.L. as we can see the various different supported methods for exchanging keys encrypting data and authenticating 39 00:03:54,680 --> 00:04:02,330 message integrity and the first one here is shrinkers authentication and exchanging of keys and the 40 00:04:02,330 --> 00:04:05,660 various different algorithms that are supported. 41 00:04:05,660 --> 00:04:13,370 Now I remember back to the asymmetric algorithms that we discussed these so we can see RSA we can see 42 00:04:13,370 --> 00:04:19,680 Diffie Hellman RSA elliptical curve etc.. 43 00:04:20,150 --> 00:04:29,970 Now the best ones to use are this one this one and this one with the problem is you don't always get 44 00:04:29,970 --> 00:04:30,800 a choice. 45 00:04:30,990 --> 00:04:37,120 A server will support certain authentication and key agreement methods. 46 00:04:37,410 --> 00:04:41,490 And if you want to speak to them then you'll have to use those. 47 00:04:41,490 --> 00:04:47,940 Now the reason that these are the preferred option is because they're using Diffie Hellman for key exchange 48 00:04:48,240 --> 00:04:54,220 which can ensure a property of privacy called Forward Secrecy which you can see here. 49 00:04:55,090 --> 00:05:01,420 Now this property gives assurance your session keys will not be compromised even if the private key 50 00:05:01,420 --> 00:05:07,810 of the server is compromised by generating a unique session key for every session a user initiate. 51 00:05:08,020 --> 00:05:15,010 Even the compromise of a single session key will not affect any data other than the exchange in that 52 00:05:15,010 --> 00:05:18,740 specific session protected by that particular key. 53 00:05:18,790 --> 00:05:26,200 Perfect Forward Secrecy represents a big step forward in protecting data on the transport there and 54 00:05:26,200 --> 00:05:31,720 has become to see more important since vulnerabilities such as Heartbleed. 55 00:05:32,000 --> 00:05:38,830 Pervert for secrecy really means that if the server you're communicating with is compromised and their 56 00:05:38,830 --> 00:05:45,850 private key is compromised it means that all of your previous conversations cannot be decrypted because 57 00:05:45,850 --> 00:05:52,410 you are using Diffie Helman to negotiate sesshin keys that are only used for a very short time. 58 00:05:52,480 --> 00:05:59,950 If you move further down here we can then see the symmetric algorithms used. 59 00:06:00,000 --> 00:06:05,650 So when we're talking about sesshin keys these are the keys are actually used to encrypt the data because 60 00:06:05,650 --> 00:06:08,370 the symmetric keys are quicker. 61 00:06:08,370 --> 00:06:12,400 And remember we talked about a less than out a was a good option. 62 00:06:12,700 --> 00:06:22,600 And here we can see a yes and various other types of symmetric encryption algorithms and this interestingly 63 00:06:22,600 --> 00:06:32,110 shows which ones are secure and which ones are in secure because there's some sort of ability or weakness 64 00:06:32,650 --> 00:06:40,170 against them which is another reason why I recommended a yes you'll notice here that there are some 65 00:06:40,170 --> 00:06:46,770 other things at the end of this A shouldn't really worry too much about that that is called a mode of 66 00:06:46,770 --> 00:06:48,080 operation. 67 00:06:48,180 --> 00:06:56,390 It is a different way for a GPS to scramble or encrypt the data which doesn't really matter too much 68 00:06:56,400 --> 00:07:03,300 in this case and for this cause just knowing that using a GPS is enough and the bit lenth which we've 69 00:07:03,300 --> 00:07:04,780 already explained. 70 00:07:04,890 --> 00:07:09,670 You can also see here illustrates the different versions of SSL. 71 00:07:09,840 --> 00:07:13,620 So actually this is very confusing for a lot of people. 72 00:07:13,650 --> 00:07:18,150 This is the first version or earliest version sharing here of SSL. 73 00:07:18,300 --> 00:07:19,810 And this is the next one. 74 00:07:20,130 --> 00:07:31,580 And then this is the next warm so it goes to one after it was three for SSL so T.L. s 1.3 is the latest 75 00:07:31,640 --> 00:07:36,160 and most secure version but is at least compatible with browsers. 76 00:07:36,290 --> 00:07:41,910 So when using tailless you really want to be on tailless Warne or a ball. 77 00:07:42,020 --> 00:07:46,720 And as you can see here you can see which one of these is secure or not secure. 78 00:07:46,740 --> 00:07:53,450 You can see even with a yes you've got depends on mitigations if you are using s one that's come down 79 00:07:53,450 --> 00:07:54,690 a little bit further. 80 00:07:57,560 --> 00:08:07,120 And you can see the caches and Max that are used you know to maintain data integrity M.D 5 shouldn't 81 00:08:07,120 --> 00:08:08,070 be used. 82 00:08:08,200 --> 00:08:10,370 One is definitely getting very old. 83 00:08:10,570 --> 00:08:18,670 And when we should be starting to use in later versions of Shaw which is 2 5 6 and 3 8 4 but for compatibility 84 00:08:18,670 --> 00:08:25,810 reasons these aren't necessarily the used terms have been made to compromise and subvert aspects of 85 00:08:25,840 --> 00:08:34,690 the security that TLR us and the protocol has been revised several times to address these evolving security 86 00:08:34,690 --> 00:08:37,840 threats and identified weaknesses and vulnerabilities. 87 00:08:37,840 --> 00:08:46,370 Examples of these include beast crime Pulo logjam with interesting names. 88 00:08:46,510 --> 00:08:50,450 You can google those and find out more details if you're interested. 89 00:08:50,740 --> 00:08:59,290 But the result has been that browsers and the implementations of SSL have to be upgraded by the developers 90 00:08:59,650 --> 00:09:05,650 in order to keep up with the attacks and to defend against these vulnerabilities. 91 00:09:05,650 --> 00:09:17,110 Now if we go here here you can see listed the versions of Firefox this is Firefox 2:33 and you can see 92 00:09:17,300 --> 00:09:27,900 the beast when Roberti crime poodle freak logjam and you can see if you've got version 36 or 38 then 93 00:09:27,990 --> 00:09:31,630 then that is vulnerable to logjam. 94 00:09:31,750 --> 00:09:39,220 And if you get older and older versions you'll see that they become more and more susceptible to various 95 00:09:40,540 --> 00:09:42,380 weaknesses and abilities. 96 00:09:42,610 --> 00:09:49,480 Which is why you should be on the latest version of your browser where possible and the servers or signs 97 00:09:49,480 --> 00:09:53,290 that you connect to also need to be on the latest versions. 98 00:09:53,340 --> 00:09:55,950 The thing is you can't necessarily control that. 99 00:09:56,000 --> 00:10:04,390 The thing is if you need privacy you need extreme privacy and you know that your server is not supporting 100 00:10:04,570 --> 00:10:12,460 or is vulnerable to some of these things because maybe using just SSL warn then you know that you can't 101 00:10:12,460 --> 00:10:13,890 communicate with that. 102 00:10:13,990 --> 00:10:16,840 No energy secure and private way. 103 00:10:17,170 --> 00:10:21,910 The combination of algorithms used is known as a cipher suite. 104 00:10:21,940 --> 00:10:28,720 It is useful to know what all both the strongest and most compatible ciphers suites. 105 00:10:29,020 --> 00:10:36,610 So instead of giving you a list I'm going to point you at resources that you can use instead. 106 00:10:36,610 --> 00:10:43,030 This way you can find the latest ciphered list to be considered the most secure compatible when you 107 00:10:43,030 --> 00:10:43,500 need it. 108 00:10:43,500 --> 00:10:49,150 This is because if I give you a list now tomorrow a new vulnerability could come out which would invalidate 109 00:10:49,150 --> 00:10:50,150 the order. 110 00:10:50,230 --> 00:10:57,020 Probably one of the best places to go for a good Scifres Swee with compatibility. 111 00:10:57,040 --> 00:11:01,230 Well actually the best place I know of anyway is Mozilla. 112 00:11:01,250 --> 00:11:04,310 All the people behind Firefox. 113 00:11:04,570 --> 00:11:14,100 Now what you can see here is the Sipher Swee list in order of preference so here is the most desirable. 114 00:11:14,500 --> 00:11:18,940 And here is the least desirable but still strong. 115 00:11:18,940 --> 00:11:25,900 Plus you have all of the best options as well such as your T.L. S version your certificate type your 116 00:11:25,990 --> 00:11:28,260 certificate signature etc.. 117 00:11:28,540 --> 00:11:34,270 And if you go up here you can see what these ciphers are compatible with. 118 00:11:34,270 --> 00:11:39,060 So these are the oldest compatible clients that will work with the Scifres. 119 00:11:39,070 --> 00:11:46,300 So that's a really great list of the strong deciphers the ones that you want to use in preference. 120 00:11:46,300 --> 00:11:54,100 And also if we go further down here we have a list designed for increased compatibility. 121 00:11:54,160 --> 00:12:02,110 So if you're looking for a list or work with a wide a number of clients then this is a good option here. 122 00:12:02,380 --> 00:12:09,580 If we go further down there you know they see all the Scifres if we go further down we can see that 123 00:12:09,580 --> 00:12:15,980 the ultimate compatibility list here which will work with the really old clients if you need to configure 124 00:12:15,980 --> 00:12:20,720 a server then check this out is a really cool tool. 125 00:12:20,720 --> 00:12:27,230 So if we select the type of server that we want and then we can set the server here. 126 00:12:27,240 --> 00:12:34,190 So maybe it's Apache when the old version the intermediate version the modem version and then it produces 127 00:12:34,580 --> 00:12:42,650 the configuration for us so we can see here it's set it all up for is we don't want SSL v 3 v 2 and 128 00:12:43,070 --> 00:12:44,340 or V 1.1. 129 00:12:44,370 --> 00:12:51,070 So it's going to work for 1.2 and there's all the safest suites which create that conflict for. 130 00:12:51,080 --> 00:12:53,150 So this is really brilliant. 131 00:12:53,170 --> 00:13:03,260 Another site to look at for a good cipher suite list is weak D.H. to OLG as one here and the one I recommend 132 00:13:03,590 --> 00:13:10,710 from Steve Gibson This is his list and it's in the format suitable for Windows servers. 133 00:13:10,890 --> 00:13:16,290 And this is also another good list of preferred order for your cipher suites. 134 00:13:16,390 --> 00:13:21,080 And the next section is I'm going to show you how you can tell what it is that the server is offering 135 00:13:21,080 --> 00:13:26,100 in terms of its encryption algorithms and hashes and digital signatures et cetera.