一、HTTPS与HTTP介绍

二、TLS/SSL工作原理

三、TSL/SSL握手过程

四、HTTPS性能优化

五、PKI体系

一、HTTPS与HTTP介绍

1.Https（Secure Hypetext Tranfer Protocol）安全超文本传输协议

是一个安全通信通道，基于HTTP开发用于在客户计算机和服务器之间交换信息，使用安全套接子层（SSL）进行信息交换，换句话说就是使用TLS/SSL加密的HTTP协议，HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议SSL具有身份验证、信息加密和完整性校验的功能。

HTTPS是在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。HTTPS主要作用是：

（1）对数据进行加密，并建立一个信息安全通道，来保证传输过程中的数据安全；

（2）对网站服务器进行真实身份认证。

2.HTTP（Hypetext Tranfer Protocol）超文本传输协议

HTTP是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议。HTTP是采用明文形式进行数据传输，极易被不法份子窃取和篡改。

3.HTTPS和HTTP的区别

（1）HTTPS是加密传输协议，HTTP是名文传输协议；

（2）HTTPS需要用到SSL证书，而HTTP不用；

（3）HTTPS比HTTP更加安全，对搜索引擎更友好

a:为保护用户隐私安全，谷歌优先索引HTTPS网页；

b:百度开放收录https站点，https全网化势不可挡】；

（4）HTTPS标准端口443，HTTP标准端口80；

（5）HTTPS基于传输层，HTTP基于应用层；

（6）HTTPS在浏览器显示绿色安全锁，HTTP没有显示；

HTTP和HTTPS的区别

二、TLS/SSL工作原理

TLS/SSL的功能实现主要依赖于三类基本算法：散列函数Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

非对称加密：即常见的RSA算法，还包括ECC、DH等算法，算法特点是，密钥成对出现，一般称为公钥（公开）和私钥（保密），公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信，服务器可以实现1对多的通信，客户端也可以用来验证掌握私钥的服务器身份。特点是信息传输1对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。

对称加密：常见的有AES-CBC、DES、3DES、AES-GCM等，相同的密钥可以用于信息的加密和解密，掌握密钥才能获取信息，能够防止信息窃听，通信方式是1对1；对称加密的优势是信息传输1对1，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和N个客户端通信，需要维持N个密码记录，且缺少修改密码的机制；非对称加密

散列函数Hash：常见的有MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性；在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密；

TLS的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

三、TSL/SSL握手过程

1.握手与密钥协商过程

（1）client hello客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：

*支持的最高TSL协议版本version，从低到高依次SSLv2 SSLv3TLSV1TLSV1.1TLSV1.2，当前基本不再使用低于TLSv1的版本；

*客户端支持的加密套件cipher suites列表，每个加密套件对应前面TLS原理中的四个功能的组合：认证算法Au（身份验证）、密钥交换算法KeyExchange（密钥协商）、对称加密算法Enc（信息加密）和信息摘要Mac（完整性校验）；

*支持的压缩算法compression methods列表，用于后续的信息压缩传输；

*随机数random_C，用于后续的密钥的生成；

*扩展字段extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的SNl就属于扩展字段，后续单独讨论该字段作用。

（2）server hello+server certificate+sever hello done

*server hello，服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法compression method、随机数random_S等，其中随机数用于后续的密钥协商；

*server certificates，服务器端配置对应的证书链，用于身份验证与密钥交换；

*server hello done，通知客户端 server hello信息发送结束；

（3）证书校验

客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：

*I证书链]的可信性trusted certificate path，方法如前文所述；

*证书是否吊销 revocation，有两类方式离线CRL与在线OCSP，不同的客户端行为会不同；

*有效期 expiry date，证书是否在有效时间范围；

*域名domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析；

（4）client key exchange+change_cipher_spec+encrypted handshake_message

（a）client key_exchange，合法性验证通过之后，客户端计算产生随机数字Pre-master，并用证书公钥加密，发送给服务器；

