在 C# 中临时加载 SSL 客户端密钥以进行客户端身份验证
我正在使用 WebBrowser 控件将 WebInterface 添加到 C# 应用程序。 我的愿望是验证只有这样的应用程序才能使用 SSL 客户端证书连接到我们的 Web 服务器。
我的想法是将客户端证书嵌入到应用程序中，并仅在通过我的应用程序连接时使用。 有人对如何做到这一点有建议吗？ 或者使其工作的唯一方法是将密钥加载到 X509Store 中。
如果我将其放入 X509Store，我的密钥是否可用于一般 Internet Explorer 使用？
I am using the WebBrowser control to add a WebInterface to C# app. My desire is to verify that only such app is able to connect to our Web server using SSL client certificates.
My idea was to embed the client certificate in the app and just use when connecting via my app. Anybody have a sugestion on how to do this? Or the only way to make it work is to load the key in the X509Store.
If I put it in X509Store, will it make my key available for general Internet Explorer Usage?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您确定这是您想要做的吗？ 如果您将私钥嵌入到您的应用程序中（正如您的方法所需要的那样），攻击者可以提取它并使用它来验证他们的流氓软件。
服务器无法验证客户端软件。 它只能测试客户端是否拥有某些秘密。 当您将私钥嵌入客户端并分发时，它就不再是秘密了。
我建议对软件的用户进行身份验证，而不是对软件本身进行身份验证。 您需要让用户生成自己的秘密，无论是密码还是私钥，并激励他们保护它。
Are you sure this is what you want to do? If you embed the private key in your application (as your approach entails), an attacker can extract it and use it to authenticate their rogue software.
A server cannot authenticate client software. It can only test whether a client possesses some secret. When you embed a private key in your client and distribute it, it will not be a secret anymore.
I'd recommend authenticating users of your software, rather than the software itself. You need to let users generate their own secret, whether it is a password or a private key, and give them an incentive to protect it.
因此，这里有几个想法：
1.
我同意“埃里克森”的观点，验证只有您的应用程序可以与应用程序通信对于您当前的设计几乎是不可能的。 有人对您的应用程序进行逆向工程然后游戏结束只是时间问题（如果这是您唯一的安全形式）。 如果您想验证它是您的应用程序和有效用户，那么您需要对用户进行身份验证以及检查相关应用程序签名的某种机制（我认为这在客户端服务器模型中是不可能的）。 ..毕竟我总是可以撒谎说我的“hackyou”应用程序与您的“realapp”具有相同的签名，并且您无法从服务器端验证这一点）
2.
请记住，WebBrowser 控件本质上是 IE 的包装器，因此如果没有一些技巧（我将在一秒钟内介绍），您将必须将证书添加到用户存储中。
3.
这是完成您所要求的任务的一种巧妙方法（尽管这是一个坏主意）：
这本质上意味着您必须编写一些包装类来处理往返于服务器的请求和响应，并且只需使用WebBrowser 处理 HTML 的查看。
实际上，您需要重新设计并审视您要应对的威胁！
So, several thoughts here:
1.
I agree with 'erickson', validating that ONLY your app can communicate with the app is nearly impossible with your current design. It's just a matter of time before someone reverse engineer's your app and then its game over (if that's you only form of security). If you want to validate that its your app and a valid user then you need to authenticate the user as well as some mechanism of checking the signature of the app in question (which I don't believe is possible in a client-server model...after all I can always lie and say that my 'hackyou' app has the same signature as your 'realapp' and you can't verify that from the server-side)
2.
Remember the WebBrowser control is essentially a wrapper around IE, so without some tricks (which I'll get to in a sec) you would have to add the cert to the user store.
3.
Here's a hacky way to accomplish what you're asking (even though its a bad idea):
This essentially means that you will have to write some wrapper classes to handle the Requests and Responses to and from the Server and are just using the WebBrowser to handling the viewing of the HTML.
In reality, you need to redesign and look at the threats you're trying to handle!
使用密钥的目的与其说是验证用户，不如说是限制对应用程序用户的访问，而不是使用任何 Web 浏览器。 这是公共互联网上的一种内联网行为。
这是穷人的 DRM。 由于人们提取密钥而造成的损失并不那么重要。 我认为发生这种情况的风险很低，我们可能损失的也很小。
尽管如此，如果有任何其他想法将 WebServer 的访问限制为仅该应用程序的用户，我愿意接受任何建议。 基本上我现在的愿望是拥有一个完全开放的公共Web服务器以供任何人阅读，但是从不同地方通过公共网络访问是必要的，因此建立内部网基础设施也是不可能的。
The intent of using the key is not so much to validate the users as to restrict access to users of the app instead of using any WebBrowser. This is sort of an intranet behavior over the public internet.
This is a poor man's DRM. The losses due to people extracting the key are not that important. I think the risk of this happening is low and what we could loose is minimal.
Nevertheless if there is any other idea to restrict access to the WebServer to only users of the App I am open for any suggestions. Basically my desire is now to have a public WebServer wide open to be read by anyone, but access over the public network from diverse places is necessary so setting up a intranet infrastructure is not possible either.