How to defend data from MITM attacks over HTTPS?

Question

I'm working on corporate API, that is available for corporate services, where MITM can have terrible consequences.

We decided to use HTTPs instead of HTTP, but after googling i understood that SSL only is not enough.

As i understand, there are two main vulnerabilities while using SSL: 1) There are many CA provider companies now, so nobody is protected from MITM attack, where normal certificate is used by crackers (i found some articles, where it was said that VeriSign had secret department, that was providing secret services for MITM, when VeriSign was the only CA worldwide) 2) Most MITM attacks are possible while using ARP Cache Poisoning

So, i can see only one solution for a moment but not sure if it is a best practice: As API is internal, i can use following things: 1) Encrypt data with symmetric encryption algorythm 2) Limit ips, that are able to use API (as in application, as in server firewall)

Is this enough? maybe there are other best-practices to make really secure connection, that will make MITM impossible?

If this solution (SSL + symmetric encryption algorythm) is ok, could you please advice most suitable encryption algorithms for this kind of issue?

Thanks in advance, will be glad for any help/advices.

UPD: VPN (adviced by frenchie) is not suitable in this context

UPD2: Public-Private key (RSA-alike) is possible (thx 2 Craigy), but very expensive on server side.

Answer 1

We decided to use HTTPs instead of HTTP, but after googling i understood that SSL only is not enough.

I'm not sure what you've googled, but SSL/TLS, when used correctly, can protect you against MITM attacks.

If this solution (SSL + symmetric encryption algorythm) is ok, could you please advice most suitable encryption algorithms for this kind of issue?

Encryption in SSL/TLS is already done using symmetric cryptography. Only the authentication is done via asymmetric cryptography.

As i understand, there are two main vulnerabilities while using SSL:

1. There are many CA provider companies now, so nobody is protected from MITM attack, where normal certificate is used by crackers (i found some articles, where it was said that VeriSign had secret department, that was providing secret services for MITM, when VeriSign was the only CA worldwide) 2) Most MITM attacks are possible while using ARP Cache Poisoning

Protecting against MITM attacks is exactly the purpose of the certificate. It is solely the responsibility of the client (a) to check that HTTPS is used when it's expected and (b) to check the validity of the server certificate.

The first point may be obvious, but this is the kind of attacks that tools like sslstrip do: they're MITM downgrade attacks that prevent the user to get to the HTTPS page at all. As a user, make sure you're on an HTTPS page when it should be HTTPS. In a corporate environment, tell your users they must check that they're accessing your server via HTTPS: only they can know (unless you want to use client-certificate authentication too).

The second point (the certificate validation) is also up to the client, although most of it is automated within the browser. It's the user's responsibility not to ignore browser warnings. The rest of the certificate validation tend to be done via pre-installed CA certificates (e.g. Verisign's).

If there's an MITM attack taking place (perhaps via ARP poisoning), the user should be get an incorrect certificate and should not proceed. Correct HTTPS verifications should allow you to have a secure connection or to have no connection at all.

The vulnerabilities you're mentioning have to do with the certificate verification (the PKI model). Indeed, verifying that the server certificate is correct depends on the CA certificates that are trusted by your browser. There, any trusted CA could issue a certificate for any server in principle, so this model is a good as the weakest CA in the list. If one a the trusted CAs issues a fake certificate for a site and gives it to another party, it's as good as having a passport office issuing a real "fake" passport. It's quite tricky to counter, but there are ways around it.

• You could rely on extensions like the Perspective Projects, which monitor certificate changes, even if both are trusted. Such a warning should prompt the user to investigate whether the certificate change was legitimate (done by your company) or not.

• More radically, you could deploy your own CA, remove all the trusted CA certificates from the user browser and install only your own CA certificate. In this case, users will only be able to connect securely to machines that have certificates issued by your CA. This could be a problem (including for software updates if your browser uses the OS certificate repository).

• In principle, you could avoid certificate altogether and use Pre-Shared Keys cipher suites. However, this is not supported by all SSL/TLS stacks, and not necessarily adapted for HTTP over TLS (lacking specification regarding the host name verification, as far as I know).

You may also be interested in these questions on Security.SE:

• How to roll my own security mechanism - avoid SSL
• What is an SSL certificate intended to prove, and how does it do it?