一、HTTP为什么不安全？

HTTP协议没有任何的加密以及身份验证的机制，非常容易遭到窃听、劫持、篡改等。不安全的原因主要包含以下三个方面：

• 1. 通信使用明文，内容可能被窃听。
• 2. 不验证通信方的身份，因此有可能遭到伪装。
• 3. 无法验证报文的完整性，所以有可能被篡改。

下面会逐条分析：

1. 通信使用明文，内容可能被窃听。
   

   由于HTTP本身不具备加密的功能，所以也无法做到对通信整体进行加密，HTTP报文使用明文方式发送。 通信使用明文.png

2. 不验证通信方的身份，因此有可能遭到伪装。
   HTTP协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患：

   • a. 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web服务器。
   • b. 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
   • c. 无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限。
   • d. 无法判定请求是来自何方、出自谁手。
     即使是无意义的请求也会照单全收。无法阻止海量请求下的DoS攻击（Denial of Service，拒绝服务攻击）。

3. 无法验证报文的完整性，所以有可能被篡改。
   所谓完整性是指信息的准确度。若无法证明其完整性，通常也就意味着无法判断信息是否准确。

• 接收到的内容可能有误
  • 由于HTTP协议无法证明通信的报文完整性，因此，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。

  • 换句话说，没有任何办法确认，发出的请求/响应和接收到的请求/响应是前后相同的。

    
    无法验证报文的完整性01.png

• 中间人攻击
  如“从某个Web网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的已改变，作为接收方的客户端也是觉察不到的。

  
  无法验证报文的完整性02.png
• 如果防止篡改
  虽然有使用HTTP协议确定报文完整性的方法，但事实上并不便捷、可靠。其中常用的MD5和SHA-1等散列值校验的方法，以及用来确认文件的数字签名方法。
  • 提供文件下载服务的Web网站也会提供相应的以PGP（Pretty Good Privacy，完美隐私）创建的数字签名及MD5算法生成的散列值。PGP是用来证明创建文件的数字签名，MD5是由单向函数生成的散列值。不论使用哪一种方法，都需要操纵客户端的用户本人亲自检查验证下载的文件是否就是原来服务器上的文件。浏览器无法自动帮用户检查。
  • 可惜的是，用这些方法也依然无法百分百保证确认结果正确。因为PGP和MD5本身被改写的话，用户是没有办法意识到的。

二、HTTPS如何保证安全

如果在HTTP协议通信过程中使用未经加密的明文，比如在Web页面中输入信用卡号，如果这条通信线路遭到窃听，那么信用卡号就暴露了。

另外，对于HTTP来说，服务器也好，客户端也好，都是没有办法确认通信方的。因为很有可能并不是和原本预想的通信方在实际通信。并且还需要考虑到接收到的报文在通信途中已经遭到篡改这一可能性。

为了统一解决上述这些问题，需要在HTTP上再加入加密处理和认证等机制。我们把添加了加密及认证机制的HTTP称为HTTPS（HTTP Secure）。

经常会在Web的登录页面和购物结算界面等使用HTTPS通信。使用HTTPS通信时，不再用http://，而是改用https://。另外，当浏览器访问HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记。对HTTPS的显示方式会因浏览器的不同而有所改变。

在采用了SSL后，HTTP就拥有了HTTPS的加密、证书和完整性保护这些功能。
SSL是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的SMTP和Telnet等协议均可配合SSL协议使用。可以说SLL事当今世界上应用最为广泛的网络安全技术。

1. HTTPS是身披SSL外壳的HTTP

HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL 和TLS协议替代而已。通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。

想要讲清楚为什么使用SSL协议，必须要了解一下加密演化进程，下面介绍一下如今使用比较广泛的几种加密方式。

2. 加密方法简介

近代的加密方法中加密算法是公开的，而密钥却是保密的。通过这种方式得以保持加密方法的安全性。
加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说，任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。

2.1. 对称秘钥加密

加密和解密通用一个秘钥的方式称为共享密钥加密（Common key cryptosystem），也被叫做对称秘钥加密 共享密钥加密的困境 .png

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之手，同时也就失去了加密的意义。另外还得设法安全地保管接收到的密钥。

对称加密又分为两种模式：流加密和分组加密。

