3.2Https详细流程分析

目录介绍

  • 01.为何会有Https
    • 1.1 Http的缺点
    • 1.2 Http缺点解决方案
    • 1.3 Http的风险
    • 1.4 如何避免风险
  • 02.解决方案分析
    • 2.1 Https加密方式
    • 2.2 SSL是什么
    • 2.3 SSL原理是什么
  • 03.SSL存在隐患
    • 3.1 RSA验证的隐患
    • 3.2 中间方伪造公钥和私钥
    • 3.3 存在两类问题
  • 04.CA证书解决SSL隐患
    • 4.1 如何解决SSL隐患
    • 4.2 CA证书流程原理
  • 05.Https工作流程
    • 5.1 工作流程图
    • 5.2 详细流程说明
  • 06.Https真安全吗
    • 6.1 Https代理了解
    • 6.2 charles抓包流程
  • 07.Https性能分析
    • 7.1 HTTPS性能损耗
    • 7.2 HTTPS接入优化

01.为何会有Https

1.1 Http的缺点

  • 通信使用明文；
    • 通信使用明文意味着安全性大大降低，当通信过程被窃听后，无需花费额外的投入就可看到传输的数据。
    • 例如使用抓包工具，无需任何配置就可查看任何使用HTTP协议的通信数据；
  • 不验证通信方身份
    • 不验证通信方的身份，将导致通信过程被窃听后，可能会遭遇伪装，例如使用抓包工具抓取数据后，就可按照数据包的格式构造HTTP请求；任何人都坑你发送请求，不管对方是谁都返回相应。
  • 无法验证报文的完整性
    • 不验证报文的完整性，数据在传输过程中就可能被篡改，本来想看杨充呢，结果数据在传输过程中被换成了逗比。
    • 遭到篡改，即没有办法确认发出的请求/相应前后一致。

1.2 Http缺点解决方案

  • 通信使用明文
    • 既然明文不安全，那可以考虑使用密文，即：对通信数据进行加密。即便数据被窃听，对方依然需要花费一定的投入来破解，这种高昂的成本间接提高安全级别。
  • 不验证通信方身份
    • 和服务端使用相同的算法，根据网络请求参数生成一个token，请求/应答时根据token来确定双方的身份。
  • 无法验证报文的完整性
    • 使用MD5/SHA1等算法进行完整性验证，对方接收到数据后，根据同样的算法生成散列值，比对发送方生成的散列值，即可验证数据的完整性。

1.3 Http的风险

  • 你知道Http存在哪些风险吗？
    • 窃听风险：Http采用明文传输数据，第三方可以获知通信内容
    • 篡改风险：第三方可以修改通信内容
    • 冒充风险：第三方可以冒充他人身份进行通信

1.4 如何避免风险

  • 如何解决这些风险
    • SSL/TLS协议就是为了解决这些风险而设计，希望达到：所有信息加密传输，三方窃听通信内容；具有校验机制，内容一旦被篡改，通信双发立刻会发现；配备身份证书，防止身份被冒充
  • SSL原理及运行过程
    • SSL/TLS协议基本思路是采用公钥加密法（最有名的是RSA加密算法）。大概流程是，客户端向服务器索要公钥，然后用公钥加密信息，服务器收到密文，用自己的私钥解密。
    • 为了防止公钥被篡改，把公钥放在数字证书中，证书可信则公钥可信。公钥加密计算量很大，为了提高效率，服务端和客户端都生成对话秘钥，用它加密信息，而对话秘钥是对称加密，速度非常快。而公钥用来机密对话秘钥。

02.解决方案分析

2.1 Https加密方式

  • Https加密方式
    • image
      image
  • Https=Http+Ssl
    • Https保证了我们数据传输的安全，Https=Http+Ssl
    • 之所以能保证安全主要的原理就是利用了非对称加密算法，平常用的对称加密算法之所以不安全，是因为双方是用统一的密匙进行加密解密的，只要双方任意一方泄漏了密匙，那么其他人就可以利用密匙解密数据。
    • 非对称加密算法之所以能实现安全传输的核心精华就是：公钥加密的信息只能用私钥解开，私钥加密的信息只能被公钥解开。

  • 非对称加密算法为什么安全

    服务端申请CA机构颁发的证书，则获取到了证书的公钥和私钥，私钥只有服务器端自己知道，而公钥可以告知其他人，如可以把公钥传给客户端，这样客户端通过服务端传来的公钥来加密自己传输的数据，而服务端利用私钥就可以解密这个数据了。由于客户端这个用公钥加密的数据只有私钥能解密，而这个私钥只有服务端有，所以数据传输就安全了。
    • 上面只是简单说了一下非对称加密算法是如何保证数据安全的，实际上Https的工作过程远比这要复杂。

