问题描述
我工作的公司的API，这是适用于企业服务，其中MITM可以有可怕的后果。
我们决定使用HTTPS而不是HTTP，但谷歌上搜索后，我明白，只有SSL是不够的。
据我所知，有同时使用SSL两大漏洞：
1）有许多CA提供商的公司了，所以没有人会从MITM攻击，其中普通证书用于饼干的保护（我发现了一些文章，其中有人说，VeriSign公司已经秘密部门，这是为MITM，当提供秘密服务威瑞信是全球唯一的CA）
2）最MITM攻击是可能的，而使用ARP缓存中毒
所以，我只能看到一个一时解决方案，但不知道这是否是最佳做法：
由于API是内部的，我可以用以下的事情：
1）用对称加密algorythm加密数据
2）极限的IPS，即能够使用的API（如在应用中，如在服务器防火墙）
这还不够吗？也许还有其他的最佳实践，使真正的安全连接，这将使MITM不可能的？
如果这个解决方案（SSL +对称加密algorythm）是好的，请您指点最合适的加密算法对这类问题的？
在此先感谢，
会很高兴的任何帮助/建议。
UPD：VPN（由frenchie劝）是不适合在此上下文
UPD2：公私密钥（RSA-一样）是可能的（THX 2 Craigy），但在服务器端非常昂贵的。
。I'm not sure what you've googled, but SSL/TLS, when used correctly, can protect you against MITM attacks.
Encryption in SSL/TLS is already done using symmetric cryptography. Only the authentication is done via asymmetric cryptography.
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?
这篇关于如何通过HTTPS从防御MITM攻击的数据？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！