HTTPS协议=HTTP协议+加密+证书+完整性保护

一.HTTPS协议

概念:基于安全套接字的超文本传输协议. HTTPS基于HTTP协议,通过SSL(安全套接层协议)或TLS(安全层传输协议)提供加密处理数据,其实就是披着SSL外壳的HTTP协议,其本质还是HTTP.

二.HTTP的缺陷

HTTP并非只有好的一面,事物皆具有两面性,它也有不足之处.

1. 通信使用明文(不加密),内容可能会被窃听
2. 不验证通信方的身份,因此有可能遭遇伪装
3. 无法验证报文的完整性,所以有可能已遭篡改

通信使用明文可能会被窃听

不验证通信方的身份就有可能遭遇伪装

查明对手的证书:证书由值得信任的第三方机构颁发,用以证明服务器和客户端是实际存在的.另外,伪造证书从技术角度来说是异常困难的一件事.所以只要能够确认通信方持有的证书,即可判断通信方的真实意图.

无法证明报文完整性,可能已遭篡改

所谓完整性是指信息的准确度,若无法证明其完整性,通常也就意味着无法判断信息是否准确.

三.HTTPS=HTTP+加密+证书+完整性保护

为了弥补HTTP的上述缺陷,HTTPS就诞生了,HTTPS并不是一个新的协议,而是身披SSL外壳的HTTP,通过引入加密,证书,完整性保护来保证它的安全.

(一).通信加密:

对称加密: 对称密钥加密也叫做共享密钥加密,其实就是加密和解密采用同一个密钥.

双方在进行通信时，发送方会利用密钥进行加密，再将密钥一同发送给接收方，让其使用这个密钥进行解密。

这种方法看起来不错，但是也存在问题，如果在发送的时候被拦截下来，密钥就会泄露给中间人，此时中间人就可以通过密钥来对之后的数据进行解密，此时也就失去了加密的意义

非对称加密:又叫公开密钥加密.它使用一对非对称的密钥,一把叫做私有密钥,一把叫做公有密钥.公有密钥是公开的,任何人都可以获得,而私有密钥则不能让任何人知道.

当进行通信时,发送方使用对方的公有密钥进行加密,而接收方接收时则用自己的私有密钥进行解密,这样一来,用于解密的私钥就完全掌握在接受者自己手里,中间人也无法从中窃取密钥,安全也一定程度的得到了保障.

混合加密:但是，从上面的描述也可以看出来，由于非对称加密的处理比起对称加密来说较为复杂，所以如果在通信时一直使用非对称加密，就会导致通信的效率大大的降低，所以HTTPS采用 对称加密和非对称加密 并用的 混合加密机制.

具体加密通信流程:

1. 使用非对称加密的方式 来 交换之后 用来进行加密解密的 对称加密密钥 （因为对称加密的主要问题就是无法确保密钥是否安全，而此时采用非对称加密来传输密钥，就能很好的规避这个问题）

2. 在确保之前交换安全的情况下，使用对称加密密钥来进行通信 (而非对称加密的最大问题就在于其复杂的处理机制导致效率降低，所以在安全的情况下使用对称加密就可以大大提高效率)

 

(二).证书

证明公开密钥正确性的证书

公开密钥加密方式还是存在一些问题,那就是无法证明公开密钥本身就是货真价实的公开密钥.

比如: 正准备和某台服务器建立公开密钥加密方式下的通信时,如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥.获取在公开密钥传输途中,真正的公开密钥已经被攻击者替换掉了.

数字证书认证机构的流程:

