参考文献：百度运维博客&知乎车小胖的回答
这是拖了很久的一篇记录，项目完结了，也找个时间写完。(额，阅读者最好对http协议有一定了解，否则就没必要浪费时间看下去了)首先来一段百度的解释：
HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系，用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。
简单来说，https相对于http，多了一个s，这个s是secure，由TSL(SSL)提供。http与https都基于TCP(以及UDP)协议，但是又有所不同，TCP用的端口是80，而https用的端口是443。
一、SSL协议(略微说明)
如上图，SSL位于应用层和传输层之间，它可以为任何基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议本身分为两层：
a)上层为SSL握手协议（SSL handshake protocol）、SSL密码变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）；
b)下层为SSL记录协议（SSL record protocol）。
其中：
1)SSL握手协议：是SSL协议非常重要的组成部分，用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在服务器和客户端之间安全地交换密钥、实现服务器和客户端的身份验证。
2)SSL密码变化协议：客户端和服务器端通过密码变化协议通知对端，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
3)SSL警告协议：用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。
4)SSL记录协议：主要负责对上层的数据（SSL握手协议、SSL密码变化协议、SSL警告协议和应用层协议报文）进行分块、计算并添加MAC值、加密，并把处理后的记录块传输给对端。
SSL通过握手过程在客户端和服务器之间协商会话参数，并建立会话。会话包含的主要参数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将采用该会话的主密钥和加密套件进行加密、计算MAC等处理。大致有三种情况下的握手过程：
1)只验证服务器的SSL握手过程
2)验证服务器和客户端的SSL握手过程
3)恢复原有会话的SSL过程
二、HTTPS工作流程
数据在浏览器与服务器中间传输就必须要经过一些节点(例wifi，路由器，反向代理，缓存服务器等)，而http本身是明文传输的，没有任何安全手段保证数据的安全，中间者通过抓包工具可以分析数据，窃取隐私。如果其中包含你的银行卡信息与密码等，你肯定是无法接受的，那么就需要有东西来加密这些数据，这就是https的由来。
https的工作流程一般如下：
1.完成TCP三次同步握手
2.客户端验证服务器数字证书，通过进入步骤3
3.DH算法协商对称加密算法的密钥、hash算法的密钥
4.SSL安全加密隧道协商完成
5.网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性。用协商的hash算法进行数据完整性保护，保证数据不背篡改。
如果HTTPS是网银服务，以上SSL安全隧道成功建立才会要求用户输入账户信息，账户信息是在安全隧道中传输的，所以不会泄密。
三、HTTPS加密涉及的算法以及密钥
1、加密算法
加密算法一般分两种，对称加密与非对称加密。最直接的区别就在于对称加密(密钥加密)加解密使用的是相同的密钥，而非对称加密(公钥加密)加解密使用了不同的密钥。虽然对称加密强度比较高，但是这里有个问题，就是无法安全的生成和保密密钥。假如客户端软件和服务器之间每次会话都使用固定的相同的密钥加密和解密，如果有人从客户端端获取到了对称密钥，整个内容就不存在安全性了，而且管理海量的客户端密钥也是一件很复杂的事情。
这个时候就出现了非对称加密，它主要用于密钥交换(也叫密钥协商)。浏览器和服务器每次新建会话时都使用非对称密钥交换算法协商出对称密钥，使用这些对称密钥完成应用数据的加解密和验证，整个会话过程中的密钥只在内存中生成和保存，而且每个会话的对称密钥都不相同（除非会话复用），中间者无法窃取。非对称密钥交换很安全，但是也很吃“资源”，会导致性能下降。
2、非对称密钥交换
密钥交换算法本身非常复杂，整个过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等操作。常见的算法有：
1)RSA：算法实现简单，安全性高。缺点就是需要比较大的素数（目前常用的是 2048 位）来保证安全强度，很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
2)DH：diffie-hellman 密钥交换算法。缺点是比较消耗 CPU 性能。
3)ECDHE：使用椭圆曲线（ECC）的 DH 算法，优点是能用较小的素数（256 位）实现 RSA 相同的安全等级。缺点是算法实现复杂，用于密钥交换的历史不长，没有经过长时间的安全攻击测试。
4)ECDH：不支持 PFS，安全性低，同时无法实现 false start。
5)DHE：不支持 ECC。非常消耗 CPU 资源。
本身的缺点：
1)CPU 计算资源消耗非常大。一次完全 TLS 握手，密钥交换时的非对称解密计算量占整个握手过程的 90% 以上。而对称加密的计算量只相当于非对称加密的 0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。
2)非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是 2048 位，意味着待加密内容不能超过 256 个字节。
基于以上，公钥加密目前主要用于做密钥交换或者内容签名，不适合用来做应用层传输内容的加解密。
3、握手过程中的密钥协商(以TLS1.2为例)
3.1 RSA算法
1)浏览器发送client_hello，包含一个随机数random1
2)服务端回复 server_hello，包含一个随机数 random2，同时回复 certificate，携带了证书公钥 P。
3)浏览器接收到 random2 之后就能够生成 premaster_secrect 以及 master_secrect。（浏览器此时密钥已经完成协商）
其中 premaster_secret 长度为 48 个字节，前 2 个字节是协议版本号，剩下的 46 个字节填充一个随机数。而 master secrect 包含了六部分内容，分别是用于校验内容一致性的密钥，用于对称内容加解密的密钥，以及初始化向量（用于 CBC 模式），客户端和服务端各一份。从上式可以看出，把 premaster_key 赋值给 secret，”master key”赋值给 label，浏览器和服务器端的两个随机数做种子就能确定地求出一个 48 位长的随机数。
4)浏览器使用证书公钥 P 将 premaster_secrect 加密后发送给服务器。
5)服务端使用私钥解密得到 premaster_secrect。又由于服务端之前就收到了随机数 1，所以服务端根据相同的生成算法，在相同的输入参数下，求出了相同的 master secrect。
3.2 ECDHE算法
1)浏览器发送 client_hello，包含一个随机数 random1，同时需要有 2 个扩展：Elliptic_curves和Ec_point_formats
2)服务端回复 server_hello，包含一个随机数 random2 及 ECC 扩展。
3)服务端回复 certificate，携带了证书公钥。
4)服务端生成 ECDH 临时公钥，同时回复 server_key_exchange，包含三部分重要内容：ECC 相关的参数、ECDH 临时公钥以及ECC 参数和公钥生成的签名值，用于客户端校验。
5)浏览器接收 server_key_exchange 之后，使用证书公钥进行签名解密和校验，获取服务器端的 ECDH 临时公钥，生成会话所需要的共享密钥。（浏览器此时密钥已经完成协商）
6)浏览器生成 ECDH 临时公钥和 client_key_exchange 消息，跟 RSA 密钥协商不同的是，这个消息不需要加密了。
7)服务器处理 client_key_exchang 消息，获取客户端 ECDH 临时公钥。
8)服务器生成会话所需要的共享密钥。
9)Server 端密钥协商过程结束。
四、身份认证
身份认证主要涉及到 PKI 和数字证书。通常来讲 PKI（公钥基础设施）包含如下部分：
1)End entity：终端实体，可以是一个终端硬件或者网站。
2)CA：证书签发机构。
3)RA：证书注册及审核机构。比如审查申请网站或者公司的真实性。
4)CRL issuer：负责证书撤销列表的发布和维护。
5)Repository：负责数字证书及 CRL 内容存储和分发。
申请一个受信任的数字证书通常有如下流程：
1、终端实体生成公私钥和证书请求。
2、RA 检查实体的合法性。如果个人或者小网站，这一步不是必须的。
3、CA 签发证书，发送给申请者。
4、证书更新到 repository，终端后续从 repository 更新证书，查询证书状态等。
4.1数字证书的作用以及数字签名的由来
1.身份授权：确保浏览器访问的网站是经过 CA 验证的可信任的网站。
2.分发公钥：每个数字证书都包含了注册者生成的公钥。在 SSL 握手时会通过 certificate 消息传输给客户端。申请者拿到 CA 的证书并部署在网站服务器端，那浏览器发起握手接收到证书后，如何确认这个证书就是 CA 签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名（digital signature）。
数字签名是证书的防伪标签，目前使用最广泛的 SHA-RSA 数字签名的制作和验证过程如下：
1.数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用 CA 自己的私钥对消息摘要进行加密。
2.数字签名的校验。使用 CA 的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。
补充说明：
a)数字签名签发和校验使用的密钥对是 CA 自己的公私密钥，跟证书申请者提交的公钥没有关系。
b)数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。
c)现在大的 CA 都会有证书链，证书链的好处一是安全，保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销，即如果证书出现问题，只需要撤销相应级别的证书，根证书依然安全。
d)根 CA 证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
e)怎样获取根 CA 和多级 CA 的密钥对？它们是否可信？当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的公钥都默认装到了浏览器或者操作系统环境里。
因为对TCP/IP整个协议体系没有一个全局的认知，所以条例不够清晰，暂时先这样吧。在深究下去就有点跑偏了，毕竟我是个测试，这已经算是网络运维的知识了。之后应该主要是看Python&Jmeter&数据库方面的知识了，该收收心，扎实的学点东西。已经被周围的人甩开了太远.....
_____神剑御雷真诀