Transport Layer Security (TLS) - Computerphile

we're back to uh um skype team zoom whatever you want to call it everything what should we talk about today then i was watching um a video by richard mortier on secure web stuff right so sort of tls bit of certificates and things and i thought it might be a good time to revisit this issue of tls right what is it you know what's ssl what's tls where did it come from um because it's it's everywhere i was going to attempt to remember what it what tls stands for uh transport layer service close but no uh transport layer security you got two two or three it's absolutely everywhere it'll be being used for the for the communication we're doing right now it's going to be used when you go on the web to upload this to youtube you know and so on and so forth right it's used it's used everywhere um but that wasn't always the case right if you went if you go back to you know the mid 90s very little on the internet was encrypted at all um and maybe at that time it wasn't quite so important because there was fewer people on the internet for a start and we did less stuff like online banking online shopping things like this there were less there were fewer credit card details flying over the place that we want to try and keep an eye on um but that is not the case anymore right now we kind of have come to actually expect that everything is encrypted and when it's not big warnings start to show which is not you know didn't used to be the case um so actually this goes this goes way back sort of sort of to the mid and early 90s right so at that time netscape were using their netscape navigator browser i actually managed to install it on a windows 98 virtual machine the other day it took me back a bit a few people you know the nsa had been looking at this netscape had been looking at this other groups have been looking at this idea of web encryption um and they'd all come at it from different ways and you have a problem when everyone comes out starting something from a different direction that you end up with loads of competing protocols that don't work together and and maybe none of me end up getting used right so there was definitely a consensus that something needed to be done about web encryption but there was no kind of way forward so yeah i fired up um both internet explorer five would you believe and uh and netscape navigator three i think neither of which work on the majority of websites anymore because thankfully these websites tell us to get lost because we don't have sufficient security right you know there's fewer websites that support only http now those kind of load but then javascript turns up and everything goes a bit wrong so it was quite a fun experience um i got uh to use the web archive to look through some old bbc articles you know in in very grainy graphics i mean it's worth bearing in mind but there was very little on the web in the early 90s right so in fact it didn't really matter once amazon appears in other online shops suddenly we've got a real need for this if you recall very brief recap right um when you send a request to a website and just for now we'll talk only about websites but of course actually tls applies to a lot of other stuff as well you're going to be sending http messages right so these http messages you know http get http response things like this this payload is going to be put inside a tcp packet right which is going to give information on things like the ordering of packets and and some acknowledgement that things have been received and then above this is going to be an ip packet which is going to have the destination and where it's going and where it's come from and things like this and then you've got ethernet frames right at the bottom which are very close to proximity hardware stuff if you want to add encryption to this setup there's a question of the way you put it right because things like ipsec already exist so we can already encrypt ip packets right and this kind of existed already but then you if you do that then you have um questions over you know do all the routers support this and you've got to set up routers it's it's not as end-to-end as you might imagine so that's one that's one option but it's not it's not for everyone another option is just to encrypt the http itself so maybe you come up with some protocol which is like an encrypted version of http which is the same but also now some of the data is encrypted in some way right um and that the benefit of that is that then there's the web servers and the browsers can control this so that's good but the downside is that it doesn't work on anything other than http right actually quite a lot of the internet traffic is not web it's other things you know tor for example uses tls doesn't use http so what was decided what seemed like a good idea and this is where sort of ssl came from or secure sockets layer is to put the encryption between these two things above tcp but below the actual application that's running as i recall we draw this as a stack we talk about it as a stack but in reality it's sort of things in other things i seem to remember doing an animation about envelopes where one goes inside another goes inside another yeah that's exactly what it is right you have your http data or some other application data here and that's going to be its own size with its own information in it we don't care what that is in some sense and this goes with a tcp header which is going to add some information and then we have an ip header here and then we have an ethernet frame here which has a little bit of a checksum at the end as well so they kind of wrap each other like this and what we're proposing to do here is add another header in here which is going to be where our tls information is held and then of course this information will be encrypted that's the idea and so as far as tcp and ip and ethernet are concerned they don't know that the information is encrypted because they're not interested that's just their payload they're shipping off so that's you know nice and handy so this was a design principle for this in about 1994 some some researchers in netscape developed ssl one so they put it in between tcp and http so it has nothing to do with http in some sense and it has very little to do with tcp apart from it relies on the fact that tcp reorders packets correctly right because obviously decryption doesn't work so well if you mix everything up um and it was very basic this was it was a start right now the problem with ssl one was that it had um loads and loads of bugs right it used a stream cipher but it didn't have any kind of mechanism to prevent alteration of the packets and things like this it used only a simple checksum it didn't have any sequence numbers so the replay attacks happened a lot so it you know it wasn't it wasn't ideal it was only internal it was never actually deployed on the web so very quickly this was sort of ironed out and they and they came up with secure socket layer 2. this was about at the end of 1994 somewhere around this area and um and this replaces the simple checksum with a slightly better md5 construction we know now that md5 has some problems back then it was fine you know at least we didn't know it wasn't fine netscape actually patented this in 1995 um not with a view to selling it but with a view to stop other people patenting it so they could release it for free right which you know admirable right not not all companies at this time were operating in that way should we say in 1995 internet explorer was released right it's hard to imagine a time when internet explorer didn't um generate headlines and didn't exist but it actually didn't exist until 1995. microsoft saw the rise of things like netscape and thought we need to get in on this web game so microsoft released this or just designed alongside internet explorer this rival technology called pct or private communications technology very similar to ssl in some sense so similar it's a bit suspicious but so similar that it was almost interoperable which which did make it easier for browsers theoretically and web servers to support this but as with all of these things if you have multiple things that do the same function eventually you're going to have to come together and solve that problem right because it's just a bit silly in november 1996 then ssl 3 was released right which was the much improved version of ssl 2 and had some actually incorporated technology from pct in it as well this was still netscape at this time this was obviously not going to work long term with multiple technologies all doing exactly the same thing so um the internet engineering task force said right let's let's create a working group for this we'll call it the tier transport layer security working group the tls working group and we'll basically make a new version of this that will actually be a standard and maybe we'll all just use the same one that seems to make a lot of sense um it was renamed from ssl to tls purely because microsoft didn't want netscape having dibs on the name essentially um okay fine all right um you know i i think microsoft's practice is probably much improved by now right but during the 90s obviously there's quite a lot of stuff going on with browser walls and things so you know it's quite heated this working group was formed in 1996 actually took him until about 1999 to get a proper release out and that was tls1 right so transport layer security one and basically this is very very similar to ssl miner changes so in some sense it's sort of spiritually we might say ssl 3.1 and in fact actually the version three one is sent in the header for tls one what's really improved over time is bugs have been found protocol issues various attacks and things have been ironed out and actually now it's really quite impressive you know the sort of security and robustness you get from this you know it's quite difficult to intercept and fiddle around with someone's traffic so how does it actually work then yeah um i mean that's what everyone wants to know right i mean i've spoken at length now about how it became to be without actually talking have the history lesson right yeah yeah sorry i went where's the tactic i got carried away all right um so what we have what we want to do is we want to have some kind of it's a cryptographic protocol that exists between two parties and they have to agree certain things and they have to follow certain rules about message structure and things like this if this bike has to be here and this bike has to be here in this order and things like this the idea being that you can use it to very quickly establish encryption and then use that encryption to bury things like http so everyone thinks about this in terms of https but actually has very little to do with http it's actually just a cryptographic protocol that sits on top of tcp and can be used for anything right so loads of inter application communication will take place over tls and won't go anywhere near http messages right so i think that's that was an important part of the design process so there's a few things we need to do if we want to have um encrypted communication right so tls said right i'll talk in general about tls well pat's going in a different video go into detail about how the handshake works i think that would be quite quite interesting um but in general what we want to do is we want to work out what ciphers are we going to use because if you can't agree on which encryption algorithm you're going to use you're not going to understand each other's messages is it agnostic to the kind of concretion yes and no there are certain certain versions of tls support certain ciphers so as long as you and the server or you and the other party at least have one of those in common you're going to be able to communicate right so if i only talk aes and you only talk char chart that's going to be a problem but as long as one of us speaks the other one it's fine which ciphers are used have changed over the years because some of the older ones are no longer seen as secure and we have more modern aead encryption and things like this that we use now right but you know that's the idea but it is meant to be interoperable and one key part of this is that you know if i write my tls client in in let's say java and you write yours in c plus they should be able to talk because the message structure is fixed right it doesn't matter who sent it and so actually that's the case right you go and you'll talk to a web server programmed in some other language that you your browser doesn't doesn't know about it doesn't matter right it's just about the message structure so what ciphers are we going to use then we need to have some kind of secret key so you know we're going to do some kind of key exchange maybe to establish some kind of secret key or some other key material like keys for use with mesh authentication codes and things we need some kind of authentication right so now authentication means we need to demonstrate that at least one of the parties is who they claim to be right now richard talked about this in his video it's very very important because if you don't have this then of course i send tls messages the whole point is they're interoperable right so some of some attacker could also interoperate themselves let's say nicely into the middle of the conversation so it's very important usually with the server sometimes a client as well but usually but the server is authenticated and this is going to involve public key right so this is going to be public key cryptography the server is going to have to resign some digital signature and you're going to back this up with a certificate and things like this the last thing this needs to do is it needs to be very robust right robust to things like man in the middle attacks replay attacks where i just send the same messages over again and try and trick someone who's doing the same thing twice or something like that you know downgrade attacks where you try and trick a couple of people having a conversation into using let's say weak ciphers or something like this or weak keys and various other possible attacks right and it has to do all this within just a few messages at the start of every conversation because of course if it takes 10 minutes to establish this no one's going to do this right it has to be super super quick and in fact as an example tls 1.2 does this with two round trips so client to server and back and server and back and then it's done right so it's pretty cool are there any other things used instead of tls or is this become no no tns has become by far the most used for this right because it sits nicely in this point between the applications and the tcp stack like ip security is used a lot for you know vpns and things because it makes a lot of sense at that low level but you don't tend to see it so much for sort of just quick end-to-end encryption right and again we see tls all over the place in other net other applications that are not um but are not web-based necessarily so you know most of your instant messages will use tls to secure their communication to the server because why wouldn't they do that you know um so it's hugely prevalent it's really important um and it's very very clever but it can do all of these things in just a few messages and i guess we'll talk about that in the next video does it ever go wrong yeah all the time well what happens if it goes wrong what's what's the user experience there okay so i mean the the most of a time when you go to a website where something's gone wrong with tls is you'll see a big warning on your screen probably because of a certificate issue right classically it's gone wrong because they found attacks not necessarily attacks that were exploited in the wild on you know consumers but you know padding attacks and things that needed to be fixed and have been ironed out and then of course you have implementation problems like heart bleed right which steve covered in a video was a huge problem because everyone used openssl and that was a bug in their implementation of tls which allowed you to extract server ram right so you know often it's it's it's sometimes approachable fault sometimes it's the implementation of that protocol fault but yes plenty of things go wrong recently slightly less fingers crossed carry on copying for another 65 528 worth of bytes now where those extra bytes going to come from or they're going to come from whatever follows on in memory in the computer's memory that's there if we're lucky that data will be meaningless so it's still just you claiming to be whoever you claim to be and i've got no other way of checking that out which is why a lot of browsers

Channel: Computerphile

Views: 266,261

Keywords: computers, computerphile, computer, science, University of Nottingham, Dr Mike Pound, TLS, Transport Layer Security, Web Encryption, SSL

Id: 0TLDTodL7Lc

Length: 15min 33sec (933 seconds)

Published: Fri Oct 23 2020