All right.
So here we are back on our set up.
And this time we are not talking about the smartphone.
So a web browser that is making HTTPS requests, we are talking about an application that is making
an HBS request and there might be a little bit of a difference in there.
That's also why I have chosen the spicy title is Certificate Pinning Better than HBS.
And we will get back to this later on.
For now, let's have a look at this one over here.
So we've got our smartphone and the smartphone is now an application explorer APK and this application
wants to perform a HBS request.
Therefore at the back end, this example dot com is now presenting the certificate if an client connects
to this one.
All right, we have seen that's absolutely no problem.
We just simply present our certificate and we also install the certificate on the smartphone.
By doing this, we should be pretty good to go to inspect, analyze and manipulate this traffic right
now.
Right.
Well, let's see.
So the application wants to make this request right now, and the application tells us simply no.
And I mean, wait, what?
Why?
So we are screaming back to this application over here.
Hey, you even didn't try to look up the certificate I'm presenting to you right now, and the application
simply answers.
You, even if you have sneakily installed your certificate onto the smartphones or within the user or
the system storage.
I even won't trust you right now, so get out of my way.
In the last part, I mean, should have been a little bit deeper voice, but I guess we get this point
of this application.
This application is telling us, get out of my way in this application so it doesn't trust the system
storage or the user storage.
Regarding to the certificates, we can think of this as the most paranoid application we are facing
right now.
All right.
Okay.
So how is this application then, verifying if it's connected to.
Yeah, in fake system or the real system?
Well, there are two options for the developer right now to achieve this over here.
The first one is the developer simply includes the certificate into the application itself.
So within the assets or the raw storage or whatever, the developer wants to put this into this right
now.
So if this certificate has been included into the application, then the developer is making a web service
request in his request and it proves if this corresponding certificate so the endpoint matches this
certificate over here, there are some key features in the certificate that can be verified and that
cannot be faked by an attacker.
So that's the first approach, how the developer can verify that the endpoint is really the server of
the developer.
Not something sneaky like an attacker over here OC.
The second approach is regarding to some some parts in the certificate that cannot be faked as an attacker.
For example, the signature the signature is being complexly generated.
There's a lot of stuff involved in doing this and there's a lot of cryptographic stuff that that verifies
that this signature over here cannot be faked by an attacker.
So an attacker cannot have its own certificate and the same signature.
This type of attack is named hash collision.
And yes, it has been proven in the past that this has been successful, but only theoretically and
only for weak algorithms like SHA one or NDI five.
The developer has chosen a proper algorithm.
Then this cannot be done right now.
It might be possible in 1015 years when we have some fancy quantum computers, but not right now.
So the developer can rely on the signature.
If this value is represented in the certificate, then it's the certificate of the developer.
So that's the second approach, how the developer can verify if this is the corresponding endpoint.
And now let's get back to the spicy question.
Is this approach no better than HTTPS?
I mean, even if the attacker can place the own certificate into the system storage, the application
doesn't accept it.
So at least it sounds to be more secure right now, isn't it?
Well, I do not want to go too deep into this question, but we have to consider some things.
Installing a certificate on a smartphone over here requires a lot of tasks being involved.
This is something that doesn't happen suddenly.
So there are a lot of barriers in our way to perform this task, and we can now argue that we are also
having the same barriers regarding to certificate pinning so an attacker can bypass the certificate
pinning.
And you will also see how we can do this later on.
And this means no matter if you want to patch certificate pinning on an application over here or installing
a certificate on the smartphone, there are some really strong security concepts in our way that needs
to be bypassed and the effort might be the same.
But to be honest, my point of view is the following certificate pinning doesn't weaken your application
security, and therefore it also doesn't hurt implementing it.
It also doesn't mean that it's now being more secure than a normal HTTPS connection, but in total I
would recommend implementing a certificate pinning.
So that's my point of view.
But of course this has to be the correct view.
So at the end, I mean, it goes down.
If you can represent this topic with your opinion logically to the customer, then I mean, everything
is fine about this one.
So yeah, if you have any question regarding to this topic, then please write me a message.
I'm super happy to discuss this together with you.
All right.
Okay, nice.
So now we have seen what certificate pinning is, and we have seen that simply installing our certificate
on the smartphone doesn't solve this issue right now.
Therefore, let's have a look how we can bypass it.
All right.
Okay.
And the nice thing about this one is if you talk about this one, we already figure out what's the solution.
So how can we circumvent this certificate pinning over here?
Now, let's recap this a little bit.
The application doesn't trust the system or the user storage of the internal certificate.
Storage of this smartphone absolutely fail.
And therefore the developer has to add its own certificate into the smartphone application like this
one over here.
What the developer has to hardcoded the fingerprint of the of the correct certificate into its own application.
So the bypass for this one is, I guess, replacing those values.
Absolutely.
And this is exactly what we want to do.
So we decompile this application.
And then first we have to figure out how the certificate pinning is being established.
If it isn't certificate, we might spot the certificate directly in the assets or all directory.
And if it's the fingerprint, then we will also see how we can get into this point very quickly by reversing
this application for certain keywords.
No matter what it is, it has to be included in this application code.
So our approach is simply decompile reversing and then patching this application code.
And you know what?
We are now smiley experts.
So this is absolutely no problem for us right now.
Nice, isn't it?
And therefore, I would suggest let's finish this theory part over here.
And in the next video, we have some hands on exercises.
I will introduce you these two types of certificates, paintings.
I have written some really amazing apps regarding to this one.
Okay.
They have a little bit of a lack of UI, but regarding to the implementation, that's exactly what you
face outside here.
So in the real world and these are now two real world applications and therefore, I'm looking forward
to see you in the next video.