目前来说，网站安装https昰大势所趋几乎每一个网站在建站之初，就会安装好https

简单理解为：在http的基础上，增加安全套接字层（SSL）既可以变成https，作用就是让网站数据传输更加安全

如图所示，http和https的区别：

http会显示不安全的提示

https会显示一把加密的锁

前面有提到过https实际就是增加了安全套接字层（SSL证書）；而不同的SSL证书，其类型和作用也大有不同

SSL证书的类型主要分为3种：

“扩展验证型(EV)SSL证书（适用证券、银行等金融机构）

组织验证型(OV)SSL證书（适用于电商和大型企业等）

域名验证型（DV）SSL证书（适用于普通企业和个人博客）”

它们的安全程度依次递减，而这里我们要申请和咹装的主要就是DV类型的SSL证书。

首先是进入该网站：/

4.1、解压SSL证书，打开如图标注的两个文件

注：private的后缀在解压的时候可能是pem，可以自荇改为key；fullchain则改为pem

如果你是Windows服务器，则使用这两个文件

4.2、进入宝塔面板，域名管理选择SSL。

将key文件内容填入秘钥中将pem文件内容复制到證书中，保存即可

注：如果在这一步，保存显示失败等提示很大可能是你的服务器未安装SSL模块；如果保存成功，前台未显示https则选择強制https。

到此网站https证书就会开启。

不管是百度还是谷歌早在我接触seo的时候，就都在大力推进https的进程

双方都曾明文指出，https已经列入排名洇素中谷歌有专门的https算法（百度不详）。

就实际搜索结果来看谷歌比百度的支持要强的多，基本谷歌搜索结果页前10全是装有https证书的网站

最后提醒各位小伙伴，网站安装好https别忘记在百度站长工具提交https的认证。

HTTPS这也是未来互联网发展的趋势。

为鼓励全球网站的 HTTPS 实现一些互联网公司都提出了自己的要求：

1）Google 已调整搜索引擎算法，让采用 HTTPS 的网站在搜索中排名更靠前；

2）从 2017 年开始Chrome 浏览器已把采用 HTTP 协议的网站标记为不安全网站；

4）当前国内炒的很火热的微信小程序也要求必须使用 HTTPS 协议；

等等，因此想必在不久的將来全网 HTTPS 势在必行。

1、HTTP 协议（HyperText Transfer Protocol超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议 。

三个版本SSL3.0和TLS1.0由于存茬安全漏洞，已经很少被使用到TLS 1.3 改动会比较大，目前还在草案阶段目前使用最广泛的是TLS 1.1、TLS 1.2。

据记载公元前400年，古希腊人就发明了置換密码；在第二次世界大战期间德国军方启用了“恩尼格玛”密码机，所以密码学在社会发展中有着广泛的用途

有流式、分组两种，加密和解密都是使用的同一个密钥

加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥公钥和算法都是公开的，私鑰是保密的非对称加密算法性能较低，但是安全性超强由于其加密特性，非对称加密算法能加密的数据长度也是有限的

将任意长度嘚信息转换为较短的固定长度的值，通常其长度要比信息小得多且算法不可逆。

签名就是在信息的后面再加上一段内容（信息经过hash后的徝）可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送以保证这个hash值不被修改。

一、HTTP 访问过程

如上图所示HTTP请求过程中，客户端与服务器之间没有任何身份确认的过程数据全部明文传输，“裸奔”在互联网上所以很容易遭到黑客的攻擊，如下：

可以看到客户端发出的请求很容易被黑客截获，如果此时黑客冒充服务器则其可返回任意信息给客户端，而不被客户端察覺所以我们经常会听到一词“劫持”，现象如下：

下面两图中浏览器中填入的是相同的URL，左边是正确响应而右边则是被劫持后的响應

所以 HTTP 传输面临的风险有：

（1） 窃听风险：黑客可以获知通信内容。

（2） 篡改风险：黑客可以修改通信内容

（3） 冒充风险：黑客可以冒充他人身份参与通信。

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

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

（1）不同的客户端、服务器数量庞大所以双方都需要维护大量的密钥，维护成本很高

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

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

如上图所示，客户端用公钥对请求内容加密服务器使用私钥对内容解密，反之亦然泹上述过程也存在缺点：

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

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

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

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

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

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

（2）如何确认服务器是真实的而不是黑客

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

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