• 流加密: 将消息作为位流对待，并且使用数学函数分别作用在每一个位上，使用流加密时，每加密一次，相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器，它生成的位流与明文位进行异或，从而生成密文。现在常用的就是RC4，不过RC4已经不再安全，微软也建议网络尽量不要使用RC4流加密。
• 分组加密: 将消息划分为若干位分组，这些分组随后会通过数学函数进行处理，每次一个分组。假设需要加密发生给对端的消息，并且使用的是64位的分组密码，此时如果消息长度为640位，就会被划分成10个64位的分组，每个分组都用一系列数学公式公式进行处理，最后得到10个加密文本分组。然后，将这条密文消息发送给对端。对端必须拥有相同的分组密码，以相反的顺序对10个密文分组使用前面的算法解密，最终得到明文的消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法，现在已经被证明不安全。而3DES是一个过渡的加密算法，相当于在DES基础上进行三重运算来提高安全性，但其本质上还是和DES算法一致。而AES是DES算法的替代算法，是现在最安全的对称加密算法之一。分组加密算法除了算法本身外还存在很多种不同的运算方式，比如ECB、CBC、CFB、OFB、CTR等，这些不同的模式可能只针对特定功能的环境中有效，所以要了解各种不同的模式以及每种模式的用途。

对称加密算法的优、缺点：

• 优点：算法公开、计算量小、加密速度快、加密效率高。

• 缺点：

  • 1.交易双方都使用同样钥匙，安全性得不到保证
  • 2.每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量呈几何级数增长，密钥管理成为用户的负担。
  • 3.能提供机密性，但是不能提供验证和不可否认性。

2.2. 非对称密钥加密

非对称密钥加密有两把秘钥：一把叫做私有密钥（private key），另一把叫做公开密钥（public key），公钥加密，私钥解密。

在非对称密钥交换算法出现以前，对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题，使得对称密钥的生成和使用更加安全。

密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等操作。

常见的密钥交换算法有RSA，ECDHE，DH，DHE等算法。涉及到比较复杂的数学问题，下面就简单介绍下最经典的RSA算法。

• RSA：算法实现简单，诞生于1977年，历史悠久，经过了长时间的破解测试，安全性高。缺点就是需要比较大的素数也就是质数（目前常用的是2048位）来保证安全强度，很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。RSA可以算是最经典的非对称加密算法了。

非对称加密相比对称加密更加安全，但也存在两个明显缺点：

• 1. CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。
• 2. 非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。

所以公钥加密（极端消耗CPU资源）目前只能用来作密钥交换或者内容签名，不适合用来做应用层传输内容的加解密。

另外，要想根据密文和公钥，恢复到信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到。退一步讲，如果能对一个非常大的整数做到快速地因式分解，那么密码破解还是存在希望的。但就目前的技术来看是不太现实的。

2.3. 混合加密机制

由于使用非对称加密能够保证安全，但是效率却大大降低，所以为了改进这个问题，可以采用混合加密机制：“非对称加密”与“对称加密”混合使用。

既：使用非对称密钥传输“对称密钥”，后续安全获得到“对称密钥”后，再使用“对称密钥”加密通信。

存在的问题：中间人攻击。中间人劫持公钥后，发送给对方伪造公钥，对方用伪造公钥进行加密传输，再次被拦截，用中间人用自己的私钥进行解密，此刻中间人得到了“对称加密密钥”

2.4. SSL & TLS

HTTPS使用SSL（Secure Socket Layer）和TLS（Transport Layer Security）这两个协议。SSL技术最初是由浏览器开发商网景通信公司率先倡导的，开发过SSL3.0之前的版本。目前主导权已转移到IETF（Internet Engineering Task Force,Internet工程任务组）的手中。

IETF以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。TSL是以SSL为原型开发的协议，有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TLS1.0。由于SSL1.0协议在设计之初被发现出了问题，就没有实际投入使用。SSL2.0也被发现存在问题，所以很多浏览器直接废除了该协议版本。

SSL速度慢吗？

SSL的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU及内存等资源，导致处理速度变慢。

和使用HTTP相比，网络负载可能会变慢2到100倍。除去和TCP连接、发送HTTP请求·响应以外，还必须进行SSL通信，因此整体上处理通信量不可避免会增加。

另一点是SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起HTTP会更多地消耗服务器和客户端的硬件资源，导致负载增强。

针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通信专用硬件，相对软件来讲，能够提高数倍SSL的计算速度。仅在SSL处理时发挥SSL加速器的功效，以分担负载。

2.4.1. 身份认证

HTTPS协议中身份认证的部分是由数字证书来完成的，证书由公钥、证书主体和数字签名等内容组成。

在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证（验证查看这张证书是否是伪造的，也就是公钥是否是伪造的），并获取公钥。

数字证书有两个作用：

• 1.身份授权：确保浏览器访问的网站是经过CA验证的可信任的网站。
• 2.分发公钥：每个数字证书都包含了注册者生成的公钥（验证确保是合法的，非伪造的公钥）。在SSL握手时会通过certificate消息传输给客户端。

证书申请流程：

