gpt4 book ai didi

java - Java 中服务器端 SSL 的概念概述

转载 作者:搜寻专家 更新时间:2023-10-31 20:14:26 29 4
gpt4 key购买 nike

就目前而言,这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持,但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开,visit the help center为指导。




8年前关闭。




我的任务是使用 HTTPS 保护(以前是 HTTP)Web 服务。我从现在离职的同事那里继承了插入 SSLEngine 的代码。我们现有服务器中 TCP 和 HTTP 层之间的对象。据我所知,这段代码可以正常工作。我收到了 SSLEngine来自 SSLContext.createSSLEngine() ,但如何产生合适的SSLContext让我困惑。
SSLEngine它本身在它的 javadoc 中有一个漂亮的概念介绍,但不幸的是我不需要与自己接口(interface)的部分。另一方面SSLContext.init()文档很少,只是说我必须通过“身份验证 key 的来源”和“对等身份验证信任决定的来源”,而我不知道那是什么。这些参数类型的文档(通常我下次尝试理解它)是通用的,什么都不说,还有 SSLContext 的类文档。也是无用的简短。

我有一堆ascii-armored .crt , .pem , 和 .key这些文件一起使 Apache 能够在 Java 服务器最终将直接处理的域中提供 HTTPS。我想我需要将它们加载到 SSLContextSSLEngine不知何故,但不确定是否SSLContext.init()甚至是正确的地方(尽管似乎没有很多其他地方可能)。

Which documentation should I start by reading to get a working understanding of how to do this?



我的 Google 尝试生成了许多质量和安全性未知的半无文档示例代码,以及一些高级演练,例如“如何编写自己的 key 提供程序”,但没有对 JRE 最基本使用的整体概念性介绍类。

特别是因为这是与安全相关的,我没有使用复制粘贴示例代码,我只会漫无目的地敲打,直到它似乎或多或少地做我想要的。我需要对各个部分实际上应该如何组合在一起有一个高层次的概念性理解。

(如果文档足够详细,可以让我弄清楚如何在实践中进行 SSL 客户端授权,那就加分了——但这并不紧急)。

最佳答案

如果您需要详细的文档,请查看 JSSE Reference Guide ,更具体地说是它的 SSLContext section .

默认值(如果您将 null 传递给 SSLContext.init(...) )在默认情况下是合理的,但您可能想了解这些默认值是什么(参见 Customization 部分)。

keystore 没有默认值(只有信任库,如果您想要客户端证书身份验证,您几乎肯定会希望对其进行自定义)。

通常,您可以初始化 SSLContext如下:

KeyStore ks = KeyStore.getInstance(...); // Load the keystore
ks.load(...); // Load as required from the inputstream of your choice, for example.

KeyStore ts = KeyStore.getInstance(...); // Load the truststore
ts.load(...);

KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(ks, <the key password>);

TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
tmf.init(ts);

SSLContext sslContext = SSLContext.getInstance("TLS");
sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

或许您也对 this answer感兴趣 keystore 和信任库之间的区别。简而言之,两者都是存储意义上的“ keystore ”,但 keystore 是您存储证书(+链)和相关私钥(即服务器上的服务器证书和私钥以及客户端证书和私钥)的地方在客户端上)并且信任库是您存储 CA 证书或远程证书(没有私钥,因为它们不是您的证书)的地方,当远程方出示其证书时,您愿意信任这些证书。

关于如何处理您的 key /证书文件,最简单的当然是使用类型 PCKS12 的 keystore 。 ,您可以按照 this answer 中的说明进行构建.

编辑: (以下评论)

So is it correctly understood that I can get away with a null TrustManager if I'm a server and not yet doing SSL client authentication?



是的。

But that if I were to do cliemt authentication I need to provide a TrustManager that contains the public keys of every client that should be able to connect?



通常不会。您将为颁发这些客户端证书的 CA 提供 CA 证书。如果您没有这个基础设施(或者如果您正在构建它并且还没有任何客户端证书),您应该考虑创建自己的 PKI,或者从知名 CA 购买客户端证书。

您还可以构建一个接受自签名证书(独立于任何 CA)并使用来自预定义列表的指纹验证它们的 TrustManager,但这会带来许多问题(特别是服务器如何请求正确的证书) ),并且您最终可能会复制 PKI 的部分用途。除非您更了解自己在做什么,否则我不建议这样做。

That's a bit of a downer; I had hoped I could have waited until I got the request URL before I needed to retrieve a fingerprint for the authorized client and only then compare to the fingerprint the actual client authenticated with.



在这里,你谈论的是一个完全不同的方面。如果您想先获取请求的 URL,则在请求证书之前,您需要使用重新协商。 HTTP 层必须与 SSLEngine 通信。要求它触发新的握手(现在设置为要求客户端证书)。
SSLEngine一般而言,这不是 Java 中 SSL/TLS 的简单途径,但异步重新协商可能会变得非常棘手。事实上,它的语义在应用层还不是很清楚。您很可能在收到 HTTP 请求后触发重新协商,但同时处于发送响应的中间(因为您可能有异步请求/响应,可能是流水线)。从技术上讲,新的握手会影响两个管道。

总的来说,无论是否重新协商,这与检查您如何信任客户端证书完全无关。如果你真的想让你的应用层(而不是 SSL/TLS 层)进行证书验证,你必须写一个 X509TrustManager信任任何东西(绕过 SSL/TLS 层的验证)并让您的应用程序从 SSLSession 获取证书(对等证书)并在那里进行验证。总的来说,这与接受自签名证书并更手动地验证它们非常相似。它可以完成,但您将退出 PKI 模型,并且您需要一些自定义代码来执行此操作(而不是仅使用默认情况下使用的 API)。

如果你不熟悉这一切,我会避免这种方法。也许尝试设置一个测试 CA 并首先了解它的工作原理。使用 CA 或进行手动指纹验证的整个问题最终更像是一个管理问题:它由您将如何在相关各方之间分发证书来定义。

Also, what is <the key password> doing here? This is supposed to run on an unattended server in a hosting facility somewhere; we cannot wait for someone to come around to type in a password during startup (say, after a power outage).



您需要设置密码。如果需要,大多数服务器从配置文件中读取它(或者更糟的是,您可以对其进行硬编码)。

关于java - Java 中服务器端 SSL 的概念概述,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11959135/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com