HTTPS原理篇

英文缩写汇总

HTTPS 基础

HTTPS

• 它是一个安全通信通道，基于HTTP开发，用于在客户端和服务器之间交换信息
• 它使用安全套接字层进行信息交换，简单来说它是HTTP的安全版，使用TLS/SSL加密的HTTP协议

为什么要使用HTTPS

• 由于HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险
• HTTPS具有身份验证、信息加密和完整性校验的功能，可以避免此类问题

TLS/SSL

• 是介于HTTP和TCP之间的一层安全协议，
• 不影响原有的HTTP协议和TCP协议
• 使用HTTPS基本上不需要对HTTP页面做太多的改造

图解HTTPS

TLS/SSL工作原理

TLS/SSL的功能实现主要依赖于三类算法

• 非对称加密：身份认证 和 对称密钥协商
• 对称加密：采用协商的对称密钥对数据进行加密
• 散列算法：验证数据完整性
• 图解

非对称加密

• 非对称加密算法：RSA、ECC、DH等
• 算法特点：由一对密钥组成，俗称密钥对（公钥和私钥），公钥加密的信息只有私钥能解开，私钥加密的信息只有公钥能解开
• 掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器才能解开加密信息
• 通信方式：1 v N，服务器可以实现1对多的通信
• 客户端可以通过此算法来验证掌握私钥的服务器身份
• 缺点：算法的复杂度高，加密速度慢

对称加密

• 对称加密算法：AES、DES、3DES、IDEA、RC4等
• 同一个密钥可以用于信息的加密 和 解密
• 掌握密钥才能解密信息，能够防止信息被盗取
• 通信方式：1 v 1，服务器和客户端共享相同密钥，不同客户端之间的密钥不同，服务器要维护多个密钥（且服务器不能修改密钥），密钥是数据安全传递的基础

散列算法

• 散列算法：MD5、SHA1、SHA256
• 算法特点：单向不可逆、对输入非常敏感、输出长度固定
• 针对数据的任何修改都会改变散列算法的结果，可以验证数据的完整性
• 补充：SHA-1、SHA-224和SHA-256适用于长度不超过2^64二进制位的消息，SHA-384和SHA-512适用于长度不超过2^128二进制位的消息

非对称加密 vs 对称加密

• HTTPS 的通信过程中只在握手阶段使用了非对称加密，后面的通信过程均使用的对称加密
• 非对称加密相比对称加密更加安全，但也存在明显缺点
  • 非对称加密对CPU 计算资源消耗非常大。一次完整的TLS 握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。
  • 非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256 个字节
• 所以公钥加密目前只能用来作密钥交换或者内容签名，不适合用来做应用层数据的加解密。
• 非对称密钥交换算法是整个HTTPS 协议得以安全的基石，充分理解非对称密钥交换算法是理解HTTPS 协议的关键

TLS的基本工作方式总结

• 客户端使用非对称加密与服务器进行通信，实现身份验证和协商对称密钥，通信方式：1(Server) v N(Client)
• 采用协商的对称密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而保证数据只能通信双方获取，通信方式：1(Server) v 1(Client)
• 使用散列算法校验信息以及信息摘要的完整性

PKI

非对称加密进行身份验证存在的隐患

• 中间人攻击：客户端无法验证服务器的身份合法性，就会存在中间人攻击的安全隐患
• 信息抵赖：服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出的

中间人攻击

• 客户端C 和服务器S 进行通信，中间节点M 截获了二者的通信；
• 节点M 自己计算产生一对公钥pub_M 和 私钥pri_M;
• C 向S 请求公钥时，M 把自己的公钥pub_M 发给了C;
• C 使用公钥pub_M 加密的数据能够被M 解密，因为M 掌握对应的私钥pri_M
• 而C 无法根据公钥信息判断服务器的身份，从而C 和M 之间建立了合法连接;
• 中间节点M 和服务器S 之间再建立合法的连接，从而使得C 和S 之间通信被M完全掌握，M 可以进行信息的窃听、篡改等操作。
• 图解中间人攻击

信息抵赖

• 由于客户端无法验证服务器的身份，所以存下信息抵赖的隐患
• 图解信息抵赖

解决方案：CA证书

• 解决上述问题的关键在于确保获取公钥的途径是合法的，即：验证服务器身份的真实性，需要借助于权威的第三方机构CA的帮助，CA主要负责核实公钥拥有者（服务器 S）的信息，验证合法后颁发认证证书，同时为公钥使用者（客户端 C）提供证书验证服务，即：PKI体系

CA 的工作原理

• 图解证书申请过程
• 申请者（服务方 S）向第三方权威机构CA提交公钥（私钥不要提供，确保只有服务器自己才掌握）、组织信息、个人信息、域名等信息；
• CA通过线上、线下等多种手段验证申请者提供的信息的真实性，如：组织是否存在、企业是否合法、是否拥有域名的所有权等；
• 如果信息审核通过，CA 会向申请者签发符合X.509V3国际标准的数字证书，证书包含以下信息：
  • 证书的版本信息；
  • 证书的序列号，每个证书都有一个唯一的证书序列号；
  • 证书的发行机构(CA)名称，命名规则一般采用X.500格式；
  • 证书的有效期，通用的证书一般采用UTC时间格式，它的计时范围为1950-2049；
  • 证书所有者的名称，命名规则一般采用X.500格式；
  • 证书所有者提供的公钥
  • 证书所有者的组织信息和个人信息
  • 证书所使用的散列算法；
  • 证书的数字签名，数字签名的产生算法：
    • 首先，使用散列算法计算公开的明文信息的信息摘要
    • 然后，采用签发机构CA 的私钥对信息摘要进行加密，密文即数字签名
    • 解密服务器证书的数字签名，是从上级CA 机构的数字证书中获取到公钥来解密服务器证书的数字签名得到信息摘要，数字签名的解密涉及到一个证书链的概念，下面会分析
• 客户端C 向服务器S 发出请求时，S 返回证书文件（包含完整的证书链信息）；
• 客户端C 读取证书中的相关的明文信息，采用证书中指定的散列算法计算得到信息摘要H1
• 然后，找到对应的上级CA 机构的证书，拿到证书中的公钥来解密当前服务器证书的数字签名，得到信息摘要H2
• 对比H1和H2，如果一致，则可以确认证书的合法性，即：公钥的获取途径是合法的；
• 证书验证合法后，客户端接着验证证书中的域名信息、有效时间等信息；

上级CA 机构的证书是怎么获取到的呢？

• 一般操作系统（PC 或 移动系统）和浏览器只包含根CA机构的证书，在配置Web服务器的HTTPS时，会配置整个证书链，通过验证整个证书链来确认当前证书是否可信
• 校验流程：从最后面的子证书开始验证，用父证书校验子证书，一层层校验整个证书链的可信性
• 一定要保护好自己环境（浏览器 or 操作系统（PC 或 移动系统））中根CA 证书信任列表，信任了根CA 证书就表示信任了所有由根CA 证书所签发的子级证书
• 谨记：千万不要随便添加根CA 证书，切记！切记！切记！
• 补充：内置的根CA 证书的颁发者和使用者相同，即：自签名证书
• Mac 用户可以通过钥匙串->系统根证书 查看系统默认信任的所有根证书，如果想取消信任(如：CNNIC证书)，可以双击，改为永不信任

证书链

• 证书链：由服务器证书、中间证书与根证书组成一条合法的证书链，证书链的验证是自下而上的信任传递的过程

• 验证原理

  • 服务器证书的签发者为中间证书机构inter，所以由inter 负责验证服务器证书的合法性；
  • 中间证书的签发者为CA，所以由CA 验证中间证书 inter的合法性；
  • 浏览器 或 操作系统（PC 或 移动系统）通过内置信任的CA 机构颁发的根证书(自签名证书)，按照上面的验证方式自上而下的验证证书的每一级的有效性，这里的自上而下是指从由根证书签发的子证书开始一级级的向下验证证书链的有效性
  • 图解验证过程

• 中间证书机构存在的优势

  • 减轻根证书机构的管理工作量，可以更高效的进行证书的审核与签发；
  • 根证书一般内置在客户端中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救，而中间证书机构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书；
  • 证书链四级以内一般不会对HTTPS 的性能造成明显影响。
• 证书链有以下特点
  • 同一服务器证书可能存在多条合法的证书链
  • CA 证书的生成和验证是基于 公钥和私钥 的密钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的CA，不同的是中间证书的签发机构不同；
  • 证书链的层级不一定相同，可能二级、三级或四级证书链，中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构
  • 图解服务器证书可能存在多条合法的证书链

证书吊销

• 主要存在两类机制：CRL 与 OCSP
• 离线CRL
  • 证书吊销列表，一个单独的文件
  • 该文件包含了CA 已经吊销的证书序列号（唯一标识一个证书）与证书的吊销日期，同时包含该文件生效日期，以及通知下次更新该文件的时间
  • 该文件包含一个用CA 私钥加密的签数字名以用来验证CRL文件的合法性
  • 证书中一般会包含一个URL 地址(CRL Distribution Point)，用于告知使用者去哪里下载对应的CRL 以校验证书是否吊销
  • 该吊销方式的优点：不需要频繁更新，
  • 缺点：不能及时吊销证书，因为CRL 更新时间一般是几天，这期间可能已经造成了极大损失
• 在线OCSP
  • 证书状态在线查询协议，一个实时查询证书是否吊销的方式
  • 请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的一个状态
  • 证书中一般也会包含一个OCSP 的URL 地址
  • 要求查询服务器具有良好的性能
• 注意：部分或大部分的自签 CA (根证书)都是未提供CRL 或 OCSP 地址的，对于吊销证书会是一件非常麻烦的事情

TLS/SSL 握手过程

身份验证与对称密钥协商过程

• 图解身份验证与对称密钥协商过程

• 先由客户端发起client_hello请求，请求信息是明文的，相关信息如下：

  • 支持的最高TSL协议版本号，从低到高依次SSLv2、SSLv3、TLSv1、TLSv1.1、TLSv1.2，当前应不再使用低于TLSv1 的版本；
  • 客户端支持的加密套件(cipher suites)列表，每个加密套件对应前面TLS 原理中的四个功能的组合：身份验证、密钥协商(KeyExchange)、对称加密算法(Enc)和信息摘要Mac(完整性校验算法);
  • 支持的压缩算法(compression methods)列表，用于后续的信息压缩传输；
  • 随机数random_C，用于后续对称密钥的生成；
  • 扩展字段(extensions)，支持协议与算法的相关参数，以及其它辅助信息等，常见的SNI 就属于扩展字段，后续单独讨论该字段作用。

• server_hello+server_certificate+sever_hello_done

  • server_hello，服务端返回协商的结果
    • 选择使用的TLS协议版本号，如果客户端与服务器支持的协议版本不一致，服务器将断开通信
    • 选择的加密套件(cipher suite)
    • 选择的压缩算法(compression method)
    • 随机数random_S，用于后续对称密钥的生成
  • server_certificates，服务器端配置的证书链，用于身份验证与密钥交换；
  • server_hello_done，告知客户端server_hello 信息发送完成；
  • 如果服务器也需要确认客户端的身份，就会再包含一项请求client_certificate_request，要求客户端提供客户端证书。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供U盾，里面就包含了一张客户端证书

• 客户端校验服务端返回的证书链

  • 客户端验证服务端返回的证书链的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括：
    • 证书链的可信性(trusted certificate path)
    • 证书是否被吊销(revocation)，证书吊销有两种方式：离线 CRL 与在线 OCSP，不同的客户端行为会不同；
    • 校验证书的有效期(expiry date)；
    • 校验证书中的域名(domain)，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析；

