维护https和http之间的私钥

Maintaining private key between https and http

本文关键字：私钥 之间 http https 维护      更新时间：2023-09-26

我正在开发一个新网站，该网站使用面向服务的架构，前端使用纯JavaScript，通过RESTful AJAX调用访问web服务以获取数据。

它不应该特别重要，但我的堆栈是：

  • javascriptMVC
  • jQuery
  • Bootsrap
  • ASP。NET Web API（.NET 4.0上的C#）
  • MS-SQL

从这篇文章中，我已经找到了一些很好的方法来保护我的web服务调用，一旦我在客户端（JavaScript）和服务器（通过web API的REST服务）之间共享了私钥。然而，我正在为如何建立用于加密的私钥而苦苦挣扎。

坏主意#1

不过，最初的做法是将其设置为通过HTTPS进行的登录，然后将其存储在客户端的cookie中以供重用。问题是我们的SSL证书用于https://secure.example.com，而我们的网站在http://www.example.com-所以我无法从www.example.com.访问secure.example.com cookie

坏主意#2

我的下一个想法是通过URL参数将其加密和签名，从HTTPS登录到HTTP登录后页面，如下所示：

http://www.example.com/processLogin?key=[encryptedKey]&sig=[encryptedSig]&user=[userid]

encryptedKey和encryptedSig都将使用另一个仅针对该交易存在的私钥进行加密。它将在登录时创建，并分配给数据库中的该用户。在HTTP端，所有这些都被传递给服务器，服务器对其进行解密，验证签名，删除私钥（以防止重放攻击——本质上是一个随机数），并返回解密的私钥（[encryptedKey]解密）。

从那时起，[encryptedKey]的解密值将用于所有未来事务。问题是，解密后的私钥必须通过HTTP通过线路发送，这很糟糕。

坏主意#3

我还短暂地想到，JavaScript中有一个硬编码的密钥，用于解密这个值，但无论我如何尝试混淆它，它都可能被黑客找到并使用。

坏主意#4

我也考虑过在初次握手时使用公钥加密进行某种密钥交换，但正如其他地方所指出的，除非是通过SSL，否则客户端无法真正确信在初次握手过程中没有篡改——这让我回到了原点。

大问题

那么，如果所有都不通过HTTPS，你们如何管理这些事情呢？我的HTTP和HTTPS是否有相同的域名，以便将此私钥存储在cookie中？

请注意，网站的非SSL部分不会共享信用卡或登录信息等。我只是不想让这个混蛋大开方便之门。

如果不实现SSL，javascript客户端和服务器之间就无法进行安全加密的通信。这是不可能的。如果您真正想要实现的不是加密流量，而是简单地确保与您交谈的客户端已被授权发出请求，并且该客户端不是模仿者，那么OAuth可能就足够了。看见http://www.dotnetopenauth.net/用于标准OAuth.net实现。

如果您不想参与OAuth，而只是想在已经构建的基础上进行构建，那么您应该向javascript客户端分发一个令牌、一个公钥和一个私钥。公钥和令牌是每个请求来回发送的内容，而私钥从不来回发送，而是用于生成某种类型的签名哈希。每个请求都应该有这个签名和一个基于时间的nonce，以防止重放。您还应该频繁地使令牌过期，并要求客户端使用其sig和公钥请求"刷新"令牌。本质上，我所描述的是OAuth 1.0a，如果你真的想走这条路，我会参考DotNet OpenAuth，而不是自己尝试。

但是，需要重申的是，如果没有SSL，您仍然容易受到其他类型的攻击。此外，除非您对初始令牌请求进行SSL加密，否则黑客总是可以嗅到令牌/公钥/私钥对的初始交付，因此，从一开始就消除了您为确保安全所做的所有艰苦工作。

上述方法的替代方法是在客户端和RESTneneneba API之间设置一个代理服务器。对API的请求只能通过代理服务器。客户端登录并从中获取cookiehttps://secure.example.com使用基本身份验证。然后客户端继续向secure.example.com和secure.exexample.com发出请求，然后向API发出请求并将数据返回给客户端。

不管怎样，希望有足够的信息给你思考。

您可以查看如何使用子域和cookie，方法是查看以下答案：在域上创建javascript cookie并在子域之间读取

关于坏主意#3：

我知道我可以使用http://jsbeautifier.org使用http://dean.edwards.name/packer/带有"收缩变量"复选框&或"Base62编码"复选框。所以JavaScript是完全不安全的&不应依赖于在浏览器中保存任何类型的SSL加密、用户身份验证令牌或可编辑帐户统计信息。否则，有人会简单地尝试编辑他们的游戏帐户&给自己+100万游戏币。

当一切都通过SSL时，它只能防止"中间人"攻击。这实际上是一种"中间的服务器机器人"攻击。这并不能阻止最终用户自己成为黑客。

在下一个示例中，SSL将阻止服务器a到e看到从客户端传递到终端服务器的任何数据，但如果没有SSL，服务器C将窃取数据。这就是服务器跳的工作方式，无需加密，客户端+所有服务器都可以读取数据：

client > a > b > server c's bot sniffs http traffic > d > e > terminus server

服务器c的机器人程序记录一个信用卡号，这是一个加密的银行账号。（大多数人没有意识到信用卡号是一个加密和转换的银行账号。如果信用卡号被泄露，银行很容易从银行账号重新发行一个新的加密CC#，并通过邮件发送一张新卡。他们不必更改原始银行账号，也不必打印新的印有银行账号的支票它们的底部。）

使用TLS/SSL/https加密的服务器跃点将像这样工作，其中只有客户端&服务器可以读取任何内容：

client > all servers from a-e are blind & pass the data through > terminus server

服务器c的机器人程序看到了垃圾：as65a89as7df08，而不是1234-5678-9012-。。。，如果他们可以使用SSL读取任何内容。

iOS的酷之处在于，当它与HTML5&CSS。用户不能像在桌面浏览器中那样在iPhone上右键单击进行检查。使用后端语言很容易在终端服务器中隐藏密码。

目前无法阻止JavaScript被最终用户（客户端）入侵。每个最终用户都可能是黑客。如果我发现了其他东西，我可以把它发布在这里，供未来的开发人员阅读。

相关文章：