将OpenSSL添加到现有应用程序中

时间:2014-01-06 18:54:04

标签: ssl openssl

我正在向现有应用程序添加SSL支持(目前正在推进OpenSSL)。在阅读大量文章和观看视频之前和之后,我从未对密码学做过任何事情我仍然对如何根据我的具体情况实施它感到困惑。

我们的软件是客户端/服务器,最终用户购买两者并将其安装在他们的场所。

我的第一点困惑是关于证书和私钥,以及如何管理这些。我应该有一个随应用程序一起安装的证书吗?每个最终用户是否应该生成自己的证书?私钥怎么样?我是否将私钥烘焙到服务器二进制文件中?或者是否应该有一个带私钥的文件?

我确定这是一个已解决的问题,但我不太确定在哪里查找,或者搜索什么。

感谢您提供任何帮助和建议。

1 个答案:

答案 0 :(得分:5)

  

将OpenSSL添加到现有应用

如果您需要的只是SSL / TLS客户端的示例,请查看OpenSSL的wiki和TLS Client示例。


  

我的第一点困惑是关于证书和私钥,以及如何管理这些。

是的,密钥管理和分发是crpyto中最难的问题。

公共CA拥有涵盖这些做法的具有法律约束力的文件。它们被称为认证实践声明(CPS)。你可以和他们一起玩得很开心,因为公司律师告诉你你不想听到的(或者营销部门拒绝告诉你)。

例如,这里摘录自Apple Inc. Certification Authority Certification Practice Statement

2.4.2. CA disclaimers of warranties
To the extent permitted by applicable law, Subscriber agreements,
if applicable, disclaim warranties from Apple, including any
warranty of merchantability or fitness for a particular purpose.

2.4.3. CA limitations of liability
To the extent permitted by applicable law, Subscriber agreements,
if applicable, shall limit liability on the part of Apple and shall
exclude liability for indirect, special, incidental, and
consequential damages.

因此,Apple向您出售没有保修的产品,并且不承担任何责任!而且他们希望你信任他们并给他们钱......真是个球拍!而且不只是苹果公司 - 其他CA也同样具有淫秽的CPS。


  

我是否应该随应用程序一起安装一个证书?

这取决于。如果您正在运行自己的PKI(即,您是CA并控制根证书),则将您的根X509证书与您的应用程序一起分发,而不是其他任何内容。无需信任任何其他CA,如Verisign或Startcom。

如果您正在使用其他人的PKI(或RFC 5280中指定的Internet的PKI),则仅分发验证链所需的根X509证书。在这种情况下,您将分发一个CA的根X509证书以进行验证。但是,您可能只信任该特定CA签署的任何证书(如果您不小心,它可能会成千上万的话)。

如果您事先不知道,那么您必须像浏览器一样,选择一堆CA来信任并随身携带您的应用程序的根证书。例如,您可以从Mozilla中获取它们的列表。但是,您可能只信任所有CA签署的任何证书(如果您不小心,它可能会在数百万的证书中出现)。

使用像浏览器这样的公共CA还有很多,你应该阅读Peter Gutmann的Engineering Security。特别注意安全多元化战略。

当客户端连接到您的服务器时,您的服务器应将其X509证书(叶证书)和构建有效链所需的任何中间证书发送回您分发的根证书。

最后,您可以从Startcom的Eddy Nigg获得大多数主流浏览器(包括移动设备)信任的免费SSL / TLS证书。他指控撤销(如果需要),因为这是成本所在。如果不需要,其他CA会向您收取费用,并将收益收入囊中。


  

每个最终用户是否应该生成自己的证书?

这也是可能的。这称为客户端证书或客户端身份验证身份验证。理想情况下,您将运行自己的PKI,因为(1)您控制所有内容(包括CA操作),并且不需要信任组织外的任何人; (2)每个用户的证书都有商业CA签名可能会很昂贵。

如果您不想使用客户端证书,请查看PSK(预共享密钥)和SRP(安全远程密码)。两者都使用RSA密钥传输击败了经典X509。 PSK和SRP这样做是因为它们提供了相互身份验证和通道绑定。在这些系统中,客户端和服务器都知道密码或密码,并建立了信道;或者一个(或两个)不知道并且通道设置失败。纯文本用户名和密码永远不会像在RSA传输和basic_auth方案中一样放在网上。 (我更喜欢SRP,因为它基于Diffie-Hellman,并且在一些系统中实现了它。)


  

私钥怎么样?

是的,您需要管理与证书关联的私钥。您可以(1)将它们存储在具有权限或ACL的文件系统中; (2)将它们存储在Keystore或Keychain中,如Android,Mac OS X,iOS或Windows; (3)将它们存储在硬件安全模块(HSM)中;或者(4)使用Key Management Interop Protocol(KMIP)将它们保持在线状态进行远程存储。

注意:如果没有解决方案,服务器上的无人值守密钥存储是一个问题。例如,参见Peter Gutmann的Engineering Security,第368页," Wicked Hard Problems"和#34;没有解决方案的问题"。


  

我是否将私钥烘焙到服务器二进制文件中?

没有。您可以在需要时生成它们,然后使用您可以提供的最佳保护来存储它们。


  

或者是否应该有一个带私钥的文件?

是的,就像那样。见上文。


  

我确定这是一个已解决的问题,但我不太确定要查找的内容或搜索内容。

由于密钥分发问题,我不确定我是否真的称其为解决方案。

有些实现非常糟糕,所以你可能想知道代码是如何通过生产的。

您可能想要的第一件事(因为您专注于密钥管理)是对密钥管理的一种处理"和#34;关键层次结构"。

您可能还需要一些参考资料。从安全工程的角度来看,阅读Gutmann的Engineering Security和Ross Anderson的Security Engineering。从实施的角度来看,抓取Network Security with OpenSSLSSL and TLS: Designing and Building Secure Systems的副本。