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.
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?
If you want to defend against Man-in-the-middle attacks then you are correct that that using symmetric key cryptography would prevent data from being compromised by a third party. However, then you are faced with the problem of distributing the keys, which is one reason asymmetric key cryptography is appealing.
To defend against MITM attacks while using asymmetric key cryptography on your network, you could set up a Public-key infrastructure of your own. You would set up and manage a Certificate Authority and disable all others so nobody could pretend to be someone else, thereby preventing MITM attacks. If the CA was compromised then MITM attacks would again be possible.
Just to make sure we're on the same page, these suggestions are implementation independent. You could use any Symmetric-key algorithm for the first suggestion.
For the second suggestion you would need a more complicated system, which is called asymmetric or Public-key cryptography. These are built on algorithms like RSA.
SSL is a protocol that uses Public-key cryptography for the key exchange and symmetric cryptography for sending messages.
Properly defending against a man in the middle attack requires two things:
- Never serve your website over HTTP; only listen for HTTPS traffic
- Use the Strict-Transport-Security header in responses with a long time to live
The ARP poisoning with SSLStrip attack relies on the browser initiating an HTTP connection with the server and transitioning later to HTTPS. It is at this transition point that the attack takes effect.
However, if the browser initiates the request as an HTTPS request, then the handshake authenticates the server to the browser before anything else happens. Basically, if a man-in-the-middle attack is taking place, the user will be notified that the SSL connection could not be made, or that the server is not the correct server.
Never serving your website over HTTP forces anyone linking to it to use HTTPS in the link. The Strict-Transport-Security header instructs compliant browsers to convert to HTTPS any attempt to communicate over HTTP to your server.
For your use case, it seems that any other solution other than the two recommendation above will be overkill. To read more on Strict-Transport-Security, see the Wikipedia article on Strict-Transport-Security.
