应用层协议：HTTPS

时间  2019-11-06
标签 应用层 协议 https 繁體版
原文   原文链接

1. HTTPS定义

　　Hyper Text Transfer Protocol over Secure Socket Layer，安全的超文本传输协议，网景公式设计了SSL(Secure Sockets Layer)协议用于对Http协议传输的数据进行加密，保证会话过程当中的安全性。html

　　缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure算法

　　两大做用：一种是创建一个信息安全通道，来保证数据传输的安全；另外一种就是确认网站的真实性。segmentfault

2. 密码学基础　

明文： 明文指的是未被加密过的原始数据。
密文：明文被某种加密算法加密以后，会变成密文，从而确保原始数据的安全。密文也能够被解密，获得原始的明文。
密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。

对称加密
对称加密又叫作私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。
其加密过程以下：明文 + 加密算法 + 私钥 => 密文 解密过程以下：密文 + 解密算法 + 私钥 => 明文 对称加密中用到的密钥叫作私钥，私钥表示我的私有的密钥，即该密钥不能被泄露。 其加密过程当中的私钥与解密过程当中用到的私钥是同一个密钥，这也是称加密之因此称之为“对称”的缘由。因为对称加密的算法是公开的，因此一旦私钥被泄露，那么密文就很容易被破解，因此对称加密的缺点是密钥安全管理困难。 对称加密的特色是算法公开、加密和解密速度快，适合于对大数据量进行加密
常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。
非对称加密
非对称加密也叫作公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通讯双方使用相同的密钥，若是一方的密钥遭泄露，那么整个通讯就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且两者成对出现。私钥被本身保存，不能对外泄露。公钥指的是公共的密钥，任何人均可以得到该密钥。用公钥或私钥中的任何一个进行加密，用另外一个进行解密。
被公钥加密过的密文只能被私钥解密，过程以下：明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文
被私钥加密过的密文只能被公钥解密，过程以下：明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文
因为加密和解密使用了两个不一样的密钥，这就是非对称加密“非对称”的缘由。
非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少许数据进行加密。
在非对称加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（椭圆曲线加密算法）等。

哈希算法
将任意长度的信息转换为较短的固定长度的值，一般其长度要比信息小得多，且算法不可逆。
例如：MD五、SHA-一、SHA-二、SHA-256 等

　指纹算法/摘要算法【hash值计算】
　对消息使用hash算法/摘要算法进行单向处理，获取一个固定长度的信息的摘要/hash值。浏览器

数字签名
对信息的摘要【经过//计算的信息/】使用签名算法进行加密，获得的密文就叫作数字签名
签名就是在信息的后面再加上一段内容（信息通过hash后的值），能够证实信息没有被修改过。hash值通常都会加密后（也就是签名）再和信息一块儿发送，以保证这个hash值不被修改。hash算法摘要算法指纹算法摘要hash值
　数字证书
　是互联网通讯中的身份标识(主要是用户身份信息和公钥)，通常由CA中心颁发，既CA认证中心，或第三方权威机构。　　　　
　 数字证书上一般包括：CA的签名，证书全部人的公钥，CA中心的签名算法，指纹以及指纹算法，证书的惟一编号，版本，有效期等。　
　数字证书是一个经证书受权中心 数字签名的包含 公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书受权中心的数字签名。数字证书还有一个重要的特征就是只在特定的时间段内有效。
　数字证书是一种权威性的电子文档，能够由权威公正的第三方机构，即CA（例如中国各地方的CA公司）中心签发的证书，也能够由企业级CA系统进行签发。

 

3. HTTP通讯问题

　　HTTP协议基于TCP进行传输的，其中传输的内容全都裸露在报文中，若是咱们获取了一个HTTP消息体，那咱们能够知道消息体中全部的内容。这其实存在很大的风险，若是HTTP消息体被劫持，那么整个传输过程将面临：缓存

（1） 窃听风险（eavesdropping）：通讯使用明文(不加密)，内容可能被窃听。安全