• 1.服务器的运营人员向数字证书认证机构提出公钥的申请（信息包括：域名唯一标识和非对称秘钥的公钥等）。
• 2.RA（证书注册及审核机构）检查实体的合法性。如果个人或者小网站，这一步不是必须的。
• 3.CA（证书签发机构）数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。
• 4.证书更新到repository（负责数字证书及CRL内容存储和分发），终端后续从repository更新证书，查询证书状态等。

证书认证流程：

• 1.服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。
• 2.接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。
• 3.此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

数字签名的制作和验证过程如下：

• 数字签名的签发：首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。
• 数字签名的校验：使用CA的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。

需要注意的是：

• 1.数字签名签发和校验使用的密钥对是CA自己的公私密钥，跟证书申请者提交的公钥没有关系。
• 2.数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。
• 3.现在大的CA都会有证书链，证书链的好处一是安全，保持根CA的私钥离线使用。第二个好处是方便部署和撤销，即如果证书出现问题，只需要撤销相应级别的证书，根证书依然安全。
• 4.根CA证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
• 5.怎样获取根CA和多级CA的密钥对？它们是否可信？当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的公钥都默认装到了浏览器或者操作系统环境里。

可证明组织真实性的EV SSL证书

作用：用来证明作为通信一方的服务器是否规范，另外一个作用是可确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是EV SSL证书（Extended Validation SSL Certificate）。
EV SSL证书是基于国际标准的认证指导方针颁发的证书。其严格规定了对运营组织是否真实的确认方针，因此，通过认证的Web网站能够获得更高的认可度。
持有EV SSL证书的Web网站的浏览器地址栏处有绿色的锁头标识，从视觉上就能一眼辨别出。

EV SSL证书标识.jpg

上述机制的愿意图是为了防止用户被钓鱼攻击，但就效果上来讲，还要打一个问号。很多用户可能不了解EV SSL证书相关的知识，因此也不会留意它。

用以确认客户端身份的客户端证书

HTTPS中还可以使用客户端证书。以客户端证书进行客户端认证，证明服务器正在通信的对方始终是预料之内的客户端，其作用跟服务器证书如出一辙。

但客户端证书仍存在几处问题点。其中的一个问题点是证书的获取及发布。
想获取证书时，用户得自行安装客户端证书。但由于客户端证书是要付费购买的，且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。另外，要让知识层次不同的用户们自行安装证书，这件事本身也充满了各种挑战。

现状是，安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务。比如那些可支撑客户端证书支出费用的业务。
例如，银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户确认输入ID和密码，还会要求用户的客户端证书，以确认用户是否从特定的终端访问网银。

客户端证书存在的另一个问题点是，客户端证书毕竟只能用来证明客户端实际存在，而不能用来证明用户本人的真实有效性。也就是说，只要获得了安装有客户端证书的计算机的使用权限，也就意味着同时拥有了客户端证书的使用权限。

2.4.2.数据完整性

数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改，SSL利用基于MD5或SHA的MAC（Message Autahentication Code）算法来保证消息的完整性。

MAC（Message Autahentication Code）算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的参与下，利用MAC算法计算出消息的MAC值，并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改，接收者将丢弃该报文。

由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1，中国山东大学的王小云教授在2005年就宣布破解了 SHA-1完整版算法。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。MAC算法涉及到很多复杂的数学问题，这里就不多讲细节了。

三、HTTPS的安全通信机制

HTTPS的安全通信机制01.png

步骤1： 客户端通过发送Client Hello报文开始SSL通信。

报文中包含：1.随机数。2.sessionID。3.密文族。

1.随机数

在客户端问候中，有四个字节以Unix时间格式记录了客户端的协调世界时间（UTC）。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中，0x2516b84b就是协调世界时间。在他后面有28字节的随机数（ random_C ），在后面的过程中我们会用到这个随机数。

2.Session ID

如果出于某种原因，对话中断，就需要重新握手。为了避免重新握手而造成的访问效率低下，这时候引入了session ID的概念， session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。
session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

3 密文族（Cipher Suites）：

RFC2246中建议了很多中组合，一般写法是"密钥交换算法-对称加密算法-哈希算法，以“TLS_RSA_WITH_AES_256_CBC_SHA”为例：

• TLS为协议。
• RSA为密钥交换的非对称算法。
• AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式）
• SHA是哈希的算法。
  浏览器支持的加密算法一般会比较多，而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。（比如综合安全性以及速度、性能等因素）
• Server_name扩展：一般浏览器也支持 SNI（Server Name Indication）
  当我们去访问一个站点时，一定是先通过DNS解析出站点对应的ip地址，通过ip地址来访问站点，由于很多时候一个ip地址是给很多的站点公用，因此如果没有server_name这个字段，server是无法给与客户端相应的数字证书的，Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。