2.1 SSL是什么

  • Https协议中需要使用到SSL证书。
    • SSL证书是一个二进制文件，里面包含经过认证的网站公钥和一些元数据，需要从经销商购买。
  • 证书有很多类型，按认证级别分类：
    • 域名认证（DV=Domain Validation）：最低级别的认证，可以确认申请人拥有这个域名
    • 公司认证（OV=Organization Validation）：确认域名所有人是哪家公司，证书里面包含公司的信息
    • 扩展认证（EV=Extended Validation）：最高级别认证，浏览器地址栏会显示公司名称。
  • 按覆盖范围分类：
    • 单域名证书：只能用于单域名，foo.com证书不能用不www.foo.com
    • 通配符证书：可用于某个域名及所有一级子域名，比如*.foo.com的证书可用于foo.com，也可用于www.foo.com
    • 多域名证书：可用于多个域名，比如foo.com和bar.com

2.3 SSL原理是什么

  • TLS/SSL的原理是什么？
    • SSL(Secure Sokcet Layer，安全套接字层)
    • TLS(Transport Layer Security,传输层安全协议)
    • image
      image

03.SSL存在隐患

3.1 RSA验证的隐患

  • SSL/TLS协议基本思路
    • 是采用公钥加密法（最有名的是RSA加密算法）,虽然说是采用非对称加密，但还是有风险隐患。
  • 身份验证和密钥协商是TLS的基础功能，要求的前提是合法的服务器掌握着对应的私钥。
    • RSA算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患。

3.2 中间方伪造公钥和私钥

  • 举个例子说明下
    • 客户端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可以进行信息的窃听、篡改等操作。
  • 另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。

3.3 存在两类问题

  • 因此该方案下至少存在两类问题：
    • 中间人攻击和信息抵赖
    • image
      image
  • 什么是中间人攻击
    • 就是上面中间节点M伪造自己的公钥和私钥，然后拦截信息，进行篡改。
  • 什么叫信息抵赖
    • 没办法校验服务端，信息不对称。

04.CA证书解决SSL隐患

4.1 如何解决SSL隐患

  • CA 的初始是为了解决上面非对称加密被劫持的情况
    • 服务器申请CA证书时将服务器的“公钥”提供给CA，CA使用自己的“私钥”将“服务器的公钥”加密后（即：CA证书）返回给服务器，服务器再将“CA证书”提供给客户端。
  • 一般系统或者浏览器会内置 CA 的根证书（公钥），HTTPS 中 CA 证书的获取流程如下所示：
    • image
      image
  • 注意问题：
    • 上图步骤 2 之后，客户端获取到“CA 证书”会进行本地验证，即使用本地系统或者浏览器中的公钥进行解密，每个“CA 证书”都会有一个证书编号可用于解密后进行比对（具体验证算法请查阅相关资料）。
    • 步骤 5 之前使用的是对称加密，之后将使用对称加密来提高通讯效率。

4.2 CA证书流程原理

  • CA证书流程原理
    • 基本的原理为，CA负责审核信息，然后对关键信息利用私钥进行"签名"，公开对应的公钥，客户端可以利用公钥验证签名。
    • CA也可以吊销已经签发的证书，基本的方式包括两类 CRL 文件和 OCSP。CA使用具体的流程如下：
    • image
      image
  • 在这个过程注意几点：
    • a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;
    • b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;
    • c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说"部署自签SSL证书非常不安全"）
    • d.证书=公钥+申请者与颁发者信息+签名;
  • CA证书链
    • 如 CA根证书和服务器证书中间增加一级证书机构，即中间证书，证书的产生和验证原理不变，只是增加一层验证，只要最后能够被任何信任的CA根证书验证合法即可。
    • a.服务器证书 server.pem 的签发者为中间证书机构 inter，inter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书;
    • b.中间证书 inter.pem 的签发 CA 为 root，root 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书;
    • c.客户端内置信任 CA 的 root.pem 证书，因此服务器证书 server.pem 的被信任。
    • image
      image

