javascript - 将C#中的HTTP PUT加密到服务器上的JS

Question

我有一个C#程序，可以将HTTP PUT从一台服务器转换为另一台运行(XS)JS的服务器。我要发送的内容类型是JSON。这已经很好了。

现在我需要研究安全性，但是我不知道从哪里开始。有人可以指出正确的方向吗？

我需要使用互联网发送什么？ AES256，Rijndael，我什至不知道朝哪个方向看。 JS还需要能够在以后解密它。

提前致谢!

Answer 1

让我们从报价开始:

Bad crypto is worse than no crypto, because it gives the user the mistaken impression that their data is secure.
    _{— Jimm Gillogly, April 19^th 2000 on cryptography@senator-bedfellow.mit.edu}

那不是在劝阻你。提醒您:要采用适当的加密技术是一个很大的挑战，而且比您我聪明的人不知不觉中以最壮观的方式将自己击中了脚。

从我所能收集的信息来看，我的确给您的印象是确实需要传输而不是内容加密。但是一个步骤又一个步骤:

内容加密

如果您使用内容加密，则旨在保持通信内容的 secret 性，同时仍允许监听元数据(谁在什么时间与谁交谈？)。

为此，您需要建立

是客户端和服务器上的通用加密方案，

客户端和服务器上用于加密消息的常见 secret

最后一点是薄弱环节，因为您需要安全地交换密钥。这就需要一个安全的通信通道，在 Diffie-Hellman Key Exchange方法兴起之前，它一直是鸡与蛋的问题，它允许在不安全的通道之间安全地交换共享 secret 。您会经常看到这种方法，因此请记住。

此处封装的请求/响应通信的性质是要求应用所谓的 block cipher。与流密码相反，分组密码可以一次又一次地用相同的 secret 解密。明显的缺点是，如果您的 secret 受到威胁，则所有被拦截的消息将不再是 secret 。除非您一直在为每一轮通信谈判一个新的 secret ，否则就是这样。

Rijndael / AES(AES是一种 standard，而Rijndael是该标准使用的密码族)可以用于提供此功能的 ECB-或 CBC-mode。 CBC是首选，因为它对 replay attacks是安全的。如果重播攻击无关紧要，请选择CBC，无论如何:您将花很少的钱就能获得额外的安全性。

AES实际上很适合另一个原因:许多现代CPU都内置了硬件AES支持，这曾经是单独的 hardware crypto accelerator cards的一部分。实际上，如果选择通过JavaScript(或js库)实现此功能，则不会利用此功能。

另一个问题是所选 secret 的位长。您可能偶然发现了AES-128或AES-256:该数字指的是以位为单位的密钥大小。关于密钥大小和保护级别之间关系的讨论正在进行中。近年来，发生了许多理论攻击，使AES-256的有效密钥长度低于AES-128的有效密钥长度。实际上，这几乎没有效果，因为AES仍然非常强大。无论选择哪种密钥长度，在当前技术水平上，您宁愿看到太阳熄灭，也不愿看到AES破裂。不过，一个128位的密钥可能会获得更好的硬件和软件支持。因此，您可以在这里选择AES-128-CBC，AES-192-CBC或AES-256-CBC。询问 security.SE以获取建议，如果您希望看到它在火焰中冒出来:)

如果您认为AES不适合您，请查看 Twofish，它没有包含在AES中。它正在OpenPGP中看到实际使用，但缺少库支持。

因此，总而言之，我们在这里:

AES实际上是一个不错的选择

Michael提到的lib支持它

在ECB上选择CBC模式

不保护元数据

用于密钥交换的额外往返行程

没有硬件加速

这些都不是k-o-criterium，但应该放在脑后。

传输加密

更进一步，我们最终不对消息内容进行加密，而是对消息交换的方式进行加密:通过对通信通道本身进行加密。过去，这是通过SSL(安全套接字层)实现的。现在，它已被 Transport Layer Security取代，但仍然偶尔被称为SSL(不要让它混淆您!)。

TLS的工作原理是让对等方协商共同的密码，然后进行密钥交换(通常类似于前面提到的Diffie-Hellman方法)。这是用明文完成的，这应该与您无关。所有应用程序协议(protocol)数据都是 going to be encrypted。当我们讨论它时:AES是可协商的密码之一。不过，它更可能处于流密码模式。

就 secret 性而言，攻击者仍将能够选择与谁进行通信的主机。由于完整的URL已经在加密部分中，因此很少或根本没有迹象表明已经传达了什么信息。

您可能已经注意到，基于SSL / TLS的HTTP(通常称为HTTPS)是已建立的标准，几乎没有互操作性问题。实际上，您正在通过它访问此站点:)

当您使用.NET的 WebRequest 时，很幸运，因为它已经具有 HTTPS support了:

If the scheme for the Uniform Resource Identifier (URI) is http:// or https://, Create returns an HttpWebRequest object.

就HANA XS Engine而言，我知道它为 supports SSL，但它似乎与专有的加密库有关。在我看来，将 nginx配置为 reverse proxy来处理SSL / TLS部分似乎没有那么麻烦(也更安全)。

话虽这么说，但这是一个值得一提的问题:HTTP逐跳工作，这意味着您无法确定是在与原始服务器还是中​​介之间使用HTTP。 HTTPS可以帮助您确定SSL / TLS隧道的终点:

SSL / TLS的一个重要方面是每个对等方都保留一组密钥:一个公共(public)密钥和一个私有(private)密钥。它们在密钥交换中起着至关重要的作用，但是公共(public)密钥也可以用于标识对等方(或至少是主机名-公钥对)。这样就可以在协商阶段尽早识别 man-in-the-middle attacks，因此不会泄漏任何 secret 信息。

话虽如此，您没有提到端点是否公开。如果是这样，您可能不希望使用自签名证书(即您在没有其他参与方的情况下为自己颁发的一对公钥和私钥)。浏览器供应商倾向于运送受信任证书颁发者的列表，这些列表会尽全​​力确保不只为某个域颁发证书，而是要为希望为该域颁发证书的人控制的域颁发证书。

如果您的证书未被任何列出的发行者批准(“签名”)，则您将面临互操作性问题，因为浏览器倾向于发出警告，并且出于安全原因，完全自动化的客户端可能会完全退出服务。您可以通过以下服务获得 免费证书:

startssl.com

The Let's Encrypt Initiative

通用方法是生成私钥，为其创建证书签名请求(CSR)，将此CSR提交给您选择的发行者并接收签名的公钥。让我们加密具有某种程度的自动化，因此您可能会发现它更易于使用。 OpenSSL库具有 extensive documentation，但对于该主题的新手来说可能很难阅读。

如果您足够高级，则可以尝试解决更高级的技术，例如OCSP装订，严格的HTTP传输安全性和HTTP公钥证书固定。所有这些都将帮助您加强TLS / SSL设置的安全性。虽然是开始，但请确保已设置 reasonable list of ciphers进行协商并测试 obvious errors的设置。

总结一下:

建立并经过充分测试的解决方案

很可能是硬件加速

如果(当)向公共(public)开放API，则

几乎没有互操作性问题

元数据在很大程度上是 secret 的

建立端到端消息 secret 性是强制执行

的挑战

如前所述，我真的觉得传输加密是您的理想之选。毕竟，它速度更快，并且(相对而言)更易于设置和维护。您可能会想结合使用这两种方法:不一定是 a good idea。从一开始就引用报价。