如何使用 libcurl 在客户端应用程序中缓存 SSL 客户端证书密码

发布于 2024-08-13 01:42:49 字数 273 浏览 5 评论 0原文

我们有一个(多操作系统)应用程序,它使用 libcurl 与 https 服务器进行通信,并使用 SSL 客户端认证。当客户端认证受密码保护时,应用程序必须要求用户输入密码。应用程序向服务器发送数百个不同的 https 请求,因此我们不能在每次创建新连接时都要求用户输入密码。现在我们只需在应用程序启动时提示用户输入一次密码,然后通过“CURLOPT_KEYPASSWD”选项将密码设置为curlib。但我担心恶意用户可以轻松侵入正在运行的进程并读取客户端认证密码。无论如何,我可以缓存客户端认证密码并防止它被轻易地从内存中读取吗?

We have a (multi-os) application which communicates with a https server using libcurl and uses SSL client certification. When the client certification is password protected, the application must ask the user to input password. The application sends hundreds of different https request to the server, so we can not ask the user to input password each time a new connection is going to be created. Now we simply prompt the user to input password once when the application starts then set the password to curllib through "CURLOPT_KEYPASSWD" option. But I'm worrying about malicious user could easily hack into the running process and read the client certification password. Is there anyway I can cache the client certification password and also prevent it from being easily read from memory?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

染火枫林 2024-08-20 01:42:49

在现实生活中,你不应该太担心它。如果您担心此类攻击,也许可以研究一下智能卡中基于硬件的密钥和证书。

对抗交换和冷启动攻击的一些建议:

  • 锁定保存密码的内存,不允许其被换出(mlock+mprotect 在 posix 上,Windows 也有类似的功能)
  • 可能对保存密码的内存进行加密,并且仅使用密码对其进行解密。

在现实生活中,如果您的机器被拥有,以便某人可以侵入他/她不应该访问的进程 - 您已经受到损害,不知道试图使其变得模糊。

如果您认为您控制了缓存 - 再想一想 - 您永远无法知道在某些情况下,例如curl是否会使用密码复制和泄漏内存。

如果您认真对待 SSL 和安全性,请使用硬件令牌或智能卡。否则,一旦主机受到损害,您的软件和通过该主机运行的任何访问代码都会受到损害。

You should not worry that much about it, in real life. If you worry about such attacks, maybe look into hardware based keys and certificates in smart cards.

Some suggestions to fight swap and coldboot attacks:

  • Lock the memory that holds the password, don't allow it to be swapped out (mlock+mprotect and on posix, Windows also has similar functions)
  • possibly encrypt the memory that holds the password and only decrypt it while using the password.

In real life, if your machine is owned so that somebody can intrude into processes he/she should not have access to - you're already compromised, no idea trying to make it obscure.

If you think that you control the cache - think again - you can never know if curl for example copies and leaks the memory with the password, under some circumstances.

If you're serious about SSL and security, use hardware tokens or smart cards. Otherwise expect that once the host is compromised, your software and any access codes running through that host have been compromised.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文