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

一，对称加密

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

对称加解密的步骤例如以下：

发送端和接收端首先要共享同样的密钥k(即通信前两方都须要知道相应的密钥)才干进行通信。

发送端用共享密钥k对明文p进行加密。得到密文c。并将得到的密文发送给接收端，接收端收到密文后，并用其同样的共享密钥k对密文进行解密，得出明文p。

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

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

1，  发送方和接收方首先须要共享同样的密钥，即存在密钥k的分发问题。怎样安全的把共享密钥在两方进行分享，这本身也是一个怎样安全通信的问题，一种方法是提前两方约定好。不通过详细的通信进行协商。避免被监听和截获。第二种方式，将是以下我们介绍的通过非对称加密信道进行对称password的分发和共享，即混合加密系统。

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

对称加密的优点是：

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

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

二，非对称加密

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

非对称加解密的步骤例如以下：

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

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

非对称加密的长处是：

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

2。  攻克了密钥管理的复杂度问题，多个加密方都能够使用一个已知的公钥进行加密，但仅仅有拥有私钥的一方才干解密。

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

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

三，数字签名

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

因为私钥仅仅有相应一方才知道。因此若通过相应的公钥能够验证对方是用相应的私钥进行加密的，则能够说明对方的身份，这就是数字签名。

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

1。  谁编写的报文；

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

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

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

2，  A对摘要应用了一个签名函数，而且用A自己的私钥作为參数。由于仅仅有A才知道私钥，所以正确的签名会说明签名者就是其全部者。

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

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

四。数字证书

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

主要的数字证书包含了一些常见的信息：

1。 对象的名称（人，server，组织等）

2， 过期时间

3， 对象的公钥

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

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

…

须要注意的是。不论什么人都可以创建一个证书，但不是全部人都可以获得受人尊敬的签发权从而为证书信息提供担保，并用其私人密钥签发证书。

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

x.509证书格式：

字段	描写叙述
版本	这个证书的X.509证书版本号号，如今一般是版本号3
序列号	证书颁发机构CA生成的唯一整数。CA生成的每一个证书都要有一个唯一的系列号，类似身份证号码
签名算法ID	签名使用是算法。如用RSA加密的MD2摘要
证书颁发者	以X.500格式说明的CA的组织名称
有效期	证书的有效期，由一个起始日期和一个结束日期来表示
对象名称	证书中描写叙述的实体。比方一个人或者一个组织，对象名称以x.500格式表示
对象的公开密钥信息	证书对象的公钥，公钥使用的算法。以及全部附加的參数
公布者唯一的ID(可选)	可选的证书公布者唯一ID。这样能够重用同样的公布者名称了
对象唯一的ID（可选）	可选的证书对象唯一ID，这样就能够重用同样的对象名称了
扩展	一些扩展信息
证书的颁发机构签名	CA用指定的签名算法对上述全部字段的数字签名

x.509证书有非常多种，如server端证书。个人证书等。

浏览器中的证书：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGVuZnlndW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

注意：每一个证书均有相应于证书公钥的私钥，私钥不能被导出，訪问一般须要password等。

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGVuZnlndW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvdGVuZnlndW8=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

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

在支付站点中，用户须要确认他们输入支付password的站点是真正的经过认证的站点，而不是被钓鱼的站点，因此用户有必要认证相应的server。而这样的方式是通过server证书来进行的。

过程大概例如以下：

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

当中server证书包含了：

   Web网站名称和主机名

        Web网站的公钥。

        颁发机构的名称；

        颁发机构给证书的签名；

2。  若server没有证书。则安全连接失败。

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

4，  浏览器查看server证书相应的CA，若该CA是非常权威的机构，则浏览器可能已经知道了相应的公钥了（浏览器会预先安装非常多签名颁发机构的证书并觉得是受信任的），这时，浏览器用CA的数字证书里面的公钥来验证该CA颁发的server证书的有效性。

类似去公安局验证某人的身份证是否是真的。

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

5，  一旦完毕了对server证书的验证，接下来就能够使用server证书里面的公钥进行server身份的验证；

6。  client生成一个随机数给到server，要求相应的服务用相应server证书是私钥进行签名。

7。  server对随机数进行签名。并回传给到client。

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

六，用client证书对client进行认证

client证书和server证书类似，仅仅是server证书添加一些对server网站名称和主机名等内容的签注，client证书通常是某个机构针对个人颁发的，用于标识个人的身份。如財付通提示用户安装相应的数字证书。就是一个client证书，在安装client证书的时候，实际上会把用户相应该证书的私钥要保存起来。

client用私钥进行签名。然后第三方用client证书的公钥进行验签实现对client身份的认证。

七，HTTPS的双向认证，则须要client和server交换证书。

在发送已加密的HTTP报文前，client和server要进行一次SSL握手。在这个握手的过程中，它们要完毕下面工作：

1。  交换协议版本。

2。  选择一个两端都了解的password。

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

4，  生成暂时的会话密钥，兴许便用该密钥进行加密信道。