All right, you guys, in the last video, we had a lot of fun, and I hope you played around a little
bit with the setup and men in the middle, your devices just if you have the permission to do so.
In this video, we take a look at https.
Why is it more secure than HTTP?
And also, how is this encryption being established?
But don't worry, only on a high level.
You do not go down the rabbit hole and do some cryptographic analysis on this one.
Alrighty.
So let's see.
And so here we have our, our really well-drawn setup.
I mean, it looks absolutely realistic and pretty amazing, right?
That's definitely no surprise.
That's what it is right now.
Okay.
So we've got our smartphone.
The smartphone is being connected via wi fi to our router and this one is being connected to our Ubuntu
VM, which is being connected to the Internet.
That's well known to us right now.
Okay.
But now is the question, why do we get this kind of error warning sign, however you call this, if
you're trying to man in the middle and HTTPS connection, the reason for this is HTTPS is just way more
secure than HTTP.
There are some kind of yeah.
Some kind of trust relationship between the device and the server.
And this trust relationship builds up a strong cryptographic channel.
And afterwards, after building this channel up, this channel is being used to transfer data from the
smartphone to the server and backwards.
That's why HTTPS.
Is that more secure?
All right.
That's all for this video right now.
No, just kidding.
Let's have a look.
Under the under the hood.
Is it called under the hood?
I guess so.
And if not, then we still make this.
This is our well-known setup over here.
And now.
Now, let's say the smartphone wants to open up that page and this one, for example, example dot org.
But this time it's HTTPS.
The smartphone is now crafting this package, this HTTPS package, and it will be sent to the router.
This one will forwarded through our interfaces into the internet.
Now this web server realizes, okay, that's the request, but related to https.
So the web server is now screaming back to the smartphone wherever it is right now in this world.
Yo, this one here is an HTTPS request.
We need to establish a secure channel over here, so we need to perform some encryption to prove that
I'm really example dot org.
Here's my certificate and this one over here and this has been signed by Google.
All right.
So maybe with a little bit deeper voice, but I guess we get this point.
The Web server is now presenting the certificate and this one has been signed by Google and this certificate
will be now transferred back to the smartphone.
There are some bunch of other stuff involved, like the public key from this web server over here.
But now let's make it not more complex.
So we simply just focus on the certificate.
Alrighty.
So now we are sending back the certificate to the client.
The client is now extracting the certificate and realizes, okay, so here we have now the certificate
from example dot org but we do not know example dot org.
So how can we now prove that this is really example dot org?
Well, we do not have to do this.
This has been already done by Google.
Google has verified in this case that this one here is example dot org.
And after verifying this, Google has signed the certificate over here with the private key.
So this signature has been created with the private key from Google.
And if this is the case and we are trusting Google, then we also trust that this one here is example
dot org.
That's the base about https.
We have some trusted authorities and everything that has been signed by them will be automatically trusted
to.
All right.
Okay.
But now the question, how can we verify that this certificate has been really signed by Google with
the private key of Google and not by some third party over here?
The answer for this one is asymmetric cryptography.
Based on this principle, Google can sign the certificate with the private key and we can verify this
with the corresponding public key.
Therefore, the private key never, ever leave school at this point right now and it stays secure and
this is very important.
Otherwise we would have a huge problem with the Internet right now.
Okay.
So the private key is safe at Google and Google can now provide us in public key to the corresponding
private key.
Having this public key is absolutely no problem because only the private key regarding to this one can
decrypt these data.
So therefore we can now distribute this key to everyone else.
And the nice thing about this asymmetric cryptography is we can now use this public key to verify if
this signature has been really signed by Google, because having the public key, we can now verify
if this this signature has been created with the corresponding private key, the private key from Google
over here already.
And this is exactly what the smartphone is doing right now.
So the smartphone looks it up.
The smartphone checks in its internal certificate storage if there are some cars.
The public key for this private key over here.
So the public key from Google.
And you know what?
Of course it is in there.
And so this server has been signed by Google.
Therefore we can trust that example dot org is related at this server over here having the public key.
Absolutely no problem.
Getting the private key would be absolutely dangerous.
The Internet would be definitely broken.
And therefore, Google is not giving away or placing its private key onto other servers.
It's being kept private at Google and Google just signs other certificates with this private key, which
can be now proven.
All right.
After verifying that this server over here is really example dot org and not some malicious attacker
which is trying to spoof this one over here, we can now establish our magic.
This one over here, we can build up our encrypted channel between the smartphone and the web server.
And you know what?
This is possible.
Even having an attacker just directly in front of us or not even just in front of us, we are also using
the network devices that this attack is providing for us.
So we are having an attacker establishing a man in the middle connection by having its own devices,
which we are using.
And even then, the attacker cannot decrypt this channel over here.
Isn't this amazing?
It absolutely is.
So how is this possible?
How can these two components exchange security data, which cannot be fetched by this attacker over
here?
Well, let's have a look into this one on the graphic tablet there.
We will find out how this amazing feature works.
Okay.
So first, let's have a look at the difference between symmetric and asymmetric crypto.
And don't worry, we are doing this on a high level.
In symmetric encryption.
We are having a shared secret and we are using this to encrypt and decrypt the message.
Here's an example.
Bob wants to send a message to Ellis, but not in plaintext.
Bob wants to encrypt this message and use this secret P.W. exclamation mark as some sort of password.
If Ellis now wants to view this message, she has to know the password to decrypt it.
So both need to know the same secret.
And this is a problem in our case right now.
Why?
Because we cannot simply send the secret over to Ellis over the wire.
An attacker would immediately get this password and could also decrypt this message afterwards.
So therefore, we need some sort of asymmetric cryptography.
And we have already talked about this.
But nevertheless, let's recap this here real quick.
Once again, Ellis and Bopp.
But this time we are talking about asymmetric cryptography, which means we are not using the same secret
to decrypt and encrypt a message.
Bob has, therefore, a public and a private key.
The same for Ellis.
Bob is now fetching the public key from Ellis over the wire and uses this key to encrypt the message
by encrypting the message with the public key of Ellis, only the private key of Ellis is able to decrypt
it.
The private key states.
At least this key has not been transferred over the wire and can now be used to decrypt this message
by Ellis.
If Ellis wants to reply back to Bob and she needs to get the public key from Bob.
Once again, this can be easily transferred over the wire, and afterwards this key is being used to
encrypt this message.
This means after the encryption, even Ellis is not able to decrypt this message anymore.
This can be only done with the private key of Bob.
And Bob is not giving away his private key.
So this private key also stays at Bob.
This means those public keys can be easily exchanged even if an attacker is sitting in between them
because they can only be used to write encrypted messages to the corresponding persons so they cannot
be used to decrypt these messages.
This can be only done with the private key, with the corresponding private key.
Okay.
So now we know a little bit about symmetric and asymmetric crypto.
So symmetric crypto is not an option for us if we have to send a password over the wire.
I mean, this is an absolute bad idea because the attacker simply gets the password and then can decrypt
our traffic easily, right?
Absolutely.
Okay.
No big deal then, simply by not using asymmetric crypto based on public and private key.
Yes, this would work, I guess.
But let's imagine the the amount of stuff we have to handle there.
So every client needs to have a private and public key.
Who's generating those keys?
Who has access to those keys?
This is the user.
What if he gets revoked?
So we have to handle all these things for billions of certificates.
So this would be this would be absolutely ridiculous.
The other problem I see right now, let's assume the private key gets compromised.
So if an attacker has access to the private key, the attacker is able to decrypt this whole this whole
network traffic for this person over here.
Yes, of course.
But how shall we handle this right now?
If if this is all, it's not an option.
The answer to this one is we do not have to, because there are so many freaking smart people out there
which want the solution for us.
And two of them are Mr. Diffie and Mr. Hellman.
And this whole concept behind this, it's freaking amazing.
And this is something we are going to analyze right now.
So we take a quick look on a high level into this key exchange via Diffie Hellman.
And this is it's absolutely mind blowing.
So therefore let's have a look.
Okay.
So the problem we're still having is we want to establish a secure connection with our web server,
even if an attacker is sitting in a man in the middle position between us and web server.
And we also want to encrypt our data in a different way for every connection we are making.
So this is this is freaking ridiculous.
And this is the problem that if we Hellman solves okay, so let's get into this.
Most of the time people try to explain this key exchange with some colors, but I would like to try
it differently.
I'm trying to explain this based on some tricks.
So at the end, Ellis and Bob should have the exact same string with the exact same components and the
exact same amount of milliliter.
So identical drinks.
All right.
Okay.
So here we are having LZ and Pop.
We start with an asymmetric crypto because otherwise the attacker could easily sniff our components
and the game would be over.
So asymmetric crypto means we are having a private and a public part.
All right.
Yes.
They're talking about mixing a drink, which is identical and cannot be mixed by an attacker that gets
all the information by sitting in between us.
So let's start a lesson, Bob.
Have to commit to a base route which both are putting into their drinks.
In this case right now, it's an apple.
And this one over here, the applicant's mixed and the truth is getting put into their glasses and the
attacker has this information.
But this is fine right now.
Okay.
Now, Bob is putting this fruit into his drink.
You you do not know what this fruit is?
Of course not.
Because this is Bob secret.
And we also do not know how much of this fruit is Bob putting into his drink.
It could be 42 milliliter or it could be 122 milliliter.
We do not know this.
Ellis is doing the same.
And no, this is not a lemon.
This is the secret of LLS.
So less secrets, fruit.
Both are having the apple and their own fruit mixed into their drinks right now.
But how does Ellis now get the information from Bob, which fruit and how much of this fruit she needs
to put into her drink?
The answer is she doesn't.
Crazy, right?
Because at the end, both drinks have to be absolute identical.
This is also the reason why we are having the apple at the beginning, because otherwise I would immediately
see how much and maybe also taste which fruit both are using, but together with an apple.
This is absolutely impossible.
And now you might already see what is happening next.
Both are taking their swap glasses and inserting their own fruit.
Once again, they know which fruit and they also know how much of their own fruit they need to put back
into this class over here, because this is their own secret.
Amazing, right?
Because now they are having exactly the same drinks.
But Ellis does not know the secret fruit of pop.
And pop does not know the fruit of Ellis.
They are now having a drink, which can be which can be seen as an shared secret.
This secret drink can be now used as an symmetric key to encrypt and decrypt the data between Ellis
and Pop.
And they can choose a new key for every connection they are making because they just have to think about
some cocktail recipe or in reality, very large prime numbers.
This is absolutely ridiculous.
The attacker sitting in between them doesn't realize what's going on and the whole connection has been
already established securely.
Okay.
Now we have seen how we can establish a secure connection, even if an attacker is sitting in a man
in the middle position between us and the attackers also owning the hardware.
So even then we can make and secure connection with our connection partner.
And this is this is absolutely amazing.
But of course, not for the attacker, which is good, but not in our case right now, because we as
an attacker want to get into this connection.
Breaking Decryptor is definitely not an option, as we have already seen right now.
This is something we we cannot circumvent.
So if breaking the crypto is not an option for us right now, what else can we do?
Because we need to get into this position.
We need to decrypt this traffic of this mobile application because this is why we are here.
We want to analyze and hack this application.
So how can we do this?
The easiest solution for this one here would be becoming invalid authority.
And this sounds absolutely ridiculous because this is something that never, ever happens in the real
world online right now.
But we are not in the real world online.
We are on the smartphone.
So so we have the control of our smartphone.
And therefore, we can also adjust those settings.
So if we are able to tell the smartphone that we are a trustworthy authority with our perps with instance,
then our perps, we can can claim every certificate we want to have right now.
For example, we can take our birth certificate and say this certificate is, for example, dot com
or this is, for example, dot org and we are a trustworthy authority.
Therefore the client is also trusting us.
The nice thing about this one is we do not have to care about this cryptography.
I mean, the whole element exchange is still happening, but it's happening with us.
So we are the connection partner right now and therefore we do not have to break the crypto because
we are an invalid partner right now where the client is connecting to.
And of course we need to be able to decrypt this message because this message is addressed to us right
now.
We are the partner that should read this message from the client and therefore we also need to have
this development key exchange.
But this time we are receiving all this information and therefore are also able to to mix the exact
same drink, to analyze the traffic or to decrypt these packages.
All right.
So let's have a look how we can do this.
Okay.
So let's add our attacker over here and then let's see what happens, how this interaction works.
All right, there we go.
Here we have now our attacker and the smartphone is still making a connection to https example dot org.
All right.
We still have our web server over here.
This is our example dot org and web server.
Now, the smartphone is making this connection, but the attacker sits in between this connection.
So it looks like this.
The web server might still present the certificate, but that's absolutely irrelevant right now because
this type of connection does not reach this web server.
The smartphone now sees our attacker machine in between this connection, the attacker needs to present
the own certificate because the attacker does not have a valid certificate which has been signed by
an authority that proves that example dot org is located at this machine.
So that's also of course not the case because no authority would claim that example dot org is located
at the machine of this attacker over here.
All right.
Okay.
So the smartphone receives not the certificate from the attacker and it looks at that.
This certificate is not known to the smartphone.
And also the certificate has not been signed by a valid authority, like, for example, Google or Comodo
or whatever you want to have here.
And this means the smartphone simply tells the attacker, nope, I'm not going to make a connection
to this instance because you are not example dot org.
Otherwise it would have been signed by a valid authority, or at least the certificate would be included
in my certificate storage over here.
Therefore, the client simply aborts this connection.
So the connection gets terminated and the client is not communicating with the attacker anymore until
the attacker can provide a valid certificate.
But I mean, that's of course not possible because no authority will sign a certificate for the attacker
for a domain that the attacker does not own.
So at this point, it seems to be lost.
Right now, we cannot interact with this client.
And the client also doesn't trust us.
I mean, the client has absolute valid reasons not trusting us right now, but how can we still establish
this type of connection?
The client needs to trust us, and if we do not get them signature from a valid authority, then the
only chance we have right now is adding our certificate into the client certificate storage.
So if you push now our certificate to the client, then this will be inserted into the client certificate
storage like this one over here.
And now if the client is establishing a connection to https example dot org and we are sitting in between
this connection, the client takes a look into the certificate storage and sees the certificate in there.
Then the client is telling us, okay, I trust you right now and step.
Fishing and connection to us.
All we have to do right now is forwarding this connection to the real website to example dot org.
But that's absolutely no problem because we as a client right now can make or establish an HBS connection
with example dot org and we can simply pass this data between those two components.
So between the smartphone and example dot org, both channels are being encrypted, but we as an attacker
have now breaking off this connection over there so we can take a look into the data and we can also
refer with them to the real application.
So we are real proxy in an HTTPS connection.
So the only attack vector regarding to this one is adding our certificate onto the client.
So that's also the explanation for this error message we got in the last video over here.
So getting this error message that this certificate has not been trusted.
So now we know the reason behind this.
And in the next video, we get rid of this message by simply installing our own certificate on our smartphone.
Then this website will be trusted and we do not get any warnings anymore.
All right.
Okay.
So in case if you have any questions regarding to this topic over here, then yeah, please write me
a message.
I'm super glad, as always, if I receive some feedback on this one over here.
Okay.
Otherwise, I'm looking forward to see you in the next video.