05.Https工作流程

5.1 工作流程图

  • 工作流程图
    • image
      image
  • 工作流程说明
    • 一、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
    • 二、客户端如果校验通过后，就根据证书的公钥的有效，生成随机数，随机数使用公钥进行加密（RSA加密）；
    • 三、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
    • 四、发送给服务端，此时只有服务端（RSA私钥）能解密。
    • 五、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。

5.2 详细流程说明

  • 客户端发起HTTPS请求
    • 这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。
    • 如果有私密信息，包括url，端口啊，你的账号密码等等。账号密码登陆应该用的是Post方式，所以相关的用户信息会被加载到body里面。

  • 服务端的配置

    采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面( startssl就是个不错的选择，有1年的免费服务) 。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
  • 传送证书
    • 服务器端会有一套数字证书（相当于是个钥匙模板），这个证书会先发送给客户端。这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

  • 客户端解析证书

    这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
  • 客户端传送加密信息
    • 这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
  • 服务端解密信息
    • 服务端用私钥解密后，得到了客户端传过来的随机值(私钥) ，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
  • 传输加密后的信息
    • 这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
  • 客户端解密信息
    • 客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

06.Https真安全吗

6.1 Https代理了解

  • HTTPS代理的作用是什么？
    • 代理作用：提高访问速度、Proxy可以起到防火墙的作用、通过代理服务器访问一些不能直接访问的网站、安全性得到提高
    • image
      image

6.2 charles抓包流程

  • charles抓包原理图
    • image
      image

  • 大概步骤流程

    第一步，客户端向服务器发起HTTPS请求，charles截获客户端发送给服务器的HTTPS请求，charles伪装成客户端向服务器发送请求进行握手 。

    第二步，服务器发回相应，charles获取到服务器的CA证书，用根证书（这里的根证书是CA认证中心给自己颁发的证书）公钥进行解密，验证服务器数据签名，获取到服务器CA证书公钥。然后charles伪造自己的CA证书（这里的CA证书，也是根证书，只不过是charles伪造的根证书），冒充服务器证书传递给客户端浏览器。
    • 第三步，与普通过程中客户端的操作相同，客户端根据返回的数据进行证书校验、生成密码Pre_master、用charles伪造的证书公钥加密，并生成HTTPS通信用的对称密钥enc_key。
    • 第四步，客户端将重要信息传递给服务器，又被charles截获。charles将截获的密文用自己伪造证书的私钥解开，获得并计算得到HTTPS通信用的对称密钥enc_key。charles将对称密钥用服务器证书公钥加密传递给服务器。
    • 第五步，与普通过程中服务器端的操作相同，服务器用私钥解开后建立信任，然后再发送加密的握手消息给客户端。
    • 第六步，charles截获服务器发送的密文，用对称密钥解开，再用自己伪造证书的私钥加密传给客户端。
    • 第七步，客户端拿到加密信息后，用公钥解开，验证HASH。握手过程正式完成，客户端与服务器端就这样建立了”信任“。
    • 在之后的正常加密通信过程中，charles如何在服务器与客户端之间充当第三者呢？
    • 服务器—>客户端：charles接收到服务器发送的密文，用对称密钥解开，获得服务器发送的明文。再次加密， 发送给客户端。
    • 客户端—>服务端：客户端用对称密钥加密，被charles截获后，解密获得明文。再次加密，发送给服务器端。由于charles一直拥有通信用对称密钥enc_key，所以在整个HTTPS通信过程中信息对其透明。
  • 总结一下
      *HTTPS抓包的原理还是挺简单的，简单来说，就是Charles作为“中间人代理”，拿到了服务器证书公钥和HTTPS连接的对称密钥，前提是客户端选择信任并安装Charles的CA证书，否则客户端就会“报警”并中止连接。这样看来，HTTPS还是很安全的 **。
  • 相对安全
    • 从抓包的原理可以看出，对Https进行抓包，需要PC端和手机端同时安装证书。
    既然这么容易被抓包，那Https会不会显得很鸡肋？其实并不会，能抓包，那是因为你信任抓包工具，手机上安装了与之对应的证书，你要不安装证书，你抓一个试试。而且安全这个课题，是在攻防中求发展，没有最安全，只有更安全，所以将攻击的成本提高了，就间接达到了安全的目标。

07.Https性能分析

7.1 HTTPS性能损耗

  • 增加延时
    • 分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2* RTT，利用会话缓存从而复用连接，延时也至少1* RTT*
  • 消耗较多的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接入的主要难题。

7.2 HTTPS接入优化

  • CDN接入
    • HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。
    • CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。
  • 会话缓存
    • 虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化;同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。
  • 硬件加速
    • 为接入服务器安装专用的SSL硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供35k的解密能力，相当于175核 CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。
  • 远程解密
    • 本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。
  • SPDY/HTTP2
    • 前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。

11.从网络模型认识Https

  • 网络模型一般是指OSI七层参考模型和TCP/IP五层模型的协议，这个模型是干嘛的呢？
    • 就是将计算机和计算机之间信息交换“概念化”成不同的层次，每层分别有它自己的“实现”，每层有它自己的任务，同时“向上”提供“抽象”的“接口”供上层使用。一般分成7层或者5层。
  • 为了简便期间我这里按照5层架构说一下，这五层分别是：
    • 应用层(application layer)
    • 传输层(transport layer)
    • 网络层(network layer)
    • 数据链路层(data link layer)
    • 物理层(physical layer)

举个例子，当张三用QQ向李四发送一条信息时，首先QQ属于应用层，应用层需要将信息发送给传输层，传输层经过处理之后传给网络层，以此类推传给物理层，这样一层层向下“包装”，每层有对应的协议，这样最后通过物理层传出去，传到李四的物理层，然后李四那边通过一层层向上按照协议“解包”，最后到应用层，传到李四的qq里。

  • 所以每层都有相对应的协议比如我们的物理层和数据链路层通过无线网传输使用的802.2传输协议，有线网的Ethernet(以太网) 传输协议，还有网络层的IPv4, IPv6协议，传输层的TCP, UDP协议，而我们熟悉的HTTP协议其实属于应用层，所以HTTP是建立在TCP/IPv4或v6/以太网基础上进一步细化用于传输“超文本”信息的协议，比如FTP也属于应用层，也是在下面各层协议基础上进行细化，专门用于“文件传输”的协议。

大家可以看到，协议越往上越具体，越往下约抽象，其实计算机技术的发展就是一层层的向上抽象，这样上层的可以直接使用下层的“成果”( API)！

  • 我们再来说一下TLS/SSL，SSL(secure sockets layer)是TLS(transport layer security) 的前身，为什么将他们合起来的，大家可以理解成都属于同一东西的不同阶段吧，比如该协议之前叫SSL后来改名成TLS了。
  • 为什么要有这种协议呢？因为HTTP是使用明文传输，随着网络的发展，安全性越来越重要，所以大家就要想办法让传输更加安全，同时使用密码学的成果，利用“非对称加密算法”的思想以及OSI模型，来对HTTP的信息进行加密。
  • 因为上面我们说了，根据OSI模型，如果向外传输信息就是要从上到下挨个层进行，TLS/SSL也是位于应用层，所以为了加密HTTP的内容，那么TLS/SSL必须位于HTTP下面，可以看成这样：
    • HTTP
    • TLS/SSL
    • TCP
    • Ip
  • 信息从HTTP经过TLS/SSL非对称加密后传出去，而在接收方，接收到信息是需要一层层向上进行，经过每层的“解包/解密”，最终通过HTTP转换成超文本信息。
    • 从网络协议上来说，HTTPS = HTTP + TLS/SSL
    • 从功能上来说，HTTPS = HTTP + 非对称加密的证书身份验证 + 对称加密的传输信息加密

技术博客汇总：https://github.com/yangchong211/YCBlogs

贡献者: yangchong211