（2） 篡改风险（tampering）：没法证实报文的完整性，因此可能遭篡改服务器

（3） 冒充风险（pretending）：不验证通讯方的身份，所以有可能遭遇假装网络

　　正由于HTTP协议的这个缺点, HTTP变成了一种不安全的协议。大数据

　　 

　　https://zhuanlan.zhihu.com/p/27395037网站

4. SSL/TLS协议

　　SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向链接的网络层协议和应用层协议之间的一种协议层。SSL经过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通信。该协议由两层组成：SSL记录协议和SSL握手协议。

　　TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。
　　

　　位置：介于传输层与应用层之间

 　　
　　

　　SSL/TLS协议是为了解决HTTP这三大风险而设计的，但愿达到：

（1） 全部信息都是加密传播，第三方没法窃听。

（2） 具备校验机制，一旦被篡改，通讯双方会马上发现。

（3） 配备身份证书，防止身份被冒充。

　　

　　http://www.sohu.com/a/294450321_100134138

 

5. HTTP 向 HTTPS 演化的过程

　　最直观上的差别，HTTP协议用明文传输报文，HTTPS用密文。

　　

 

 

5.1 对称加密

　　第一步：为了防止上述现象的发生，人们想到一个办法：对传输的信息加密（即便黑客截获，也没法破解）

　　

　　如上图所示，此种方式属于对称加密，双方拥有相同的密钥，信息获得安全传输，

在通过TCP的三次握手以后，客户端和服务器开启了链接，若是对后续双方传输的内容进行对称加密，那么理论上咱们在本次传输中防止了内容裸露。
可是因为对称加密使用秘钥在两端是同样的，要维持每一个客户端的秘钥不一致整套加密才有意义，这样将会产生海量的秘钥，维护困难。
另外，由于对称加密须要双方协商一致，通常可用提早约定，或者使用前传输秘钥，无论是哪一种方式，都很容易致使秘钥邪泄漏。只要黑客获取到秘钥，那么所谓的加密传输就如同虚设了。

　　此种方式的缺点是：

　　　　（1）不一样的客户端、服务器数量庞大，因此双方都须要维护大量的密钥，维护成本很高

　　　　（2）因每一个客户端、服务器的安全级别不一样，密钥极易泄露

 

5.2 非对称加密

　　第二步：既然使用对称加密时，密钥维护这么繁琐，那咱们就用非对称加密试试

　　

　　如上图所示，客户端用公钥对请求内容加密，服务器使用私钥对内容解密，反之亦然·　　

用户使用公钥进行加密以后，消息体可以安全的抵达服务器，可是在服务器返回数据的时候，黑客截取到信息以后,可以经过公钥对响应的内容进行解密，最后进行篡改，致使这个加密方案失败。
另外，非对称加密不适用与数量太大的报文，大数量的报文致使加密效率下降。

（1）公钥是开放给全部人的，但私钥是须要保密的，存在于服务端
（2）服务器端server向client端（A、B.....）的信息传输是不安全的：由于全部人均可以获取公钥
（3）但client端（A、B.....）向server端的信息传输确实安全的：由于私钥只有server端存在

　　缺点：

　　（1）公钥是公开的（也就是黑客也会有公钥），因此第 ④ 步私钥加密的信息，若是被黑客截获，其可使用公钥进行解密，获取其中的内容

　　（2）非对称加密不适用与数量太大的报文，大数量的报文致使加密效率下降。

 

5.3 对称加密+非对称加密

　　第三步：非对称加密既然也有缺陷，那咱们就将对称加密，非对称加密二者结合起来，取其精华、去其糟粕，发挥二者的各自的优点

　　

如上图所示

（1）第 ③ 步时，客户端说：（我们后续回话采用对称加密吧，这是对称加密的算法和对称密钥）这段话用公钥进行加密，而后传给服务器

（2）服务器收到信息后，用私钥解密，提取出对称加密算法和对称密钥后，服务器说：（好的）对称密钥加密

