I'm trying to understand how would a man-in-the-middle attack affect my web server.

I have a self-signed certificate. This certificate can be faked through the man-in-the-middle attack, which means that everything that I send from the browser will be intercepted and modified?

If the request gets modified, than it won't be decrypted by the web server since the certificate on the server is different. Is this correct?

The request sent from the browser can be intercepted and may get re-directed, but the data on my server won't be affected, is this correct?

I'm starting to understand the theory behind certificates, but it would be great if someone could provide a real world example of the man-in-the-middle attack and to see what problems it caused.

Thank you


As I stated in my previous answer to your question, man-in-the-middle attacks (if successful) can own all the data passed back and forth for an encrypted channel.

Certs, both self-signed and issued from a trusted root, can be faked, so don't be lulled into a false sense of security if you issue one to your users from a trusted root. The only issue I have to overcome with one issued by a trusted root, is getting your user to accept mine when I've arp-poisoned their computer. If you think about most end users, how easy would this be?

Can you see the problems now?

Once the end-user accepts MY cert, I own the connection from that point forward and all data passes through my machine.

  • Not sure I get your point here. Attackers can attempt to fake certificates, but they can't forge the signature (there may be collision attacks with MD5 but SHA-1 is still reasonably reliable). If you arp-poison the user's machine, you may get their browser to be redirected to your fake certificate, but it won't pass the verification... unless the user chooses the ignore the warning, which is indeed possible. – Bruno Sep 9 '10 at 21:11

Basically what happens is this you have self signed your cert so you have no way to prove that it is valid. So it encrypts traffic just fine but you can't prove it is yours. If a hacker can get between your site and the user's computer and intercept traffic he can decrypt the traffic and read what is going on. (He can also do this be registering a domain name that is similar to yours and waiting for a typo or sending out and e-mail that directs them to his site and not yours)

User ****** Hacker **** Your website

The reason he can do this is that he can present a self signed certificate as well. Then the user is really in communication with the hacker and not you. The user can't tell the difference. In fact if he wants the Hacker can the re-encrypt the traffic and send it back to your site and start his own communication stream with your site using the users credentials. Or just watch the traffic in the clear as it moves back and forth.


It's not that he can modify traffic. It's that the SSL handshake begins unencrypted, and the server sends an SSL certificate for the client to use from that point onwards. If the attacker is there from the beginning, he can replace this initial certificate with his own, and then use the one the server sent to encrypt/decrypt traffic to/from the server, using his own certificate to send it to you.
If the certificate is signed by a certificate authority, it's a little harder to replace it with a fake one that's also signed by a CA. The attacker can easily replace this certificate with a self-signed one however, hence the warning.


There are two points to consider when verifying a certificate:

  • verifying it has been emitted by an entity you trust, and
  • verifying it matches the identity of the server you're trying to contact.

CA-issued certificates

The Public Key Infrastructure using X.509 cert. specification defines the structure to put in place for this. It's a hierarchical model where you get a tree, the root of which are Certification Authorities (CA) and its leafs are the end-entity certificates (in particular server certificates).

The root CA certificates tend to be self-signed. A bunch of them are included by default in your OS or browser. That's the "leap of faith" part, where you trust your OS/browser vendor to have vetted the CAs to do their job properly. Some of the big commercial CAs are Verisign, Thawte, ...

A CA may then sign other certificates. You can verify a certificate you've never seen before by checking whether it has been signed by a CA you trust. There may also be intermediate CAs. For example, the certificate for https://www.google.com/ has been signed by "Thawte SGC CA", which has itself been signed by "VeriSign, Inc./Class 3 Public Primary Certification Authority" (I'm shorting the names here to simplify). The job of the CA is to verify (by means external to the PKI) that the person/institution to which it issues the certificate is the legitimate owner of that host name (e.g. www.google.com here). The way this out-of-band verification varies, for non-EV certificates, this is often done simply by sending an e-mail to the address that registered the domain name (available in the whois directory).

Once this is done, suppose you don't know whether to trust https://www.google.com/, the client verify this certificate against the trust anchors it has (the CAs, often pre-imported by OS/browser vendors). If you connect to www.google.com, the browser gets the certificate and is then able to work out the chain up to the top issuer (there's an issuer entry in every certificate), until it finds one it trusts (in this case the one from Verisign). So far, so good, the certificate is trusted. The second step consists of checking that this certificate is indeed for this machine. For HTTPS, this is done by checking that the hostname is in the subject alternative name extension of the certificate, or as a fallback, that it's in the "Common Name" (CN) entry in the subject distinguished name. This is explained in RFC 2818 (server identity).

Here the possible attempts to attack are as follows:

  • The attackers forges a certificate (for that hostname or not), with their own CA. Since their CA isn't recognised by your browser the certificate won't be verified. Even if they faked the issuer name, they wouldn't be able to fake the signature (because you verify using the public key using the CA certificates you already trust). One of the biggest problems here was in the strength of the signature: collision attacks have been demonstrated using the MD5 digest algorithm, so CAs now use SHA-1 instead, which is considered more robust. If you consider RSAwithSHA1 or DSAwithSHA1 to be sufficiently robust, you shouldn't have a problem there.
  • The attackers get a legitimate certificate from a well-known CA, but for a different host name (as a CA shouldn't emit to someone else). Let's say they get www.example.com. You're trying to connect to www.google.com, they redirect the traffic to their box, which will show a certificate that will be verifiable by a CA you trust, but for www.example.com. This is where the host name verification is important. Your browser will warn you that you're not connected to the host you intended.

This system is designed to ensure that, if a MITM redirects the traffic to their machine, the client will not accept the connection. This is of course only valid if the user doesn't ignore the warnings shown by the browser.

Self-signed certificates

It's the same principle, except that you're the CA, and this self-signed cert may also directly be the server certificate. If you create your own self-signed certificate and put it on your machine, you can also import it in your browser as a trusted authority, in which case you follow the same procedure as described above.

Some browsers, like Firefox, will let you add permanent exceptions to these rules. If you know, by some other means (e.g. the admin gave you in person the certificate), what the certificate for the machine you want to connect to is, you can choose to trust them explicitly, even if they haven't been signed by a CA you trust or if the name doesn't match. Of course, for this, you do need to know a priori and explicitly what this particular certificate should be.

If in either cases, the user chooses to ignore the warnings and accepts to be redirected to a connection with an untrusted certificate, then the MITM (with that untrusted certificate) can see/redirect/alter the traffic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.