安全套接字连接的最佳做法 [英] Best practice for secure socket connection
问题描述
安全套接字连接（不含SSL）的最佳做法是什么。
我将通过TCP Socket连接移动敏感数据（登录/密码/帐户） ，并想知道是否有一个好的/快速的加密/解密和避免恶意注入的方式。
如果你过敏SSL，使用SSH。但原则是一样的。密钥通过非对称算法（RSA，Diffie-Hellman ...）交换，然后用于对称加密和MAC。该结构是微妙的，因此我们强烈建议您使用现有的协议，如SSL或SSH，处理棘手的细节。
在两种协议中，主要阶段发生与相互认证。 服务器部分（在连接模型中，客户端是发起连接的任何人，并且服务器是另一个机器）需要以对客户端足够令人信服的方式呈现其不对称密钥客户端希望确保它正在与正确的服务器通信，而不是其他模拟服务器的人）。在SSL中，该密钥是X.509证书的一部分。当Web浏览器使用SSL时，如果浏览器可以根据已知的信任锚（也称为根证书）对其进行验证，则认为该证书正确。这些锚点由与浏览器制造商进行交易的一些组织（例如，Verisign）管理;底线是，如果你想要一个证书，可以验证这些根证书，那么你必须从一个锚定管理器，他们不会免费。
但是，请注意，对一组已知的信任锚进行验证是浏览器的事情。由于这是为您自己的项目，您可以创建您自己的信任锚，和您自己的证书。 OpenSSL 可以帮助您。更简单的是，对客户端使用虚拟证书作为服务器，客户端只需验证服务器是否发送预期证书。
更简单的模型实际上是什么SSH。在SSH中，每个客户端应该维护自己的已知服务器密钥数据库（在Unix实现上在 $ HOME / .ssh / known_hosts 中）。当联系新服务器时，客户端将显示充足的警告，如果联系已知的服务器但不使用先前记录的密钥，则会显示更大的警告。对于许多有限规模的项目，这是一个适当的模型。具有信任锚点的X.509证书的目的是允许客户端安全地识别许多服务器，甚至在部署客户端软件时甚至不存在的服务器。如果你控制客户端和服务器比你不需要。
默认情况下SSH实现似乎更好地匹配你之前的，但SSL实现更常见特别是，我相信有一个在.NET，准备使用）。你需要做的是捕获服务器证书验证部分，并替换为您自己的简单匹配函数是确切的字节到字节证书我期待？。
What is the best practice for a secure socket connection (without SSL).
I will be moving sensitive data (logins/passwords/accounts) across TCP Socket connection, and wondering if there is a good/fast way of Encrypting/Decrypting and avoiding malicious injection.
If you are allergic to SSL, use SSH. But the principles are identical. A key is exchanged through an asymmetric algorithm (RSA, Diffie-Hellman...) then used for symmetric encryption and MAC. The construction is subtle so it is highly recommended that you use an existing protocol such as SSL or SSH, where tricky details have been dealt with.
In both protocols, a primary phase occurs with mutual authentication. The "server" part (in the connection model, the "client" is whoever is initiating the connection, and the server is the other machine) needs to present its asymmetric key in a way which is "convincing enough" for the client (the client wants to be sure that it is talking to the right server, not somebody else who is impersonating the server). In SSL, that key is part of an X.509 certificate. When SSL is used by a Web browser, that certificate is deemed correct if the browser can validate it against a known set of "trust anchors", also known as "root certificates". Those anchors are managed by some organizations (e.g. Verisign) which made a deal with the browser maker; bottom-line is that if you want a certificate which can be validated against those root certificates, then you have to get it from one of the anchor managers, and they will not do it for free.
Note, though, that validating against a known set of trust anchors is a browser thing. Since this is for your own project, you could create your own trust anchor, and your own certificates. OpenSSL can help you with that. Even simpler, use a "dummy" certificate for the server, also known by the client, and the client simply verifies that the server sends the "expected" certificate.
The simpler model is actually what SSH does. In SSH, each client is supposed to maintain its own database of "known server keys" (in $HOME/.ssh/known_hosts on Unix implementations). The client will display ample warnings when a new server is contacted, and even bigger warnings if a known server is contacted but does not use the previously recorded key. For many limited-scale projects, this is an appropriate model. The point of X.509 certificates with trust anchors is to allow clients to securely identify many servers, even servers which did not exist yet when the client software was deployed. If you control both client and server than you do not need that.
What SSH implements by default seems to better match what you are after, but SSL implementations are more common (in particular, I believe there is one in .NET, ready to be used). What you have to do is to capture the "server certificate validation" part, and replace it with your own simple matching function "is that the exact byte-to-byte certificate I was expecting ?".
这篇关于安全套接字连接的最佳做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
