Diffie-Hellman 密钥交换算法

DH算法的特点是可以在非加密的传输线路上，交换好密钥，然后服务器客户端之间用交换好的密钥进行加密传输。

如果没有DH算法，那么服务器，客户端在非加密通道进行加密传输之前，必须约定一个密钥。并且把这个密钥告诉对方。因为通道是非加密的，在这样的通道上传输密钥就有可能被第三方监听到，从而进一步破解出加密传输的信息。

DH加密的算法分为两步：

服务器准备好私钥，我们把它称之为$dh_private_key，他可能是一个很大的数字。接下来服务器生成两个很大的质数。我们设其为 $p, $g。

然后服务器用$dh_private_key, $p, $g 三个很大的数，计算生成服务器端的公钥 $dh_public_key。计算方法如下：

$dh_public_key = ($g ^ $dh_private_key) % $p

大家看到没，公钥是计算出来的。这个计算出来的公钥，就可以在公网上传输了。不怕别人监听到。于是服务器就把 ($p, $g, $dh_public_key ) 用公开的方式传输给客户端了。

客户端收到了服务器发来的 ($p, $g, $dh_public_key) ，先存下来，一会儿派用场呢。 然后也学着服务器，生成了一个自己的私钥。我们称之为$private_key。当然它也是一个很大的数。 接下来根据客户端根据服务器送来的($p, $dh_public_key)，打上自己生成的私钥，计算出将来加密通信用的共享密钥$shared_key，算法如下：

$shared_key = ($dh_public_key ^ $private_key) % $p

接下来我怎么把这个$shared_key告诉服务器呢，自然是不能直接发给它了，因为通道是不加密的，会被别人监听到。 于是呢客户端就根据服务器送过来的$p, $g，搭上自己生成的$private_key，计算出自己的公钥 $public_key。计算方法如下：

$public_key = ($g ^ $private_key) % $p

大家注意到没，类似的算法。以$g为基础，幂换成了$private_key；一样的 模$p。 这时候生成的$public_key，客户端把它发给服务器，同样也是在非加密通道上，不怕人家监听。 服务器收到客户端发来的$public_key，作如下计算，就能算出客户端的$shared_key啦：

$shared_key = ($public_key ^ $dh_private_key) % $p

经过上面两步，服务器和客户端都知道了将来要用$shared_key进行加密传输。 这个监听的坏人呢？ 他偷听到了四个很大的数：$dh_public_key , $g, $p, $public_key。 然后他想用这四个大数，合成我们的$shared_key 该怎么办？

事实证明，只要$p, $g 足够的大，要想通过4个公开的数字，计算出$shared_key，是非常困难的。

服务器跑在 http://localhost:8000

HTTPS 的算法和协议本身是十分安全的。目前没有公开的、成本合理的破解方式。为什么要加两个限定条件？因为关于“公开”：谁也不知道设计者、或者数学大牛留下或者发现了什么后门，然后在默默地偷窥全世界。关于“成本合理”：目前已知的只能是暴力破解，而这在时间成本上完全无法接受。也就是说，只要能“正确”地实现、使用HTTPS协议，你的信息就是安全的。但是为什么还是有关于HTTPS这么多的漏洞呢？就是在“实现”、“使用”中出了问题。两种常见作死情况是：实现中有大的BUG，比如说之前出来的OPENSSL HEARTBLEED 漏洞更多的情况，是小白用户作死。明明看到浏览器提示证书过期或者证书无效，还要点继续 -- 这种情况，真是神也挡不住。

1、建立安全能力

这一阶段由客户端向服务器发起建立连接请求，然后服务器与客户机进行消息交换，创建主密钥在这个阶段交换两个信息，即Client Hello和Server Hello信息。

2、服务器验证和密钥交换

若要认证,则在此阶段,服务器发送其证书、公钥,也许还要对客户请求证书。然后服务器将发送server_key_exchange消息,如果服务器已发送含固定Diffie-Hellman参数的证书或用了RSA密钥交换方法,则不用发送该消息。

3、客户端认证和密钥交换

该阶段共有三个消息从客户端发送到服务器。

首先，如果服务器在第二阶段已请求证书，则客户端要发送一个证书信息；若无证书，那么发送一个告警信息。

4、完成

在这个阶段交换4个信息。

首先客户端发送一个改变密码规格信息,并把未定的密码规格复制到当前密码规格中,这个信息实际上是将要讨论的改变密码各个协议的一部分。然后发送一个完成消息宣布握手协议完成。

扩展资料：

握手协议由一些客户与服务器交换的消息所构成，每一个消息都含有以下三个字段。

(1)类型(type)，1个字节:表示消息的类型,总共有十种

(2)长度(length)，3个字节：消息的位组长度。

(3)内容(content)，大于或等于1个字节，与此消息有关的参数。

参考资料来源：百度百科-握手协议

---