学习Https加密过程笔记

前言

针对网上很多这方面的回答，虽然每个都有可取之处，但总感觉缺了什么。于是自己学习汇总了一些知识点，在这分享给大家。

Url请求流程图

首先放一张网上找的感觉还算全的流程图。

对于Https中的一些疑问和理解

1.为什么不用对称加密
原因：对称加密在客户端和服务器交流过程中会被第三者劫持而失去安全作用。
解决方案：浏览器缓存网站的密钥，确保只要浏览器和服务器知道。（需要缓存全世界网站的密钥，科学，所以不可行）。
2.为什么不纯用非对称加密
原因：只能确保浏览器->服务器的安全，不能确保服务器->浏览器的安全
改进方案：浏览器和服务器都用非对称加密。
3.为什么实际中不采用 浏览器和服务器都用非对称加密 方案
原因之一：非对称加密十分耗时，加密大数据时力不从心，对称加密速度快。
改进方案：采用对称加密+非对称加密
4.为什么采用对称加密+非对称加密仍然不安全
原因：存在中间人攻击
改进方案：成立一个公信机构，用数字证书确保浏览器收到的公钥一定是该网站的公钥。
5.为什么数字证书能确保浏览器收到的公钥一定是该网站的公钥
原因：数据证书由一个公信机构-CA机构颁发，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取公钥就行了，证书就如身份证一样，可以证明“该公钥对应该网站”。并通过数字签名来防篡改。
6.数字签名

7.中间人有可能篡改该证书吗？
解答：假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
8.中间人有可能把证书掉包吗？
解答：证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就能知道是否背掉包。
9.为什么制作数字签名时需要hash一次？
解答：性能上加密解密就会快很多，安全方面也更加安全。

过程描述 （c为客户端,s为服务端）

c->s：发送报文Client Hello 内容如下

• 客户端支持的TLS最高版本号
• 客户端生成的随机数
• 客户端支持的加密套件

s->c：Server Hello

• 协商后的TLS/SSL版本号
• 服务端生成的随机数
• 协商后的加密套件

s->c：Certifcate

• 服务端提供证书信息给客户端验证，包括证书有效期等

s->c：Server Key Exchange

• 密钥交换用到的服务器方的信息，有公钥信息

s->c：Server Hello Done

• 客户端与服务端的SSL握手过程结束

c->s：Cerficate

• 双向校验，服务端要求验证客户端的证书信息

c->s：Client Key Exchange

• 客户端会生成一个pubkey发送给服务端，服务端根据之前的random_c，random_s，pubkey三个随机数生成对称加密的session Key

c->s：Change Cipher Spec

• 通知服务端，接下来的数据采用session Key对称加密的方式

c->s：Encrypted Handshake Message

• 客户端随后发送一个经过加密的数据，服务端可以根据生成的session Key来进行解密，这个加密的消息解密后有固定的格式，符合这个格式，或者满足一些字符匹配才是合法的。

s->c：Change Cipher Spec

• 通知客户端接下来的数据采用被sessionKey加密的对称加密方式

s->c：Encrypted Handshake Message

• 服务端立刻发送一个经过加密的消息，让客户端进行验证

至此之后，服务端和客户端之间通过协商的sessionKey进行数据交互。