4

I have another question to security in the web. If I understand it correctly certificates are for identify who you really are. So the man in the middle attack isn't possible. But when I see this image:

http://upload.wikimedia.org/wikipedia/commons/thumb/2/2b/Digital_Signature_diagram.svg/800px-Digital_Signature_diagram.svg.png

I think a man in the middle attack is possible. You could split the Signature, the certificate from the data. Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.

What I also not understand in this picture is where the certificate gets checked, on the verification side.

thanks.

SCBoy

SCBoy
  • 545
  • 8
  • 19

1 Answers1

6

Make your own signature with your fake data and send the fake data with the fake signature (but the right certificate) to the server/client.

The problem is that the receiver will then look at the fake signature and see that it does not match the certificate of the real sender.

You can only create signatures that match a given certificate when you have the correct private key for that certificate (even though the certificate itself is public, that is the magic of asymmetric cryptography). This private key is being kept secret by the owner of the certificate (the original sender of the message).

The man-in-the-middle is prevented by distributing trusted certificates in advance. You have to trust the authenticity of the certificates, either by trusting them directly (root certificates) or by trusting a chain of signatures on the certificate leading up to one that you trust.

If the man in the middle can make you believe that his fake certificate is the real deal, then the whole system fails.

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • But why do the certificate match to the signature. In the picture from wikipedia the signature gets created from the data and not from the certificate? I dont see the context between certificate and signature. – SCBoy Oct 15 '10 at 08:04
  • The signature is created using the data and your private key (which is linked to the certificate, the certificate contains the matching public key). – Thilo Oct 15 '10 at 08:05
  • Just to clarify, it's the private key of the issuer that's used to sign a given certificate. – Bruno Oct 15 '10 at 10:04
  • And the private key of the certificate owner that is used to sign the message. – Thilo Oct 15 '10 at 10:06
  • 1
    One other question I had from reading your description: it sounds like it is the client's responsibility to verify the certificate correct? I only control the server side, and could verify certs on my side, but this would not prevent the man in the middle attack if the client was sloppy and did not verify right? Was wondering if any companies when designing APIs have a way to ensure validation on the client side, or maybe an example where they made it easy/well documented. Thanks for the response! – Brian Armstrong Aug 05 '12 at 19:43
  • 1
    Yes, the client needs to verify the certificate. Your SSL software stack does that by default. But sometimes people turn it off (because dealing with self-signed or expired certificates is too "troublesome" for them). And the client has to be able to trust that the root certificates are authentic. As the server, you cannot ensure (I think) that the client really does all that. A completely locked-down device like an iPhone is as close as you can get. – Thilo Aug 06 '12 at 00:00