HTTPS工作原理与加密机制全面解析

1、HTTPS是什么HTTPS就是经过加密解密后的HTTP。HTTPS 也是一个应用层协议是在 HTTP 协议的基础上引入了一个加密层。那HTTP协议为什么要加密呢因为HTTP本身很不安全HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况。2、概念准备2.1.什么是加密、解密、密钥加密就是把明文 (要传输的信息)进行一系列变换, 生成密文解密就是把密文再进行一系列变换, 还原成 明文 .在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥2.2.为什么要加密臭名昭著的 “运营商劫持”下载一个 天天动听未被劫持的效果, 点击下载按钮, 就会弹出天天动听的下载链接.已被劫持的效果, 点击下载按钮, 就会弹出 QQ 浏览器的下载链接客户端与服务端进行通信不是直接进行通信的而是通过第三方的运营商进行信息的中转。作为中间人的运营商就能够看到客户端和服务端通信的信息是是什么这样势必会造成用户隐私的泄漏在互联网上, 明文传输是比较危险的事情!!!HTTPS 就是在 HTTP 的基础上进行了加密, 进一步的来保证用户的信息安全~2.3.常见的加密方式1.对称加密采用单钥密码系统的加密方法同一个密钥可以同时用作信息的加密和解密这种加密方法称为对称加密也称为单密钥加密特征加密和解密所用的密钥是相同的常见对称加密算法(了解)DES、3DES、AES、TDEA、Blowfish、RC2 等特点算法公开、计算量⼩、加密速度快、加密效率高对称加密其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文。一个简单的对称加密, 按位异或假设 明文 a 1234, 密钥 key 8888则加密 a ^ key 得到的密文 b 为 9834.然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234.(对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字)当然, 按位异或只是最简单的对称加密。HTTPS 中并不是使用按位异或。2.非对称加密概念需要两个密钥来进行加密和解密这两个密钥是公开密钥public key简称公钥和私有密钥private key简称私钥。常见非对称加密算法(了解)RSADSAECDSA特点算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂而使得加密解密速度没有对称加密解密的速度快。非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”.公钥和私钥是配对的. 最大的缺点就是运算速度非常慢比对称加密要慢很多.用法通过公钥对明文加密, 变成密文通过私钥对密文解密, 变成明文也可以反着用通过私钥对明文加密, 变成密文通过公钥对密文解密, 变成明文2.4.数据摘要 数据指纹数据摘要为什么叫做数据指纹因为数据摘要具有唯一性跟人的指纹一样具有唯一性数字指纹(数据摘要)其基本原理是利用单向散列函数(Hash 函数)对信息进行运算,生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。摘要常见算法有 MD5、SHA1、SHA256、SHA512 等算法把无限的映射成有限因此可能会有碰撞两个不同的信息算出的摘要相同但是概率非常低摘要特征和加密算法的区别是摘要严格意义不是加密因为没有解密只不过从摘要很难反推原信息通常用来进行数据对比比如数据库明文密码保存——不推荐我们就可以将密码进行摘要保存2.5. 数字签名摘要经过加密就得到数字签名3.HTTPS 的工作过程探究既然要保证数据安全, 就需要进行 “加密”.网络传输中不再直接传输明文了, 而是加密之后的 “密文”.加密的方式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密方案 1 - 只使用对称加密如果通信双方都各自持有同一个密钥 X且没有别人知道这两方的通信安全当然是可以被保证的除非密钥被破解但是我们怎么让客户端双方都知道这个锁是什么呢如果明文传递的话不就是又泄露了所以只用对称加密首次的时候无法同步双方的密钥X。方案 2 - 只使用非对称加密鉴于非对称加密的机制如果服务器先把公钥以明文方式传输给浏览器之后浏览器向服务器传数据前都先用这个公钥加密好再传从客户端到服务器信道似乎是安全的(有安全问题)因为只有服务器有相应的私钥能解开公钥加密的数据。但是服务器到浏览器的这条路怎么保障安全如果服务器用它的私钥加密数据传给浏览器那么浏览器用公钥可以解密它而这个公钥是一开始通过明文传输给浏览器的若这个公钥被中间人劫持到了那他也能用该公钥解密服务器传来的信息了方案二保证单向的数据安全但也是临时的并且运算速度非常慢所以也不采用方案二的安全隐患但是服务器到浏览器的这条路怎么保障安全如果服务器用它的私钥加密数据传给浏览器那么浏览器用公钥可以解密它而这个公钥是一开始通过明文传输给浏览器的若这个公钥被中间人劫持到了那他也能用该公钥解密服务器传来的信息了所以也存在安全隐患方案 3 - 双方都使用非对称加密服务端拥有公钥 S 与对应的私钥 S’客户端拥有公钥 C 与对应的私钥 C’客户和服务端交换公钥客户端给服务端发信息先用 S 对数据加密再发送只能由服务器解密因为只有服务器有私钥 S’服务端给客户端发信息先用 C 对数据加密在发送只能由客户端解密因为只有客户端有私钥 C’存在的问题其实也并不安全同方案二通信速度会比较慢方案 4 - 非对称加密 对称加密通信过程服务端具有非对称公钥 S 和私钥 S’客户端发起 https 请求获取服务端公钥 S客户端在本地生成对称密钥 C, 通过公钥 S 加密, 发送给服务器.由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥(真的吗)服务器通过私钥 S’解密, 还原出客户端发送的对称密钥 C. 并且使用这个对称密钥加密给客户端返回的响应数据.后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义。由于对称加密的效率比非对称加密⾼很多, 因此只是在开始阶段协商密钥的时候使用非对称加密, 后 续的传输仍然使用对称加密所以效率问题解决了虽然上面已经比较接近答案了但是依旧有安全问题方案 2方案 3方案 4 都存在一个问题如果最开始中间人就已经开始攻击了呢4.中间人攻击 - 针对上面的场景Man-in-the-MiddleAttack简称“MITM 攻击”确实在方案 2/3/4 中客户端获取到公钥 S 之后对客户端形成的对称秘钥 X 用服务端给客户端的公钥 S 进行加密中间人即使窃取到了数据此时中间人确实无法解出客户端形成的密钥 X因为只有服务器有私钥 S’。但是中间人的攻击如果在最开始握手协商的时候就进行中间人攻击了那就不一定了假设hacker 已经成功成为中间人了呢攻击流程服务器具有非对称加密算法的公钥 S私钥 S’中间人具有非对称加密算法的公钥 M私钥 M’客户端向服务器发起请求服务器明文传送公钥 S 给客户端中间人劫持数据报文提取公钥 S 并保存好然后将被劫持报文中的公钥 S 替换成为自己的公钥 M并将伪造报文发给客户端客户端收到报文提取公钥 M(自己当然不知道公钥被更换过了)自己形成对称秘钥 X用公钥 M 加密 X形成报文发送给服务器中间人劫持后直接用自己的私钥 M’进行解密得到通信秘钥 X再用曾经保存的服务端公钥 S 加密后将报文推送给服务器服务器拿到报文用自己的私钥 S’解密得到通信秘钥 X双方开始采用 X 进行对称加密进行通信。但是一切都在中间人的掌握中劫持数据进行窃听甚至修改都是可以的上面的攻击方案同样适用于方案 2方案 3问题本质出在哪里了呢客户端无法确定收到的公钥是否是合法的那么如何让client得知自己收到的“公钥”是合法的呢在安全测试和开发调试中使用抓包工具如 Sniffmaster 可以帮助分析和模拟中间人攻击场景。Sniffmaster 是一款全平台抓包工具支持 HTTPS、TCP 和 UDP 协议抓包无需代理、越狱或 root 即可解密 HTTPS 流量便于开发者理解和防御此类威胁。5.证书的引入CA 认证服务端在使用 HTTPS 前需要向 CA 机构申领一份数字证书数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器浏览器从证书里获取公钥就行了证书就如身份证证明服务端公钥的权威性这个证书可以理解成是一个结构化的字符串, 里面包含了以下信息:• 证书发布机构• 证书有效期• 公钥• 证书所有者• 签名6.理解数据签名数据签名就是将数据摘要或者指纹进行加密。当服务端申请 CA 证书的时候CA 机构会对该服务端进行审核并专门为该网站形成数字签名过程CA 机构拥有非对称加密的私钥 A 和公钥 A’CA 机构对服务端申请的证书明文数据进行 hash形成数据摘要然后对数据摘要用 CA 私钥 A’加密得到数字签名 S验证过程接收到数据时先将原始数据和签名分开然后原始数据通过同样的散列算法再次获得到一个散列值。将签名通过签名者的公钥进行解密新散列值和签名进行比较最终就可以判断数据是否有被更改了那么客户端的签名者公钥是从哪里来的呢所有的浏览器客户端一般都要有内置可信的CA机构或者授权的子机构的公钥7.HTTPS最终方案非对称加密 对称加密 证书认证在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书证书包含了之前服务端的公钥, 也包含了网站的身份信息.客户端进行认证client第一次请求得到返回结果不仅仅得到了公钥实际上client得到的是一个”证书“CA机构签发的证书。客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).判定证书的有效期是否过期判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的常见问题中间人有没有可能篡改该证书由于中间人没有 CA 机构的私钥所以无法 hash 之后用私钥加密形成签名那么也就没法办法对篡改后的证书形成匹配的签名这个世界上只有CA机构有私钥也就意味着只有CA机构才有对数据进行签名的能力中间人整个掉包证书因为中间人没有 CA 私钥所以无法制作假的证书所以中间人只能向 CA 申请真证书然后用自己申请的证书进行掉包这个确实能做到证书的整体掉包但是别忘记证书明文中包含了域名等服务端认证信息如果整体掉包客户端依旧能够识别出来。永远记住中间人没有 CA 私钥所以对任何证书都无法进行合法修改包括自己的为什么签名不直接加密而是要先 hash 形成摘要?缩⼩签名密文的⻓度,加快数字签名的验证签名的运算速度对于 iOS 开发人员和程序员使用抓包工具如 Sniffmaster 可以方便地进行 HTTPS 流量分析支持多种协议包括 HTTPS 抓包无需复杂设置即可解密和调试加密通信。总结HTTPS 工作过程中涉及到的密钥有三组第一组(非对称加密):用于校验证书是否被篡改. 服务器持有私钥(私钥在形成 CSR 文件与申请证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客户端请求时返回携带签名的证书. 客户端通过这个公钥进行证书验证, 保证证书的合法性进一步保证证书中携带的服务端公钥权威性。第二组(非对称加密):用于协商生成对称加密的密钥. 客户端用收到的 CA 证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密.其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的