没有证书的SSL/TLS [英] SSL/TLS without certificates

问题描述

我正在研究一个宠物项目，该项目最终将在最终完成时允许安全的文件传输(不仅仅是文件传输，还有其他并没有特别的意义).我想使用OpenSSL库，因为它似乎是最完整的免费密码库(并且我需要支持基本对称加密和散列，以及SSL/TLS).

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).

我正在寻求实现与SSH类似的安全方案.基本上，用户将使用TLSv1(SSLv3.1)连接到我的计算机.无论安全性如何，我都希望连接成功.然后，我希望能够检查用户使用的公共密钥(不是完整的证书).该密钥将与已知的公共密钥进行比较，如果匹配，则将允许用户访问特定的命令集.如果不匹配，则用户可以选择使用连接申请将其公钥添加到我的收藏中，但除此之外，将无法访问我的服务.

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.

我这里不需要证书.如果我可以跳过所有证书详细信息并仅使用原始加密密钥，那对我来说将简单得多.这是因为此模型遵循信任网络模型，而不是大多数SSL/TLS连接使用的分层模型，因此我不需要任何CA或已签名的证书.

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.

不幸的是，大多数OpenSSL的文档都不存在.我发现所有相关文章似乎都涉及建立标准" SSL/TLS连接，在该连接中，服务器的证书一直进行验证，直到一组根证书为止.这可能很有用，但是对我来说很难弄清楚如何建立和运行这些非传统的SSL连接.

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?

(OpenSSL的使用不是一成不变的，如果它提供了一种更好的方法来实现此目的，那么我可以切换到另一个库，以及使用散列[SHA-512]和对称加密[AES].我以Linux为目标，但如果最终产品可以移植到Windows上，这样我的朋友们也可以使用它，那将是很好的.)

(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.)

推荐答案

扩大Eugene的答案(我会把它作为评论，但有点长)...

To expand on Eugene's answer (I would have put this as a comment, but it's a bit long)...

使用 FOAF + SSL项目(后来重命名为WebID) )，坚持使用X.509证书使实现起来更加容易，这仅仅是因为大多数SSL/TLS堆栈在设计时就考虑了它们(并且其API反映了这一点).

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).

上次我检查FOAF + SSL时，传统的PKI检查仍然存在，客户端可以检查服务器证书.类似于SSH的另一种选择是，在您首次遇到公钥/证书时接受它，并在更改时向用户发出警告.无论如何，这或多或少都是SSH的工作方式(特别是，我猜很少有人真正在第一次看到密钥时就从频带外检查密钥的指纹).

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):

• 大多数服务器库似乎都能够处理X.509证书，但是让您更改它们的验证方式(例如Java中的X509TrustManager).
• 尽管您无法通过其他方式验证客户端证书上的内容，除非您对其进行了验证，但可以嵌入一些额外的信息(例如使用者DN或使用者备用名称，以查看用户声称自己是谁) )可以帮助(a)用户组织其证书，并且(b)提示验证者知道要查找的内容.裸露的公钥可能很难管理.
• 许多现有的客户端工具(特别是浏览器)在进行SSL/TLS客户端身份验证时使用X.509证书.将客户端配置为使用自签名X.509证书(与来自PKI的证书相反)不需要太多工作. (支持TLS的OpenPGP的工具很少，我不确定是否有任何工具可以将其用作客户端证书的形式.)
• 由于没有外部检查您将无法信任证书，因此至少可以假设用户不会自签名(即，发行人和主题是否相同)都无关紧要.不会向您发送它不会同意的证书(因此不必用自己的密钥密封).这样做的结果是，您可以构建一个服务来轻松发行证书.例如，对于不想使用openssl或keytool命令的用户来说，浏览器内部密钥生成很方便. 此处是一个示例服务，它将向用户想要的SAN颁发证书(可能是较新的版本，如果您使用FOAF + SSL/ WebID 项目进行检查).不管使用哪种服务的私钥或发行者名称，都没什么关系，但是由于浏览器是围绕传统PKI设计的，因此使用真正的自签名证书并不容易.

• Most server libraries seem to be able to process X.509 certificates, but let you change the way they are verified (e.g. X509TrustManager in Java).
• Whilst you won't be able to trust anything the client-cert says until you have verified it otherwise, being able to embed some extra information (such as a Subject DN or Subject Alternative Name to see who the user claim to be) can help (a) the users organise their certs and (b) give a hint for the verifier to know what to look for. A bare public key can be hard to manage.
• A number of existing client tools (especially browsers) use X.509 certificates when doing SSL/TLS client authentication. Not much needs to be done to configure a client to use a self-signed X.509 cert (as opposed to a cert from a PKI). (There are very few tools that support OpenPGP for TLS, I'm not sure any are able to use it as a form of client certificate.)
• Since you won't be able to trust the cert without external checks, it doesn't matter whether it's self-signed or not (i.e. whether the issuer and the subject are the same), at least assuming the user wouldn't send you a cert with which it wouldn't agree (so it wouldn't have to be sealed by its own key). A consequence of that is that you can build a service to issue certs quite easily. In-browser key-generation, for example, is convenient for users who don't want to use openssl or keytool commands. 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.

在询问特定的客户证书时也存在一些问题. TLS 1.1规范明确允许使用空的certification authorities(请参阅 RFC 4346 ) ，而TLS 1.0对此主题保持沉默.实际上，即使使用TLS 1.0，大多数客户端工具似乎对空列表也很满意(它们将提供更多选择).如果您希望系统的证书易于识别，则即使所有这些证书在实践中都没有使用相同的私钥进行签名，也可以使用相同的颁发者DN(再次，因为您将忽略签名).

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).

这篇关于没有证书的SSL/TLS的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！