Https详细分析

目录介绍

• 01.为何会有Https
• 02.解决方案分析
• 03.SSL是什么
• 04.RSA验证的隐患
• 05.CA证书身份验证
• 06.Https工作原理
• 07.Https代理作用
• 08.Https真安全吗
• 09.Https性能优化

01.为何会有Https

• Http的缺点
  • 通信使用明文；
    • 通信使用明文意味着安全性大大降低，当通信过程被窃听后，无需花费额外的投入就可看到传输的数据。
    • 例如使用抓包工具，无需任何配置就可查看任何使用HTTP协议的通信数据；
  • 不验证通信方身份
    • 不验证通信方的身份，将导致通信过程被窃听后，可能会遭遇伪装，例如使用抓包工具抓取数据后，就可按照数据包的格式构造HTTP请求；任何人都坑你发送请求，不管对方是谁都返回相应。
  • 无法验证报文的完整性
    • 不验证报文的完整性，数据在传输过程中就可能被篡改，本来想看杨充呢，结果数据在传输过程中被换成了逗比。
    • 遭到篡改，即没有办法确认发出的请求/相应前后一致。
• Http的缺点解决方案
  • 通信使用明文
    • 既然明文不安全，那可以考虑使用密文，即：对通信数据进行加密。即便数据被窃听，对方依然需要花费一定的投入来破解，这种高昂的成本间接提高安全级别。
  • 不验证通信方身份
    • 和服务端使用相同的算法，根据网络请求参数生成一个token，请求/应答时根据token来确定双方的身份。
  • 无法验证报文的完整性
    • 使用MD5/SHA1等算法进行完整性验证，对方接收到数据后，根据同样的算法生成散列值，比对发送方生成的散列值，即可验证数据的完整性。
• 你知道Http存在哪些风险吗？
  • 窃听风险：Http采用明文传输数据，第三方可以获知通信内容
  • 篡改风险：第三方可以修改通信内容
  • 冒充风险：第三方可以冒充他人身份进行通信
• 如何解决这些风险
  • SSL/TLS协议就是为了解决这些风险而设计，希望达到：所有信息加密传输，三方窃听通信内容；具有校验机制，内容一旦被篡改，通信双发立刻会发现；配备身份证书，防止身份被冒充
• SSL原理及运行过程
  • SSL/TLS协议基本思路是采用公钥加密法（最有名的是RSA加密算法）。大概流程是，客户端向服务器索要公钥，然后用公钥加密信息，服务器收到密文，用自己的私钥解密。
  • 为了防止公钥被篡改，把公钥放在数字证书中，证书可信则公钥可信。公钥加密计算量很大，为了提高效率，服务端和客户端都生成对话秘钥，用它加密信息，而对话秘钥是对称加密，速度非常快。而公钥用来机密对话秘钥。

02.解决方案分析

• Https加密方式
  • 
• Https=Http+Ssl
  • Https保证了我们数据传输的安全，Https=Http+Ssl
  • 之所以能保证安全主要的原理就是利用了非对称加密算法，平常用的对称加密算法之所以不安全，是因为双方是用统一的密匙进行加密解密的，只要双方任意一方泄漏了密匙，那么其他人就可以利用密匙解密数据。
  • 非对称加密算法之所以能实现安全传输的核心精华就是：公钥加密的信息只能用私钥解开，私钥加密的信息只能被公钥解开。
• 非对称加密算法为什么安全
  • 服务端申请CA机构颁发的证书，则获取到了证书的公钥和私钥，私钥只有服务器端自己知道，而公钥可以告知其他人，如可以把公钥传给客户端，这样客户端通过服务端传来的公钥来加密自己传输的数据，而服务端利用私钥就可以解密这个数据了。由于客户端这个用公钥加密的数据只有私钥能解密，而这个私钥只有服务端有，所以数据传输就安全了。
  • 上面只是简单说了一下非对称加密算法是如何保证数据安全的，实际上Https的工作过程远比这要复杂。

03.SSL是什么

• 什么是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
• TLS/SSL的原理是什么？
  • SSL(Secure Sokcet Layer，安全套接字层)
  • TLS(Transport Layer Security,传输层安全协议)
  • 

04.RSA验证的隐患

• SSL/TLS协议基本思路是采用公钥加密法（最有名的是RSA加密算法）,虽然说是采用非对称加密，但还是有风险隐患。
• 身份验证和密钥协商是TLS的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但RSA算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患:
  • 客户端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可以进行信息的窃听、篡改等操作。
  • 另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。
• 因此该方案下至少存在两类问题：
  • 中间人攻击和信息抵赖
  • 

05.CA证书身份验证

• CA 的初始是为了解决上面非对称加密被劫持的情况，服务器申请CA证书时将服务器的“公钥”提供给CA，CA使用自己的“私钥”将“服务器的公钥”加密后（即：CA证书）返回给服务器，服务器再将“CA证书”提供给客户端。一般系统或者浏览器会内置 CA 的根证书（公钥），HTTPS 中 CA 证书的获取流程如下所示：
  • 
  • 注意：上图步骤 2 之后，客户端获取到“CA 证书”会进行本地验证，即使用本地系统或者浏览器中的公钥进行解密，每个“CA 证书”都会有一个证书编号可用于解密后进行比对（具体验证算法请查阅相关资料）。步骤 5 之前使用的是对称加密，之后将使用对称加密来提高通讯效率。
• CA证书流程原理
  • 基本的原理为，CA负责审核信息，然后对关键信息利用私钥进行"签名"，公开对应的公钥，客户端可以利用公钥验证签名。
  • CA也可以吊销已经签发的证书，基本的方式包括两类 CRL 文件和 OCSP。CA使用具体的流程如下：
  • 
• 在这个过程注意几点：
  • 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 的被信任。
  • 

06.Https工作原理

• HTTPS工作原理
  • 一、首先HTTP请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验；
  • 二、客户端如果校验通过后，就根据证书的公钥的有效， 生成随机数，随机数使用公钥进行加密（RSA加密）；
  • 三、消息体产生的后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名；
  • 四、发送给服务端，此时只有服务端（RSA私钥）能解密。
  • 五、解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务端知道）。
  • 
• 详细一点的原理流程
  • 客户端发起HTTPS请求
    • 这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。
  • 服务端的配置
    • 采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
  • 传送证书
    • 这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
  • 客户端解析证书
    • 这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
  • 传送加密信息
    • 这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
  • 服务端解密信息
    • 服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
  • 传输加密后的信息
    • 这部分信息是服务端用私钥加密后的信息，可以在客户端被还原。
  • 客户端解密信息
    • 客户端用之前生成的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

07.Https代理作用

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

08.Https真安全吗

• charles抓包原理图
  • 
• 大概步骤流程
  • 第一步，客户端向服务器发起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会不会显得很鸡肋？其实并不会，能抓包，那是因为你信任抓包工具，手机上安装了与之对应的证书，你要不安装证书，你抓一个试试。而且安全这个课题，是在攻防中求发展，没有最安全，只有更安全，所以将攻击的成本提高了，就间接达到了安全的目标。

09.Https性能优化

• 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接入的主要难题。
• 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 的性能，提高下载速度等。

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