安全HTTPS-全面详解对称加密，非对称加密，数字签名，数字证书和HTTPS【上】

一，对称加密

所谓对称加密，就是它们在编码时使用的密钥e和解码时一样d(e=d)，我们就将其统称为密钥k。

对称加解密的过程如下：

发送端和接收端首先要共享相同的密钥k(即通信前双方都需要知道对应的密钥)才能进行通信。发送端用共享密钥k对明文p进行加密，得到密文c，并将得到的密文发送给接收端，接收端收到密文后，并用其相同的共享密钥k对密文进行解密，得出明文p。

一般加密和解密的算法是公开的，需要保持隐秘的是密钥k，流行的对称加密算法有：DES，Triple-DES，RC2和RC4

对称加密的不足主要有两点：

1，  发送方和接收方首先需要共享相同的密钥，即存在密钥k的分发问题，如何安全的把共享密钥在双方进行分享，这本身也是一个如何安全通信的问题，一种方法是提前双方约定好，不通过具体的通信进行协商，避免被监听和截获。另外一种方式，将是下面我们介绍的通过非对称加密信道进行对称密码的分发和共享，即混合加密系统。

2，  密钥管理的复杂度问题。由于对称加密的密钥是一对一的使用方式，若一方要跟n方通信，则需要维护n对密钥。

对称加密的好处是：

加密和解密的速度要比非对称加密快很多，因此常用非对称加密建立的安全信道进行共享密钥的分享，完成后，具体的加解密则使用对称加密。即混合加密系统。

另外一个点需要重点说明的是，密钥k的长度对解密破解的难度有很重大的影响，k的长度越长，对应的密码空间就越大，遭到暴力破解或者词典破解的难度就更大，就更加安全。

二，非对称加密

所谓非对称加密技术是指加密的密钥e和解密的密钥d是不同的（e!=d），并且加密的密钥e是公开的，叫做公钥，而解密的密钥d是保密的，叫私钥。

非对称加解密的过程如下：

加密一方找到接收方的公钥e (如何找到呢？大部分的公钥查找工作实际上都是通过数字证书来实现的)，然后用公钥e对明文p进行加密后得到密文c，并将得到的密文发送给接收方，接收方收到密文后，用自己保留的私钥d进行解密，得到明文p，需要注意的是：用公钥加密的密文，只有拥有私钥的一方才能解密，这样就可以解决加密的各方可以统一使用一个公钥即可。

常用的非对称加密算法有：RSA

非对称加密的优点是：

1，  不存在密钥分发的问题，解码方可以自己生成密钥对，一个做私钥存起来，另外一个作为公钥进行发布。

2，  解决了密钥管理的复杂度问题，多个加密方都可以使用一个已知的公钥进行加密，但只有拥有私钥的一方才能解密。

  非对称加密不足的地方是加解密的速度没有对称加密快。

综上，分析了对称加密和非对称加密各自的优缺点后，有没有一种办法是可以利用两者的优点但避开对应的缺点呢？答应是有的，实际上用得最多的是混合加密系统，比如在两个节点间通过便捷的公开密码加密技术建立起安全通信，然后再用安全的通信产生并发送临时的随机对称密钥，通过更快的对称加密技术对剩余的数据进行加密。

三，数字签名

上面讨论了非对称加密技术在编码中的使用，解决的是传送数据的私密性，一般是用公钥作为加密key，而私钥作为解密key，那假如是用私钥作为加密key，而公钥作为解密key呢？

由于私钥只有对应一方才知道，因此若通过对应的公钥可以验证对方是用对应的私钥进行加密的，则可以说明对方的身份，这就是数字签名。

数字签名需要解决的两个任务是：

1，  谁编写的报文；

2，  报文的内容是否被篡改过；

数字签名的过程一般如下：

1，  发送方A首先对变长的报文提取成一个定长的摘要，一般是md5等

2，  A对摘要应用了一个签名函数，并且用A自己的私钥作为参数，因为只有A才知道私钥，所以正确的签名会说明签名者就是其所有者。

3，  一旦计算出签名，节点A就将其附加到报文的末尾，并将报文和签名一起都发送给B

