HTTPS/数字证书/数字签名

HTTPS

所有的HTTP请求和响应数据都需要加密。 一个传输级的安全密码层：SSL
后继者：TLS。 我们不严格的用SSL表示SSL和TLS
HTTPS是位于安全层之上的HTTP，这个安全层位于TCP之上。

为什么用HTTPS (必要性)
服务器认证 ：客户端知道它是在与真正的而不是伪造的服务器通话
客户端认证：服务器知道他们是在与真正的而不是伪造的客户端通话
完整性： 客户端和服务器的数据不会被修改
加密：对话是私密的，不怕被窃听
效率： 一个运行足够快速的算法
普遍性：所有的客户和服务器都支持这些协议
管理的可扩展性：任何地方的任何人都可以立即进行安全通信

加密原理

对称加密技术

编码的时候使用的密钥值 和 解码的一样
e=d . 对称密钥加密中发送端和接收端共享相同的密钥才能通信！
举例
一个客户端发送信息给另一个节点，它用自己的一个密钥加密这个信息，然后发送给另一个节点客户端，另一个节点也要使用这个对应的密钥来解密这个信息。 如果一个通信链路上有N个节点，那么其中一个节点和其他N-1个节点进行通信的话就需要N^2个密钥。这对于管理来说非常困难。

非对称加密技术

一把公钥发给多个客户端，它们可以用这个公钥加密自己的信息然后发送给服务端，如果要对内容解密的话就必须用服务端的私钥才能解密。

对于一个通信链路中的一个节点来说，就是，任何想要发送报文给节点X的人它的密钥是公开的，你使用它提供的密钥加密即可。 X接收到信息后，使用它自己的私钥才能解密。 别人就算获取了它的报文，也无法破解。

RSA

RSA是一种用在公开密钥非对称加密系统的算法。
公开密钥（公有的）
一小片拦截下来的密文（可通过网络获取）
一条报文及与之相关的密文（对任意一段文本运行加密器就可以得到）

破解它的难度就是对一个极大的数进行质因子分解的难度

数字签名

将报文按双方约定的HASH算法计算得到一个固定位数的报文摘要。
在数学上保证：只要改动报文中任何一位，重新计算出来的报文摘要值就会与原先的值不相符。这就保证了报文的不可更改性。

关键: Hash生成摘要然后再用私钥加密

HASH –> 摘要
私钥加密—> 签名

签名是加了密的“校验和”

• 签名可以证明是作者编写了这条报文。
• 签名防止被篡改。恶意攻击者报文传输过程修改，校验和不再匹配了。 校验和只有作者保密的私有密钥才能产生，所以攻击者无法为报文伪造出正确的校验码。

流程

发送者
节点A 将报文 HASH ,然后生成一个摘要。
然后一个摘要应用一个签名函数以及私钥加密，生成签名

接收者
接收者需要使用公钥解密数字签名，然后将得到报文的摘要。 证明这个报文确实是节点A发送的。
然后再对接收到的报文使用Hash函数，得到摘要，与刚才的摘要比较，两者一致则证明没有被修改过。

附加

校验和：是传输位数的累加，当传输完成，接收者可以根据这个数值判断是否接到了所有数据。 如果数值匹配，那么说明传送已经完成。
以每16位为单位进行反码求和，如果最高位进位，就与最后一位求和。 将结果取反。

数字证书

数字证书一般是CA机构颁发的。
原因：
无法确定公钥是否权威。 如果A的公钥被恶意的B用自己的公钥替换了，那么本来要发送报文给A的客户端都会拥有了B的公钥，然后用B的公钥加密发送给B，无法区分两个公钥。
我们用证书，给公钥附加很多的信息！！！
CA证书中心会对公钥和一些相关信息一起加密生成数字证书

Usage
自己的网站比如在腾讯云上的，我用的https协议，那么我需要去申请一个权威的一般浏览器都认可的数字证书。然后下载它并配置到我的web服务器上面。

它可能包含这些内容
ID ：主要内容包含了由某个受信任组织担保的用户或公司的相关信息。
对象的名称
过期时间
证书发布者
来自证书发布者的数字签名
所有这些信息都是由一个官方的“证书颁发机构”以数字方式签发的。

使用数字证书流程

浏览器接收到数字证书，需要使用CA的公钥来验证签名，(如果这是一个权威的公共签名机构，那么浏览器可能就内置了这个CA的公钥了), 使用CA的公钥以及发送者的公钥解密生成 报文摘要，然后比较摘要是否相同。验证数字签名。

HTTPS

1. 客户端发送加密请求给服务器
   

2. 服务器用自己的私钥加密资源后(如HTML网页)，连同本身的数字证书一起发送给客户端。
   

3. 客户端的证书管理器
   

4. 如果数字证书记载的网址与你正在浏览的网址不一致，说明这个证书可能被冒用，浏览器会发出警告。

5. 如果证书不是受信任的机构颁发的，浏览器会发出另外一种警告。
   12306的证书不是受信任的
   

HTTPS怎么实现安全传输的？

建立安全传输

HTTPS中， 客户端首先打开一条到WEB服务器443端口的连接。 一旦建立了TCP连接
，客户端和服务器就会初始化SSL层，对加密参数进行沟通，并交换密钥。
握手完成后，SSL初始化就完成了，客户端就可以将请求报文发送给安全层了。

重点 SSL握手

发送已加密的HTTP报文之前，客户端和服务器要进行一次SSL握手，这个握手过程中，他们完成：

1. 客户端发送列出客户端密码能力的客户端信息，比如SSL的版本，客户端支持的密钥对和客户端支持的hash方法(压缩方法)。 client_hello
2. 服务器响应，服务器选择一个两端都了解的密钥。和服务器的hash方法。 server_hello
3. 服务器发送SSL数字证书 X.509，等待客户端响应
4. 一旦接受到，客户端将验证服务器的SSL数字证书的有效性。 服务器也可以请求客户端的SSL证书(SSL支持双向)
5. 一旦校验通过，客户端就回随机生成一个用于后面通信的“对称密码”pre_master_secret，用服务器的公钥加密。然后发送给服务器。
6. 服务端用私有密钥解密加密后的随机数据并协商暗号
   得到pre_master_secret，然后双方利用这个协商得到master_secret。 这个是为了保证数据的安全。
7. 服务端跟客户端利用mastersecret产生真正的sessionkey，这是一个对称加密的key。 然后握手结束。

选择一个两端都了解的密码
对两端的身份进行认证。
生成临时的会话密钥，加密信道

其实还有SSL双向握手，这里就不阐述了。

对比HTTP和HTTPS的传输

本质关键原因

SSL是一个二进制的协议，和HTTP完全不同。 流量是在443端口承载的。