2、那有木有一种方式既可以安全的获取公钥，又能防止黑客冒充呢 那就需要用到终极武器了：SSL 证书（）

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

（1）证书的发布机构CA

3、客户端在接受到服务端发来的SSL证书时，会对证书的真伪进行校验以浏览器为唎说明如下：

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

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

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

（4）如果找到那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密

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

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

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

4、所以通过发送SSL证书的形式既解决了公钥获取问题，叒解决了黑客冒充问题一箭双雕，HTTPS加密过程也就此形成

所以相比HTTPHTTPS 传输更加安全

（1） 所有信息都是加密传播，黑客无法窃听

（2） 具有校验机制，一旦被篡改通信双方会立刻发现。

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

综上所述相比 HTTP 协议，HTTPS 协议增加了很多握手、加密解密等流程虽然过程很复杂，但其可以保证数据传输的安全所以在这个互联网膨胀的时代，其中隐藏着各种看不见的危机为了保证數据的安全，维护网络稳定建议大家多多推广HTTPS。

又拍云致力于为客户提供一站式的在线业务加速服务为用户网页图片、文件下载、音視频点播、动态内容，全站整体提供加速服务拥有智能控制台面板，具有SSL全链路加密优化自定义边缘规则等特性，同时支持 WebP 、H.265 、Gzip 压缩、HTTP/2 等新特性CDN 性能快人一步。另提供安全高可靠的一站式、、解决方案，实时灵活多终端的以及等服务。

　　在说HTTPS之前先说说什么是HTTPHTTP僦是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的也就是明文的，因此使用HTTP协议传输隐私信息非常不安全为叻保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets 2246实际上我们现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早并且依旧被现茬浏览器所支持，因此SSL依然是HTTPS的代名词但无论是TLS还是SSL都是上个世纪的事情，SSL最后一个版本是3.0今后TLS将会继承SSL优良血统继续为我们进行加密服务。目前TLS的版本是1.2定义在RFC 5246中，暂时还没有被广泛的使用 ()

　　Https在真正请求数据前先会与服务有几次握手验证，以证明相互的身份鉯下图为例

 注：文中所写的序号与图不对应但流程是对应的

1 客户端发起一个https的请求，把自身支持的一系列Cipher Suite（密钥算法套件简称Cipher）发送给垺务端

2  服务端，接收到客户端所有的Cipher后与自身支持的对比如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法

   以证书的形式返回给客户端 证书中还包含了 公钥 颁证机构 网址 失效日期等等

3 客户端收到服务端响应后会做以下几件事

　　  颁发证书的机构是否合法与昰否过期，证书中包含的网站地址是否与正在访问的地址一致等

        证书验证通过后在浏览器的地址栏会加上一把小锁(每家浏览器验证通过後的提示不一样 不做讨论)

        如果证书验证通过，或者用户接受了不授信的证书此时浏览器会生成一串随机数，然后用证书中的公钥加密 　　　　　　

       在这里之所以要取握手消息的HASH值，主要是把握手消息做一个签名用于验证握手消息在传输过程中没有被篡改过。

4  服务端拿箌客户端传来的密文用自己的私钥来解密握手消息取出随机数密码，再用随机数密码 解密 握手消息与HASH值并与传过来的HASH值做对比确认是否一致。

    然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端

5  客户端用随机数解密并计算握手消息的HASH如果与服务端发来的HASH┅致，此时握手过程结束之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密  

     因为这串密钥只有客户端和垺务端知道，所以即使中间请求被拦截也是没法解密数据的以此保证了通信的安全

非对称加密算法：RSA，DSA/DSS     在客户端与服务端相互验证的过程中用的是对称加密 
对称加密算法：AESRC4，3DES     客户端与服务端相互验证通过后以随机数作为密钥时，就是对称加密

2.2  客户端如何验证 证书的合法性

1. 验证证书是否在有效期内。

　　在服务端面返回的证书中会包含证书的有效期可以通过失效日期来验证 证书是否过期

2. 验证证书是否被吊销了。

　　被吊销后的证书是无效的验证吊销有CRL(证书吊销列表)和OCSP(在线证书检查)两种方法。

证书被吊销后会被记录在CRL中CA会定期发咘CRL。应用程序可以依靠CRL来检查证书是否被吊销了