（3）后续二者之间信息的传输就可使用对称加密的方式了

遇到的问题：

（1）客户端如何得到公钥

（2）如何确认服务器是真实的而不是黑客，客户端在获取一个公钥以后，如何肯定这个公钥是正确的服务端发出的？

5.4 安全的获取公钥 CA

　　第四步：获取公钥与确认服务器身份

　　如何安全的获取公钥，并确保公钥的获取是安全的， 那就须要用到终极武器了：SSL 证书（须要购买）和CA机构

　　怎么保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥呢？

　　

　　http://www.javashuo.com/article/p-wybdsvhv-kt.html

　　

　　https://blog.51cto.com/11883699/2160032

　　一、获取公钥

　　（1）提供一个下载公钥的地址，回话前让客户端去下载。（缺点：下载地址有多是假的；客户端每次在回话前都先去下载公钥也很麻烦）
　　（2）回话开始时，服务器把公钥发给客户端（缺点：黑客冒充服务器，发送给客户端假的公钥）

　　二、那有木有一种方式既能够安全的获取公钥，又能防止黑客冒充呢？ 那就须要用到终极武器了：SSL 证书（须要购买申购）和CA机构

　　

　　如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有：

（1）证书的发布机构CA

（2）证书的有效期

（3）公钥

（4）证书全部者

（5）签名

6. HTTPS通讯过程

 　　HTTPS实际上是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会经过TLS进行加密，因此传输的数据都是加密后的数据。

　　

一个HTTPS请求实际上包含了两次HTTP传输，能够细分为8步。

1. 客户端发起HTTPS请求

客户端向服务器发起HTTPS请求，链接到服务器的443端口,，请求携带了浏览器支持的加密算法和哈希算法。

2. 服务端的配置

服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥能够发送给任何人。

服务器收到请求，选择浏览器支持的加密算法和哈希算法。

采用HTTPS协议的服务器必需要有一套数字证书，能够本身制做，也能够向组织申请。区别就是本身颁发的证书须要客户端验证经过，才能够继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。公钥给别人加密使用，私钥给本身解密使用。若是对公钥和私钥不太理解，能够想象成一把钥匙和一个锁头，只是全世界只有你一我的有这把钥匙，你能够把锁头给别人，别人能够用这个锁把重要的东西锁起来，而后发给你，由于只有你一我的有这把钥匙，因此只有你才能看到被这把锁锁起来的东西。

3. 传送证书

服务器将本身的CA 证书(公钥)发送给客户端。

这个证书其实就是公钥，只是包含了不少信息，如证书的颁发机构，过时时间等等。

4. 客户端解析证书

客户端收到服务器端的公钥以后，会对公钥进行检查，验证其合法性，若是发现发现公钥有问题，那么HTTPS传输就没法继续。若是公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，咱们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。而后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

这部分工做是有客户端的TLS来完成的，首先会验证公钥是否有效，好比颁发机构，过时时间等等，若是发现异常，则会弹出一个警告框，提示证书存在问题。若是证书没有问题，那么就生成一个随即值。而后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，否则看不到被锁住的内容。

证书真伪进行校验

（1）首先浏览器读取证书中的证书全部者、有效期等信息进行一一校验

（2）浏览器开始查找操做系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发

（3）若是找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）若是找到，那么浏览器就会从操做系统中取出 颁发者CA 的公钥，而后对服务器发来的证书里面的签名进行解密获得服务端的公钥和证书的数字签名，数字签名通过CA公钥解密获得证书信息摘要。

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名作对比

（6）对比结果一致，则证实服务器发来的证书合法，没有被冒充

（7）此时浏览器就能够读取证书中的公钥，用于后续加密了

5. 传送加密信息

客户端会发起HTTPS中的第二个HTTP请求，将加密以后的客户端密钥发送给服务器。

这部分传送的是用证书加密后的随机值R(私钥)，目的就是让服务端获得这个随机值R，之后客户端和服务端的通讯就能够经过这个随机值R来进行加密解密了。