还有一个很好的功能： SNI（Server Name Indication）。这个的功能比较好，为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是，在连接到服务器建立SSL连接之前先发送要访问站点的域名（Hostname），这样服务器根据这个域名返回一个合适的CA证书。目前，大多数操作系统和浏览器都已经很好地支持SNI扩展，OpenSSL 0.9.8已经内置这一功能，据说新版的nginx也支持SNI。）

步骤2： Server Hello

服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含回复三个数据包,包括 Server Hello， Certificate， Certificate Status。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。下面分别看一下：

随机数、sessionID和加密族

1.我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 （random_S）。

2.Seesion ID，服务端对于session ID 一般会有三种选择 ：

• a.恢复的session ID：我们之前在client hello里面已经提到，如果client hello里面的session ID在服务端有缓存，服务端会尝试恢复这个session；
• b.新的session ID：这里又分两种情况。
  • 第一种是client hello里面的session ID是空值，此时服务端会给客户端一个新的session ID。
  • 第二种是client hello里面的session ID此服务器并没有找到对应的缓存，此时也会回一个新的session ID给客户端；
• c.NULL：服务端不希望此session被恢复，因此session ID为空。

3.我们记得在client hello里面，客户端给出了21种加密族，而在我们所提供的21个加密族中，服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”

• a. TLS为协议，ECDHE-RSA为密钥交换的算法；
• b. AES_128_GCM是对称加密算法（其中128是密钥长度，GCM是分组方式）；
• c.SHA256是哈希的算法。

这就意味着服务端会使用ECDHE-RSA算法进行密钥交换，通过AES_128_GCM对称加密算法来加密数据，利用SHA256哈希算法来确保数据完整性。

步骤3：Certificate

之后服务器发送Certificate报文。报文中包含公开密钥证书。
在前面的https原理研究中，我们知道为了安全的将公钥发给客户端，服务端会把公钥放入数字证书中并发给客户端（数字证书可以自签发，但是一般为了保证安全会有一个专门的CA机构签发），所以这个报文就是数字证书。

步骤4： Server Hello Done

最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。

步骤5: ClientKeyExchange

客户端验证证书真伪性

客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：

• 证书链的可信性trusted certificate path，方法如前文所述；
• 证书是否吊销revocation，有两类方式离线CRL与在线OCSP，不同的客户端行为会不同；
• 有效期expiry date，证书是否在有效时间范围；
• 域名domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析；

秘钥交换

这个过程非常复杂，大概总结一下：

• 1.首先，其利用非对称加密实现身份认证和密钥协商，利用非对称加密，协商好加解密数据的对称秘钥（外加CA认证，防止中间人窃取对称秘钥）
• 2.然后，对称加密算法采用协商的密钥对数据加密，客户端和服务器利用 对称秘钥 进行通信；
• 3.最后，基于散列函数验证信息的完整性，确保通信数据不会被中间人恶意篡改。

此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数random_C和random_S与自己计算产生的Pre-master（由客户端和服务器的 pubkey生成的一串随机数），计算得到协商对称密钥;
enc_key=Fuc(random_C, random_S, Pre-Master)

SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。

步骤6： ChangeCipherSpec

接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。

步骤7： Finished

客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。

步骤8： 服务器同样发送Change Cipher Spec报文。

步骤9： 服务器同样发送Finished报文。

步骤10：Application Data(HTTP)

服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。

步骤11： Application Data(HTTP)

应用层协议通信，即发送HTTP响应。

步骤12： Close notify

最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。

在以上流程中，应用层发送数据时会附加一种叫做MAC（Message Autahentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性。
下面是对整个流程的图解。图中说明了从仅使用服务器端的公开密钥证书（服务器证书）建立HTTPS通信的整个过程。

HTTPS的安全通信机制02.png

① CBC模式（Cipher Block Chaining）又名密码分组链接模式。在此模式下，将前一个明文块加密处理后和下一个明文块做XOR运算，使之重叠，然后再对运算结果做加密处理。对第一个明文块做加密时，要么使用前一段密文的最后一块，要么利用外部生成的初始向量（initial vector,IV）。

四、为什么不一直使用HTTPS

其中一个原因是，因为与纯文本通信相比，加密通信会消耗更多的CPU及内存资源。如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。

因此，如果是非敏感信息则使用HTTP通信，只有在包含个人信息等敏感数据时，才利用HTTPS加密通信。

特别是每当那些访问量较多的Web网站在进行加密处理时，它们所承担着的负载不容小觑。在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。

除此之外，想要节约购买证书的开销也是原因之一。
要进行HTTPS通信，证书是必不可少的。而使用的证书必须向认证机构（CA）购买。证书价格可能会根据不同的认证机构略有不同。
那些购买证书并不合算的服务以及一些个人网站，可能只会选择采用HTTP的通信方式。

资料参考：图解HTTP