理解HTTPS协议
2015-07-05 19:20:54 
阿炯
HTTPS 是 HTTP 协议的一个版本，在浏览器和服务器之间提供安全的数据传输。浏览器和服务器是通过超文本协议进行通信，在使用 HTTP 协议时，客户端向服务端提交表单数据时使用的是非加密方式。
所以当浏览器和服务器通信的物理网络被侵入时，入侵者会得到网页浏览器和服务器之间传输的信息。
HTTP的应用场景是我们不需要使用高安全级别的方法加密数据。但银行这样的应用会发送像信用卡详细信息类的敏感数据，这会产生安全威胁。如果入侵者监视通信信道，他可以轻易获取到底层用户的敏感数据。
HTTPS 保证安全可靠通信
为了避免这样的安全威胁，HTTPS 应运而生。HTTPS 是一个确保数据在 web 浏览器与 web 服务器之间传输安全的协议。HTTPS 是由 HTTP 协议+SSL 协议构成。SSL协议通过对信息进行加密，为网络通信提供安全保障。它运用了非对称密钥机制，这种机制是将公钥自由对外分发，而私钥只有信息接收者才有。HTTPS 对比标准的HTTP协议的两大优势：
它确保了用户访问的是正确的网站，这个网站是他原本打算访问的而不是一些假冒网站。
它确保了web浏览器与web服务器之间通信的内容是加密的，因此入侵者不能得到原始的通信内容。
所以在 HTTPS 中，SSL 起到了确保了数据在客户端和 web 服务端传输安全。
HTTPS 工作流程
为了弄清 HTPPS 协议是怎么工作的，我们首先应该明白加密、解密处理过程是怎么工作的。
加密就是把文本内容转换成其他某种格式，这样他人就无法解析原始内容。解密就是将之前我们转换的密文再转换回原始内容。加密和解密过程也可以用密钥去加密和解密信息。因此如果信息是用某个密钥加密的，那么使用同一个密钥就能解密。这种方式称为对称密钥机制，因为使用的是同一个密钥进行加密和解密。
假如我们用一个密钥加密字符串，另一个密钥来解密字符串，我们就把这个密钥称为非对称密钥。我们把用来加密字符串的密钥称为公钥，而用来解密字符串的密钥称为私钥。
那么现在我们明白了 HTTPS 是用来安全传输 web 服务端与 web 浏览器之间的信息，这就是一个非常好的处理在传输信息的时候使用 HTTPS 协议。当浏览器用 HTTPS 协议请求一个页面时，下面的过程也会发生：
1.浏览器向 server 发出 https 请求，server 监听 443 端口，这个端口是 web server 用来监听使用了 HTTPS 协议的请求。
2.一旦 web 浏览器与 web 服务器之间成功建立连接，SSL 握手流程就开始了。
在握手流程中，浏览器和服务器会针对数据的加密算法进行协商并答成一致。过程如下：
1). 浏览器向服务器发送一些自身的信息(例如其支持的SSL版本)；
2). 服务器响应类似信息，例如通信过程中将要使用的SSL版本；
3). 服务器会向浏览器发送证书，证书中包含了加密数据的公钥，发布者信息，有效期以及服务端唯一标识；
4). 浏览器核实该证书，并发送信息通知服务器证书已验证完成；
5). 浏览器向服务器发送“Change cipher spec”指令：浏览器将对数据进行加密；
6). 服务器向浏览器发送“Change cipher spec”指令，服务端将要对待发送的数据进行加密。
当我们单击chrome中小锁标志，我们就可以看到服务端发送过来的数字证书。
3.浏览器产生对称的密钥并通过服务器公钥将其加密，随后将加密后的密钥发送到服务器，这个对称的密钥用于在整个会话中进行加密和解密。我们知道数字证书是用来提供公钥的，有两个关键的术语用来理解数字证书。
X.509 是一个定义数字证书格式的标准，它规定了证书中需要包含哪些信息，例如下面：
版本 指定 X.509 的版本
序列号 唯一的一串数字用以区分证书
证书发布者名称 CA
公钥
CA(Certification authority)表示发布该证书的机构，只有从发布者那里才能获得证书，证书中通常会有发布者的签名用以保证有效性。
https建立流程简介
以下介绍https的实际流程：
CA将自己的证书(公信凭证)交给各浏览器厂商，厂商将证书配置到各自浏览器。
网站将自己的证书(身份凭证)交给CA，让CA使用私钥对证书进行签名，CA签名后发回给网站。在这个过程中，CA需要核实网站的真实性，网站发给CA签名的也不仅只是证书，其中网站证书(含网站URL)和网站公钥是必要的，还会包含一些其他信息一同签名。
浏览器用户向网站请求安全连接，网站把CA签名后的证书发给用户，浏览器会根据证书信息，检查是哪个CA做的签名，从浏览器自带的CA证书中找到对应公钥验证。
如果验证通过，就证明了网站身份的可靠性，用户可以通过网站提供的公钥进行安全连接，和网站协商后续对称加密的密钥。
https协议简介
为什么是简单地介绍https协议呢？因为https涉及的东西实在太多了，尤其是其中的加解密算法，十分复杂，作者本身对这些算法也研究不完，只是懂其中的一些皮毛而已。这部分仅仅是简单介绍一些关于https的最基本原理，为后面分析https的建立过程以及https优化等内容打下理论基础。
1 对称加密算法
对称加密是指：加密和解密使用相同密钥的算法。它要求发送方和接收方在安全通信之前，商定一个对称密钥。对称算法的安全性完全依赖于密钥，密钥泄漏就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信至关重要。
1.1 对称加密又分为两种模式：流加密和分组加密
流加密是将消息作为字节流对待，并且使用数学函数分别作用在每一个字节位上。使用流加密时，每加密一次，相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器，它生成的字节流与明文字节流进行异或，从而生成密文。
分组加密是将消息划分为若干个分组，这些分组随后会通过数学函数进行处理，每次一个分组。假设使用64位的分组密码，此时如果消息长度为640位，就会被划分成10个64位的分组如果最后一个分组长度不到64，则用0补齐之后加到64位，每个分组都用一系列数学公式进行处理，最后得到10个加密文本分组。然后，将这条密文消息发送给对端。对端必须拥有相同的分组密码，以相反的顺序对10个密文分组使用前面的算法解密，最终得到明文消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法，现在已经被证明不安全。而3DES是一个过渡的加密算法，相当于在DES基础上进行三重运算来提高安全性，但其本质上还是和DES算法一致。而AES是DES算法的替代算法，是现在最安全的对称加密算法之一。
1.2 对称加密算法的优缺点：
优点：计算量小、加密速度快、加密效率高。
缺点：
1)交易双方都使用同样密钥，安全性得不到保证；
2)每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信息双方所拥有的钥匙数量呈几何级数增长，密钥管理成为负担。
2 非对称加密算法
在非对称密钥交换算法出现以前，对称加密的最主要缺陷就是不知道如何在通信双方之间传输对称密钥，而又不让中间人窃取。非对称密钥交换算法诞生之后，专门针对对称密钥传输做加解密，使得对称密钥的交互传输变得非常安全了。
非对称密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等等一系列极其复杂的过程。常见的密钥交换算法有RSA，ECDHE，DH，DHE等算法。涉及到比较复杂的数学问题。其中，最经典也是最常用的是RSA算法。
RSA：诞生于1977年，经过了长时间的破解测试，算法安全性很高，最重要的是，算法实现非常简单。缺点就是需要比较大的质数目前常用的是2048位来保证安全强度，极其消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法，RSA 是最经典，同时也是最常用的是非对称加解密算法。
2.1 非对称加密相比对称加密更加安全，但也存在两个致命的缺点：
1CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%。如果后续的应用层数据传输过程也使用非对称加解密，那么CPU性能开销太庞大，服务器是根本无法承受的。赛门特克给出的实验数据显示，加解密同等数量的文件，非对称算法消耗的CPU资源是对称算法的1000倍以上。
2非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。
所以非对称加解密极端消耗CPU资源目前只能用来作对称密钥交换或者CA签名，不适合用来做应用层内容传输的加解密。
3 身份认证
https协议中身份认证的部分是由CA数字证书完成的，证书由公钥、证书主体、数字签名等内容组成。在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证验证这张证书是否是伪造的？也就是公钥是否是伪造的，如果证书不是伪造的，客户端就获取用于对称密钥交换的非对称密钥获取公钥。
3.1 数字证书有三个作用：
1、身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。
2、分发公钥。每个数字证书都包含了注册者生成的公钥验证确保是合法的，非伪造的公钥。在SSL握手时会通过certificate消息传输给客户端。
3、验证证书合法性。客户端接收到数字证书后，会对证书合法性进行验证。只有验证通过后的证书，才能够进行后续通信过程。
3.2 申请一个受信任的CA数字证书通常有如下流程：
1)公司实体的服务器生成公钥和私钥，以及CA数字证书请求。
2)RA证书注册及审核机构检查实体的合法性在注册系统里面是否注册过的正规公司。
3)CA证书签发机构签发证书，发送给申请者实体。
4)证书更新到repository负责数字证书及CRL内容存储和分发，实体终端后续从repository更新证书，查询证书状态等。
4 数字证书验证
申请者拿到CA的证书并部署在网站服务器端，那浏览器发起握手并接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名digital signature。数字签名是证书的防伪标签，目前使用最广泛的SHA-RSASHA用于哈希算法，RSA用于非对称加密算法。数字签名的制作和验证过程如下：
1、数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。
2、数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对签名证书内容进行签名，并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。
需要注意的是：
1)数字签名签发和校验使用的非对称密钥是CA自己的公钥和私钥，跟证书申请者提交证书申请的公司实体提交的公钥没有任何关系。
2)数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。一对公钥和私钥，公钥加密的内容只有私钥能够解密；反过来，私钥加密的内容，也就有公钥才能够解密
3)现在大的CA都会有证书链，证书链的好处：首先是安全，保持CA的私钥离线使用。第二个好处是方便部署和撤销。这里为啥要撤销呢？因为，如果CA数字证书出现问题被篡改或者污染，只需要撤销相应级别的证书，根证书依然是安全的。
4)根CA证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的非对称密钥进行签名和验证的。
5)怎样获取根CA和多级CA的密钥对？还有，既然是自签名和自认证，那么它们是否安全可信？这里的答案是：当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的根公钥都默认装到了浏览器或者操作系统环境里。
5 数据完整性验证
数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改，或者数据比特被污染，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性。MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的作用下，利用MAC算法计算出消息的MAC值，并将其添加在需要发送的消息之后，并发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改或者污染，接收者将丢弃该报文。SHA也不能使用SHA0和SHA1，山东大学的一个叫王小云女教授在2005年就宣布破解了SHA-1完整版算法，并获得了业内专家的认可。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。
https如何保证安全
要解决http带来的问题，就要引入加密以及身份验证机制。
如果Server以后简称服务器给Client以后简称 客户端的消息是密文的，只有服务器和客户端才能读懂，就可以保证数据的保密性。同时，在交换数据之前，验证一下对方的合法身份，就可以保证通信双方的安全。那么，问题来了，服务器把数据加密后，客户端如何读懂这些数据呢？这时服务器必须要把加密的密钥对称密钥，后面会详细说明告诉客户端，客户端才能利用对称密钥解开密文的内容。但是，服务器如果将这个对称密钥以明文的方式给客户端，还是会被中间人截获，中间人也会知道对称密钥，依然无法保证通信的保密性。但是，如果服务器以密文的方式将对称密钥发给客户端，客户端又如何解开这个密文，得到其中的对称密钥呢？
说到这里，大家是不是有点儿糊涂了？一会儿密钥，一会儿对称密钥，都有点儿被搞晕的节奏。在这里，提前给大家普及一下，这里的密钥，指的是非对称加解密的密钥，是用于TLS握手阶段的； 对称密钥，指的是对称加解密的密钥，是用于后续传输数据加解密的。下面将详细说明。
这时，我们引入了非对称加解密的概念。在非对称加解密算法里，公钥加密的数据，有且只有唯一的私钥才能够解密，所以服务器只要把公钥发给客户端，客户端就可以用这个公钥来加密进行数据传输的对称密钥。客户端利用公钥将对称密钥发给服务器时，即使中间人截取了信息，也无法解密，因为私钥只部署在服务器，其他任何人都没有私钥，因此，只有服务器才能够解密。服务器拿到客户端的信息并用私钥解密之后，就可以拿到加解密数据用的对称密钥，通过这个对称密钥来进行后续通信的数据加解密。除此之外，非对称加密可以很好的管理对称密钥，保证每次数据加密的对称密钥都是不相同的，这样子的话，即使客户端病毒拉取到通信缓存信息，也无法窃取正常通信内容。
上述通信过程，可以画成以下交互图：
但是这样似乎还不够，如果通信过程中，在三次握手或者客户端发起HTTP请求过程中，客户端的请求被中间人劫持，那么中间人就可以伪装成“假冒客户端”和服务器通信；中间人又可以伪装成“假冒服务器”和客户端通信。接下来，我们详细阐述中间人获取对称密钥的过程：
中间人在收到服务器发送给客户端的公钥这里是“正确的公钥”后，并没有发给客户端，而是中间人将自己的公钥这里中间人也会有一对公钥和私钥，这里称呼为“伪造公钥”发给客户端。之后，客户端把对称密钥用这个“伪造公钥”加密后，发送过程中经过了中间人，中间人就可以用自己的私钥解密数据并拿到对称密钥，此时中间人再把对称密钥用“正确的公钥”加密发回给服务器。此时，客户端、中间人、服务器都拥有了一样的对称密钥，后续客户端和服务器的所有加密数据，中间人都可以通过对称密钥解密出来。
中间人获取对称密钥的过程如下：
为了解决此问题，我们引入了数字证书的概念。服务器首先生成公私钥，将公钥提供给相关机构CA，CA将公钥放入数字证书并将数字证书颁布给服务器，此时服务器就不是简单的把公钥给客户端，而是给客户端一个数字证书，数字证书中加入了一些数字签名的机制，保证了数字证书一定是服务器给客户端的。中间人发送的伪造证书，不能够获得CA的认证，此时，客户端和服务器就知道通信被劫持了。加入了CA数字签名认证的SSL会话过程如下所示：
所以综合以上三点：非对称加密算法公钥和私钥交换对称密钥+数字证书验证身份验证公钥是否是伪造的+利用对称密钥加解密后续传输的数据=安全
---------------
美国政府所有网站开始使用 HTTPS 加密
作为维护安全和隐私的一项新举措，美国政府宣布了一项计划，使HTTPS成为其公共网站联邦安全标准。其目标是到2016年12月31日，让美国政府所有网站都使用HTTPS加密。白宫甚至在Github上张贴这项政策的最终版本，让公众自己来进行比较。美国政府内部数据机构表示，这些变化将有助于带来跨美国政府网站和API的隐私和安全。
该机构长期以来一直支持一刀切地采用HTTPS标准，认为每一个以gov为后缀的网站都应该提供一个安全的连接。在此期间，有一个网站显示有多少联邦网站开始过渡到HTTPS，甚至对这些联邦网站进行安全评级。
---------------
维基百科将默认开启 HTTPS 以强化安全
维基媒体基金会发布公告称，旗下所有网站将全部默认开启HTTPS，以确保用户在不牺牲隐私和安全的前提下访问内容。目前这项工作正在进行中，这些网站里面其中最出名的当然是全球最大的在线百科网站维基百科。
默认HTTPS开启意味着用户对其包括维基百科在内的所有旗下网站的访问流量都将进行加密，这样第三方就无法知道用户浏览了什么内容，也无法获取敏感数据，从而保护用户的隐私和安全。
实际上，维基媒体基金会的这项工作在一年前就已经开始，但是由于全站默认支持HTTPS要涉及到对基础设施(HTTPS相对于HTTP要多占用服务器端的资源)和底层代码进行改造，所以没有办法一蹴而就。为了确保用户都能采用HTTPS访问旗下网站内容，维基媒体基金会还启用了HTTP Strict Transport Security（HSTS）协议。该协议的作用正是强制客户端（如浏览器）使用HTTPS与服务器创建连接。
尽管从去年开始维基媒体基金会已经针对不同设备访问进行了大量测试，但该基金会仍警告称局部地区对网站的访问可能会存在问题，基金会保证最后会将变动的技术细节公布出来。当然对于某些局部地区而言，加不加密的意义其实并不大，因为首先你得能访问它。
尽管如此，对网络流量进行加密已经成为全球网站的普遍趋势。Google早已经将Gmail流量完全HTTPS化，而且为了鼓励其他网站效仿，Google去年已经调整搜索引擎算法，让采用HTTPS的网站排名更高。这种做法一方面是为了避免第三方窃听或阻断流量，保护用户的隐私和安全，另一层意义则是实现网站对数据的独享。而在大数据时代，数据就是财富。
我们所熟悉的HTTP前缀正快速被HTTPS所取代。HTTPS中的S代表你的连接是安全的，其他人要想看你在做什么将会变得愈加困难。而今天的互联网上人人都想看你正在干什么。HTTPS曾经主要被金融、购物类网站使用，但在主要互联网公司和浏览器开发商的推动之下，HTTPS在加速普及，HTTP正在被加速淘汰。不加密的HTTP连接是不安全的，你和目标服务器之间的任何中间人能读取和操纵传输的数据，比如ISP可以在你点击的网页上插入广告，你很可能根本不知道你看到的广告是否是网站发布的。中间人能够注入的代码不仅仅是看起来无害的广告，他们还可能注入具有恶意目的的代码。去年，百度联盟广告的脚本被中间人修改，加入了代码对两个政府不喜欢的网站发动了DDoS攻击。这次攻击被称为网络大炮，敌意的大炮让普通的网民在不知情下变成了DDoS攻击者。唯一能阻止大炮的方法是加密流量。
---------------
HTTPS网络安全之SSL,TLS,CA,RSA,ECDHE
我们知道，明文传输和不安全是HTTP的其中一个特点，但是随着越来越多机密的业务交易转移到线上，如银行转账、证券交易、在线支付、电商等，我们对传输的安全性有了更高的要求，为此，出现了HTTP的扩展：HTTPS，Hypertext Transfer Protocol Secure，超文本传输安全协议。HTTPS默认端口号为433，基于HTTP扩展了安全传输的特性，其他特性完全沿用HTTP。
1、HTTPS协议架构
先来看一看HTTP的协议架构和HTTPS协议架构的区别：
HTTP是基于TCP/IP的协议，中间没有任何安全传输相关的模块。为此，HTTPS在中间引入了一个传输级的密码安全层，该层可以使用安全套接层 Secure Sockets Layer(SSL)，也可以使用其后继者：传输层安全 Transport Layer Security(TLS)。
HTTPS = HTTP + SSL or TLS
加入这层之后，**收发报文也就不再是使用Socket API，而是调用了安全层提供的安全API**。在使用HTTPS时无需过多的修改协议处理逻辑。为此，如果我们弄清楚这个SSL/TLS，就理解了HTTPS的精华所在了。
2、SSL/TLS发展历史
为了保证安全性，SSL/TLS在不断的迭代升级版本，引入了更加安全的算法套件。下面是大致的升级过程：
在1999年，SSL 3.0升级为TLS 1.0，写入到RFC 2246标准中。不过由于安全问题，TLS 1.1及其以下版本都将作废，不再维护，目前主要在用的是TLS 1.2和TLS 1.3。
OpenSSL是开源版本的实现，目前急需在维护的是OpenSSL 1.1.1版本。
3、TLS详解
浏览器和服务器通信之前，会先协商，选出他们都支持的加密套件，用于实现安全的通信。常见的加密套件可以参考：Cipher Suites。
选一个来看看加密套件的命名格式：
如最后一个组合，意味着：
ECDHE: 握手时，使用ECDHE算法交换密钥；
ECDSA: 使用ECDSA算法进行签名；
AES128-GCM: 使用AES256对称加密算法进行通信，密钥长度128，分组模式GCM；
SHA256: 使用SHA256算法进行消息的完整性验证和产生随机数。
3.1、为什么需要用到这么多算法？
以密码学为基础的信息安全包含主要的五个方面：机密性，可用性，完整性，认证性，不可否认性。
为了保证安全，TLS就需要保证这五个特性。简要说明下这个五个特性：
机密性：保密信息不会透露给非授权的用户或实体；
可用性：指的是加密服务的高可用；
完整性：信息不回被非法篡改，有对应的篡改检测机制；
认证性：参与信息交换的两个主体需要确认对方的身份是否可信，避免信息被不怀好意的人给窃取或者篡改；
不可否认性：指的是用户在事后无法否认曾经进行的信息交换、签发；
每种算法，在TLS中都有其特定的用处，下面先简单介绍各种算法。
3.2、对称加密算法
所谓对称加密，就是使用同一个密钥进行加解密。
最常见的就是AES加密算法。但是对称加密，加解密双方如何安全的传递密钥是一个问题。如果服务器直接把密钥传输给客户端，然后才进行加密通信，可能在传输密钥的过程中，密钥就被窃取了。
3.3、非对称加密
非对称加密通常包含一对密钥，称为公钥(public key)和私钥(private key)。
其中一个密钥加密后的数据，只能让另一个密钥进行解密。
使用公钥推算出私钥是非常困难的，但是随着计算机运算能力提升，目前在程序中使用的非对称密钥至少要2048位才能保证安全性。
虽然非对称加密能够保证安全性，但是性能却比对称加密差很多。
为此，在TLS中，实际上用的是用到了两种算法的混合加密。通过非对称加密算法交换对称加密算法的密钥，交换完成之后，在使用对称加密进行加解密传输数据。这样就保证了会话的机密性。
3.4、摘要算法
摘要算法主要用于保证信息的完整性，相当于信息的指纹信息。常见的散列函数，哈希函数，MD5算法都属于这类算法，其特点是单向性，无法反推原文。
为了保证安全性，目前TLS推荐使用SHA-2摘要算法，禁止使用MD5和SHA-1。
有了摘要算法就能保证完整性了吗？
假如黑客截取了信息，改动了信息之后，重新生成了摘要，那么，这个时候就判断不出来消息是被篡改过了。
为了避免这类消息发生，我们需要给摘要也通过会话密钥进行加密，这样就看不到摘要明文信息了，能更好的保证信息的安全性了。
可见，离开了机密性，完整性也就无从说起了。
3.5、数字签名
到目前为止，我们还有一个问题没有解决，那就是：怎么知道我们要连接的网站不是伪造的呢，如果是伪造的，即使他给了我们他的公钥，也是可以成功进行加解密的，因为他给的公钥给他自己的私钥本身就是一对。
如下图，客户端的请求被中间人截获了，中间人给了客户端自己的公钥，最终客户端把消息发给了中间人，中间人这个时候是可以解密密文拿到原始数据的。然后中间人请求实际的服务器，拿到了实际服务器的公钥，再把消息转发给实际的服务器。这样就窃取了客户端的信息了。
中间人攻击
为了避免拿到假的公钥，所以我们需要一个权威机构帮忙验证这个公钥是不是真的。
通过CA机构生成数字证书
这个时候我们请来了权威的机构，来帮忙我们生成网站公钥的数字证书：
如上图，服务器和CA机构分别有一对密钥，服务器请求CA机构把服务器公钥生成一个数字证书，生成流程：
CA机构通过摘要算法生成公钥的摘要；
CA机构通过自己的CA私钥以及特定的签名算法加密摘要，生成签名；
把签名、服务器公钥，以及其他基本信息打包放入数字证书中。
最后，CA机构把生成的数字证书返回给服务器。
服务器配置好生成的证书，以后客户端连接服务器，都先把这个证书返回给客户端，让客户端验证并获取服务器的公钥。
服务器公钥验证流程
客户端接收到服务器发送的数字证书和CA机构的公钥，通过CA机构的公钥对数字证书上的签名进行验证。
验证过程：
使用CA公钥和声明的签名算法对CA中的签名进行解密，得到服务器公钥的摘要内容；
拿到证书里面的服务器公钥，用摘要算法生成摘要内容，与第一步的结果对比，如果一致，则说该证书就是合法的，里面的公钥是正确的，否则证书就是非法的。
谁来保证CA的公钥的正确性?
服务器验证的时候，需要拿到数字证书发布机构的CA公钥，但是怎么证明这个CA公钥是正确的呢？这个时候就需要有更大的CA帮小的CA的公钥做认证了，一层一层的背书，最顶层的CA，Root CA，称为根证书，作为信任链的根，是全球皆知的的极大著名CA，这些根证书一般会内置到操作系统中。
大家可以到操作系统的证书目录下，或者浏览器，看看证书文件里面都有什么内容。
思考题：即使证书验证通过了，这样就能够保证安全了么，想想还有没有其他原因导致请求的网站身份不可信的；
有了CA机构，就没法进行中间人攻击了吗？
3.6、算法总结
来总结一下上面提到的各种算法的作用：
签名算法：通过数字证书，和CA公钥，验证获取到的服务器公钥的可靠性，保证了认证性；
密钥交换算法 + 对称加密算法：通过交换的密钥，进行加密通信，保证了机密性和不可否认性；
摘要算法：保证完整性。
4、HTTPS连接过程
HTTS连接访问比HTTP多了一步TLS连接：DNS解析，TCP连接、TLS连接。
最关键的就是TLS连接，这里我们重点来分析。
其中TLS连接认证分为单向认证和双向认证：
单向认证 ：服务器提供证书，客户端验证服务器证书；
双向认证 ：服务器客户端分别提供证书给对方，并互相验证对方的证书。
不过，大多数运行HTTPS的web服务器都不需要客户端提供证书，如果服务器需要验证客户端的身份，一般是通过用户名和密码、手机验证码等之类的凭证来完成。对于更高安全级别要求的系统，如大额网银转账等，则会提供双向认证的场景，来确保对客户身份提供认证性。
早期的TLS密钥交换用的是RSA算法，目前主流都是用ECDHE算法来做密钥交换的。下面我们分别来介绍下。
4.1、基于TLS1.2的HTTPS连接过程
4.1.1、RSA密钥交换算法
这个过程稍微有点复杂，还是先上图，流程的关键部分都加上了注释，后面详细解释。
如上图：
首先是TCP三次握手，握手成功之后，就可以开始通过TCP传输数据了；
接下来是TLS握手的流程：
Client Hello：客户端生成一个Client Random随机数，明文发送给服务器，同时提供自己的 TLS版本号，以及自己支持的加密套件；
Server Hello：服务器收到之后，也生成了一个Server Random随机数，明文发送给客户端，同时告知自己选择的TLS版本号，以及选择的加密套件；
Server Certificate：服务器发送自己的证书给到客户端；
Server Hello Done：提示服务器信息发送完毕；
客户端收到证书之后进行证书的校验，确保公钥是合法的；
Client Key Exchange：客户端生成一个PreMaster随机数，通过服务器的公钥加密传输给服务器；
这个时候客户端和服务器都有三个参数：Server Random、Client Random、PreMaster，其中PreMaster是无法被不怀好意的人截获的，通过这三个参数，生成对称密钥；
客户端Change Cipher Spec：客户端通知服务器后续改用刚刚生成的密钥进行加密通信；
客户端Encrypted Handshake Message：客户端准备用刚刚的参数加密传输，验证加密通信；
服务器Change Cipher Spec：服务器也通知客户端后续改用刚刚生成的密钥进行加密通信；
服务器Encrypted Handshake Message：服务器准备用刚刚的参数加密传输，验证加密通信；
在双方都确认好了之后，最后是验证的消息。
这里的核心是：通过非对称加密交换参数，生成对称通信加密的密钥，其中PreMaster是非对称加密传输的，保证了不会泄露通信加密的密钥。
下面我们再来看看主流的ECDHE密钥交换算法的HTTPS连接过程。
4.1.2、ECDHE密钥交换算法
我把与基于RSA算法的连接过程的差异步骤都进行高亮显示了，如下图：
这里重点说明不一样的地方：
Server Key Exchange：在服务端发送完证书之后，多了这一步，这个是椭圆曲线参数Server Params，为了保证认证性，这里同时生成了Server Params的签名，一起发给客户端；
Client Key Exchange：这里不再是直接发送客户端生成PreMaster，而是生成客户端的椭圆曲线参数Client Params，直接传送给服务端；接着，客户端和服务端双方通过ECDHE算法用Client Params和Server Params算出最终的PreMaster，这个PreMaster是保证不会被截获的。这样双方就有了：Client Random，Server Random，PreMaster参数了，通过这三个参数就可以生成通信密钥了；
在客户端发送了Encrypted Handshake Message之后，就立刻发送测试包了，不用等到服务端发送完Encrypted Handshake Message。
4.2、TLS1.3对安全性和性能的提升
TLS1.3是2018年发布的，这个版本中对安全性和性能上有了大幅度提升。
4.2.1、安全性提升
这个版本中砍掉了很多不够安全点加密套件中的算法，只提供了少而精的加密套件。
密钥交换算法废弃了RSA，更好地保证了安全性，不会因为RSA私钥泄露导致历史报文被破解的问题出现。
假设有人故意截获了会话中所有的加密报文，在RSA算法中，如果私钥泄露，那么就可以推算出PreMaster和对称密钥，那么保存了所有的历史报文都会被破解。
4.2.2、性能提升
上图我们看到，TLS握手经历了两个RTT。
TLS1.3简化了握手过程，主要就是把原来两个RTT中的信息，打包成一个发送了，减少传输次数，最终只需要1个RTT就完成了信息的交换和握手。
所以当浏览器和服务器通信的物理网络被侵入时，入侵者会得到网页浏览器和服务器之间传输的信息。
HTTP的应用场景是我们不需要使用高安全级别的方法加密数据。但银行这样的应用会发送像信用卡详细信息类的敏感数据，这会产生安全威胁。如果入侵者监视通信信道，他可以轻易获取到底层用户的敏感数据。
HTTPS 保证安全可靠通信
为了避免这样的安全威胁，HTTPS 应运而生。HTTPS 是一个确保数据在 web 浏览器与 web 服务器之间传输安全的协议。HTTPS 是由 HTTP 协议+SSL 协议构成。SSL协议通过对信息进行加密，为网络通信提供安全保障。它运用了非对称密钥机制，这种机制是将公钥自由对外分发，而私钥只有信息接收者才有。HTTPS 对比标准的HTTP协议的两大优势：
它确保了用户访问的是正确的网站，这个网站是他原本打算访问的而不是一些假冒网站。
它确保了web浏览器与web服务器之间通信的内容是加密的，因此入侵者不能得到原始的通信内容。
所以在 HTTPS 中，SSL 起到了确保了数据在客户端和 web 服务端传输安全。
HTTPS 工作流程
为了弄清 HTPPS 协议是怎么工作的，我们首先应该明白加密、解密处理过程是怎么工作的。
加密就是把文本内容转换成其他某种格式，这样他人就无法解析原始内容。解密就是将之前我们转换的密文再转换回原始内容。加密和解密过程也可以用密钥去加密和解密信息。因此如果信息是用某个密钥加密的，那么使用同一个密钥就能解密。这种方式称为对称密钥机制，因为使用的是同一个密钥进行加密和解密。
假如我们用一个密钥加密字符串，另一个密钥来解密字符串，我们就把这个密钥称为非对称密钥。我们把用来加密字符串的密钥称为公钥，而用来解密字符串的密钥称为私钥。
那么现在我们明白了 HTTPS 是用来安全传输 web 服务端与 web 浏览器之间的信息，这就是一个非常好的处理在传输信息的时候使用 HTTPS 协议。当浏览器用 HTTPS 协议请求一个页面时，下面的过程也会发生：
1.浏览器向 server 发出 https 请求，server 监听 443 端口，这个端口是 web server 用来监听使用了 HTTPS 协议的请求。
2.一旦 web 浏览器与 web 服务器之间成功建立连接，SSL 握手流程就开始了。
在握手流程中，浏览器和服务器会针对数据的加密算法进行协商并答成一致。过程如下：
1). 浏览器向服务器发送一些自身的信息(例如其支持的SSL版本)；
2). 服务器响应类似信息，例如通信过程中将要使用的SSL版本；
3). 服务器会向浏览器发送证书，证书中包含了加密数据的公钥，发布者信息，有效期以及服务端唯一标识；
4). 浏览器核实该证书，并发送信息通知服务器证书已验证完成；
5). 浏览器向服务器发送“Change cipher spec”指令：浏览器将对数据进行加密；
6). 服务器向浏览器发送“Change cipher spec”指令，服务端将要对待发送的数据进行加密。
当我们单击chrome中小锁标志，我们就可以看到服务端发送过来的数字证书。
3.浏览器产生对称的密钥并通过服务器公钥将其加密，随后将加密后的密钥发送到服务器，这个对称的密钥用于在整个会话中进行加密和解密。我们知道数字证书是用来提供公钥的，有两个关键的术语用来理解数字证书。
X.509 是一个定义数字证书格式的标准，它规定了证书中需要包含哪些信息，例如下面：
版本 指定 X.509 的版本
序列号 唯一的一串数字用以区分证书
证书发布者名称 CA
公钥
CA(Certification authority)表示发布该证书的机构，只有从发布者那里才能获得证书，证书中通常会有发布者的签名用以保证有效性。
https建立流程简介
以下介绍https的实际流程：
CA将自己的证书(公信凭证)交给各浏览器厂商，厂商将证书配置到各自浏览器。
网站将自己的证书(身份凭证)交给CA，让CA使用私钥对证书进行签名，CA签名后发回给网站。在这个过程中，CA需要核实网站的真实性，网站发给CA签名的也不仅只是证书，其中网站证书(含网站URL)和网站公钥是必要的，还会包含一些其他信息一同签名。
浏览器用户向网站请求安全连接，网站把CA签名后的证书发给用户，浏览器会根据证书信息，检查是哪个CA做的签名，从浏览器自带的CA证书中找到对应公钥验证。
如果验证通过，就证明了网站身份的可靠性，用户可以通过网站提供的公钥进行安全连接，和网站协商后续对称加密的密钥。
https协议简介
为什么是简单地介绍https协议呢？因为https涉及的东西实在太多了，尤其是其中的加解密算法，十分复杂，作者本身对这些算法也研究不完，只是懂其中的一些皮毛而已。这部分仅仅是简单介绍一些关于https的最基本原理，为后面分析https的建立过程以及https优化等内容打下理论基础。
1 对称加密算法
对称加密是指：加密和解密使用相同密钥的算法。它要求发送方和接收方在安全通信之前，商定一个对称密钥。对称算法的安全性完全依赖于密钥，密钥泄漏就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信至关重要。
1.1 对称加密又分为两种模式：流加密和分组加密
流加密是将消息作为字节流对待，并且使用数学函数分别作用在每一个字节位上。使用流加密时，每加密一次，相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器，它生成的字节流与明文字节流进行异或，从而生成密文。
分组加密是将消息划分为若干个分组，这些分组随后会通过数学函数进行处理，每次一个分组。假设使用64位的分组密码，此时如果消息长度为640位，就会被划分成10个64位的分组如果最后一个分组长度不到64，则用0补齐之后加到64位，每个分组都用一系列数学公式进行处理，最后得到10个加密文本分组。然后，将这条密文消息发送给对端。对端必须拥有相同的分组密码，以相反的顺序对10个密文分组使用前面的算法解密，最终得到明文消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法，现在已经被证明不安全。而3DES是一个过渡的加密算法，相当于在DES基础上进行三重运算来提高安全性，但其本质上还是和DES算法一致。而AES是DES算法的替代算法，是现在最安全的对称加密算法之一。
1.2 对称加密算法的优缺点：
优点：计算量小、加密速度快、加密效率高。
缺点：
1)交易双方都使用同样密钥，安全性得不到保证；
2)每次使用对称加密算法时，都需要使用其他人不知道的惟一密钥，这会使得发收信息双方所拥有的钥匙数量呈几何级数增长，密钥管理成为负担。
2 非对称加密算法
在非对称密钥交换算法出现以前，对称加密的最主要缺陷就是不知道如何在通信双方之间传输对称密钥，而又不让中间人窃取。非对称密钥交换算法诞生之后，专门针对对称密钥传输做加解密，使得对称密钥的交互传输变得非常安全了。
非对称密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等等一系列极其复杂的过程。常见的密钥交换算法有RSA，ECDHE，DH，DHE等算法。涉及到比较复杂的数学问题。其中，最经典也是最常用的是RSA算法。
RSA：诞生于1977年，经过了长时间的破解测试，算法安全性很高，最重要的是，算法实现非常简单。缺点就是需要比较大的质数目前常用的是2048位来保证安全强度，极其消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法，RSA 是最经典，同时也是最常用的是非对称加解密算法。
2.1 非对称加密相比对称加密更加安全，但也存在两个致命的缺点：
1CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%。如果后续的应用层数据传输过程也使用非对称加解密，那么CPU性能开销太庞大，服务器是根本无法承受的。赛门特克给出的实验数据显示，加解密同等数量的文件，非对称算法消耗的CPU资源是对称算法的1000倍以上。
2非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。
所以非对称加解密极端消耗CPU资源目前只能用来作对称密钥交换或者CA签名，不适合用来做应用层内容传输的加解密。
3 身份认证
https协议中身份认证的部分是由CA数字证书完成的，证书由公钥、证书主体、数字签名等内容组成。在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证验证这张证书是否是伪造的？也就是公钥是否是伪造的，如果证书不是伪造的，客户端就获取用于对称密钥交换的非对称密钥获取公钥。
3.1 数字证书有三个作用：
1、身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。
2、分发公钥。每个数字证书都包含了注册者生成的公钥验证确保是合法的，非伪造的公钥。在SSL握手时会通过certificate消息传输给客户端。
3、验证证书合法性。客户端接收到数字证书后，会对证书合法性进行验证。只有验证通过后的证书，才能够进行后续通信过程。
3.2 申请一个受信任的CA数字证书通常有如下流程：
1)公司实体的服务器生成公钥和私钥，以及CA数字证书请求。
2)RA证书注册及审核机构检查实体的合法性在注册系统里面是否注册过的正规公司。
3)CA证书签发机构签发证书，发送给申请者实体。
4)证书更新到repository负责数字证书及CRL内容存储和分发，实体终端后续从repository更新证书，查询证书状态等。
4 数字证书验证
申请者拿到CA的证书并部署在网站服务器端，那浏览器发起握手并接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名digital signature。数字签名是证书的防伪标签，目前使用最广泛的SHA-RSASHA用于哈希算法，RSA用于非对称加密算法。数字签名的制作和验证过程如下：
1、数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。
2、数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对签名证书内容进行签名，并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。
需要注意的是：
1)数字签名签发和校验使用的非对称密钥是CA自己的公钥和私钥，跟证书申请者提交证书申请的公司实体提交的公钥没有任何关系。
2)数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。一对公钥和私钥，公钥加密的内容只有私钥能够解密；反过来，私钥加密的内容，也就有公钥才能够解密
3)现在大的CA都会有证书链，证书链的好处：首先是安全，保持CA的私钥离线使用。第二个好处是方便部署和撤销。这里为啥要撤销呢？因为，如果CA数字证书出现问题被篡改或者污染，只需要撤销相应级别的证书，根证书依然是安全的。
4)根CA证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的非对称密钥进行签名和验证的。
5)怎样获取根CA和多级CA的密钥对？还有，既然是自签名和自认证，那么它们是否安全可信？这里的答案是：当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的根公钥都默认装到了浏览器或者操作系统环境里。
5 数据完整性验证
数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改，或者数据比特被污染，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性。MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的作用下，利用MAC算法计算出消息的MAC值，并将其添加在需要发送的消息之后，并发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改或者污染，接收者将丢弃该报文。SHA也不能使用SHA0和SHA1，山东大学的一个叫王小云女教授在2005年就宣布破解了SHA-1完整版算法，并获得了业内专家的认可。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。
https如何保证安全
要解决http带来的问题，就要引入加密以及身份验证机制。
如果Server以后简称服务器给Client以后简称 客户端的消息是密文的，只有服务器和客户端才能读懂，就可以保证数据的保密性。同时，在交换数据之前，验证一下对方的合法身份，就可以保证通信双方的安全。那么，问题来了，服务器把数据加密后，客户端如何读懂这些数据呢？这时服务器必须要把加密的密钥对称密钥，后面会详细说明告诉客户端，客户端才能利用对称密钥解开密文的内容。但是，服务器如果将这个对称密钥以明文的方式给客户端，还是会被中间人截获，中间人也会知道对称密钥，依然无法保证通信的保密性。但是，如果服务器以密文的方式将对称密钥发给客户端，客户端又如何解开这个密文，得到其中的对称密钥呢？
说到这里，大家是不是有点儿糊涂了？一会儿密钥，一会儿对称密钥，都有点儿被搞晕的节奏。在这里，提前给大家普及一下，这里的密钥，指的是非对称加解密的密钥，是用于TLS握手阶段的； 对称密钥，指的是对称加解密的密钥，是用于后续传输数据加解密的。下面将详细说明。
这时，我们引入了非对称加解密的概念。在非对称加解密算法里，公钥加密的数据，有且只有唯一的私钥才能够解密，所以服务器只要把公钥发给客户端，客户端就可以用这个公钥来加密进行数据传输的对称密钥。客户端利用公钥将对称密钥发给服务器时，即使中间人截取了信息，也无法解密，因为私钥只部署在服务器，其他任何人都没有私钥，因此，只有服务器才能够解密。服务器拿到客户端的信息并用私钥解密之后，就可以拿到加解密数据用的对称密钥，通过这个对称密钥来进行后续通信的数据加解密。除此之外，非对称加密可以很好的管理对称密钥，保证每次数据加密的对称密钥都是不相同的，这样子的话，即使客户端病毒拉取到通信缓存信息，也无法窃取正常通信内容。
上述通信过程，可以画成以下交互图：
但是这样似乎还不够，如果通信过程中，在三次握手或者客户端发起HTTP请求过程中，客户端的请求被中间人劫持，那么中间人就可以伪装成“假冒客户端”和服务器通信；中间人又可以伪装成“假冒服务器”和客户端通信。接下来，我们详细阐述中间人获取对称密钥的过程：
中间人在收到服务器发送给客户端的公钥这里是“正确的公钥”后，并没有发给客户端，而是中间人将自己的公钥这里中间人也会有一对公钥和私钥，这里称呼为“伪造公钥”发给客户端。之后，客户端把对称密钥用这个“伪造公钥”加密后，发送过程中经过了中间人，中间人就可以用自己的私钥解密数据并拿到对称密钥，此时中间人再把对称密钥用“正确的公钥”加密发回给服务器。此时，客户端、中间人、服务器都拥有了一样的对称密钥，后续客户端和服务器的所有加密数据，中间人都可以通过对称密钥解密出来。
中间人获取对称密钥的过程如下：
为了解决此问题，我们引入了数字证书的概念。服务器首先生成公私钥，将公钥提供给相关机构CA，CA将公钥放入数字证书并将数字证书颁布给服务器，此时服务器就不是简单的把公钥给客户端，而是给客户端一个数字证书，数字证书中加入了一些数字签名的机制，保证了数字证书一定是服务器给客户端的。中间人发送的伪造证书，不能够获得CA的认证，此时，客户端和服务器就知道通信被劫持了。加入了CA数字签名认证的SSL会话过程如下所示：
所以综合以上三点：非对称加密算法公钥和私钥交换对称密钥+数字证书验证身份验证公钥是否是伪造的+利用对称密钥加解密后续传输的数据=安全
---------------
美国政府所有网站开始使用 HTTPS 加密
作为维护安全和隐私的一项新举措，美国政府宣布了一项计划，使HTTPS成为其公共网站联邦安全标准。其目标是到2016年12月31日，让美国政府所有网站都使用HTTPS加密。白宫甚至在Github上张贴这项政策的最终版本，让公众自己来进行比较。美国政府内部数据机构表示，这些变化将有助于带来跨美国政府网站和API的隐私和安全。
该机构长期以来一直支持一刀切地采用HTTPS标准，认为每一个以gov为后缀的网站都应该提供一个安全的连接。在此期间，有一个网站显示有多少联邦网站开始过渡到HTTPS，甚至对这些联邦网站进行安全评级。
---------------
维基百科将默认开启 HTTPS 以强化安全
维基媒体基金会发布公告称，旗下所有网站将全部默认开启HTTPS，以确保用户在不牺牲隐私和安全的前提下访问内容。目前这项工作正在进行中，这些网站里面其中最出名的当然是全球最大的在线百科网站维基百科。
默认HTTPS开启意味着用户对其包括维基百科在内的所有旗下网站的访问流量都将进行加密，这样第三方就无法知道用户浏览了什么内容，也无法获取敏感数据，从而保护用户的隐私和安全。
实际上，维基媒体基金会的这项工作在一年前就已经开始，但是由于全站默认支持HTTPS要涉及到对基础设施(HTTPS相对于HTTP要多占用服务器端的资源)和底层代码进行改造，所以没有办法一蹴而就。为了确保用户都能采用HTTPS访问旗下网站内容，维基媒体基金会还启用了HTTP Strict Transport Security（HSTS）协议。该协议的作用正是强制客户端（如浏览器）使用HTTPS与服务器创建连接。
尽管从去年开始维基媒体基金会已经针对不同设备访问进行了大量测试，但该基金会仍警告称局部地区对网站的访问可能会存在问题，基金会保证最后会将变动的技术细节公布出来。当然对于某些局部地区而言，加不加密的意义其实并不大，因为首先你得能访问它。
尽管如此，对网络流量进行加密已经成为全球网站的普遍趋势。Google早已经将Gmail流量完全HTTPS化，而且为了鼓励其他网站效仿，Google去年已经调整搜索引擎算法，让采用HTTPS的网站排名更高。这种做法一方面是为了避免第三方窃听或阻断流量，保护用户的隐私和安全，另一层意义则是实现网站对数据的独享。而在大数据时代，数据就是财富。
我们所熟悉的HTTP前缀正快速被HTTPS所取代。HTTPS中的S代表你的连接是安全的，其他人要想看你在做什么将会变得愈加困难。而今天的互联网上人人都想看你正在干什么。HTTPS曾经主要被金融、购物类网站使用，但在主要互联网公司和浏览器开发商的推动之下，HTTPS在加速普及，HTTP正在被加速淘汰。不加密的HTTP连接是不安全的，你和目标服务器之间的任何中间人能读取和操纵传输的数据，比如ISP可以在你点击的网页上插入广告，你很可能根本不知道你看到的广告是否是网站发布的。中间人能够注入的代码不仅仅是看起来无害的广告，他们还可能注入具有恶意目的的代码。去年，百度联盟广告的脚本被中间人修改，加入了代码对两个政府不喜欢的网站发动了DDoS攻击。这次攻击被称为网络大炮，敌意的大炮让普通的网民在不知情下变成了DDoS攻击者。唯一能阻止大炮的方法是加密流量。
---------------
HTTPS网络安全之SSL,TLS,CA,RSA,ECDHE
我们知道，明文传输和不安全是HTTP的其中一个特点，但是随着越来越多机密的业务交易转移到线上，如银行转账、证券交易、在线支付、电商等，我们对传输的安全性有了更高的要求，为此，出现了HTTP的扩展：HTTPS，Hypertext Transfer Protocol Secure，超文本传输安全协议。HTTPS默认端口号为433，基于HTTP扩展了安全传输的特性，其他特性完全沿用HTTP。
1、HTTPS协议架构
先来看一看HTTP的协议架构和HTTPS协议架构的区别：
HTTP是基于TCP/IP的协议，中间没有任何安全传输相关的模块。为此，HTTPS在中间引入了一个传输级的密码安全层，该层可以使用安全套接层 Secure Sockets Layer(SSL)，也可以使用其后继者：传输层安全 Transport Layer Security(TLS)。
HTTPS = HTTP + SSL or TLS
加入这层之后，**收发报文也就不再是使用Socket API，而是调用了安全层提供的安全API**。在使用HTTPS时无需过多的修改协议处理逻辑。为此，如果我们弄清楚这个SSL/TLS，就理解了HTTPS的精华所在了。
2、SSL/TLS发展历史
为了保证安全性，SSL/TLS在不断的迭代升级版本，引入了更加安全的算法套件。下面是大致的升级过程：
在1999年，SSL 3.0升级为TLS 1.0，写入到RFC 2246标准中。不过由于安全问题，TLS 1.1及其以下版本都将作废，不再维护，目前主要在用的是TLS 1.2和TLS 1.3。
OpenSSL是开源版本的实现，目前急需在维护的是OpenSSL 1.1.1版本。
3、TLS详解
浏览器和服务器通信之前，会先协商，选出他们都支持的加密套件，用于实现安全的通信。常见的加密套件可以参考：Cipher Suites。
选一个来看看加密套件的命名格式：
如最后一个组合，意味着：
ECDHE: 握手时，使用ECDHE算法交换密钥；
ECDSA: 使用ECDSA算法进行签名；
AES128-GCM: 使用AES256对称加密算法进行通信，密钥长度128，分组模式GCM；
SHA256: 使用SHA256算法进行消息的完整性验证和产生随机数。
3.1、为什么需要用到这么多算法？
以密码学为基础的信息安全包含主要的五个方面：机密性，可用性，完整性，认证性，不可否认性。
为了保证安全，TLS就需要保证这五个特性。简要说明下这个五个特性：
机密性：保密信息不会透露给非授权的用户或实体；
可用性：指的是加密服务的高可用；
完整性：信息不回被非法篡改，有对应的篡改检测机制；
认证性：参与信息交换的两个主体需要确认对方的身份是否可信，避免信息被不怀好意的人给窃取或者篡改；
不可否认性：指的是用户在事后无法否认曾经进行的信息交换、签发；
每种算法，在TLS中都有其特定的用处，下面先简单介绍各种算法。
3.2、对称加密算法
所谓对称加密，就是使用同一个密钥进行加解密。
最常见的就是AES加密算法。但是对称加密，加解密双方如何安全的传递密钥是一个问题。如果服务器直接把密钥传输给客户端，然后才进行加密通信，可能在传输密钥的过程中，密钥就被窃取了。
3.3、非对称加密
非对称加密通常包含一对密钥，称为公钥(public key)和私钥(private key)。
其中一个密钥加密后的数据，只能让另一个密钥进行解密。
使用公钥推算出私钥是非常困难的，但是随着计算机运算能力提升，目前在程序中使用的非对称密钥至少要2048位才能保证安全性。
虽然非对称加密能够保证安全性，但是性能却比对称加密差很多。
为此，在TLS中，实际上用的是用到了两种算法的混合加密。通过非对称加密算法交换对称加密算法的密钥，交换完成之后，在使用对称加密进行加解密传输数据。这样就保证了会话的机密性。
3.4、摘要算法
摘要算法主要用于保证信息的完整性，相当于信息的指纹信息。常见的散列函数，哈希函数，MD5算法都属于这类算法，其特点是单向性，无法反推原文。
为了保证安全性，目前TLS推荐使用SHA-2摘要算法，禁止使用MD5和SHA-1。
有了摘要算法就能保证完整性了吗？
假如黑客截取了信息，改动了信息之后，重新生成了摘要，那么，这个时候就判断不出来消息是被篡改过了。
为了避免这类消息发生，我们需要给摘要也通过会话密钥进行加密，这样就看不到摘要明文信息了，能更好的保证信息的安全性了。
可见，离开了机密性，完整性也就无从说起了。
3.5、数字签名
到目前为止，我们还有一个问题没有解决，那就是：怎么知道我们要连接的网站不是伪造的呢，如果是伪造的，即使他给了我们他的公钥，也是可以成功进行加解密的，因为他给的公钥给他自己的私钥本身就是一对。
如下图，客户端的请求被中间人截获了，中间人给了客户端自己的公钥，最终客户端把消息发给了中间人，中间人这个时候是可以解密密文拿到原始数据的。然后中间人请求实际的服务器，拿到了实际服务器的公钥，再把消息转发给实际的服务器。这样就窃取了客户端的信息了。
中间人攻击
为了避免拿到假的公钥，所以我们需要一个权威机构帮忙验证这个公钥是不是真的。
通过CA机构生成数字证书
这个时候我们请来了权威的机构，来帮忙我们生成网站公钥的数字证书：
如上图，服务器和CA机构分别有一对密钥，服务器请求CA机构把服务器公钥生成一个数字证书，生成流程：
CA机构通过摘要算法生成公钥的摘要；
CA机构通过自己的CA私钥以及特定的签名算法加密摘要，生成签名；
把签名、服务器公钥，以及其他基本信息打包放入数字证书中。
最后，CA机构把生成的数字证书返回给服务器。
服务器配置好生成的证书，以后客户端连接服务器，都先把这个证书返回给客户端，让客户端验证并获取服务器的公钥。
服务器公钥验证流程
客户端接收到服务器发送的数字证书和CA机构的公钥，通过CA机构的公钥对数字证书上的签名进行验证。
验证过程：
使用CA公钥和声明的签名算法对CA中的签名进行解密，得到服务器公钥的摘要内容；
拿到证书里面的服务器公钥，用摘要算法生成摘要内容，与第一步的结果对比，如果一致，则说该证书就是合法的，里面的公钥是正确的，否则证书就是非法的。
谁来保证CA的公钥的正确性?
服务器验证的时候，需要拿到数字证书发布机构的CA公钥，但是怎么证明这个CA公钥是正确的呢？这个时候就需要有更大的CA帮小的CA的公钥做认证了，一层一层的背书，最顶层的CA，Root CA，称为根证书，作为信任链的根，是全球皆知的的极大著名CA，这些根证书一般会内置到操作系统中。
大家可以到操作系统的证书目录下，或者浏览器，看看证书文件里面都有什么内容。
思考题：即使证书验证通过了，这样就能够保证安全了么，想想还有没有其他原因导致请求的网站身份不可信的；
有了CA机构，就没法进行中间人攻击了吗？
3.6、算法总结
来总结一下上面提到的各种算法的作用：
签名算法：通过数字证书，和CA公钥，验证获取到的服务器公钥的可靠性，保证了认证性；
密钥交换算法 + 对称加密算法：通过交换的密钥，进行加密通信，保证了机密性和不可否认性；
摘要算法：保证完整性。
4、HTTPS连接过程
HTTS连接访问比HTTP多了一步TLS连接：DNS解析，TCP连接、TLS连接。
最关键的就是TLS连接，这里我们重点来分析。
其中TLS连接认证分为单向认证和双向认证：
单向认证 ：服务器提供证书，客户端验证服务器证书；
双向认证 ：服务器客户端分别提供证书给对方，并互相验证对方的证书。
不过，大多数运行HTTPS的web服务器都不需要客户端提供证书，如果服务器需要验证客户端的身份，一般是通过用户名和密码、手机验证码等之类的凭证来完成。对于更高安全级别要求的系统，如大额网银转账等，则会提供双向认证的场景，来确保对客户身份提供认证性。
早期的TLS密钥交换用的是RSA算法，目前主流都是用ECDHE算法来做密钥交换的。下面我们分别来介绍下。
4.1、基于TLS1.2的HTTPS连接过程
4.1.1、RSA密钥交换算法
这个过程稍微有点复杂，还是先上图，流程的关键部分都加上了注释，后面详细解释。
如上图：
首先是TCP三次握手，握手成功之后，就可以开始通过TCP传输数据了；
接下来是TLS握手的流程：
Client Hello：客户端生成一个Client Random随机数，明文发送给服务器，同时提供自己的 TLS版本号，以及自己支持的加密套件；
Server Hello：服务器收到之后，也生成了一个Server Random随机数，明文发送给客户端，同时告知自己选择的TLS版本号，以及选择的加密套件；
Server Certificate：服务器发送自己的证书给到客户端；
Server Hello Done：提示服务器信息发送完毕；
客户端收到证书之后进行证书的校验，确保公钥是合法的；
Client Key Exchange：客户端生成一个PreMaster随机数，通过服务器的公钥加密传输给服务器；
这个时候客户端和服务器都有三个参数：Server Random、Client Random、PreMaster，其中PreMaster是无法被不怀好意的人截获的，通过这三个参数，生成对称密钥；
客户端Change Cipher Spec：客户端通知服务器后续改用刚刚生成的密钥进行加密通信；
客户端Encrypted Handshake Message：客户端准备用刚刚的参数加密传输，验证加密通信；
服务器Change Cipher Spec：服务器也通知客户端后续改用刚刚生成的密钥进行加密通信；
服务器Encrypted Handshake Message：服务器准备用刚刚的参数加密传输，验证加密通信；
在双方都确认好了之后，最后是验证的消息。
这里的核心是：通过非对称加密交换参数，生成对称通信加密的密钥，其中PreMaster是非对称加密传输的，保证了不会泄露通信加密的密钥。
下面我们再来看看主流的ECDHE密钥交换算法的HTTPS连接过程。
4.1.2、ECDHE密钥交换算法
我把与基于RSA算法的连接过程的差异步骤都进行高亮显示了，如下图：
这里重点说明不一样的地方：
Server Key Exchange：在服务端发送完证书之后，多了这一步，这个是椭圆曲线参数Server Params，为了保证认证性，这里同时生成了Server Params的签名，一起发给客户端；
Client Key Exchange：这里不再是直接发送客户端生成PreMaster，而是生成客户端的椭圆曲线参数Client Params，直接传送给服务端；接着，客户端和服务端双方通过ECDHE算法用Client Params和Server Params算出最终的PreMaster，这个PreMaster是保证不会被截获的。这样双方就有了：Client Random，Server Random，PreMaster参数了，通过这三个参数就可以生成通信密钥了；
在客户端发送了Encrypted Handshake Message之后，就立刻发送测试包了，不用等到服务端发送完Encrypted Handshake Message。
4.2、TLS1.3对安全性和性能的提升
TLS1.3是2018年发布的，这个版本中对安全性和性能上有了大幅度提升。
4.2.1、安全性提升
这个版本中砍掉了很多不够安全点加密套件中的算法，只提供了少而精的加密套件。
密钥交换算法废弃了RSA，更好地保证了安全性，不会因为RSA私钥泄露导致历史报文被破解的问题出现。
假设有人故意截获了会话中所有的加密报文，在RSA算法中，如果私钥泄露，那么就可以推算出PreMaster和对称密钥，那么保存了所有的历史报文都会被破解。
4.2.2、性能提升
上图我们看到，TLS握手经历了两个RTT。
TLS1.3简化了握手过程，主要就是把原来两个RTT中的信息，打包成一个发送了，减少传输次数，最终只需要1个RTT就完成了信息的交换和握手。