6. 服务端解密信息

服务器接收到客户端发来的密文以后，会用本身的私钥对其进行非对称解密，解密以后的明文就是客户端密钥(随机数 R)，而后把内容用客户端密钥随机数 R进行对称加密，这样数据就变成了密文。

服务端用私钥解密后，获得了客户端传过来的随机值(私钥)，而后把内容经过该值进行对称加密。所谓对称加密就是，将信息和私钥经过某种算法混合在一块儿，这样除非知道私钥，否则没法获取内容，而正好客户端和服务端都知道这个私钥，因此只要加密算法够彪悍，私钥够复杂，数据就够安全。

7. 传输加密后的信息

而后服务器将加密后的密文发送给客户端。(服务器以随机数 R 为密钥把传输内容使用对称加密算法加密并传输给浏览器)。

这部分信息是服务端用私钥加密后的信息，能够在客户端被还原

8. 客户端解密信息

客户端收到服务器发送来的密文，用客户端密钥(随机数 R)对其进行对称解密，获得服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

客户端用以前生成的私钥解密服务段传过来的信息，因而获取了解密后的内容。整个过程第三方即便监听到了数据，也一筹莫展。

7. HTTPS单向认证

Https在创建Socket链接以前，须要进行握手，具体过程以下：

 

 

  1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
  2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
  3. 客户端使用服务端返回的信息验证服务器的合法性，包括：
    • 证书是否过时
    • 发型服务器证书的CA是否可靠
    • 返回的公钥是否能正确解开返回证书中的数字签名
    • 服务器证书上的域名是否和服务器的实际域名相匹配
    • 验证经过后，将继续进行通讯，不然，终止通讯
  4. 客户端向服务端发送本身所能支持的对称加密方案，供服务器端进行选择
  5. 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
  6. 服务器将选择好的加密方案经过明文方式返回给客户端
  7. 客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用做通讯过程当中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器
  8. 服务器收到客户端返回的加密信息后，使用本身的私钥进行解密，获取对称加密密钥。
  9. 在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通讯过程当中信息的安全。

8. 中间人攻击原理

　　中间人攻击，即所谓的Man-in-the-middle attack(MITM)，顾名思义，就是攻击者插入到本来直接通讯的双方，让双方觉得还在直接跟对方通信，但实际上双方的通讯对方已变成了中间人，信息已是被中间人获取或篡改。

 

解决办法

HTTPS 双向验证在客户端中内置服务器公钥，在服务器下将 CA 证书给浏览器的时候返回的公钥，服务端要求客户端发送客户端的证书，客户端会将本身的证书发送至服务端。

除了验证公钥的有效性以外，再比对公钥是否是和内置的公钥同样，不同说明被中间者攻击了，就断开连接不在请求了。

9. HTTPS双向认证

双向认证和单向认证原理基本差很少，只是除了客户端须要认证服务端之外，增长了服务端对客户端的认证，具体过程以下：

 

 

  1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。
  2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书
  3. 客户端使用服务端返回的信息验证服务器的合法性，包括：
    • 证书是否过时
    • 发型服务器证书的CA是否可靠
    • 返回的公钥是否能正确解开返回证书中的数字签名
    • 服务器证书上的域名是否和服务器的实际域名相匹配
    • 验证经过后，将继续进行通讯，不然，终止通讯
  4. 服务端要求客户端发送客户端的证书，客户端会将本身的证书发送至服务端
  5. 验证客户端的证书，经过验证后，会得到客户端的公钥
  6. 客户端向服务端发送本身所能支持的对称加密方案，供服务器端进行选择
  7. 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式
  8. 将加密方案经过使用以前获取到的公钥进行加密，返回给客户端
  9. 客户端收到服务端返回的加密方案密文后，使用本身的私钥进行解密，获取具体加密方式，然后，产生该加密方式的随机码，用做加密过程当中的密钥，使用以前从服务端证书中获取到的公钥进行加密后，发送给服务端
  10. 服务端收到客户端发送的消息后，使用本身的私钥进行解密，获取对称加密的密钥，在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通讯过程当中信息的安全。

10. https服务部署过程和原理

了解https的原理，最好的方法就是走一遍流程，理论上的流程和原理经过如下几点来解释：

  1. 证书申请
  2. 证书信任
  3. 密文通讯

10.1 证书的获取

https的关键之一就是ssl证书，为了保证证书的安全有效性，在各种委员会/厂商之间合做，经过相似圆桌会议来造成若干权威的认证机构【顶级认证机构能够有若干附属的二级、三级...认证机构】，想要获得受信任的证书，就须要向CA机构提交证书签名请求 (CSR, Certificate Signing Request)。过程以下：

  1. 证书申请者【通常是公司、我的开发者等】须要使用加密算法【大部分是RSA算法】来生成私钥，其中私钥保存在服务器上，不提供给任何人。
  2. 使用私钥生成证书签名请求 (CSR, Certificate Signing Request)【CSR中附带有公钥】，须要提供一些申请者相关的信息【域名、拥有者等信息】，发送给CA机构请求他们的签名，通过他们签名才能成为被信任的证书。
  3. CA机构对申请者进行验证【这里不一样类型收费不一样，验证方式也会不一样】，验证经过后，将会在证书中添加部分信息【证书颁发机构、有效期、指纹/hash算法、签名算法】，造成新的证书。【CA机构也是使用其自身的私钥来签名其余证书的】

  4. 对新的证书进行签名，步骤以下：

    • 对新证书按照指纹/hash算法进行hash值计算
    • 使用CA机构的私钥对计算出来的hash值按照签名算法进行加密，得出的密文就是数字签名；
    • 将数字签名放在证书的最后面【签名完成】，获得完整的证书，并返回给申请者；
    • 申请者获取签名证书，保证本身的HTTPS服务被信任。

 


因此最后的证书基本包括但不限于的内容以下：

  • 证书的有效期
  • 公钥
  • 证书全部者（Subject）
  • 签名所使用的算法
  • 指纹以及指纹算法【hash算法】
  • Version Number，版本号。
  • Serial Number，序列号。
  • 颁发机构
  • 数字签名

10.2 客户端识别证书

在申请到受信任的证书后，客户端是怎么知道这些证书是值得信任的呢，不一样浏览器和系统的具体实现不太同样，可是基本的方式差很少，都是在系统或者浏览器中事先准备好权威的CA机构的相关信息[公钥、常使用的各种hash、签名、加密算法等]。具体过程以下：

  1. 浏览器访问某https服务，带上浏览器自身支持的一系列Cipher Suite（密钥算法套件，后文简称Cipher）[C1,C2,C3, …]发给服务器【算法套件包括非对称算法、对称算法、hash算法】；
  2. 服务器接收到浏览器的全部Cipher后，与本身支持的套件做对比，若是找到双方都支持的Cipher【双方套件中都能支持的最优先算法】，则告知浏览器，并返回本身的证书；
  3. 浏览器确认和服务端后续的密文通讯的加密算法，同时对证书进行认证；
  4. 使用证书中的认证机构【多是二级、三级机构】的公钥【系统、浏览器事先准备好的】按照证书中的签名算法进行解密【认证机构使用私钥加密的密文只能经过该认证机构的公钥进行解密】，解密获取hash值；
  5. 使用证书中的hash/摘要算法对证书信息【证书签名除外的信息[服务器公钥、有效期等]】hash值计算，和4中解密的hash值进行对比，若是相等，表示证书值得信任；【经过数字签名来保证证书内容没有被篡改】。

 

 

 

10.3 https的加密通讯过程

在上文的流程以后【证书信任，客户端和服务端握手中须要的非对称算法、握手信息验证的hash算法、正文传输的对称加密】，就是具体的通讯过程：

  1. 客户端信任了服务端的证书，并和服务端确认了双方的加密算法【握手中须要的非对称算法、握手信息验证的hash算法、正文传输的对称加密】；
  2. 客户端生成随机数，经过证书中的公钥按照约定的非对称加密算法进行加密，获得加密的随机数秘钥，同时将以前全部的通讯信息【秘钥算法套件、证书等全部的通讯内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥和加密签名发送到服务端。
  3. 服务端收到随机数秘钥和加密签名，先使用私钥将随机数按照约定的非对称解密算法进行解密，获取随机数，同时使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将以前的通讯消息体【秘钥算法套件、证书等全部的通讯内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否。
  4. 成功之后，服务器再次将以前全部的通讯信息【秘钥算法套件、证书等全部的通讯内容】按照约定的hash/摘要算法获取hash值，并使用随机数和协商好的对称加密算法进行签名加密，将随机数秘钥发送到客户端，
  5. 客户端使用随机数按照约定的对称解密算法进行解密，获取待验证的hash值，将以前的通讯消息体【秘钥算法套件、证书等全部的通讯内容】按照约定的hash/摘要算法获取hash值，与刚才解密获取的待验证的hash值对比，验证加密成功与否，
  6. 成功的话整个连接过程完成，以后将使用随机数和约定的对称加密算法进行密文通讯，【若是上面的任何步骤出现问题，都将会结束整个握手过程，致使创建安全链接失败】。

 

10.4 综合解惑

这里的整个过程分的很细，不过仍是很清晰的把整个https的原理和过程阐述了;下面解释一下其中一些疑惑点：

  1. CA机构认证的做用？
    能够做为全球有限的权威认证，通过其签名的证书均可以视为可信任的，因此他们的私钥必需要保证不被泄露，若是泄露的话须要及时的进行吊销，
  2. 签名为何须要加密计算的hash值，hash值已是单向不可逆的运算了？
    由于虽然hash值是单向的，可是计算hash的算法和内容都是公开的，若是不进行加密，那么因为其余人能够修改证书内容，根据hash算法从新计算hash，这样就会出现安全漏洞，因此使用加密的密文才是安全的。
  3. 为何要有随机数，为何在客户端生成？
    随机数是做为后续整个密文加解密的关键秘钥，只有获取这个随机数的人才能够看到通讯的内容，保证通讯的安全；经过客户端产生是由于会话的发起者是用户端，为了保证用户端的惟一，以及保证服务端和客服端的会话内容不被篡改，若是是服务端来生成的话，第三方能够经过公钥来解密服务端加密的随机数，存在不安全因素。
  4. 证书验证完成后，为何客户端须要和服务端互相发送一次签名信息？
    证书验证完成之后，须要传递一个随机数，使用公钥、私钥进行非对称加解密，后面在发生内容消息的前面是为了验证经过随机数进行对称加解密，保证双方获取的数据正确性。

11. 注意

  1. HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么做用
  2. SSL证书的信用链体系并不安全，特别是在某些国家能够控制CA根证书的状况下，中间人攻击同样可行

  3. SSL证书须要购买申请，功能越强大的证书费用越高

  4. SSL证书一般须要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展能够部分解决这个问题，可是比较麻烦，并且要求浏览器、操做系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。

  5. 根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增长10%到20%的耗电。

  6. HTTPS链接缓存不如HTTP高效，流量成本高。

  7. HTTPS链接服务器端资源占用高不少，支持访客多的网站须要投入更大的成本。

  8. HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，相似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。

 

 参考网址

  1. HTTPS协议的实现原理
  2. Https原理及流程
  3. 图解HTTPS
  4. HTTPS原理和CA证书申请（满满的干货）
  5. HTTPS系列干货（一）：HTTPS 原理详解
  6. HTTP和HTTPS协议，看一篇就够了
  7. https服务的原理和实现
  8. Https单向认证和双向认证
  9. HTTPS 之原理
  10. 中间人攻击原理
  11. Https双向认证
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程