Cryptography/SSL 101 #4: Simplified man in the middle attack MITM

okay so this video is going to be a quick one on what is called a man-in-the-middle attack which is a very common attack in this sort of cryptographic web security type scenarios that we've been talking about so we do on the Sylas again I'm going to go back and talk about an analogy which is completely removed from the the world of computers so we're going to go back in time to the the old Humpty Dumpty scenario and if you remember we wanted Humpty Dumpty to to be able to to send some information securely back to his bank I'm not going to go over the the public/private key stuff all over again you can see my previous videos for a very detailed introduction to that but essentially the public private key is the treasure chest where you use a use one key to unlock it and one key to lock it so let's say so here's the first scenario and the the courier in the middle here he doesn't actually have any bright ideas on how to corrupt this situation so he just delivers the delivers the unlocked chest and then delivers the lock chest back to the bank now in the second scenario so in this one the courier gets a little bit clever here anything hmm okay well I've been sent this asymmetric chest so a treasure chest with this with with the public key and I've been asked by the bank to deliver it to Humpty Dumpty so he can put his passport in it lock the chest and send it back to the bank now at this point the courier gets a bit smart anythings hang on a second I can actually grip my own chest with my own public key this black one here and I can deliver that one to Humpty and Humpty will be none the wiser so he will happily lock his passport into my chest with the public key that I gave him and send it back to the bank via me the Korean and obviously the courier is the one who has the private key to this chest here so he can unlock that chest pull out the passport take a copy of it do it everyone's with it the key thing is that the bank is still accepting it so he sorry expecting it so if he doesn't send it off the bank then then the theft is going to be reported or whatever so what he does don't forget he still has the original chest and public key that the bank sent him to pass on to Humpty so all he has to do is take the passport put it in that original chest belonging to the bank lock it with the bank's key and send it back on its way to the bank so if you think about it what's happened here is that Humpty is none the wiser he doesn't think anything anything's happened he asked the bank to send him a chest with the public key which he received the bank for expecting his passport which they also received the only thing is this evil Korea guy in the middle has actually managed to intercept everything and basically to to make a copy of the passport and do all his dastardly things so what's the challenge for Humpty in this scenario because he's requested the chest in the public key from the from the bank and the key question is how does Humpty know that the public key that he's being presented with actually belongs to the bank or whoever he's expecting it from and not let's go down here so if we extend this back into the digital world the analogy is more or less exactly the same so in my first video we went over the basics of the HTTP protocol again I'm not going to go over it once more in full but essentially what happens if hum if Humpty in the modern world requests a HTTP transaction with the bank right so the request goes to the bank's web server over here and the web server will send back a copy of the SSL certificate that's installed at the bank and that SSL certificate contains among other things the the public key belonging to the bank then subscribed by the way this is without the attack happening so this is without any man level this is just a normal successful if you like a transaction so the client at that point Humpty's computer will generate a random number will encrypt that random number using the server's public key and it will send it back to the server right the server will then decrypt that number with with its own private key the corresponding private key to the public key that is sent out and then at this point the client and the server both have this same number it's called the premaster secret right so they both have the same number and what they do is they both feed that number through a function which generates a AES symmetric session key and they both use that session key to encrypt and decrypt the data symmetrically for the rest of the session so that's the that's the good old a s symmetric box where you've just got literally one one key to lock the box and the same key unlocks a box but they've got the keys that they've managed to securely agree a common key between the two so that's all well and good but what happens what happens if somebody is girl bandit again but this time he's a web bandit rather than a courier bandit let's say he manages to intercept the certificate that the bank sends back to Humpty right so this is the best exactly the same certificate here sent by the bank but this time this bandit here what he does is he says okay I'll tell you what what I'm going to do is I'm going to actually intercept this and send my own certificate with my own proper public key he noticed that the public keys have been changed missed from in these two certificates and he'll then obviously he'll have to sign that signature himself see my early video on the digital signatures and he can then send that certificate on his way to Humpty's claim machine but at this point Humpty's client is none the wiser he doesn't know he doesn't know whether whether that public key that bits in the Civic at that he received belongs to the bank or anybody else this is assuming by the way that we're using self-signed certificates and in my next video I'm going to go into what what exactly that means because the same is a technique that's used in this whole SSL protocol using chess train just trust chains excuse me which solves this problem but I'm just trying to explain the problem first and then the next video I'll show how the problem is it's actually solved so at this point the client will generate the premaster secret that that magic random number he will encrypt it and send it back to who he thinks is the bank the actual fact he's encrypting it using the public key belonging to the the bandit in the middle right so the bandit wait for the response he unlocks basically decrypts that number with his own private key which is the corresponding key to the the public key that he sent to hunt him and and then at that point he has his own copy of the premaster secret just like in the previous example the bandit was able to pull the contents of the the Bob pull out the passport in this case from this box and then pack it in a different box and send it on its way so exactly the same situation here the bandit is able to inspect this premaster secret generate the symmetric key as well and then re encrypt the premaster secret with the bank's public key which it received in the first transmission here and send that onwards on its way back to the bank so at this point the bank decrypt the premaster secret with its own private key did it that that has bright in the beginning and the client and the bank they both generate the symmetric key as well the difference is this is far from being a secure connection now because you've got this one guy in the middle who has access to the symmetric keys who basically can listen to all of the traffic going back and forth between the client and the server so that's that's basically an example of a man-in-the-middle attack and how Mike how it might apply to a sort of SSL transaction so in summary so what we're saying is that the this that the bandit was able to send his own public key to Humpty instead of the bank's one and Humpty was none the wiser he didn't know he didn't know that the key he'd received does not belong to the bank and the bank wasn't able to intercept content which Humpty thought he it securely encrypted for the bank so Humpty was able Humpty encrypted the data but he was sending back but because he was using the bandits publicly the bandit was able to decrypt that but the information and do what he wanted with it and the last point is that the bank received the secret content completely unaware that somebody in the middle had actually first decrypted that with his own private key and then re encrypted using the bank's public key and then sent it on to wake the bank so that's why it's called a man-in-the-middle because it's very difficult for the two hand parties to actually realize that there's somebody in the middle who's intercepting and listening and listening in on the traffic so in the next video I'm going to talk about in more detail SSL Certificates and in particular the chain of trust because those away there's a way to get around this so that each time each time Humpty over here receives a public key that is supposed to belong to the bank there's no way that somebody in the middle can basically just replace the contents of the certificate with their own certificate and then and then fool somebody into using a public key that does not belong to the people who they thought it did so hope that makes sense please leave any any questions comments or feedback below I'll get back to as soon as I can I hope you found it interesting and see you the next video

Channel: Matt Thomas

Views: 9,112

Rating: 5 out of 5

Keywords:

Id: U5qqFXufnlw

Length: 11min 46sec (706 seconds)

Published: Thu Mar 03 2016