Question

我想加密在我的Web应用程序中在服务器和客户端之间来回传输的数据。我会使用SSL，但需要证书和专用IP地址。我没有问题获得证书，但专用IP要求我升级到我的Web主机上每月20美元的商业托管计划。我没有计划这样做，因为我坚持我的20美元/年共享主机方案。

所以，我想实现SSL的替代方案。但它确实比SSL更多。除了加密来回发送的数据外，它还加密数据库中的行。我在考虑做这样的事情：

JavaScript代码：

var transfer_key = 'whatever'; 
function encrypt(data, key) {...}
function decrypt(data, key) {...}

function send_data_to_server(url, data)
{
    $.post(url, {'data' : encrypt(data, transfer_key) }, function(response) {
        var decrypted_response = JSON.parse(decrypt(response));
    });
}

PHP代码：

$data = $_POST['data']; 
$transfer_key = 'whatever'; 
$storage_key = 'whatever2'; 

function encrypt($data, $key) {...}
function decrypt($data, $key) {...}

databaseQuery('INSERT INTO table VALUES (?)', encrypt($data, $storage_key)); 

$decrypted_data = decrypt($data, $transfer_key); 
$response = processData($decrypted_data); 

echo encrypt($transfer_key, $response);

如您所见，客户端发送到服务器的数据已加密，反之亦然。并且数据库中的数据也被加密。当然，我永远不会实现这样的键。我可能会为每个用户随机生成第二个或第三个密钥。因此，transfer_key可以等于与随机密钥连接的constant_key，对于storage_key也是如此。

这是SSL的一个很好的替代品吗？如何以一种难以击败的方式实现这种类型的加密？这种方法有什么特别的缺点吗？

我可能会找到一个负责加密的JS库，并为服务器端使用PHP的mcrypt扩展。我在想Blowfish，也许是AES256，但我不确定哪一个能给我加密强度与内存消耗的最佳比例。

么？

Answer 1

噢，哦。祝你好运。你看过TLS specification了吗？你认为你能提出足以让数百万人测试的东西吗？

不，真的，多年来TLS已经过如此多的测试和改进，密码学家除了打破这些协议之外什么也不做，这将是一项艰巨的任务，可以提供足够的东西。

SSL是由该领域的专家开发的，他们最初也肯定认为他们的协议是绝对牢不可破的。但后来有版本2，然后是3，然后是TLS v.1，v1.1和现在1.2。

如果您在设计安全协议方面没有任何经验，则应坚持使用主流并使用TLS / SSL。

安全性是一个罕见的领域，它是有道理的，与主流相比实际上很酷，所以我会说增加的钱会花得很好。

编辑：

也许我有点苛刻，而且我没有解释为什么你的方法无法与TLS之类的复杂协议竞争，所以让我们分析一下：

1）你会如何进行密钥交换？要使AES在两端工作，您需要执行Key Exchange，对于对称加密，双方都需要拥有相同的密钥。正如您所说，您希望在客户端上随机生成它 - 到目前为止一切顺利。第一个问题 - 您需要生成secure random number - 否则，例如通过使用内置的Javascript随机数生成器 - 攻击者可以在一段时间后预测您的随机数。

2）假设你掌握了这一点。然后出现下一个问题，如何以安全的方式将此密钥发送到服务器，即执行密钥交换？在那里，您需要在服务器端进行某种形式的身份验证，否则几乎任何人都可以将其强加为服务器并执行此操作：

诱骗人们首先将密钥发送到他们的流氓服务器
然后将密钥转发到您的服务器
您的服务器将尽职尽责地发送使用已建立密钥加密的数据
攻击者会拦截这些数据，并通过使用他们刚刚窃取的密钥进行解密来愉快地阅读您的秘密

3）所以你需要服务器身份验证，至少，如果不是客户端身份验证。这意味着您需要某种形式的非对称/公钥加密来使用服务器的公钥加密/包装密钥，以便服务器只能解密它。

4）一旦掌握了这一点，您仍然容易受到更多参与形式的攻击，例如replay attacks，man-in-the-middle-attacks，reflection attacks，......

5）也许您还需要Perfect Forward Secrecy，以便一旦密钥受到攻击，攻击者将无法解密任何过去的数据。您需要Diffie-Hellman（最好以Elliptic Curve Cryptography形式）才能实现此目标。

6）最后但并非最不重要的是，会话机制可能也会很好，以便您可以使用已经建立的对称密钥来获取以前的会话，这样您就可以通过不必重新建立它来减少服务器上的负载再次使用有点资源密集的公钥算法。

- ＆GT;添加更多功能，例如安全地协商客户端和服务器都认可支持的算法套件，并且您将重新实现TLS协议。

很抱歉，如果这听起来有点讽刺，但我知道看起来很有可能推出自己的加密方案（它也很有趣），但最后你应该坚持使用TLS：它（相对）易于使用，它运行在传输层上（因此您可以将应用程序编码为完全没有加密），最重要的是，它是安全的。

编辑：嗯，最近发生了一些攻击，但几乎所有的攻击都通过攻击支持协议的公钥证书（Comodo，DigiNotar等）来利用这些协议中的“人为因素”。是一些突出的例子）或协议的更加神秘的功能，如算法协商等，但BEAST是第一次在密码学层面成功攻击TLS，这同时是有趣和可怕的，因为现在some years知道了这种攻击的基础知识。

不过，最近对BEAST进行了修复，我敢打赌，TLS仍然是您在网络上进行安全通信的最佳选择，尤其是与手工制作的解决方案相比时。

Answer 2

瑞安：我说的是我希望这是最好的方式：记忆消耗是你问题中最不重要的。

这没有什么安全的。没有。 N.o.t.h.i.n.g

从第一次发送javascript开始就已经死了......我不在乎你的密钥有多长或者盐的随机性。

你所拥有的东西不会阻止某人坐在咖啡店里，他们的笔记本电脑打开时会抓住数据包拦截钥匙，并且能够轻松解密你来回传递的其他所有东西。哎呀，只要在流中看到“加密”，“解密”和“关键”这两个词，就足以激起某些人的兴趣，进一步潜入乐趣（或获利......）。别介意看一个打开的连接突然开始传输部分加密的数据包和其他部分。

如果您拥有的是值得加密的话，那么每年额外的240美元是值得的。请退出窗台，然后做好。

Answer 3

每个人都是如此消极，虽然我分享了你个人可能不应该这样做的情绪，但让我做一些一般性的评论：

对于安全通道，您需要三件事：

线路加密
密钥交换
验证

对于加密，您需要实现密码。那是可行的。

密钥交换是关键点：两个同行都需要知道他们知道一个公共密钥，而其他任何人都无法知道公共密钥。存在协议，应该可以实现它。例如，SSL正在这样做。您可以嗅探SSL连接而不学习任何东西这一事实表明它可以完成。

验证对于阻止中间人攻击是必要的，这需要某种带外信息交换（如电话呼叫或PKI基础设施）。这些是否真的有效，即使对于SSL，也是值得商榷的。

所以基本上如果你可以通过HTTP实现所有这些组件，那么原则上应该可以通过HTTP运行安全通信。毕竟，SSL正在做同样的事情，它在不安全的媒体上运行安全通道。基本上你想要的是在JavaScript中实现SSL。看看aSSL，他们尝试了类似的东西。

Answer 4

我的建议是坚持使用SSL / TLS。我认为这将使您的生活更轻松，并为您的解决方案行业提供公认的可信度。

您是否可以将DynDNS（或类似服务）与自签名证书一起使用而不是静态IP地址？

SSL的替代方案 - “手动”加密？

4 个答案: