Https原理浅析

开始之前先简单bb一下，本人android码农一枚，工作多年一直向往写一些技术文章分享出去，但是自感水平有限不敢造次，这次终于鼓足了胆量，刚好最近一直在研究（其实谈不上研究就是理解）https原理，想着整理一下写一写，希望可以帮到有所需要的童鞋，也作为自己技术成长的一个记录吧，文章有不到位地方，还请大家纠正，万谢！

概述

超文本传输安全协议（HTTPS，常称为 HTTP over TLS/SSL）是一种通过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

本篇文章主要介绍内容

1:Http协议存在的风险

2:Https如何保证数据传输的安全

3:Https握手流程

4:数字证书

5:Android 下进行 Https访问

Http协议存在的风险

HTTP 协议存在下面3方面的风险

窃听风险

按TCP/IP协议族的工作机制，互联网上的任何角落都存在通信内容被窃听的风险。而HTTP协议本身不具备加密的功能，所传输的都是明文。即使已经经过过加密处理的通信，也会被窥视到通信内容，这点和未加密的通信是相同的。只是说如果通信经过加密，就有可能让人无法破解报文信息的含义，但加密处理后的报文信息本身还是会被看到的。

篡改风险

消息加密以后攻击者无法获取消息内容的含义，但是可以篡改消息内容，篡改之后接收方也无法感知。HTTP协议无法证明通信的报文完整性，在请求或响应送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。

身份伪装风险

1：在HTTP协议通信时，由于不存在确认通信方的处理步骤，因此任何人都可以发起请求。另外，服务器只要接收到请求，不管对方是谁都会返回一个响应。因此不确认通信方，存在以下隐患：

2：无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器；

3：无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端；

4：无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息，只想发给特定用户通信的权限；

5：无法判定请求是来自何方、出自谁手；

6：即使是无意义的请求也会照单全收，无法阻止海量请求下的DoS攻击；

Https如何保证数据传输的安全

上面已经列出了Http在传输的时候存在的安全隐患，下面将详细的讲解Https如何解决这些风险做到数据传输安全的。Https比Http多了一个s，那么这个s到底是啥呢，其实就是TLS/SSL协议；TLS/SSL协议提供了身份验证、信息加密和完整性校验的功能，下面一张图介绍了Https和Http之间的关系

简单介绍一下SSL/TLS

什么是SSL,什么是TLS呢？官话说SSL是安全套接层(secure sockets layer)，TLS是SSL的继任者，叫传输层安全(transport layer security)。说白点，就是在明文的上层和TCP层之间加上一层加密，这样就保证上层信息传输的安全。如HTTP协议是明文传输，加上SSL层之后，就有了雅称HTTPS。它存在的唯一目的就是保证上层通讯安全的一套机制。

上面说到TLS通过加密保证了上层传输信息的安全，那么说到加密，不得不说对称加密和非对称加密。

对称加密：

即加密和解密使用同一个密钥，虽然对称加密破解难度很大，但由于对称加密需要在网络上传输密钥和密文，一旦被黑客截取很容就能被破解，因此对称加密并不是一个较好的选择。

非对称加密：

即加密和解密使用不同的密钥，分别称为公钥和私钥。我们可以用公钥对数据进行加密，但必须要用私钥才能解密。在网络上只需要传送公钥，私钥保存在服务端用于解密公钥加密后的密文。但是非对称加密消耗的CPU资源非常大，效率很低，严重影响HTTPS的性能和速度。因此非对称加密也不是HTTPS的理想选择。

那么HTTPS采用了怎样的加密方式呢？其实为了提高安全性和效率HTTPS结合了对称和非对称两种加密方式。即客户端使用对称加密生成密钥（key）对传输数据进行加密，然后使用非对称加密的公钥再对key进行加密。因此网络上传输的数据是被key加密的密文和用公钥加密后的密文key，因此即使被黑客截取，由于没有私钥，无法获取到明文key，便无法获取到明文数据。所以HTTPS的加密方式是安全的。

HTTPS握手流程

握手是TLS协议中最精密复杂的部分。在这个过程中，通信双方协商连接参数，并且完成身份验证。根据使用的功能的不同，整个过程通常需要交换6~10条消息。根据配置和支持的协议扩展的不同，交换过程可能有许多变种。在使用中经常可以观察到以下三种流程：

1:完整的握手，对服务器进行身份验证(单向验证，最常见)；

2:对客户端和服务器都进行身份验证的握手(双向验证)；

3:恢复之前的会话采用的简短握手；

下面以单向验证为例，介绍一下Https握手的流程

主要分为四个步骤：

1:交换各自支持的功能，对需要的连接参数达成一致;

2:验证出示的证书，或使用其他方式进行身份验证;

3:对将用于保护会话的共享主密钥达成一致;

4:验证握手消息是否被第三方团体修改;

下面对这一过程进行详细的分析

1:ClientHello

在握手流程中，ClientHello是第一条消息。这条消息将客户端的功能和首选项传送给服务器。包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。

2:ServerHello

ServerHello消息将服务器选择的连接参数传送回客户端。这个消息的结构与ClientHello类似，只是每个字段只包含一个选项。服务器的加密组件内容以及压缩方法等都是从接收到的客户端加密组件内筛选出来的。

3:Certificate

之后服务器发送Certificate报文，报文中包含公开密钥证书，服务器必须保证它发送的证书与选择的算法套件一致。不过Certificate消息是可选的，因为并非所有套件都使用身份验证，也并非所有身份验证方法都需要证书。

4:ServerKeyExchange

ServerKeyExchange消息的目的是携带密钥交换的额外数据。消息内容对于不同的协商算法套件都会存在差异。在某些场景中，服务器不需要发送任何内容，在这些场景中就不需要发送ServerKeyExchange消息。

5:ServerHelloDone

ServerHelloDone消息表明服务器已经将所有预计的握手消息发送完毕。在此之后，服务器会等待客户端发送消息。

6:ClientKeyExchange

ClientKeyExchange消息携带客户端为密钥交换提供的所有信息。这个消息受协商的密码套件的影响，内容随着不同的协商密码套件而不同

7:ChangeCipherSpec

ChangeCipherSpec消息表明发送端已取得用以生成连接参数的足够信息，已生成加密密钥，并且将切换到加密模式。客户端和服务器在条件成熟时都会发送这个消息。注意：ChangeCipherSpec不属于握手消息，它是另一种协议，只有一条消息，作为它的子协议进行实现。

8.Finished

Finished消息意味着握手已经完成。消息内容将加密，以便双方可以安全地交换验证整个握手完整性所需的数据。客户端和服务器在条件成熟时都会发送这个消息。

数字证书

我们上面提到了HTTPS的工作原理，通过对称加密和非对称加密实现数据的安全传输。我们也知道非对称加密过程需要用到公钥进行加密。

那么公钥从何而来？其实公钥就被包含在数字证书中。数字证书通常来说是由受信任的数字证书颁发机构CA，在验证服务器身份后颁发，证书中包含了一个密钥对（公钥和私钥）和所有者识别信息。数字证书被放到服务端，具有服务器身份验证和数据传输加密功能。

除了CA机构颁发的证书之外，还有非CA机构颁发的证书和自签名证书：

1:非CA机构即是不受信任的机构颁发的证书，理所当然这样的证书是不受信任的；

2:自签名证书，就是自己给自己颁发的证书。当然自签名证书也是不受信任的。

例如12306网站使用的就是非CA机构颁发的证书（最近发现12306购票页面已经改为CA证书了），12306的证书是由SRCA颁发，SRCA中文名叫中铁数字证书认证中心，简称中铁CA。这是个铁道部自己搞的机构，相当于是自己给自己颁发证书。

因此我们访问12306时通常会看到如下情景: