Linux下 HTTPS协议原理
发布时间:2026/9/25 20:54:27来源:尧图网络
欢迎来到我的频道【点击跳转专栏】本文所有代码已托管至码云【点此转跳】文章目录1. HTTPS 是什么1.1 什么是加密1.2 为什么要加密1.3 常⻅的加密⽅式1.3.1 对称加密1.3.2 ⾮对称加密1.4 数据摘要 数据指纹1.5 数字指纹Hash摘要 vs 密钥1.6 什么是数字签名2. HTTPS 的⼯作过程探究2.1 只使⽤对称加密行不通2.2 只使⽤⾮对称加密只保障单向相对安全2.3 双⽅都使⽤⾮对称加密效率低2.4 ⾮对称加密 对称加密接近答案了但是依旧有安全问题2.4.1 中间⼈攻击针对方案2、3、42.4.2 理解数字签名2.4.3 证书2.4.4 中间⼈有没有可能篡改该证书2.4.5 那么中间⼈整个掉包证书2.4.6 认识中间证书 和 根证书2.5 ⾮对称加密 对称加密 证书认证(正确方案)2.5.2 那为什么不直接对明文进行加密要先通过形成指纹再加密3. HTTPS完整流程图总结1. HTTPS 是什么HTTPS 也是⼀个应⽤层协议. 是在 HTTP 协议的基础上引⼊了⼀个加密层因为HTTP 协议内容都是按照⽂本的⽅式明⽂传输的. 这就导致在传输过程中出现⼀些被篡改的情况1.1 什么是加密加密就是把明文(要传输的信息)进行一系列变换,生成密文.解密就是把密文再进行一系列变换,还原成明文.在这个加密和解密的过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为密钥.83版火烧圆明园,有人要谋反干掉慈禧太后.恭亲王奕䜣给慈禧递的折子.折子内容只是扯一扯家常,套上一张挖了洞的纸就能看到真实要表达的意思.明文:“当心肃顺,端华,戴恒” (这几个人都是当时的权臣,后来被慈禧一锅端).密文:奏折全文密钥:挖了洞的纸.加密解密到如今已经发展成⼀个独⽴的学科:密码学⽽密码学的奠基⼈, 也正是计算机科学的祖师爷之⼀,艾伦·⻨席森·图灵1.2 为什么要加密比如臭名昭著的 “运营商劫持”:下载⼀个 天天动听,未被劫持的效果, 点击下载按钮, 就会弹出天天动听的下载链接已被劫持的效果, 点击下载按钮, 就会弹出 QQ 浏览器的下载链接:由于我们通过⽹络传输的任何的数据包都会经过运营商的⽹络设备(路由器, 交换机等), 那么运营商的⽹络设备就可以解析出你传输的数据内容, 并进⾏篡改.点击 “下载按钮”, 其实就是在给服务器发送了⼀个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载天天动听, 那么就⾃动的把交给⽤⼾的响应给篡改成 “QQ浏览器” 的下载地址了.所以因为http的内容是明⽂传输的明⽂数据会经过路由器、wifi热点、通信服务运营商、代理服务器等多个物理节点如果信息在传输过程中被劫持传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双⽅察觉这就是 中间⼈攻击 所以我们才需要对信息进⾏加密。为啥运营商要进⾏劫持?一个字钱不⽌运营商可以劫持, 其他的⿊客也可以⽤类似的⼿段进⾏劫持, 来窃取⽤⼾隐私信息, 或者篡改内容在互联⽹上, 明⽂传输是⽐较危险的事情!!!HTTPS就是在HTTP的基础上进⾏了加密, 进⼀步的来保证⽤⼾的信息安全1.3 常⻅的加密⽅式1.3.1 对称加密采用单钥密码系统的加密方法同一个密钥可以同时用作信息的加密和解密这种加密方法称为对称加密也称为单密钥加密特征加密和解密所用的密钥是相同的常见对称加密算法(了解)DES、3DES、AES、TDEA、Blowfish、RC2等特点算法公开、计算量小、加密速度快、加密效率高对称加密其实就是通过同一个 “密钥” ,把明文加密成密文,并且也能把密文解密密成明文。一个简单的对称加密按位异或:假设 明文a 1234密钥key 8888则加密a ^ key得到的密文b 为 9834。然后针对密文9834再次进行运算b ^ key得到的就是原来的明文1234。(对于字符串的对称加密也是同理每一个字符都可以表示成一个数字)当然按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或。1.3.2 ⾮对称加密需要两个密钥来进行加密和解密这两个密钥是公开密钥public key简称公钥和私有密钥private key简称私钥。常见非对称加密算法(了解)RSADSAECDSA特点算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂而使得加密解密速度没有对称加密解密的速度快。非对称加密要用到两个密钥一个叫做 “公钥”一个叫做 “私钥”。公钥和私钥是配对的。最大的缺点就是运算速度非常慢比对称加密要慢很多。通过公钥对明文加密变成密文通过私钥对密文解密变成明文表示只有持有私钥的人才能解密也可以反着用通过私钥对明文加密变成密文通过公钥对密文解密变成明文表示只有持有私钥的人才能加密非对称加密的数学原理比较复杂涉及到一些数论相关的知识.这里举一个简单的生活上的例子.A 要给 B一些重要的文件但是 B 可能不在. 于是 A 和 B 提前做出约定B 说:我桌子上有个盒子然后我给你一把锁你把文件放盒子里用锁锁上然后我回头拿着钥匙来开锁取文件。在这个场景中这把锁就相当于公钥钥匙就是私钥.公钥给谁都行(不怕泄露)但是私钥只有 B 自己持有. 持有私钥的人才能解密。1.4 数据摘要 数据指纹数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算,生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被篡改。摘要常见算法有MD5、SHA1、SHA256、SHA512等算法把无限的映射成有限因此可能会有碰撞两个不同的信息算出的摘要相同但是概率非常低摘要特征和加密算法的区别是摘要严格意义不是加密因为没有解密只不过从摘要很难反推原信息通常用来进行数据对比Hash 摘要数字指纹的核心特性输入任意长短的内容都会输出固定长度的指纹无法反向解密出原文哈希我们可以通过Value映射到对应下标但是你向只通过Key推出Value具体是多少是做不到的只要原文改动一点点生成的指纹就会完全变样生活类比快递包裹的称重 校验码假设有一份文档内容为我要转账100元给张三把这句话传入SHA256 这类 Hash 函数就可以计算出一串指纹abc123xyz。之后我们把这份文档连同指纹一起发送出去如果数据没有被篡改接收方拿到文档后自己重新计算 Hash得到的指纹依旧是abc123xyz和收到的指纹保持一致就能够确认文件没有被改动如果有中间人截获消息把原文篡改为我要转账10000元给张三哪怕是一丁点的修改此时重新计算得到的指纹会变成qwe789rty和原来的abc123xyz完全不同接收方对比指纹不一致就可以发现内容遭到了篡改。⚠️MD5 哈希函数 已经被人为制造碰撞即不同内容可能出现相同指纹SHA256 现实中几乎碰不到。1.5 数字指纹Hash摘要 vs 密钥对比项密钥对称/非对称加密用数字指纹(Hash摘要)作用用来加密、解密密文可以还原回明文用来校验防篡改只做比对不能解密还原原文输入输出明文密钥 → 密文密文密钥 → 明文任意原文 → 固定长度指纹指纹不能变回原文是否可逆可逆有密钥就能解开单向不可逆没有解密过程人为是否需要保管要保密对称密钥、私钥必须严防泄露指纹可以公开不怕别人看到改动影响密钥不同加密结果不同原文改密文也改原文改一点点指纹完全大变不依赖密钥普通hash典型算法AES、RSA、DESMD5、SHA256、SHA5121.6 什么是数字签名摘要经过加密就得到数字签名2. HTTPS 的⼯作过程探究2.1 只使⽤对称加密行不通如果通信双⽅都各⾃持有同⼀个密钥X且没有别⼈知道这两⽅的通信安全当然是可以被保证的除⾮密钥被破解引⼊对称加密之后, 即使数据被截获, 由于⿊客不知道密钥是啥, 因此就⽆法进⾏解密, 也就不知道请求真实内容是啥了但事情没这么简单. 服务器同⼀时刻其实是给很多客⼾端提供服务的. 这么多客⼾端, 每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, ⿊客就也能拿到了). 因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系, 这也是个很⿇烦的事情~⽐较理想的做法, 就是能在客⼾端和服务器建⽴连接的时候, 双⽅协商确定这次的密钥是啥!⚠️但是如果直接把密钥明⽂传输, 那么⿊客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.因此密钥的传输也必须加密传输但是要想对密钥进⾏对称加密, 就仍然需要先协商确定⼀个 “密钥的密钥”. 这就成了 “先有鸡还是先有蛋” 的问题了. 此时密钥的传输再⽤对称加密就⾏不通了2.2 只使⽤⾮对称加密只保障单向相对安全鉴于⾮对称加密的机制如果服务器先把公钥以明⽂⽅式传输给浏览器之后浏览器向服务器传数据前都先⽤这个公钥加密好再传从客⼾端到服务器信道似乎是安全的(其实是有安全问题中间人攻击)因为只有服务器有相应的私钥能解开公钥加密的数据。但是服务器到浏览器的这条路怎么保障安全如果服务器⽤它的私钥加密数据传给浏览器那么浏览器⽤公钥可以解密它⽽这个公钥是⼀开始通过明⽂传输给浏览器的若这个公钥被中间⼈劫持到了那他也能⽤该公钥解密服务器传来的信息了。2.3 双⽅都使⽤⾮对称加密效率低服务端拥有公钥S与对应的私钥S’客户端拥有公钥C与对应的私钥C’客户和服务端交换公钥客户端给服务端发信息先用S对数据加密再发送只能由服务器解密因为只有服务器有私钥S’服务端给客户端发信息先用C对数据加密在发送只能由客户端解密因为只有客户端有私钥C’但是效率太低因为非对称加密解密速度慢用户体验差依旧有安全问题中间人攻击2.4 ⾮对称加密 对称加密接近答案了但是依旧有安全问题先解决效率问题服务端具有非对称公钥S和私钥S客户端发起https请求获取服务端公钥S公开客户端在本地生成对称密钥C通过公钥S加密发送给服务器。由于中间的网络设备没有私钥即使截获了数据也无法还原出内部的原文也就无法获取到对称密钥(真的吗)服务器通过私钥S解密还原出客户端发送的对称密钥C。并且使用这个对称密钥加密给客户端返回的响应数据。后续客户端和服务器的通信都只用对称加密即可.由于该密钥只有客户端和服务器两个主机知道其他主机/设备不知道密钥即使截获数据也没有意义。由于对称加密的效率⽐⾮对称加密⾼很多, 因此只是在开始阶段协商密钥的时候使⽤⾮对称加密, 后续的传输仍然使⽤对称加密虽然上⾯已经⽐较接近答案了但是依旧有安全问题2.4.1 中间⼈攻击针对方案2、3、4在⽅案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.4.2 理解数字签名签名的形成是基于⾮对称加密算法的注意⽬前暂时和https没有关系不要和https中的公钥私钥搞混了。左边是签名发送者先对原始数据计算散列值可以理解为数据的“指纹”再用自己的私钥对这个散列值进行签名可以理解成用类似的私钥进行加密得到“签名”最后把数据、签名、SSL证书 一起发送。右边是验证接收者对收到的数据也计算一次散列值同时用发送者证书中的公钥验证签名得到原来的散列值如果两个散列值一致说明数据传输途中没有被修改并且签名确实来自对应私钥的持有者。证书的作用是证明这个公钥确实属于发送者。⚠️通过内置式的强制使用我的公钥A公开的可以理解成通过域名匹配特定公钥即 证书进行对签名的解密 这样就会导致 中间人 篡改服务器传给我的数据把我传的公钥C用于加密对称加密密钥的换成自己的公钥D 拿自己的私钥B去加密篡改后数据形成的指纹的签名从而骗取对称加密算法密钥的行为是不可能成功了 因为我们用户端是不认可你的私钥B加密的因为这个世界只有我有私钥A意味着只有我有对数据进行签名的权利2.4.3 证书CA认证服务端在使⽤HTTPS前需要向CA机构申领⼀份数字证书SSL证书数字证书⾥含有证书申请者信息、公钥信息等。CA服务器把证书传输给浏览器浏览器从证书⾥获取公钥就⾏了证书就如⾝份证证明服务端公钥的权威性而所谓的证书就是明文信息证书发布机构、证书有效期、公钥等 签名由CA机构签名因为私钥只有CA机构拥有所以证书的明文信息是无法被篡改的所以为了保证证书的安全客户端还会对证书进行验证验证成功则代表公钥可信任那么CA公钥保存在哪里⚠️而CA 公钥以根证书的形式是提前预装在客户端本地操作系统或者浏览器内部不是通信时从网络传过来的中间人无法替换本地预装的CA公钥。PS:如果你真的NB到能入侵电脑并入侵操作系统修改CA公钥那还说啥了给你了真出现这种情况就已经不单单是HTTPS安全问题了都能获得管理员权限修改你的系统了这个得请360老祖出山了我们可以在浏览器中查询证书这些是系统自带的这些则是chrome内置的证书的申请申请证书的时候需要先在特定平台⽣成推荐离线 平台会同时⽣成⼀对⼉密钥对⼉即公钥和私钥。这对密钥对⼉就是⽤来在⽹络通信中进⾏明⽂加密以及数字签名的。其中公钥会随着CSR⽂件⼀起发给CA进⾏权威认证私钥服务端⾃⼰保留⽤来后续进⾏通信其实主要就是⽤来交换对称秘钥推荐一个网站可以帮你快速生成证书请求文件https://myssl.com/csr_create.html该网站可以低限制的申领SSL证书该平台提供免费 SSL 证书的申请、管理、自动续期服务https://console.letsssl.cn/2.4.4 中间⼈有没有可能篡改该证书中间人如果篡改证书的明文由于没有CA机构的私钥无法对篡改后的证书生成匹配的签名若强行篡改客户端校验时会发现证书明文与签名解密后的值不一致判定证书不可信随即终止通信以此防止信息泄露给中间人。2.4.5 那么中间⼈整个掉包证书中间人没有CA私钥因此无法制作假证书只能向CA申请真实证书来做证书整体掉包但由于证书明文中携带域名等服务端认证信息比如中间人的是www.woshishabi.com客户端依旧可以识别出这种攻击(因为客户端访问的域名是www.woshishuaige.com)!也就是说中间人没有CA私钥就无法对任何证书进行合法修改即便是自己申请的证书。ps:若CA机构被劫持私钥泄漏难度不亚于你骑着母猪把白宫打下来那确实会出现信息泄漏的情况但是有这能力劫持你的本地机子不是更方便那不怕CA机构作为中间人嘛首先你肯定相信中国中国认证的CA机构说明被我们国家信赖这种情况是不可能发生的正是因为我们相信我们的国家所以我们一定可以相信这些CA机构2.4.6 认识中间证书 和 根证书一般情况下CA机构正统CA机构的根证书会写在OS里面会授权部分子机构拥有颁发中间证书的能力即 我的信息安全由子机构证明子机构的信息安全由CA机构证明那么此时Web端就会返回SSL证书、中间证书、以及内容、签名系统自带根证书确认中间证书的合法性中间证书确实SSL证书的合法性SSL证书解析签名为指纹指纹确保传输的内容是正确的 这也就给了我们普通人去申请证书的机会2.5 ⾮对称加密 对称加密 证书认证(正确方案)在客⼾端和服务器刚⼀建⽴连接的时候, 服务器给客⼾端返回⼀个证书证书包含了之前服务端的公钥, 也包含了⽹站的⾝份信息最后我梳理一遍完整的流程服务器把携带自身公钥、经CA签名的SSL证书、发给客户端客户端用本地预装的CA公钥校验证书签名与域名确认服务器不是伪造的中间人身份校验通过后客户端利用非对称加密用服务器公钥加密生成的随机会话密钥并传给服务端只有服务器的私钥可以解密得到该会话密后续传输业务数据就使用这个会话密钥做对称加密完成加解密对称加密加解密速度快以此兼顾身份安全校验与传输性能。2.5.2 那为什么不直接对明文进行加密要先通过形成指纹再加密缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度因为行成的签名是固定的长度而明文数据是长短不一的3. HTTPS完整流程图左侧都是客⼾端做的事情, 右侧都是服务器做的事情总结HTTPS 工作过程中涉及到的密钥有三组第一组非对称加密用于校验证书是否被篡改服务器持有私钥私钥在形成 CSR 文件与申请证书时获得客户端持有公钥操作系统包含了可信任的 CA 认证机构有哪些同时持有对应的公钥服务器在客户端请求时返回携带签名的证书客户端通过这个公钥进行证书验证保证证书的合法性进一步保证证书中携带的服务端公钥权威性。第二组非对称加密用于协商生成对称加密的密钥客户端用收到的CA 证书中的公钥是可被信任的给随机生成的对称加密的密钥加密传输给服务器服务器通过私钥解密获取到对称加密密钥。第三组对称加密用于后续业务数据的加解密客户端和服务器后续传输的数据都通过这个对称密钥加密解密。其实一切的关键都是围绕这个对称加密的密钥其他的机制都是辅助这个密钥工作的第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥。
网站建设高端定制企业官网