（b）此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数random_C和random_S与自己计算产生的Pre-master，计算得到协商密钥；enc key=Fuc（random_C，random_S，Pre-Master）

（c）change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信；

（d）encrypted handshake_message，结合之前所有通信参数的hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证；

（5）.change_cipher_spec+encrypted handshake_message

（a）服务器用私钥解密加密的Pre-master数据，基于之前交换的两个明文随机数randomC和randomS，计算得到协商密钥：enc key=Fuc（random C，random S，Pre-Master）；

（b）计算之前所有接收信息的hash值，然后解密客户端发送的encrypted_handshake_message，验证数据和密钥正确性；

（c）change_cipher_spec，验证通过之后，服务器同样发送change_cipher_spec以告知客户端后续的通信都采用协商的密钥与算法进行加密通信；

（d）encrypted_handshake_message，服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端；

（6）.握手结束

客户端计算所有接收信息的hash值，并采用协商密钥解密 encrypted handshake message，验证服务器发送的数据和密钥，验证通过则握手完成；（7）.加密通信

开始使用协商密钥与算法进行加密通信。

注意：

（a）服务器也可以要求验证客户端，即双向认证，可以在过程2要发送client certificate request信息，客户端在过程4中先发送client certificate 与certificate verify message 信息，证书的验证方式基本相同，certificate verify message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据，服务器可以采用对应的公钥解密并验证；

（b）根据使用的密钥交换算法的不同，如ECC等，协商细节略有不同，总体相似；

（c）sever key exchange的作用是server certificate 没有携带足够的信息时，发送给客户端以计算 pre-master，如基于DH的证书，公钥不被证书中包含，需要单独发送；

（d）change cipher spec 实际可用于通知对端改版当前使用的加密通信方式，当前没有深入解析；

（e）alter message 用于指明在握手或通信过程中的状态改变或错误信息，一般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接。

2.会话缓存握手过程

为了加快建立握手的速度，减少协议带来的性能降低和资源消耗，TLS协议有两类会话缓存机制：会话标识 session ID与会话记录 session ticket。

session ID由服务器端支持，协议中的标准字段，因此基本所有服务器都支持，服务器端保存会话ID以及协商的通信信息，Nginx中1M内存约可以保存4000个 session ID机器相关信息，占用服务器资源较多；session ticket 需要服务器和客户端都支持，属于一个扩展字段，支持范围约60%（无可靠统计与来源），将协商的通信信息加密之后发送给客户端保存，密钥只有服务器知道，占用服务器资源很少。

二者对比，主要是保存协商信息的位置与方式不同，类似与http中的session与cookie。

二者都存在的情况下，（nginx实现）优先使用session_ticket。

握手过程如下图：

注意：虽然握手过程有1.5个来回，但是最后客户端向服务器发送的第一条应用数据不需要等待服务器返回的信息，因此握手延时是1*RTT。

（1）会话标识 session ID

（a）如果客户端和服务器之间曾经建立了连接，服务器会在握手成功后返回 session ID，并保存对应的通信参数在服务器中；

（b）如果客户端再次需要和该服务器建立连接，则在client hello中session ID中携带记录的信息，发送给服务器；

（c）服务器根据收到的 session ID检索缓存记录，如果没有检索到货缓存过期，则按照正常的握手过程进行；

（d）如果检索到对应的缓存记录，则返回 change_cipher_spec与encrypted handshake_message信息，两个信息作用类似，encrypted handshake message 是到当前的通信参数与master secret的hash值；

（e）如果客户端能够验证通过服务器加密数据，则客户端同样发送change cipher spec与encrypted handshake message 信息；

（g）服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

（2）会话记录 session ticket

（a）如果客户端和服务器之间曾经建立了连接，服务器会在new_session_ticket 数据中携带加密的 session_ticket信息，客户端保存；

（b）如果客户端再次需要和该服务器建立连接，则在client hello 中扩展字段 session ticket中携带加密信息，一起发送给服务器；

（c）服务器解密 sesssion ticket数据，如果能够解密失败，则按照正常的握手过程进行；

（d）如果解密成功，则返回change cipher spec与encrypted handshake message 信息，两个信息作用与session ID中类似；

（f）如果客户端能够验证通过服务器加密数据，则客户端同样发送 change cipher spec与encrypted handshake message 信息；

（g）服务器验证数据通过，则握手建立成功，开始进行正常的加密数据通信。

3.重建连接

重建连接renegotiation即放弃正在使用的TLS连接，从新进行身份认证和密钥协商的过程，特点是不需要断开当前的数据传输就可以重新身份认证、更新密钥或算法，因此服务器端存储和缓存的信息都可以保持。客户端和服务器都能够发起重建连接的过程，当前windows 2000&XP与SSL2.0不支持。

（1）服务器重建连接

服务器端重建连接一般情况是客户端访问受保护的数据时发生。基本过程如下：

(a) 客户端和服务器之间建立了有效 TLS 连接并通信;

(b) 客户端访问受保护的信息;

(c) 服务器端返回 hello_request 信息;

(d) 客户端收到 hello_request 信息之后发送 client_hello 信息，开始重新建立连接

（2）客户端重建连接

客户端重建连接一般是为了更新通信密钥。

(a) 客户端和服务器之间建立了有效 TLS 连接并通信;

(b) 客户端需要更新密钥，主动发出 client_hello 信息;

(c) 服务器端收到 client_hello 信息之后无法立即识别出该信息非应用数据，因此会提交给下一步处理，处理完之后会返回通知该信息为要求重建连接;

(d) 在确定重建连接之前，服务器不会立即停止向客户端发送数据，可能恰好同时或有缓存数据需要发送给客户端，但是客户端不会再发送任何信息给服务器;

(e) 服务器识别出重建连接请求之后，发送 server_hello 信息至客户端;

(f) 客户端也同样无法立即判断出该信息非应用数据，同样提交给下一步处理，处理之后会返回通知该信息为要求重建连接;

(g) 客户端和服务器开始新的重建连接的过程。

四、HTTPS性能优化

1.HTTPS性能损耗

(1)增加延时

分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2* RTT，利用会话缓存从而复用连接，延时也至少1* RTT*。

(2).消耗较多的CPU资源

除数据传输之外，HTTPS通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据);压测 TS8 机型的单核 CPU：对称加密算法AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销，10G 网卡为对称加密需要消耗 CPU 约17核，24核CPU最多接入 HTTPS 连接 4800;静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s，如果将所有的HTTP连接变为HTTPS连接，则明显RSA的解密最先成为瓶颈。因此，RSA的解密能力是当前困扰HTTPS接入的主要难题。

2、HTTPS接入优化

(1).CDN接入

HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。

(2).会话缓存

HTTPS 即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化;同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。

(3).硬件加速

为接入服务器安装专用的SSL硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力，相当于175核 CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。

(4).远程解密

本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。

(5).SPDY/HTTP2

前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。

五、PKI体系

1.身份验证的隐患

身份验证和密钥协商是TLS的基础功能，前提是合法的服务器掌握着对应的私钥，但RSA算法无法确保服务器身份的合法性，因为公钥中并不包含服务器信息，比如下面例子：

（1）客户端C和服务器S进行通信，中间节点M截获了二者的通信；

（2）节点M自己计算产生一对公钥pub_M和私钥pri_M；

（3）C向S请求公钥时，M把自己的公钥pub_M发给了C；

（4）C使用公钥 pub_M加密的数据能够被M解密，因为M掌握对应的私钥pri_M，而C无法根据公钥信息判断服务器的身份，从而C和M之间建立了“可信”加密连接；

（5）中间节点M和服务器S之间再建立合法的连接，因此C和S之间通信被M完全掌握，M可以进行信息的窃听、篡改等操作。

另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。因此至少存在两类问题：中间人攻击和信息抵赖。

2.身份验证CA和证书