1. 服务器把自己的公开密钥登录至数字证书认证机构(CA)
2. 数字证书认证机构用自己的私有密钥向服务器的公开密钥签署数字签名并颁布公钥证书
3. 服务端将服务端的公钥证书(公开密钥以及数字证书认证机构的数字签名)发给客户端
4. 客户端拿到服务器的公钥证书(公开密钥+数字证书认证机构的数字签名)后,使用数字证书认证机构的公开密钥,向数字证书认证机构验证公钥证书上的数字签名,以确定服务器公钥的真实性
5. 如果证书合法,客户端产生一段随机数,拿着证书中的服务器公钥加密 自己支持的加密算法列表以及这段随机数 发送给服务端
6. 服务端收到客户端的公钥加密数据后,使用私钥进行解密,得到对方的对称算法列表和随机数,然后给客户端也回复一个随机数
7. 双方通过自己与对方的随机数以及对称加密算法列表计算最终得到一个对称加密算法进行加密实际的数据传输

用以确认客户端(服务端)的客户端(服务端)证书

以客户端证书进行客户端认证,证明服务器正在通信的对方始终是预料之内的客户端.

证书的缺点: 1. 价格昂贵 2.技术门槛比较高

(三).完整性保护:保护数据完整性目的就是防止传输的内容被中间篡改

MAC(消息认证码)报文摘要+数字摘要:保护数据完整性

应用层发送数据的时候会附加MAC(消息认证码)报文摘要,MAC能够查知报文是否遭到篡改,从而保护报文的完整性.

数字摘要就是采用单向Hash函数将需要加密的明文摘要成一串固定长度(128位)的密文,这一串密文又称为数字指纹,它有固定的长度,而且不同的密文摘要成密文,其结构总是不同的.而同样的明文其摘要必定一致,通过这种方法对比原文和摘要,就能够验证数据是否遭到修改.如SHA,MD5加密算法.

基本原理:

1. 被发送文件用SHA编码加密产生128位的数字摘要

2. 发送方用自己的私用密钥对摘要再加密，这就形成了数字签名。

3. 将原文和加密的摘要(数字签名)同时传给对方。

4. 对方用发送方的公共密钥对数字签名解密，同时对收到的文件用SHA编码加密产生又一摘要。

5. 将解密后的摘要和收到的文件在接收方重新加密产生的摘要相互对比。如两者一致，则说明传送过程中信息没有被破坏或篡改过。否则不然。 注意:对比的不是文件,而是加密产生的数字摘要

四.HTTPS并不能取代HTTP

SSL(安全套接层协议)是把双刃剑

对于HTTP协议来说,它直接和TCP进行通信.

而HTTPS为了保证安全,使用SSL来提供保障.通信时首先与SSL进行通信,再由SSL来与TCP进行通信,正是因为有SSL的存在,才使得HTTP具备了HTTPS的加密,证书,数据完整性等功能.

SSL是安全套接层协议,建立在可靠的传输协议之上,在TCP建立连接之后,实际数据传输之前,通讯双方通过身份认证以及加密传输实现整体的安全传输.

但是成也萧何，败也萧何，SSL为HTTPS保障安全的同时，也降低了它的效率.

SSL主要慢在两个方面:

1. 和HTTP相比，网络负载可能会变慢2到100倍。由于HTTPS还需要额外进行SSL通信，整体上处理通信量不可避免的增加了。

2. SSL为了确保安全，在客户端和服务端都需要进行大量的加密和解密的运算处理，导致其比起HTTP来说会更多的消耗服务器和客户端的硬件资源，导致负载增强。

HTTPS的遗憾之处

1. SSL的高度安全带来的低效率以及高负载使得HTTPS并不会一直使用（或者干脆不用） （对于高访问量的Web网站来说，进行大量的加密解密出来带来的负载十分庞大，并且对于非敏感信息（可公开信息）也没有加密的必要，所以大多数网站并不会一直使用HTTPS，而是只在进行私密内容传输的时候才会使用，来确保资源的节约。）

2. 数字证书的高昂成本使得个人网站及非盈利网站望而却步 （要进行HTTPS通信，数字证书是必不可少的，但是对于一些非盈利的网站以及个人网站来说，每年用来购买数字证书带来的花销并不是一个小数目，所以大多还是继续使用HTTP