【问题标题】:Alternative to SSL - "Manual" Encryption? [closed]SSL 的替代方案 - “手动”加密? [关闭]
【发布时间】:2011-10-03 06:24:09
【问题描述】:

我想加密在我的 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 的一个很好的替代方案吗?
我怎样才能以更难破解的方式实现这种类型的加密?这种方法有什么特别的弱点吗?

我可能会找到一个负责加密的 JavaScript 库,并在服务器端使用 PHP 的 mcrypt 扩展。我在考虑 Blowfish,可能是 AES256,但我不确定哪一个给我的加密强度与内存消耗的最佳比率。

建议?

【问题讨论】:

  • 我不知道 SSL 需要专用 IP。另外,我知道这是伪代码,但目前,DBData = encrypt(encrypt(clientData,transfer_key),storage_key) - 如您所指,如果 transfer_key 在某种程度上是短暂的,则意味着您永远无法解密数据库数据。
  • 所以,我(作为攻击者)所要做的就是嗅探您发送给客户端的纯 html 流量,其中包含带有加密/解密密钥的 javascript 代码。不错……说真的,坚持使用 SSL/TLS
  • @Damien_The_Unbeliever:SSL 本身没有;但他的提供者可能会将其打包为更昂贵计划的一部分。
  • 你在哪里托管?你的主机似乎很便宜。
  • 解决办法是切换到更合理的主机。

标签: php security encryption ssl


【解决方案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. 假设你已经掌握了。那么下一个问题出现了,你如何以安全的方式将这个密钥发送到服务器,即执行密钥交换?在那里,您将需要在服务器端进行某种形式的身份验证,否则几乎任何人都可以强加为您的服务器并执行此操作:

  • 诱骗人们先将他们的密钥发送到他们的恶意服务器
  • 然后将密钥转发到您的服务器
  • 您的服务器会尽职尽责地发送使用已建立的密钥加密的数据
  • 攻击者会拦截该数据,并通过使用他们刚刚窃取的密钥解密来愉快地读取您的秘密
  1. 因此,如果不需要客户端身份验证,至少也需要服务器身份验证。这意味着您需要某种形式的非对称/公钥密码术来使用服务器的公钥加密/包装密钥,以便只有服务器能够解密它。

  2. 一旦你掌握了这一点,你仍然容易受到更多形式的攻击,例如replay attacksman-in-the-middle-attacksreflection attacks、...

  3. 也许您还想要Perfect Forward Secrecy,这样一旦密钥确实被泄露,攻击者将无法解密任何过去的数据。您需要Diffie-Hellman(最好是Elliptic Curve Cryptography 形式)来实现这一点。

  4. 最后但并非最不重要的一点是,会话机制可能也很不错,这样您就可以使用已经建立的对称密钥来获取以前的会话,这样您就可以减少服务器上的负载,而不必再次使用重新建立它资源密集型公钥算法。

-> 添加更多功能,例如安全协商客户端和服务器都承认支持的算法套件,您将重新实现 TLS 协议。

抱歉,这听起来有点讽刺,但我知道推出自己的加密方案似乎很诱人(这也很有趣),但最后你应该坚持使用 TLS:它(相对)易于使用,它运行在传输层上(因此您可以像根本没有加密一样对应用程序进行编码),最重要的是,它是安全的。

编辑:嗯,最近发生了一些攻击,但几乎所有攻击都通过攻击支持协议的公钥证书(Comodo、DigiNotar 等)来利用这些协议中的“人为因素”。是突出的例子)或算法协商等协议的更多神秘特性,但BEAST 是第一次在密码学层面成功攻击 TLS,这既有趣又可怕,因为这种攻击的基础知识现在以some years 闻名。

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

【讨论】:

  • +1:在看到带有加密/解密和密钥的 javascript 代码后,我停止了阅读。
  • 我想再次为此 +1。写得很好。
  • 非常感谢,克里斯。我真的对这些事情充满热情;)
【解决方案2】:

Ryan:我希望这是最好的方式:内存消耗绝对是您的问题中最少的。

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

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

您所拥有的不会阻止某人坐在咖啡店中打开笔记本电脑抓取数据包截取密钥并能够轻松解密您来回传递的所有其他内容。哎呀,仅仅在流中看到“加密”、“解密”和“密钥”这三个词就足以激起人们进一步探索乐趣(或利润......)的兴趣。不要介意看着一个打开的连接突然开始传输部分数据包加密和其他部分明文。

如果您拥有的东西值得加密,那么每年额外花费 240 美元来做正确的事情是值得的。请从窗台上退后一步,做正确的事。

【讨论】:

    【解决方案3】:

    每个人都很消极,虽然我同意你个人可能不应该这样做的观点,但让我做一些一般性的评论:

    对于安全通道,您需要三件事:

    • 线路加密
    • 密钥交换
    • 身份验证

    对于加密,您需要实施密码。这是可行的。

    密钥交换是关键点:双方都需要知道他们知道一个公共密钥,而其他任何人都无法知道这个公共密钥。存在为此的协议,并且应该可以实现它。例如,SSL 就是这样做的。您可以嗅探 SSL 连接而不了解任何内容这一事实表明它是可以做到的。

    身份验证对于阻止中间人攻击是必要的,这需要某种带外信息交换(如电话呼叫或 PKI 基础设施)。这其中任何一个是否真的有效都值得商榷,即使对于 SSL。

    因此,基本上,如果您可以通过 HTTP 实现所有这些组件,那么原则上应该可以通过 HTTP 运行安全通信。毕竟,SSL 也在做同样的事情,它在不安全的介质上运行安全通道。基本上你想要的是在 JavaScript 中实现 SSL。查看aSSL,他们已经尝试过类似的方法。

    【讨论】:

      【解决方案4】:

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

      您可以使用带有自签名证书的 DynDNS(或类似服务)代替静态 IP 地址吗?

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-10-08
        • 2010-10-11
        • 2017-03-23
        • 2011-09-23
        • 1970-01-01
        • 1970-01-01
        • 2010-09-18
        • 2013-04-04
        相关资源
        最近更新 更多