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

本文介绍了SSL的替代方案 - “手册”加密？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

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

所以，我想实现一个替代SSL。不过，它不仅仅是SSL。除了加密来回发送的数据外，还加密数据库中的行。我在想这样做：

JavaScript代码：

  var transfer_key ='whatever'; 
函数加密（数据，密钥）{...} 
函数解密（数据，密钥）{...} 
 
函数send_data_to_server（url，data）
 {
 $ .post（url，{'data'：encrypt（data，transfer_key）}，function（response）{
 var decryptpted_response = JSON.parse（decrypt（response））; 
}）; 
}

PHP代码：

  $ data = $ _POST ['data']; 
 $ transfer_key ='whatever'; 
 $ storage_key ='whatever2'; 
 
函数加密（$ data，$ key）{...} 
函数解密（$ data，$ key）{...} 
 
 databaseQuery 'INSERT INTO table VALUES（？）'，encrypt（$ data，$ storage_key））; 
 
 $ decryptpted_data = decrypt（$ data，$ transfer_key）; 
 $ response = processData（$ decryptpted_data）; 
 
 echo encrypt（$ transfer_key，$ response）;

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

这将是SSL的好选择吗？如何以更难打败的方式实施这种类型的加密？这种做法有什么特别的弱点吗？

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

建议？

解决方案

呃哦祝你好运你看过吗？你认为你能想出一些能被数百万人测试的足够的东西吗？

不，真的，TLS已经被许多人，密码学家多年来测试和改进，除了打破这样的协议之外，密码学家们也是一个艰巨的任务有一些足够的东西。

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

如果您没有任何设计安全性的经验协议你应该坚持主流，并使用TLS / SSL。

安全是其中有意义的罕见领域之一，实际上很酷的主流，所以我会说增加的钱将花费很多。 / p>

编辑：

也许我有点苛刻，我没有解释为什么你的方法不能竞争有一些复杂的协议，如TLS，所以让我们分析一下：

1）你如何进行密钥交换？要使AES工作在两端，您需要执行一个，用于对称加密各方需要拥有相同的关键。正如你所说，你想在客户端随机生成 - 到目前为止这么好。第一个问题 - 您需要生成，否则，例如。通过使用内置的Javascript随机数生成器 - 攻击者能够在一段时间后预测你的随机数。

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

欺骗人首先将密钥发送到流氓服务器

，然后将密钥转发到您的服务器

，您的服务器将尽可能发送用已建立密钥加密的数据

攻击者将拦截该数据，并通过使用他们刚刚偷走的密钥进行解密来快速阅读您的秘密

3）所以你需要服务器认证，至少，如果不是客户端认证，也。这将意味着您需要某种形式的非对称/公开密钥加密来加密/包裹服务器的公钥，以便只有服务器能够解密它。

4）一旦你掌握了这一点，你仍然容易受到更多涉及到的攻击形式的攻击，例如，，...

5）也许您还需要，以便一旦密钥遭到入侵攻击者将无法解密任何过去的数据。您将需要（最好在其 form）来实现这一点。

6）最后但并非最不重要的一个会话机制可能也会很好，以便您可以使用已建立的对称密钥来接收以前的会话，以便您可以通过不必再使用某些资源重新建立服务器来减少服务器上的负载 - 密集的公钥算法。

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

对不起，如果这听起来有点讽刺，但我知道似乎很有可能滚动自己的加密方案（这也很有趣），但最终你应该坚持TLS：它（相对）容易y使用，它运行在传输层（所以你可以编码你的应用程序，就像没有加密一样），最重要的是，它是安全的。

BEAST 有这是TLS第一次在加密级别被成功攻击，这是有趣和可怕的同时，因为这个攻击的基础知道为现在。

尽管如此，我会打赌TLS仍然是最好的选择您必须在网络上进行安全通信，特别是与手工制作的解决方案相比。

I would like to encrypt data that travels back and forth between the server and client in my Web application. I would use SSL but that requires a certificate along with a dedicated IP address. I have no problem getting a certificate but the dedicated IP requires me to upgrade to a business hosting plan which is $20 a month on my Web host. I have no plans on doing that as I'm sticking with my $20/year shared hosting plan.

