无需证书的 SSL/TLS
我正在开发一个宠物项目，该项目（最终完成后）将允许安全文件传输（不仅仅如此，但其余的并不是特别相关）。我想使用 OpenSSL 库，因为它似乎是最完整的免费加密库（除了 SSL/TLS 之外，我还需要支持基本的对称加密和哈希）。
我正在寻求实现一个类似于 SSH 的安全方案。基本上，用户会使用 TLSv1 (SSLv3.1) 连接到我的计算机。无论安全性如何，我都希望连接成功。然后，我希望能够检查用户使用的公钥（不是整个证书）。该密钥将与已知的公钥进行比较，如果匹配，则用户将被允许访问一组特定的命令。如果不匹配，用户可以选择使用该连接来申请将他/她的公钥添加到我的集合中，但除此之外将无法访问我的服务。
我这里对证书没有任何特别的需要。如果我可以跳过所有证书详细信息并仅使用原始加密密钥，那么对我来说会简单得多。这是因为该模型遵循信任网络模型，而不是大多数 SSL/TLS 连接使用的分层模型，因此我不需要任何 CA 或签名证书。
不幸的是，大多数 OpenSSL 的文档都不存在。我发现的所有相关文章似乎都专注于设置“标准”SSL/TLS 连接，其中服务器的证书一直被验证到一组根证书。这可能很有用，但我很难弄清楚如何启动并运行这些非传统 SSL 连接。
任何人都可以建议任何文章或文档来帮助我弄清楚如何实现这一目标吗？
（OpenSSL 的使用并不是一成不变的，如果它提供了更好的方法来实现这一点，我可以切换到另一个库，以及散列 [SHA-512] 和对称加密 [AES]。我的目标是Linux，但如果最终产品可以移植到 Windows，这样我的朋友也可以使用它，那就太好了。）
I'm working on a pet project that will (eventually, when it's done) allow for secure file transfers (there's more to it than just that, but the rest isn't particularly relevant). I'd like to use the OpenSSL library, since it seems to be the most complete free cryptography library (and I need support for basic symmetric encryption and hashing, in addition to SSL/TLS).
I'm looking to implement a security scheme similar to SSH. Basically, a user would connect to my computer with TLSv1 (SSLv3.1). I'd like the connection to succeed regardless of security. Then, I want to be able to inspect the public key (not an entire certificate) that the user used. That key would be compared against known public keys, and if it matched, then the user would be allowed to access a certain set of commands. If it didn't match, the user would have the option to use the connection to apply to have his/her public key added to my collection, but other than that would not be able to access my services.
I don't have any particular need for certificates here. It would be much simpler for me if I could just skip all the certificate details and work only with the raw encryption keys. This is because this model follows a web-of-trust model, not the hierarchical model used by most SSL/TLS connections, so I don't need any CA's or signed certificates.
Unfortunately, the documentation of most of OpenSSL is, well, nonexistent. All the relevant articles I find seem to be occupied with setting up a "standard" SSL/TLS connection, where the server's certificate is verified all the way up to a set of root certificates. This can be useful, but it's hard for me to figure out how to get these non-traditional SSL connections up and running.
Can anyone suggest any articles or documentation that might help me figure out how to accomplish this?
(The use of OpenSSL is not set in stone, and I could switch to another library if it provides a better way of accomplishing this, as well as hashing [SHA-512] and symmetric encryption [AES]. I'm aiming at targeting Linux, but it would be nice if the final product was portable to Windows so my friends could use it too.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为了扩展尤金的答案（我会把它作为评论，但有点长）......
用 FOAF+SSL 项目（后来更名为 WebID），坚持使用 X.509 证书可以使实施更容易，因为大多数 SSL/TLS 堆栈在设计时都考虑到了它们（并且他们的API 反映了这一点）。
上次我检查FOAF+SSL时，客户端仍然使用传统的PKI检查来检查服务器证书。另一种选择与 SSH 类似，是在第一次遇到公钥/证书时接受它，并在其更改时警告用户。无论如何，这或多或少就是 SSH 的工作方式（特别是，我猜很少有人在第一次看到密钥指纹时会真正检查它）。
仅考虑客户端证书的使用（尽管其中一些可以以类似的方式应用于服务器证书）：
X509TrustManager（Java 中的 X509TrustManager）。openssl或keytool命令的用户来说很方便。 这里是一个示例服务，它将使用用户想要的 SAN 颁发证书（可能还有更多最新版本（如果您检查 FOAF+SSL/WebID 项目）。无论此类服务使用哪个私钥或颁发者名称都无关紧要，但由于浏览器是围绕传统 PKI 设计的，因此使用真正的自签名证书并不容易。在要求特定的客户证书时也存在问题。 TLS 1.1 规范明确允许空
证书颁发机构（请参阅RFC 4346），而 TLS 1.0 对此主题保持沉默。实际上，即使使用 TLS 1.0，大多数客户端工具似乎也对空列表感到满意（它们只是提供更多选择）。如果您希望系统的证书易于识别，您可以对所有这些证书使用相同的颁发者 DN，即使它们在实践中没有使用相同的私钥进行签名（同样，因为您会忽略签名）。To expand on Eugene's answer (I would have put this as a comment, but it's a bit long)...
Having done this sort of things with the FOAF+SSL project (later renamed WebID), sticking with X.509 certificates makes the implementation easier, simply because most SSL/TLS stacks are designed with them in mind (and their API reflect this).
Last time I checked FOAF+SSL, the traditional PKI checks were still in place for the client to check the server certificate. Another option, similar to SSH, would be to accept the public key/certificate the first time you encounter it and warn the user when it changes. That's more or less the way SSH works anyway (in particular, I guess that few people actually check the key's fingerprint out of bands the first time they see it).
Considering just the client-certificate usage (although some of this could apply to server certs in a similar way):
X509TrustManagerin Java).opensslorkeytoolcommands. Here is an example service that will issue a certificate with the SAN the user wants (there might be more recent versions if you check with the FOAF+SSL/WebID project). Whichever private key or issuer name such a service uses barely matters, but since browsers are designed around traditional PKIs, it doesn't make it easy to use really self-signed certificates.There are also issues when it comes to asking for a specific client-certificate. The TLS 1.1 specification explicitly allows empty
certification authorities(see RFC 4346), whereas the TLS 1.0 were silent on the subject. In practice, even with TLS 1.0, most client tools seem to be happy with an empty list (they'll just offer more choice). If you want your certificates for your system to be easily identifiable, you could use the same issuer DN for all these certs, even if they're not signed with the same private key in practice (again, since you would ignore the signature).使用自签名证书 - 这与“原始”密钥相同，但更易于管理（请参阅 这个问题关于如何在openssl中接受或不接受自签名证书）。
Use self-signed certificates - this is the same as "raw" keys but easier to manage (see this question regarding how to accept or not accept a self-signed certificate in openssl).