HTTPS 握手过程理解

• TCP
  传输控制协议，属于传输层协议，提供可靠数据传输。它为http等应用层协议提供服务。

• Http
  超文本传输协议，属于应用层协议。依赖于TCP协议。

• SSL/TLS
  安全传输层协议，用于在两个通信应用程序之间提供保密性和数据完整性。位于某个可靠的传输协议（例如 TCP）上面，属于应用层协议。

• Https
  在Http和TCP中间加入了SSL/TLS,保证数据传输的安全性

简易握手过程示例如下

 看一下第4点加密算法套装列表：客户端支持的加密-签名算法的列表有哪些

第二步 Server Hello (本例抓包占用了85字节，1360-85=剩余的1275字节为 被分段的Certificate部分)

包含三部分内容

验证证书有效性：

对端发来的证书签名是 CA 私钥加密的，接收到证书后，先读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性；然后去查询证书的吊销情况等 (参考：https://www.codercto.com/a/24035.html)

拓展内容=============================================

这部分对Https做一个深入的了解

TLS会话恢复

完整的TLS握手需要额外延迟和计算，为所有需要安全通信的应用带来了严重的性能损耗。为了帮助减少一些性能损耗，TLS提供恢复机制，或多个连接之间共享相同的协商密钥数据。
传输层安全（TLS）

会话标识

“会话标识符”（RFC 5246）恢复机制在SSL 2.0中首次被引入，它允许服务器在“ServerHello消息”中构建和发送一个32字节的会话标识符，作为“ServerHello”消息的一部分。

在服务器内部，服务器维护一个会话ID和其对应的协商参数的缓存。反过来，客户端也同时存储会话ID信息，在后续的会话中，可以在“ClientHello”消息中携带session ID信息，指示服务器它保存了session ID对应的密钥和加密算法等信息，并且可以重用这些信息。假设在客户端和服务器都能在它们各自的缓存中找到共享的会话ID参数，那么缩减的握手就可以进行了。否则，开始一个新的会话协商，这将产生一个新的会话ID。
我们演示一下，在前面抓包的的基础上，我们再发一次请求。

 

会话缓存.png

最外面的红框显示了整个https访问流程，内部的框是除去TCP握手和分手的的流程。我们将流程形象画出来：

 

缩减的TLS握手协议

 

session_ticket_1.png

第二次的请求中的Client Hello的消息中Session Ticket有值了。
那这个Session Ticket是啥时候获取的呢。我们继续重温下https握手流程，在最后一部。Server最后发给Client中，第一个消息就是New Session Ticket。我们看一下:

 

session_ticket_server.png

在实际应用中，大多数Web应用程序试图通过建立到同一个主机的多个连接并行获取资源，这使得会话恢复成为必不可少的一个优化项，其可以减少延​​迟，计算成本。

大多数现代浏览器都会有意的等待第一TLS连接完成后，再打开到同一台服务器的新连接：后续TLS连接，可以重复使用的SSL会话参数，以避免握手的延迟和损耗。

然而，“会话标识符”机制的一个限制就是要求服务器为每个客户端创建和维护一个会话缓存。这会为服务器上带来几个问题，对于一些每天同时几万，甚至几百万的单独连接的服务器来说：由于缓存session ID所需要的内存消耗将非常大，同时还有session ID清除策略的问题。这对一些流量大的网站来说不是一个简单的任务，理想的情况下，使用一个共享的TLS会话缓存可以获得最佳性能。

上述问题没有是不可能解决的，许多高流量的网站成功的使用了会话标识符。但是，对任何多服务主机的部署，会话标识符方案需要一些认真的思考和好的系统架构，以确保良好的的会话缓存。

Session Tickets

为了解决上面的会话缓存带来的服务器部署问题，“Sesion Ticket”（RFC 5077）取代机制被引入，目标是消除服务器需要维护每个客户端的会话状态缓存的要求。相反，如果客户指示它支持Session Ticket，在TLS握手的最后一步中服务器将包含一个“New Session Ticket”信息，包含了一个加密通信所需要的信息，这些数据采用一个只有服务器知道的密钥进行加密。

这个Session Ticket由客户端进行存储，并可以在随后的一次会话中添加到 ClientHello消息的SessionTicket扩展中-因此，所有的会话信息只存储在客户端上，Session Ticket仍然是安全的，因为它是由只有服务器知道的密钥加密的。

Session Identifiers和Session Ticket机制通常分别被称为“会话缓存”和“无状态恢复”机制。无状态恢复的主要改进是消除服务器端的会话缓存，从而简化了部署，它要求客户在每一个新的会话开始时提供Session Ticket 直到Ticket过期。

在实际应用中，在一组负载平衡服务器中部署Session Ticket，也需要仔细考虑：所有的服务器都必须用相同的会话密钥，或者可能需要额外的机制，定期轮流在所有服务器上的共享密钥。

警告 会话票证破坏了 TLS 安全模型。它使票证密钥加密的会话状态并将其暴露在线路上。有些实现中的票证密钥可能会比连接使用的密码要弱。如果票证密钥被暴露，就可以解密连接上的全部数据。因此，使用会话票证时，票证密钥需要频繁轮换。

SessionId和Session Ticket的区别

Session ID的思想就是服务器端为每一次的会话生成并记录一个ID号并发送给客户端，在重新连接的时候（多次短连接场景），客户端向服务器发送该ID号，服务器查找自己的会话记录，匹配之后，重用之前的加密参数信息。

而Sessionticket的思想类似于cookie，是由服务器将ticket数据结构发由客户端管理，ticket中是包含了加密参数等连接信息。当需要重连的时候，客户端将ticket发送给服务器。这样双方就得到了重用的加密参数。

Session ticket较之Session ID优势在于服务器使用了负载均衡等技术的时候。Session ID往往是存储在一台服务器上，当我向不同的服务器请求的时候，就无法复用之前的加密参数信息，而Session ticket可以较好的解决此类问题，因为相关的加密参数信息交由客户端管理，服务器只要确认即可。

证书

证书种类

参考SSL证书有哪些种类?

证书格式

一般来说，主流的 Web 服务软件，通常都基于 OpenSSL 和 Java 两种基础密码库。

• Tomcat、Weblogic、JBoss 等 Web 服务软件，一般使用 Java 提供的密码库。通过 Java Development Kit （JDK）工具包中的 Keytool 工具，生成 Java Keystore（JKS）格式的证书文件。

• Apache、Nginx 等 Web 服务软件，一般使用 OpenSSL 工具提供的密码库，生成 PEM、KEY、CRT 等格式的证书文件。

• IBM 的 Web 服务产品，如 Websphere、IBM Http Server（IHS）等，一般使用 IBM 产品自带的 iKeyman 工具，生成 KDB 格式的证书文件。

• 微软 Windows Server 中的 Internet Information Services（IIS）服务，使用 Windows 自带的证书库生成 PFX 格式的证书文件。

证书类型

您可以使用以下方法简单区分带有后缀扩展名的证书文件：

• *.DER 或 *.CER 文件： 这样的证书文件是二进制格式，只含有证书信息，不包含私钥。
• *.CRT 文件： 这样的证书文件可以是二进制格式，也可以是文本格式，一般均为文本格式，功能与 *.DER 及 *.CER 证书文件相同。
• *.PEM 文件： 这样的证书文件一般是文本格式，可以存放证书或私钥，或者两者都包含。 *.PEM 文件如果只包含私钥，一般用 *.KEY 文件代替。
• *.PFX 或 *.P12 文件： 这样的证书文件是二进制格式，同时包含证书和私钥，且一般有密码保护。
  您也可以使用记事本直接打开证书文件。如果显示的是规则的数字字母，例如：

—–BEGIN CERTIFICATE—–
MIIE5zCCA8+gAwIBAgIQN+whYc2BgzAogau0dc3PtzANBgkqh......
—–END CERTIFICATE—–

那么，该证书文件是文本格式的。

如果存在——BEGIN CERTIFICATE——，则说明这是一个证书文件。
如果存在—–BEGIN RSA PRIVATE KEY—–，则说明这是一个私钥文件。
更多内容参考主流数字证书都有哪些格式？

常见加密算法

• 非对称加密算法：RSA，DSA/DSS
• 对称加密算法：AES，RC4，3DES
• HASH算法：MD5，SHA1，SHA256

为啥数据传输时候用对称加密？

RSA性能是非常低的，原因在于寻找大素数、大数计算、数据分割需要耗费很多的CPU周期，所以一般的HTTPS连接只在第一次握手时使用非对称加密，通过握手交换对称加密密钥，在之后的通信走对称加密。