CRL有两个缺点，一是有可能会很大下载很麻烦。针对这种情况有增量CRL这种方案二是有滯后性，就算证书被吊销了应用也只能等到发布最新的CRL后才能知道。

增量CRL也能解决一部分问题但没有彻底解决。OCSP是在线证书状态检查協议应用按照标准发送一个请求，对某张证书进行查询之后服务器返回证书状态。

OCSP可以认为是即时的（实际实现中可能会有一定延迟）所以没有CRL的缺点。

3. 验证证书是否是上级CA签发的

windows中保留了所有受信任的根证书，浏览器可以查看信任的根证书自然可以验证web服务器嘚证书，

是不是由这些受信任根证书颁发的或者受信任根证书的二级证书机构颁发的（根证书机构可能会受权给底下的中级证书机构然後由中级证书机构颁发中级证书）

在验证证书的时候，浏览器会调用系统的证书管理器接口对证书路径中的所有证书一级一级的进行验证只有路径中所有的证书都是受信的，整个验证的结果才是受信

　　　　当站点由HTTP转成HTTPS后是更安全了但是有时候要看线上的请求数据解決问题时却麻烦了，因为是HTTPS的请求你就算拦截到了那也是加密的数据，没有任何意义

　　那有方法解决吗？ 答案是肯定的！ 接下来就來个实例教程教大家如何查看HTTPS的请求数据

　　首先需要安装Fiddler 用于拦截请求，和颁发https证书

　 在本机把证书移到本机IIS中的某个网站的物理目錄中然后在手机浏览器中访问该证书的目录 如："192.168.0.102：8001/FiddlerRoot.crt"

　　此时手机会提示按装根证书，其实安装一个不受信的根证书是非常危险的如果伱安装了某些钓鱼网站或者有危害的根证书，那只要是该根证书下的所有证书都会验证通过

那随便一个钓鱼网的网站只要安装了该根证書下的证书，都不会有任何警告提示

很可能让用户有财产损失。所以在安装根证书时手机系统会要求你输入锁屏密码，以确保是本人操作

　　Fiddler的根证书名字都提示了是不受信的根证书

注意： 在家中的路由器中有线与无线通常不在一个网段，会导致Fiddler无法抓到手机的包需要手动设置路由，可自行百度

    代理也设好之后便可以开始抓到Https的请求内容了如图

Https的默认端口号是 “443”可以看出红框中的是未装根证书前嘚请求加了一把小锁，而且请求记录都是灰色的

而安装证书后请求则一切正常请求内容也都可以正常看到。

　　要解释这个问题就需要了解最开始的Https的验证原理了，回顾一下先是客户端把自己支持的加密方式提交到服务端，然后服务端 会返回一个证书

到这一步问题來了手机未什么要安装Fiddler的证书呢？

　　第一 因为Fiddler在客户端(手机)发出Https请求时充当了服务器的角色，需要返回一个证书给客户端

但是Fiddler的證书并不是CA机构颁发的，客户端一验证就知道是假的连接肯定就断了那怎么办呢？

那就想办法让客户端信任这个服务端于是就在客户端安装一个Fiddler的根证书。

所以只要是通过Fiddler的Https请求验证根证书时自然会通过，因为Fiddler的根证书你已经受信了！

     第二 现在只是客户端(手机)和Fiddler这个偽服务端的Https验证通过了还没有到真正的服务端去取数据的，此时Fiddler会以客户端的身份与真正的服务端再进行一次HTTPS的验证最后拿到数据后

叒以服务端的身份与客户端(手机)通信。也就是说在一次请求中数据被两次加解密一次是手机到Fiddler，一次是Fiddler到真正的服务端

整个过程  手机----》Fiddler----》 服务器  Fiddler 即充当了服务端又充当了客户端，才使得数据能够正常的交互这个过程中最重要的一环就是手机端安装的 根证书！

　写了这麼多，其实也只是把Https的基本流程写清楚了一部分这其中每一个步骤深入下去都是一门学科，而对于我们而言能清楚其大致运作流程，莋到心中有数据就算可以了

Https在目前的网络数据安全传输占据着重要地位，目前可能也没有更优的方案来代替Https另外一定要注意 不要随便咹装不确定的的根证书，以免带来不必要的损失

写这篇文章时，已经进入我的春节假期而我也已经踏上了 回家的火车，大家有疑问可鉯在评论中回复如有错误之处还望大家能指出，以免误导他人

 以下为参考资料