解决身份验证和信息抵赖问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构CA（如沃通CA）。CA负责核实公钥的拥有者的信息，并颁发认证“证书”，同时能够为使用者提供证书验证服务，即PKI体系（PKI基础知识）。

基本的原理为，CA负责审核信息，然后对关键信息利用私钥进行”签名”，公开对应的公钥，客户端可以利用公钥验证签名。CA也可以吊销已经签发的证书，基本的方式包括两类CRL文件和OCSP。

CA使用具体的流程如下：

（1）服务方S向第三方机构CA提交公钥、组织信息、个人信息（域名）等信息并申请认证；

（2）CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；

（3）如信息审核通过，CA会向申请者签发认证文件-证书。

证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；

签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名；

（4）客户端C向服务器S发出请求时，S返回证书文件；

（5）客户端C读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；

（6）客户端然后验证证书相关的域名信息、有效时间等信息；

（7）客户端会内置信任CA的证书信息（包含公钥），如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法。

在这个过程注意几点：

a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握；

b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名；

c.内置CA对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说“部署自签SSL证书非常不安全"）

d.证书=公钥+申请者与颁发者信息+签名；

*即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。

3.证书链

如CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。

（1）服务器证书 server.pem的签发者为中间证书机构inter，inter根据证书inter.pem验证server.pem 确实为自己签发的有效证书；

（2）中间证书inter.pem的签发CA为root，root 根据证书root.pem 验证 inter.pem为自己签发的合法证书；

（3）客户端内置信任CA的root.pem证书，因此服务器证书 server.pem的被信任。

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

二级证书结构存在的优势：

a.减少根证书结构的管理工作量，可以更高效的进行证书的审核与签发；

b.根证书一般内置在客户端中，私钥一般离线存储，一旦私钥泄露，则吊销过程非常困难，无法及时补救；

c.中间证书结构的私钥泄露，则可以快速在线吊销，并重新为用户签发新的证书；

d.证书链四级以内一般不会对HTTPS的性能造成明显影响。

证书链有以下特点：

a.同一本服务器证书可能存在多条合法的证书链。

因为证书的生成和验证基础是公钥和私钥对，如果采用相同的公钥和私钥生成不同的中间证书，针对被签发者而言，该签发机构都是合法的CA，不同的是中间证书的签发机构不同；

b.不同证书链的层级不一定相同，可能二级、三级或四级证书链。

中间证书的签发机构可能是根证书机构也可能是另一个中间证书机构，所以证书链层级不一定相同。

4、证书吊销

CA机构能够签发证书，同样也存在机制宣布以往签发的证书无效。证书使用者不合法，CA需要废弃该证书；或者私钥丢失，使用者申请让证书无效。主要存在两类机制：CRL与OCSP。

（1）CRL Certificate Revocation List，证书吊销列表，一个单独的文件。该文件包含了CA已经吊销的证书序列号（唯一）与吊销日期，同时该文件包含生效日期并通知下次更新该文件的时间，当然该文件必然包含CA私钥的签名以验证文件的合法性。证书中一般会包含一个URL地址CRL Distribution Point，通知使用者去哪里下载对应的CRL以校验证书是否吊销。该吊销方式的优点是不需要频繁更新，但是不能及时吊销证书，因为CRL更新时间一般是几天，这期间可能已经造成了极大损失。

（2）OCSP Online Certificate Status Protocol，证书状态在线查询协议，一个实时查询证书是否吊销的方式。请求者发送证书的信息并请求查询，服务器返回正常、吊销或未知中的任何一个状态。证书中一般也会包含一个OCSP的URL地址，要求查询服务器具有良好的性能。部分CA或大部分的自签CA（根证书）都是未提供CRL或OCSP地址的，对于吊销证书会是一件非常麻烦的事情。

此文章特别感谢CSDN博主「hherima」，文章参考供大家学习

版权声明：本文为CSDN博主「hherima」的原创文章，遵循CC 4.0 BY-SA 版权协议

原文链接：https://blog.csdn.net/hherima/article/details/52469787