So, I would like to implement an alternative to SSL. It does more than SSL does, though. Along with encrypting the data sent back and forth, it also encrypts the rows in the database. I was thinking of doing something like this:

JavaScript Code:

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 Code:

$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);

As you can see, the data the client sends to the server is encrypted, and vice versa. And the data in the database is encrypted as well. Now of course, I would never implement the keys like that. I would probably have a second or third key that's randomly generated for each user. So transfer_key could be equal to a constant_key concatenated with a random key, and same goes for storage_key.

Would this be a good alternative to SSL? How can I implement this type of encryption in such a way that it is harder to defeat? Are there any particular weaknesses to this approach?

I'm probably going to find a JS library that takes care of the encryption and use PHP's mcrypt extension for the server-side. I was thinking of Blowfish, maybe AES256, but I'm not sure which one gives me the best ratio of encryption strength to memory consumption.

Advice?

解决方案

Uh, oh. Good luck with that. Have you had a look at the TLS specification? Do you think you can come up with something adequate that will be tested by millions of people?

No, really, TLS has been tested and improved over the years by so many people, cryptographers who do nothing else than breaking such protocols, it would be a hard task coming up with something adequate.

SSL has been developed by experts in the field and they most certainly thought at first, too, that their protocol was absolutely unbreakable. But then there was version 2, then 3, then TLS v.1, v1.1 and now 1.2.

If you don't have any prior experience in designing secure protocols you should stick with the mainstream and use TLS/SSL.

Security is one of the rare fields where it makes sense and is actually cool to go with the mainstream, so I'd say the added money would be well spent.

Edit:

Maybe I was a bit harsh, and I lacked some explanation as to why your approach cannot compete with a somewhat complex protocol such as TLS, so let's analyze it:

1) How would you do the key exchange? For AES to work on both ends, you need to do a Key Exchange, for symmetric encryption, both parties need to possess the same key. As you said, you would like to generate it randomly on the client - so far so good. First problem - you need to generate a secure random number - otherwise, e.g. by using the built-in Javascript random number generator - attackers would be able to predict your random numbers after some time.

2) Let's say you got that mastered. Then the next problem arises, how would you send this key to the server in a secure manner, i.e. perform the key exchange? There you will need some form of authentication on the server side, otherwise just about anyone could impose as your server and do this:

trick people into sending their keys to their rogue server first
then forward the key to your server
your server would dutifully send the data encrypted with the established key
the attackers would intercept that data and happily read your secrets by decrypting with the key they just stole

3) So you need server authentication, at least, if not client authentication, too. This will imply that you need some form of asymmetric/public key cryptography to encrypt/wrap the key with the server's public key so that just the server is able to decrypt it.

4) Once you mastered that, you are still susceptible to more involved forms of attacks such as replay attacks, man-in-the-middle-attacks, reflection attacks, ...

5) Maybe you also want Perfect Forward Secrecy so that once a key does get compromised the attacker would not be capable of decrypting any past data. You will need Diffie-Hellman (preferably in its Elliptic Curve Cryptography form) to achieve this.

6) Last but not least, a session mechanism would probably also be nice so that you can pick up previous sessions with already established symmetric keys, so that you can reduce the load on the server by not having to re-establish it again using the somewhat resource-intensive public key algorithms.

-> Add a couple more features, such as securely negotiating an algorithm suite that both client and server acknowledge to support and you will have reimplemented the TLS protocol.

Sorry if this sounds a bit sarcastic, but I know it seems tempting to roll your own crypto schemes (it's fun, too), but in the end you should stick with TLS: it's (relatively) easy to use, it runs on the transport layer (so you can code your applications as if there were no encryption at all) and best of all, it's secure.

EDIT: Well, there have been some attacks recently, but almost all attacks exploited the "human factor" in these protocols by attacking the public key certificates that back the protocol (Comodo, DigiNotar etc. are prominent examples) or more arcane features of the protocol like algorithm negotiation etc., but the BEAST has been the first time that TLS has been successfully attacked on the cryptography level, which is interesting and scary at the same time, because the basics of that attack have been known for some years now.

Still, with recent fixes for BEAST in place by now, I would bet that TLS is still the best option you have for secure communication on the web, especially when compared to hand-crafted solutions.

这篇关于SSL的替代方案 - “手册”加密？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！