• client_key_exchange+change_cipher_spec+encrypted_handshake_message

  • client_key_exchange，证书链合法性验证通过之后，客户端使用一些加密算法(如：RSA、Diffie-Hellman)产生一个48个字节的Key，即：Pre-master，前两个字节是TLS 的版本号，并用服务器返回的证书链中携带的公钥加密该随机数，发送给服务器；
  • 此时客户端已拥有协商对称加密密钥需要的所有信息：两个明文随机数 random_C 和random_S 与自己计算产生的Pre-master，通过一定规则计算得到协商的对称加密密钥，如：enc_key = Fuc(random_C, random_S, Pre-Master)
  • change_cipher_spec，客户端告知服务器后续的通信都采用协商的对称加密密钥和加密算法进行加密通信
  • encrypted_handshake_message，结合之前所有通信参数的 hash值与其它相关信息生成一段数据，采用协商的对称加密密钥与协商的算法进行加密该段数据，然后发送给服务器用于验证协商的对称加密密钥是否正确
• change_cipher_spec+encrypted_handshake_message
  • 服务器用私钥解密加密的得到第三个随机数Pre-master，基于之前交换的两个明文随机数random_C 和random_S，计算得到协商密钥：enc_key = Fuc(random_C, random_S, Pre-Master)
  • 计算之前所有接收信息的hash 值H1，然后用计算得到的对称加密密钥解密客户端发送的encrypted_handshake_message，得到数据H2，对比H1和H2是否一致，从而验证协商的对称加密密钥和协商的算法的正确性；
  • change_cipher_spec，验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信；
  • encrypted_handshake_message，服务器也结合所有当前的通信参数信息生成一段数据并采用协商的对称加密密钥与协商的算法加密并发送到客户端；
  • 如果前一步服务器要求验证客户端证书，客户端会在这一步发送client_certificate 与certificate_verify_message 信息
• 握手结束，客户端计算所有接收信息的hash 值H1，并采用协商的对称加密密钥解密encrypted_handshake_message，得到数据H2，对比H1和H2是否一致，从而验证协商的对称加密密钥和协商的算法的正确性，验证通过则握手完成，正式开始通过协商的对称密钥进行加密通信
• 补充
  • 服务器也可以要求验证客户端，即双向认证，可以在第二步发送 client_certificate_request 信息，客户端在第四步中先发送 client_certificate与certificate_verify_message 信息，证书的验证方式基本相同，certificate_verify_message 是采用client的私钥加密的一段基于协商过的通信信息，用于服务器采用对应的公钥解密并验证；
  • 根据使用的密钥交换算法的不同，如：ECC（ECC生成密钥对比较快） 等，协商细节略有不同，总体相似；
  • sever key exchange 的作用是server certificate 没有携带足够的信息时，发送给客户端用于计算Pre-master，如：基于DH 的证书，公钥不被证书中包含，需要单独发送；
  • change cipher spec 实际也可用于告知通信端改版当前使用的加密通信方式；
  • alter message 用于说明在握手或通信过程中的状态改变或错误信息，一般触发条件是连接关闭、收到不合法的信息、信息解密失败以及用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接。

会话缓存握手过程

• 如果会话会话缓存有效，则就不需要再进行身份验证和密钥协商过程，加快建立握手的速度
• TLS 协议有两类会话缓存机制：
  • 会话标识session ID
  • 会话记录session ticket
  • 二者对比，主要是保存协商信息的位置与方式不同
  • 二者都存在的情况下，优先使用session_ticket（nginx就是这么实现）
• session ID 由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx 中1M 内存约可以保存4000个session ID 机器相关信息，缺点：占用较多的服务器资源；
• session ticket 需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%(无可靠统计与来源)，将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，优点：占用服务器资源很少
• 图解握手过程
• 说明：虽然握手过程值只有1.5个来回，但是客户端向服务器发送的第一条应用数据不需要等待服务器返回的信息，因此握手延时是1*RTT
• 会话标识session ID
  • 如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回session ID，并保存对应的通信参数在服务器中；
  • 如果客户端再次需要和该服务器建立连接，则在client_hello 的扩展字段session ID中携带记录的信息，并发送给服务器；
  • 服务器根据收到的session ID 检索缓存记录，如果没有检索到或者缓存过期，则按照正常的握手过程进行；
  • 如果检索到对应的缓存记录，则返回change_cipher_spec 与 encrypted_handshake_message 信息；
  • 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与encrypted_handshake_message 信息；
  • 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。