4，  在接收端B，首先会按照同样的算法计算出报文的摘要，然后对签名用A的公钥进行解码，得出解码后的摘要，两个摘要进行比较，则可以判断是否是A发送的且内容没被篡改过。

四，数字证书

实际上，好多的公钥都是通过数字证书进行发布的，数字证书类似一个人的身份证一样，由对应的官方的颁发结构颁发的，类似一个人的身份证有姓名，身份证ID，有效期，颁发机构-一般是某某派出所等，数字证书也有类似的形式。

基本的数字证书包括了一些常见的信息：

1， 对象的名称（人，服务器，组织等）

2， 过期时间

3， 对象的公钥

4， 证书发布者（由谁为证书担保）

5， 来自证书发布者的数字签名。

…

需要注意的是，任何人都可以创建一个证书，但不是所有人都能够获得受人尊敬的签发权从而为证书信息提供担保，并用其私人密钥签发证书。

不幸的是，数字证书没有单一的全球标准，但现在使用的大多数证书是以一种标准格式– X.509 v3，来存储它们的信息。

x.509证书格式：

x.509证书有很多种，如服务器端证书，个人证书等。

浏览器中的证书：

注意：每个证书均有对应于证书公钥的私钥，私钥不能被导出，访问一般需要密码等。

浏览器会默认存储一些受信任的根证书颁发机构的证书，从图中可以看，这些证书都是颁发者颁发给自己的。

五，用服务器证书对服务进行认证

在支付网站中，用户需要确认他们输入支付密码的站点是真正的经过认证的站点，而不是被钓鱼的网站，因此用户有必要认证对应的服务器，而这种方式是通过服务器证书来进行的。过程大概如下：

1， 通过https建立一个安全web事务之后，浏览器会自动获取所连服务器的数字证书；

其中服务器证书包括了：

        Web站点名称和主机名

        Web站点的公钥；

        颁发机构的名称；

        颁发机构给证书的签名；

2，  若服务器没有证书，则安全连接失败。

3，  浏览器首先检查服务器证书是否还在有效期内，若过期，则提示失效；

4，  浏览器查看服务器证书对应的CA，若该CA是很权威的机构，则浏览器可能已经知道了对应的公钥了（浏览器会预先安装很多签名颁发机构的证书并认为是受信任的），这时，浏览器用CA的数字证书里面的公钥来验证该CA颁发的服务器证书的有效性。类似去公安局验证某人的身份证是否是真的。

5，则浏览器对签名颁发机构CA一无所知，浏览器无法确定是否该信任这个签名颁发机构，它通常会向用户提示一个对话框，看看他是否相信这个签名发布者。

5，  一旦完成了对服务器证书的验证，接下来就可以使用服务器证书里面的公钥进行服务器身份的验证；

6，  客户端生成一个随机数给到服务器，要求对应的服务用对应服务器证书是私钥进行签名。

7，  服务器对随机数进行签名，并回传给到客户端。

8，  客户端用服务器证书的公钥对随机数的签名进行验证，若验证通过，则说明对应的服务器确实拥有对应服务器证书的私钥，因此判断服务器的身份正常。否则，则任务服务器身份被伪造。

六，用客户端证书对客户端进行认证

客户端证书和服务器证书类似，只是服务器证书增加一些对服务器站点名称和主机名等内容的签注，客户端证书一般是某个机构针对个人颁发的，用于标识个人的身份。如财付通提示用户安装对应的数字证书，就是一个客户端证书，在安装客户端证书的时候，实际上会把用户对应该证书的私钥要保存起来。客户端用私钥进行签名，然后第三方用客户端证书的公钥进行验签实现对客户端身份的认证。

七，HTTPS的双向认证，则需要客户端和服务器交换证书。

在发送已加密的HTTP报文前，客户端和服务器要进行一次SSL握手，在这个握手的过程中，它们要完成以下工作：

1，  交换协议版本号；

2，  选择一个两端都了解的密码；

3，  对两端的身份进行验证；

4，  生成临时的会话密钥，后续便用该密钥进行加密信道。