• 会话记录session ticket
  • 如果客户端和服务器之间曾经建立了连接，服务器会在 new_session_ticket 数据中携带加密的session_ticket 信息，客户端保存；
  • 如果客户端再次需要和该服务器建立连接，则在client_hello 的扩展字段session_ticket 中携带加密信息，一起发送给服务器；
  • 服务器解密sesssion_ticket 数据，如果解密失败，则按照正常的握手过程进行；
  • 如果解密成功，则返回change_cipher_spec 与encrypted_handshake_message 信息
  • 如果客户端能够验证通过服务器加密数据，则客户端同样发送 change_cipher_spec 与encrypted_handshake_message 信息；
  • 服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

重建连接renegotiation

• 重建连接renegotiation 即放弃正在使用的TLS 连接，重新进行身份认证和密钥协商的过程，特点是不需要断开当前的数据传输就可以重新身份认证、更新密钥或算法，因此服务器端存储和缓存的信息都可以保持。客户端和服务器都能够发起重建连接的过程，当前windows 2000 & XP 与 SSL 2.0不支持重建连接
• 服务器重建连接：一般是由于客户端访问受保护的数据时发生，基本过程如下：
  • 图解
  • 客户端和服务器之间建立了有效TLS 连接并通信；
  • 客户端访问受保护的信息；
  • 服务器端返回hello_request 信息;
  • 客户端收到hello_request 信息之后发送client_hello 信息，开始重新建立连接。
• 客户端重建连接：一般是为了更新通信密钥。
  • 图解
  • 客户端和服务器之间建立了有效TLS 连接并通信；
  • 客户端需要更新密钥，主动发出client_hello 信息；
  • 服务器端收到client_hello 信息之后无法立即识别出该信息是非应用数据，因此会提交给下一步处理，处理完之后会得知该信息为要求重建连接信息；
  • 注意：在确定重建连接之前，服务器不会立即停止向客户端发送数据，可能恰好同时或有缓存数据需要发送给客户端，但是客户端不会再发送任何信息给服务器；
  • 服务器识别出重建连接请求之后，发送server_hello 信息至客户端；
  • 客户端同样无法立即判断出该信息是非应用数据，同样提交给下一步处理，处理之后得知该信息为要求重建连接信息；
  • 客户端和服务器开始新的重建连接的过程。

对称密钥计算

• 对称密钥的计算
  • 图解
  • 客户端使用RSA 或Diffie-Hellman 等非对称加密算法计算得到Pre-Master，关于Pre-Master有以下几点需要注意：
    • Pre-Master 长度为48个字节，前2个字节是TLS 协议的版本号（用来核对TLS 版本号有效性），剩下的46个字节填充一个随机数
    • 因为在Client Hello 阶段，客户端会发送一份加密套件列表和当前支持的TLS\SSL 协议的版本号给服务端，这期间的数据是使用明文传输的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和TLS\SSL 协议版本给服务端，从而方便后期对应用数据进行拦截破解。
    • 所以，服务端在此阶段通过私钥解密出Pre-Master，获取前两个字节的数据，得到客户端支持的TLS\SSL 协议真正的版本号，并与之前Client Hello 阶段的获取的TLS\SSL 协议版本号进行对比，如果版本号变低，则说明被串改，则立即中断通信
  • Pre-Master 结合random_C 和random_S 两个随机数通过 PseudoRandomFunction(PRF)计算得到Master secret;
  • Master secret 结合random_C 和random_S 两个随机数通过迭代计算得到Key material；
  • 为什么要用通过三个随机数来生成对称密钥？
    • 由于SSL 协议中的证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性
    • SSL 协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么Pre-master 每次都一样，就有可能被猜出来，那么仅使用Pre-master 作为密钥就不合适了
    • 因此，必须引入新的随机因素，那么通过random_C、random_S以及Pre-master 三个随机数共同生成的密钥就不容易被猜出了，要知道一个伪随机可能完全不随机，但是三个伪随机就十分接近随机了，每增加一个自由度，随机性就会相应增加
• 对称密钥的使用
  • 对称密钥经过12轮迭代计算会获取到12个hash 值，分组成为6个元素，列表如下：
  • mac key、encryption key 和IV 是一组加密元素，分别被客户端和服务器使用，两组元素被两边同时获取；
  • 客户端使用client 组元素加密数据，服务器使用client 组元素解密；
  • 服务器使用server 组元素加密，client 使用server 组元素解密；
  • 所以，通信的方向不同使用的密钥不同，破解客户端和服务端的通信至少需要破解两次；
  • encryption key 用于对应用数据进行对称加密；
  • IV 作为很多加密算法的初始化向量使用，有兴趣可以研究对称加密算法；
  • Mac key 用于校验数据的完整性；

数据加密通信过程

• 在数据传输前先将应用层数据切割成合适的数据块;
• 为每个数据块进行编号，防止重放攻击；
• 使用协商的压缩算法数据压缩；
• 由计算得到MAC 值和压缩后的数据共同组成传输数据；
• 使用client encryption key 加密传输数据，发送给服务器；
• server 收到数据之后使用client encrytion key 解密，根据MAC 值校验数据的完整性，解压缩数据，将数据块进行组装。
• 注：MAC值的计算包括两个Hash 值：
  • client Mac key
  • 由数据编号、数据包类型、数据长度、压缩后的数据共同计算得来的Hash值

抓包分析

• 抓包HTTP 通信，能够清晰的看到通信的头部和信息的明文，但抓包 HTTPS 是通信，无法看到HTTP 协议的相关头部和数据的明文信息
• 抓包HTTPS 通信主要包括三个过程：TCP 建立连接、TLS 握手、TLS 加密通信，主要分析HTTPS 通信的握手和状态等信息。
• client_hello阶段，可以知道客户端支持的最高的TLS 协议版本号，如果是SSL 3.0 或TLS 1.0 等低版本协议，很有可能因为版本过低引起一些握手失败的情况；
• 根据扩展字段中的server_name 可以判断是否支持SNI，存在则支持，否则不支持，该字段对于定位握手失败 或 证书返回错误 非常有用；
• 会话标识session ID 是标准协议部分，session ID值为空，说明之前未建立并缓存连接，值不为空，说明有缓存连接；
• 会话记录session ticket 是扩展协议部分，存在该字段就说明当前协议支持sesssion ticket，否则不支持，存在且值为空，说明之前未建立并缓存连接，存在且值不为空，说明有缓存连接。
• server_hello阶段，根据TLS version 字段能够推测出服务器支持的TLS 协议的最高版本，客户端和服务端的版本不同可能造成握手失败，基于cipher_suite 信息判断出服务器优先支持的加密协议；
• ceritficate，服务器配置并返回的证书链，通过校验证书链来判断公钥的获取途径是否合法
• alert告警信息会说明建立连接失败的原因，对于定位问题非常有用

HTTPS 性能与优化

HTTPS 性能损耗

• 增加了正式通信时间
  • 分析前面的握手过程，一次完整的握手至少需要来回两次通信，至少增加延时2*RTT
  • 利用会话缓存达到复用连接，延时也至少1*RTT
• 消耗更多的CPU 资源
  • 除数据传输之外，HTTPS 通信主要包括非对称加解密、对称加解密；
  • 如果将所有的HTTP 连接变为HTTPS 连接，则RSA 的解密明显最先成为瓶颈，因此，RSA 的解密能力是当前困扰HTTPS 接入的主要难题

HTTPS 接入优化

• CDN 接入：减少传输延时
  • CDN，内容分发网络
  • 基本思路：尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。
  • 目的：使用户可就近取得所需内容，解决Internet 网络拥挤的状况，提高用户访问的响应速度
• 会话缓存：减少传输延时
• 硬件加速：减轻单机负载
• 远程解密：减轻单机负载，当前也是CDN 用于大规模HTTPS 接入的解决方案之一
• SPDY/HTTP2：通过修改协议的方法来提升HTTPS 的性能，提高速度