目录一. HTTPS是什么二. 加密是什么加密算法三. HTTPS的工作过程引入对称加密引入非对称加密为什么不只使用非对称加密传输数据中间人攻击引入证书证书是什么引入证书后的工作流程常见问题1. 黑客能否修改证书中的公钥2. 黑客能否把数据签名一起修改了3. 黑客能否针对公证机构的pub3进行中间人攻击4. 补充安装Fiddler时为什么要安装证书5. SSL/TLS协议是在什么时候生效的6. 为什么摘要内容在网络传输的时候一定要加密形成签名?7. 为什么签名不直接加密而是要先hash形成摘要完整流程四. 总结一. HTTPS是什么HTTPS是一个应用层协议是在HTTP协议的基础上引入了一个加密层名字叫SSL / TLS.关于SSL/TLS这其实是同一个东西只不过以前旧版本名字叫SSL升级后新版叫TLS这个加密层可以视作一个单独的协议至于其是如何加密的就是我们下面要探讨的内容。由于HTTP协议内容本身都是按照文本的方式进行明文传输的这就导致在传输过程中可能会出现一些内容被篡改的情况。比如臭名昭著的运营商劫持问题简单来说就是你点击下载网易云音乐的按钮页面上会给你弹出一个下载链接以及下载位置等在没有被劫持的情况下这些内容都是网易这个公司来提供的正确的内容而这个过程如果被运营商劫持了在下载链接位置就可能会变成其他内容的下载链接比如QQ浏览器等。由于我们通过网络传输的任何数据都会经过运营商的网络设备路由器交换机等那么运营商的网络设备就可以解析出你传输的数据内容从而进行篡改。点击下载按钮其实本质上就是在给服务器发送一个HTTP请求获取到的HTTP响应其实就包含了该APP的下载链接。在被运营商劫持之后发现这个请求是要下载网易云音乐那么就自动的把交给用户的响应给篡改成QQ浏览器的下载地址了。运营商劫持其实还不是最关键的更关键的是黑客也可以用类似的手段来进行劫持窃取用户隐私信息或者篡改内容。试想一下如果黑客在用户登录支付宝的时候就能够获取到用户的账户余额甚至支付密码...所以在互联网上明文传输是比较危险的事情。HTTPS就是在HTTP的基础上进行了加密进一步来保证用户的信息安全。二. 加密是什么前面说了要保证数据安全就需要进行加密安全与否防的是黑客。加密后网络传输的数据不再是明文而是密文此时就提高了数据的安全性。加密就是把明文(要传输的信息) 进行一系列变换生成密文.解密就是把密文再进行一系列变换还原剩明文.在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥(正确发音 yue 四声, 不过大家平时都读作 yao 四声) .而加密解密在如今已经发展成一个独立的学科密码学.而密码学的奠基人, 也正是计算机科学的祖师爷之一, 艾伦·麦席森·图灵不过这里我们不过多展开。加密算法加密算法有多种分类的方式按照类型可以分为可逆加密算法 / 不可逆加密算法可逆密文 - 明文 不可逆密文 ≠ 明文按照用途可以分为对称加密算法 / 非对称加密算法 / 摘要算法其中对称加密和非对称加密算法都是可逆的摘要算法是不可逆的对称加密一个密钥key既可以加密又可以解密特点速度快效率高适合传输大量数据但不安全。非对称加密两个密钥key1,key2若用key1加密就必须用key2解密若用key2加密就必须用key1解密通常用法是把其中一个公开出去称为公钥另一个自己保存好称为私钥这里的一对公钥和私钥有一定关联关系底层有数学理论支撑。特点速度慢不适合传输大量数据。用于比较安全的交换对称密钥和后续的数字签名。摘要算法像数据的指纹能够将任意数据转换为固定长度的摘要且不可逆(无法从摘要还原出原文)主要用于校验数据是否被篡改(如CRC循环冗余校验)至于加密解密的具体细节/算法属于数学问题计算机圈子中都有很多现成的库供我们直接使用。我们这里主要说HTTPS加密的流程是如何来使用的。三. HTTPS的工作过程引入对称加密对称加密一个密钥既可加密又可解密思路客户端 / 服务器生成一个密钥让对方也持有这个密钥客户端发送给服务器的数据就用这个密钥来加密服务器就使用这个密钥来解密。上述过程过于理想实际存在许多问题一个服务器是要给很多客户端提供服务的这么多客户端是使用同一个密钥还是不同的密钥 当然绝对不能是同一个如果是同一个黑客自己整个请求发过去就完事了。所以可以让客户端生成一个随机的对称密钥把对称密钥通过网络传输给服务器那么怎么传呢这一传就会出问题。所以上面我们用对称加密问题是什么首先一个服务器要给很多客户端提供服务那么此时每个客户端使用的密钥就必须是不同的如果相同黑客随时能拿到既然每个客户端都使用不同密钥那就意味着再通信前都要先把密钥通过网络传输给对方无论是客户端传给服务器还是反过来都会有这么一个密钥传输的过程这样的密钥传输过程如果密钥是明文传输就可以被黑客截获如何对密钥安全传输自然还是加密再搞对称密钥222用222进行加密这样还得传明文222还是会被黑客拿到。所以仅仅引入对称加密不足以解决安全问题。引入非对称加密非对称加密两个密钥一个用来加密就必须用另一个来解密思路服务器生成一对公钥和私钥私钥只有服务器自己知道公钥直接公开出去任何人都能拿到。 服务器生成的公钥和私钥对每次也是不同的。客户端决定对称密钥是什么通过公钥进行加密。后续数据再用对称密钥进行传输。此时黑客即使拿到数据也无法进行解密因为他手里只有公钥没有私钥公钥是一把锁头私钥是对应的钥匙此时就保证了数据传输的安全性。为什么不只使用非对称加密传输数据因为对称加密效率比较高占用的系统资源少.非对称加密效率比较低占用的系统资源多.我们只使用非对称加密传输对称密钥规避非对称加密开销大的问题.使用对称加密加密数据. 由于对称密钥已经安全的到达对方了对称加密此时也是一样安全的。由于对称加密效率比非对称加密高得多所以只是在开始阶段协商对称密钥时采用非对称加密后续传输仍然使用对称加密。PS黑客能否黑入服务器拿到私钥 - 理论上当然可以但凡事讲究成本。没有绝对的安全尤其是大公司的服务器都会有专业的安全团队做安全相关的措施。至此引入非对称加密后数据看起来就安全多了但是黑客真的就无法获取到我们的数据了吗中间人攻击思路由于生成公钥 / 私钥的算法都是开源的所以黑客自己也可以生成一个公钥 / 私钥对。对客户端黑客把自己的设备伪装成服务器。对服务器黑客把自己的设备伪裝成客户端。具体中间人攻击过程如下整个中间人攻击过程梳理客户端经过黑客向服务器索要公钥服务器给客户端公钥中间的这个公钥是通过明文传输的没有被加密黑客自己也去生成一个公钥/私钥对把上面服务器给客户端的这个公钥给截获到替换为自己生成的交给客户端.此时相当于黑客伪装成服务器与客户端进行交互客户端生成对称密钥使用黑客给的公钥进行加密发送给服务器黑客截获到这个数据后由于黑客持有对应的私钥进行解密出对称密钥然后再拿着服务器给的公钥对对称密钥再进行加密给服务器.此时相当于黑客伪装成客户端与服务器进行交互最后的结果就是客户端与服务器的对称密钥也被黑客获取到了数据完全泄露。这就是中间人攻击所以即使在引入对称加密和非对称加密的情况下也会在黑客的中间人攻击的情况下丧失数据安全性。引入证书要想应对中间人攻击首先要找到问题出在哪在中间人攻击的流程中最关键的问题在于客户端并不知道对方是黑客伪造的还是真实的服务器。所以我们要有手段让客户端识别出真伪能够识别出这个公钥就是服务器提供的真实的公钥而不是黑客伪造的。此时就需要引入证书服务器在使用HTTPS前需要向CA机构申领一份数字证书数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器浏览器从证书里获取公钥就行了证书就如身份证证明服务端公钥的权威性证书是什么证书是一个结构化字符串是第三方机构给服务器颁发的证明服务器身份的一个东西。结构化字符串即字符串里面包含了许多属性类似于一个结构体只不过变成了字符串的方式。服务器需要把自己的域名和公钥向公证机构CA提交资质申请数字证书然后公证机构验证通过后给服务器颁发证书。确保你访问的是真实合法的服务器而不是钓鱼网站等这个证书结构化字符串中包含明文信息和签名信息两大部分。被签名的明文信息待签证书主体信息证书持有者的身份比如域名公司名称等公钥持有者的非对称加密公钥服务器的公钥颁发者签发这张证书的 CA 机构名称有效期证书的起始和结束时间序列号该 CA 颁发的唯一编号用于吊销列表查询。签名算法标识告诉你 CA 使用了哪种算法来签名。如sha256RSA签名信息本质是加密后的校验和它是 CA 用自己生成的非对称加密私钥生成的最终密文附在证书末尾.证书中最重要的就是这个签名信息这部分确保了证书不可伪造证书中的签名信息正是根据上面提到的被签名的明文信息来计算出来的CA将所有上述信息按固定格式排列使用摘要算法不可逆算法中的哈希算法如SHA-256计算出一个固定长度的数字摘要生成校验和。然后对这个校验和使用CA自己的非对称加密私钥来加密。引入证书后的工作流程客户端拿到证书后就可以对证书的真实性进行验证客户端校验证书真实性上面证书部分说了除了签名外其余部分都是证书上的明文部分。1. 客户端使用证书中标记的哈希算法计算校验和check12. 客户端拿着公证机构的公钥对签名进行解密得到校验和check23. 对比check1和check2的值如果校验和相等说明证书真实有效。否则说明证书是假的。此处校验和相等说明两点1. 证书正文内容在传输中没有被篡改。 2. 该证书确实是由持有该私钥的 CA 签发的因为只有CA的私钥才能加密出能被CA公钥正确解密的签名。此时浏览器会直接弹一个红色页面提示你访问的网站存在安全风险此时用户停止访问就可以避免数据发生泄漏了。由于证书中的明文信息部分包含的有服务器的公钥所以后续就是客户端生成对称密钥使用服务器公钥进行加密由于只有服务器拥有对应的私钥所以只有服务器能成功解密获得私钥。后续所有的数据传输信息都使用对称密钥来加密传输。常见问题1. 黑客能否修改证书中的公钥当然是不能假设黑客把证书中服务器的公钥pub1换成了自己的pub2客户端校验证书真实性时从证书中解密出来的校验和也是用原始的pub1计算出来的而不是黑客的pub2此时就会导致客户端自己计算出的校验和和解密出的校验和不同。2. 黑客能否把数据签名一起修改了还是不行因为证书中的数字签名需要使用公证机构自己的非对称加密私钥 pri3来进行加密黑客最多算校验和绝对无法生成数字签名除非黑客把公证机构黑了3. 黑客能否针对公证机构的pub3进行中间人攻击更不可能因为公证机构的pub3就不是通过网络传输的。而是用户的操作系统内置的。全世界的公证机构也没有很多。主流的操作系统中都内置了主流公证机构的公钥如果你使用的是盗版系统提前内置好黑客的公钥... 此时黑客是可以伪造整个数字签名的...所以引入证书的方式是能彻底实现数据安全的。黑客既不能篡改公钥改变校验和客户端认证失败也无法伪造数字签名黑客无CA公钥无法生成有效签名客户端解密失败/校验和不匹配更无法冒充CA机构客户端只信任预置根证书黑客伪造的CA证书不在信任列表仍然导致校验和不匹配4. 补充安装Fiddler时为什么要安装证书fiddler 抓取 HTTPS 的时候其实就是在进行中间人攻击如果你想用fiddler抓HTTPS需要先信任fiddler的证书勾选的那几个选项此时其实就相当于信任了fiddler的公钥。我们信任了fiddler的证书此时fiddler就相当于一个公证机构。fiddler拦截服务器返回的真实证书后替换其中服务器公钥为fiddler自己的公钥并基于fiddler根证书重新生成数字签名形成伪造证书篡改后的证书域名等信息与真实证书一致公钥替换为fiddler公钥数字签名由fiddler根证书私钥生成非原始CA签名由于客户端已经信任fiddler根证书所以会认为伪造的证书是合法的.验证签名时使用fiddler公钥解密成功条件作用实现方式客户端信任fiddler根证书使客户端接受伪造证书用于手动安装fiddler证书到设备信任fiddler启用HTTPS解密激活中间人攻击功能勾选两个选项(见HTTP章节fiddler使用)代理流量劫持强制客户端流量经过fiddler设备配置代理指向fiddlerIP端口号88885. SSL/TLS协议是在什么时候生效的前提最开头部分已经提到HTTPS是在HTTP的基础上引入了加密层加密层的名字叫SSL/TLS。上面我们所说的内容就是这个加密层做的工作如何加密的1. SSL/TLS是在哪里生效的SSL/TLS协议是在传输层与应用层之间建立的加密通道。并不是在传输层可以理解为传输层TCP/UDP应用层HTTPS这两层中间还有独立的安全层SSL/TLS就作用在这里。一般来说在TCP/IP四层模型中SSL/TLS被归为应用层作为HTTP的扩展在OSI七层模型中被归为会话层/表示层安全抽象层HTTP —— TLS/SSL —— TCP6. 为什么摘要内容在网络传输的时候一定要加密形成签名?常见的摘要算法有: MD5 和 SHA 系列以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:• 定长: 无论多长的字符串, 计算出来的 MD5 值都是固定长度 (16字节版本或者32字节版本)• 分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大.• 不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同.理解判定证书篡改的过程类似于判定一个身份证是不是伪造的假设我们的证书只是一个简单的字符串test对这个字符串计算hash值假设用md5结果为098F6BCD4621D373CADE4E832627B4F6若test中有任何一个字符被篡改了比如teat此时计算出的md5值就会变化很大55CAEB5DE0B558FB7836F5346D35D67E然后我们可以把这个字符串 test 和 哈希值 098F6BCD4621D373CADE4E832627B4F6从服务器返回给客户端, 此时客户端如何验证 test 是否是被篡改过?那么就只要计算 test 的哈希值, 看看是不是 098F6BCD4621D373CADE4E832627B4F6即可.这里就涉及一个问题如果黑客把test篡改了并且把哈希值也重新计算此时客户端就无从分辨了。(连着字符串和哈希值一起改)所以被传输的哈希值不能是明文必须是密文。所以对于证书明文形成的哈希值CA要用自己的私钥来进行加密将test和加密后的签名合起来形成CA证书此时黑客就无法进行更改或整体掉包就能安全的证明证书的合法性。最后客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密, 还原出原始的哈希值, 再进行校验.7. 为什么签名不直接加密而是要先hash形成摘要缩小签名密文的长度,加快数字签名的验证签名的运算速度完整流程四. 总结关于HTTPS的加密同时涉及对称加密和非对称加密同时还引入了数字证书来防伪.HTTPS的工作过程中涉及到的密钥有三组.第一组非对称加密:用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这组 私钥-公钥 对, 然后通过证书把公钥传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥
【Web基础】HTTPS详解
发布时间：2026/6/29 19:50:46
目录一. HTTPS是什么二. 加密是什么加密算法三. HTTPS的工作过程引入对称加密引入非对称加密为什么不只使用非对称加密传输数据中间人攻击引入证书证书是什么引入证书后的工作流程常见问题1. 黑客能否修改证书中的公钥2. 黑客能否把数据签名一起修改了3. 黑客能否针对公证机构的pub3进行中间人攻击4. 补充安装Fiddler时为什么要安装证书5. SSL/TLS协议是在什么时候生效的6. 为什么摘要内容在网络传输的时候一定要加密形成签名?7. 为什么签名不直接加密而是要先hash形成摘要完整流程四. 总结一. HTTPS是什么HTTPS是一个应用层协议是在HTTP协议的基础上引入了一个加密层名字叫SSL / TLS.关于SSL/TLS这其实是同一个东西只不过以前旧版本名字叫SSL升级后新版叫TLS这个加密层可以视作一个单独的协议至于其是如何加密的就是我们下面要探讨的内容。由于HTTP协议内容本身都是按照文本的方式进行明文传输的这就导致在传输过程中可能会出现一些内容被篡改的情况。比如臭名昭著的运营商劫持问题简单来说就是你点击下载网易云音乐的按钮页面上会给你弹出一个下载链接以及下载位置等在没有被劫持的情况下这些内容都是网易这个公司来提供的正确的内容而这个过程如果被运营商劫持了在下载链接位置就可能会变成其他内容的下载链接比如QQ浏览器等。由于我们通过网络传输的任何数据都会经过运营商的网络设备路由器交换机等那么运营商的网络设备就可以解析出你传输的数据内容从而进行篡改。点击下载按钮其实本质上就是在给服务器发送一个HTTP请求获取到的HTTP响应其实就包含了该APP的下载链接。在被运营商劫持之后发现这个请求是要下载网易云音乐那么就自动的把交给用户的响应给篡改成QQ浏览器的下载地址了。运营商劫持其实还不是最关键的更关键的是黑客也可以用类似的手段来进行劫持窃取用户隐私信息或者篡改内容。试想一下如果黑客在用户登录支付宝的时候就能够获取到用户的账户余额甚至支付密码...所以在互联网上明文传输是比较危险的事情。HTTPS就是在HTTP的基础上进行了加密进一步来保证用户的信息安全。二. 加密是什么前面说了要保证数据安全就需要进行加密安全与否防的是黑客。加密后网络传输的数据不再是明文而是密文此时就提高了数据的安全性。加密就是把明文(要传输的信息) 进行一系列变换生成密文.解密就是把密文再进行一系列变换还原剩明文.在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥(正确发音 yue 四声, 不过大家平时都读作 yao 四声) .而加密解密在如今已经发展成一个独立的学科密码学.而密码学的奠基人, 也正是计算机科学的祖师爷之一, 艾伦·麦席森·图灵不过这里我们不过多展开。加密算法加密算法有多种分类的方式按照类型可以分为可逆加密算法 / 不可逆加密算法可逆密文 - 明文 不可逆密文 ≠ 明文按照用途可以分为对称加密算法 / 非对称加密算法 / 摘要算法其中对称加密和非对称加密算法都是可逆的摘要算法是不可逆的对称加密一个密钥key既可以加密又可以解密特点速度快效率高适合传输大量数据但不安全。非对称加密两个密钥key1,key2若用key1加密就必须用key2解密若用key2加密就必须用key1解密通常用法是把其中一个公开出去称为公钥另一个自己保存好称为私钥这里的一对公钥和私钥有一定关联关系底层有数学理论支撑。特点速度慢不适合传输大量数据。用于比较安全的交换对称密钥和后续的数字签名。摘要算法像数据的指纹能够将任意数据转换为固定长度的摘要且不可逆(无法从摘要还原出原文)主要用于校验数据是否被篡改(如CRC循环冗余校验)至于加密解密的具体细节/算法属于数学问题计算机圈子中都有很多现成的库供我们直接使用。我们这里主要说HTTPS加密的流程是如何来使用的。三. HTTPS的工作过程引入对称加密对称加密一个密钥既可加密又可解密思路客户端 / 服务器生成一个密钥让对方也持有这个密钥客户端发送给服务器的数据就用这个密钥来加密服务器就使用这个密钥来解密。上述过程过于理想实际存在许多问题一个服务器是要给很多客户端提供服务的这么多客户端是使用同一个密钥还是不同的密钥 当然绝对不能是同一个如果是同一个黑客自己整个请求发过去就完事了。所以可以让客户端生成一个随机的对称密钥把对称密钥通过网络传输给服务器那么怎么传呢这一传就会出问题。所以上面我们用对称加密问题是什么首先一个服务器要给很多客户端提供服务那么此时每个客户端使用的密钥就必须是不同的如果相同黑客随时能拿到既然每个客户端都使用不同密钥那就意味着再通信前都要先把密钥通过网络传输给对方无论是客户端传给服务器还是反过来都会有这么一个密钥传输的过程这样的密钥传输过程如果密钥是明文传输就可以被黑客截获如何对密钥安全传输自然还是加密再搞对称密钥222用222进行加密这样还得传明文222还是会被黑客拿到。所以仅仅引入对称加密不足以解决安全问题。引入非对称加密非对称加密两个密钥一个用来加密就必须用另一个来解密思路服务器生成一对公钥和私钥私钥只有服务器自己知道公钥直接公开出去任何人都能拿到。 服务器生成的公钥和私钥对每次也是不同的。客户端决定对称密钥是什么通过公钥进行加密。后续数据再用对称密钥进行传输。此时黑客即使拿到数据也无法进行解密因为他手里只有公钥没有私钥公钥是一把锁头私钥是对应的钥匙此时就保证了数据传输的安全性。为什么不只使用非对称加密传输数据因为对称加密效率比较高占用的系统资源少.非对称加密效率比较低占用的系统资源多.我们只使用非对称加密传输对称密钥规避非对称加密开销大的问题.使用对称加密加密数据. 由于对称密钥已经安全的到达对方了对称加密此时也是一样安全的。由于对称加密效率比非对称加密高得多所以只是在开始阶段协商对称密钥时采用非对称加密后续传输仍然使用对称加密。PS黑客能否黑入服务器拿到私钥 - 理论上当然可以但凡事讲究成本。没有绝对的安全尤其是大公司的服务器都会有专业的安全团队做安全相关的措施。至此引入非对称加密后数据看起来就安全多了但是黑客真的就无法获取到我们的数据了吗中间人攻击思路由于生成公钥 / 私钥的算法都是开源的所以黑客自己也可以生成一个公钥 / 私钥对。对客户端黑客把自己的设备伪装成服务器。对服务器黑客把自己的设备伪裝成客户端。具体中间人攻击过程如下整个中间人攻击过程梳理客户端经过黑客向服务器索要公钥服务器给客户端公钥中间的这个公钥是通过明文传输的没有被加密黑客自己也去生成一个公钥/私钥对把上面服务器给客户端的这个公钥给截获到替换为自己生成的交给客户端.此时相当于黑客伪装成服务器与客户端进行交互客户端生成对称密钥使用黑客给的公钥进行加密发送给服务器黑客截获到这个数据后由于黑客持有对应的私钥进行解密出对称密钥然后再拿着服务器给的公钥对对称密钥再进行加密给服务器.此时相当于黑客伪装成客户端与服务器进行交互最后的结果就是客户端与服务器的对称密钥也被黑客获取到了数据完全泄露。这就是中间人攻击所以即使在引入对称加密和非对称加密的情况下也会在黑客的中间人攻击的情况下丧失数据安全性。引入证书要想应对中间人攻击首先要找到问题出在哪在中间人攻击的流程中最关键的问题在于客户端并不知道对方是黑客伪造的还是真实的服务器。所以我们要有手段让客户端识别出真伪能够识别出这个公钥就是服务器提供的真实的公钥而不是黑客伪造的。此时就需要引入证书服务器在使用HTTPS前需要向CA机构申领一份数字证书数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器浏览器从证书里获取公钥就行了证书就如身份证证明服务端公钥的权威性证书是什么证书是一个结构化字符串是第三方机构给服务器颁发的证明服务器身份的一个东西。结构化字符串即字符串里面包含了许多属性类似于一个结构体只不过变成了字符串的方式。服务器需要把自己的域名和公钥向公证机构CA提交资质申请数字证书然后公证机构验证通过后给服务器颁发证书。确保你访问的是真实合法的服务器而不是钓鱼网站等这个证书结构化字符串中包含明文信息和签名信息两大部分。被签名的明文信息待签证书主体信息证书持有者的身份比如域名公司名称等公钥持有者的非对称加密公钥服务器的公钥颁发者签发这张证书的 CA 机构名称有效期证书的起始和结束时间序列号该 CA 颁发的唯一编号用于吊销列表查询。签名算法标识告诉你 CA 使用了哪种算法来签名。如sha256RSA签名信息本质是加密后的校验和它是 CA 用自己生成的非对称加密私钥生成的最终密文附在证书末尾.证书中最重要的就是这个签名信息这部分确保了证书不可伪造证书中的签名信息正是根据上面提到的被签名的明文信息来计算出来的CA将所有上述信息按固定格式排列使用摘要算法不可逆算法中的哈希算法如SHA-256计算出一个固定长度的数字摘要生成校验和。然后对这个校验和使用CA自己的非对称加密私钥来加密。引入证书后的工作流程客户端拿到证书后就可以对证书的真实性进行验证客户端校验证书真实性上面证书部分说了除了签名外其余部分都是证书上的明文部分。1. 客户端使用证书中标记的哈希算法计算校验和check12. 客户端拿着公证机构的公钥对签名进行解密得到校验和check23. 对比check1和check2的值如果校验和相等说明证书真实有效。否则说明证书是假的。此处校验和相等说明两点1. 证书正文内容在传输中没有被篡改。 2. 该证书确实是由持有该私钥的 CA 签发的因为只有CA的私钥才能加密出能被CA公钥正确解密的签名。此时浏览器会直接弹一个红色页面提示你访问的网站存在安全风险此时用户停止访问就可以避免数据发生泄漏了。由于证书中的明文信息部分包含的有服务器的公钥所以后续就是客户端生成对称密钥使用服务器公钥进行加密由于只有服务器拥有对应的私钥所以只有服务器能成功解密获得私钥。后续所有的数据传输信息都使用对称密钥来加密传输。常见问题1. 黑客能否修改证书中的公钥当然是不能假设黑客把证书中服务器的公钥pub1换成了自己的pub2客户端校验证书真实性时从证书中解密出来的校验和也是用原始的pub1计算出来的而不是黑客的pub2此时就会导致客户端自己计算出的校验和和解密出的校验和不同。2. 黑客能否把数据签名一起修改了还是不行因为证书中的数字签名需要使用公证机构自己的非对称加密私钥 pri3来进行加密黑客最多算校验和绝对无法生成数字签名除非黑客把公证机构黑了3. 黑客能否针对公证机构的pub3进行中间人攻击更不可能因为公证机构的pub3就不是通过网络传输的。而是用户的操作系统内置的。全世界的公证机构也没有很多。主流的操作系统中都内置了主流公证机构的公钥如果你使用的是盗版系统提前内置好黑客的公钥... 此时黑客是可以伪造整个数字签名的...所以引入证书的方式是能彻底实现数据安全的。黑客既不能篡改公钥改变校验和客户端认证失败也无法伪造数字签名黑客无CA公钥无法生成有效签名客户端解密失败/校验和不匹配更无法冒充CA机构客户端只信任预置根证书黑客伪造的CA证书不在信任列表仍然导致校验和不匹配4. 补充安装Fiddler时为什么要安装证书fiddler 抓取 HTTPS 的时候其实就是在进行中间人攻击如果你想用fiddler抓HTTPS需要先信任fiddler的证书勾选的那几个选项此时其实就相当于信任了fiddler的公钥。我们信任了fiddler的证书此时fiddler就相当于一个公证机构。fiddler拦截服务器返回的真实证书后替换其中服务器公钥为fiddler自己的公钥并基于fiddler根证书重新生成数字签名形成伪造证书篡改后的证书域名等信息与真实证书一致公钥替换为fiddler公钥数字签名由fiddler根证书私钥生成非原始CA签名由于客户端已经信任fiddler根证书所以会认为伪造的证书是合法的.验证签名时使用fiddler公钥解密成功条件作用实现方式客户端信任fiddler根证书使客户端接受伪造证书用于手动安装fiddler证书到设备信任fiddler启用HTTPS解密激活中间人攻击功能勾选两个选项(见HTTP章节fiddler使用)代理流量劫持强制客户端流量经过fiddler设备配置代理指向fiddlerIP端口号88885. SSL/TLS协议是在什么时候生效的前提最开头部分已经提到HTTPS是在HTTP的基础上引入了加密层加密层的名字叫SSL/TLS。上面我们所说的内容就是这个加密层做的工作如何加密的1. SSL/TLS是在哪里生效的SSL/TLS协议是在传输层与应用层之间建立的加密通道。并不是在传输层可以理解为传输层TCP/UDP应用层HTTPS这两层中间还有独立的安全层SSL/TLS就作用在这里。一般来说在TCP/IP四层模型中SSL/TLS被归为应用层作为HTTP的扩展在OSI七层模型中被归为会话层/表示层安全抽象层HTTP —— TLS/SSL —— TCP6. 为什么摘要内容在网络传输的时候一定要加密形成签名?常见的摘要算法有: MD5 和 SHA 系列以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:• 定长: 无论多长的字符串, 计算出来的 MD5 值都是固定长度 (16字节版本或者32字节版本)• 分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大.• 不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同.理解判定证书篡改的过程类似于判定一个身份证是不是伪造的假设我们的证书只是一个简单的字符串test对这个字符串计算hash值假设用md5结果为098F6BCD4621D373CADE4E832627B4F6若test中有任何一个字符被篡改了比如teat此时计算出的md5值就会变化很大55CAEB5DE0B558FB7836F5346D35D67E然后我们可以把这个字符串 test 和 哈希值 098F6BCD4621D373CADE4E832627B4F6从服务器返回给客户端, 此时客户端如何验证 test 是否是被篡改过?那么就只要计算 test 的哈希值, 看看是不是 098F6BCD4621D373CADE4E832627B4F6即可.这里就涉及一个问题如果黑客把test篡改了并且把哈希值也重新计算此时客户端就无从分辨了。(连着字符串和哈希值一起改)所以被传输的哈希值不能是明文必须是密文。所以对于证书明文形成的哈希值CA要用自己的私钥来进行加密将test和加密后的签名合起来形成CA证书此时黑客就无法进行更改或整体掉包就能安全的证明证书的合法性。最后客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密, 还原出原始的哈希值, 再进行校验.7. 为什么签名不直接加密而是要先hash形成摘要缩小签名密文的长度,加快数字签名的验证签名的运算速度完整流程四. 总结关于HTTPS的加密同时涉及对称加密和非对称加密同时还引入了数字证书来防伪.HTTPS的工作过程中涉及到的密钥有三组.第一组非对称加密:用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这组 私钥-公钥 对, 然后通过证书把公钥传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密.其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥
相关文章
Docker化部署Snipe-IT实战：从零配置到QQ邮箱集成与排错
1. Docker环境准备与安装 在开始部署Snipe-IT之前，我们需要先搭建好Docker运行环境。这里以CentOS系统为例，分享我多次实战验证过的安装流程。相比官方文档，我会补充几个国内开发者常遇到的坑点。 首先更新系统基础工具包，这个步骤…
基于ruoyi-vue-pro的企业级技术架构深度解析与实战指南
基于ruoyi-vue-pro的企业级技术架构深度解析与实战指南 【免费下载链接】ruoyi-vue-pro 🔥 官方推荐 🔥 RuoYi-Vue 全新 Pro 版本，优化重构所有功能。基于 Spring Boot MyBatis Plus Vue & Element 实现的后台管理系统 微信小程序&…
HackingBuddyGPT：基于LLM的智能渗透测试助手实战指南
1. 项目概述：当AI成为你的渗透测试伙伴最近在安全圈和开源社区里，一个名为HackingBuddyGPT的项目热度悄然攀升。作为一名在渗透测试和红队攻防领域摸爬滚打了十多年的老手，我最初看到这个名字时，第一反应是好奇与怀疑并存。好奇的…
Gemmini：开源全栈DNN加速器如何重塑系统级协同设计
1. Gemmini：重新定义DNN加速器的全栈协同设计 第一次听说Gemmini时，我正在为一个边缘计算项目头疼。客户要求我们在RISC-V芯片上实现高效的图像识别，但传统加速器要么难以集成，要么软件支持太差。直到发现这个开源神器，…
完整生命周期示例
import cn.hutool.cache.impl.TimedCache;public class TimedCacheLifecycle {public static void main(String[] args) throws InterruptedException {// 1. 创建缓存，默认过期时间2秒TimedCache<String, String> cache new TimedCache<>(2000);// 2.…
低速与高速电路设计：别再只看频率，边沿才是关键
本篇博客将为你一次性讲透—— 低速电路和高速电路的设计到底有什么本质区别？ 如何区分低速信号与高速信号？ 二者分别需要关注哪些不同的问题？ 一、区分低速信号与高速信号 先抛结论：区分低速和高速信号的决定性因素是信号的…
太恐怖了，传统 Java 后端已经快找不着工作了...
这个 AI 部分的学习计划，可以调整到后面吗？[破涕为笑] 这个问题其实挺有代表性的。 因为在很多 Java 程序员的认知里，Java 才是主业，AI 只是锦上添花的东西。与其花时间研究大模型、RAG、Agent，不如把八股文再背熟一点…
QQ音乐解析终极指南：打破VIP限制，高效获取高品质音乐资源
QQ音乐解析终极指南：打破VIP限制，高效获取高品质音乐资源 【免费下载链接】MCQTSS_QQMusic QQ音乐解析 项目地址: https://gitcode.com/gh_mirrors/mc/MCQTSS_QQMusic MCQTSS_QQMusic开源项目是一款强大的Python工具，能够解析QQ音乐的…
斗地主AI实战指南：3步掌握DouZero智能辅助系统
斗地主AI实战指南：3步掌握DouZero智能辅助系统 【免费下载链接】DouZero_For_HappyDouDiZhu 基于DouZero定制AI实战欢乐斗地主 项目地址: https://gitcode.com/gh_mirrors/do/DouZero_For_HappyDouDiZhu 如果你正在寻找一款能够真正提升斗地主游戏水平的智能…
Java开发者转型安全开发：从代码审计到自动化工具实践
1. 转型背景与核心驱动力最近几年，身边不少做Java后端开发的朋友，都开始或多或少地关注起安全开发这个方向。我自己也是从写了七八年Java业务代码，一步步转向了安全领域，现在主要做代码审计和自动化安全工具开发。这个转变不是一时…
【TEE从入门到精通及实战】75 TEE内Wasm沙箱的内存安全：从“段错误”到“编译时保证”
75 TEE内Wasm沙箱的内存安全：从“段错误”到“编译时保证” 开篇故事 去年夏天，我正帮一家金融科技公司优化他们的TEE内Wasm沙箱。他们的核心业务是在Intel SGX enclave里运行用户提交的Wasm合约，用于实时交易验证。 一天下午，运维突然报警：生产环境的enclave进程频繁崩…
YAML函数动态解析：打造智能接口自动化测试用例
1. 项目概述：为什么YAML测试用例需要函数动态解析？在接口自动化测试的实践中，我们常常会面临一个核心矛盾：测试用例的可维护性与灵活性。早期的测试脚本，无论是用Python的unittest还是pytest，往往将测试数据…
AI Coding 六个月真实ROI账本：产品经理的血泪教训，研发的冷静忠告
6个月前的2025年12月，Boris Cherny 公开宣布自己卸载了 IDE。一时间，Vibe Coding 成了全行业最热的话题。6个月后，当我们回过头来拉一份真实账本，发现事情远没有"一句话生成一个App"那么浪漫。本文从产品经理和研发两个…
华为OD机试2025C卷-字符统计及重排[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
华为OD机试2025C卷-寻找相同子串[100分]（ Java _ Python3 _ C++ _ C语言 _ JsNode _ Go）实现100%通过率
📫 个人主页：深夜coding算法 📣 专栏系列：2026年华为最新OD机试题库详解 🔥 一次订阅，永久解锁 | 持续更新100篇 | 6语言全覆盖 文章目录❄️前言：☀️一：题目描述🌙 题目…
Zotero Duplicates Merger：5步彻底清理文献库重复条目
Zotero Duplicates Merger：5步彻底清理文献库重复条目 【免费下载链接】ZoteroDuplicatesMerger A zotero plugin to automatically merge duplicate items 项目地址: https://gitcode.com/gh_mirrors/zo/ZoteroDuplicatesMerger 还在为文献库中堆积如山的重…
利用随机有限集理论对蜂群的ILQR和MPC控制研究附Matlab代码
✅作者简介：热爱科研的Matlab仿真开发者，擅长数据处理、建模仿真、程序设计、完整代码获取、论文复现及科研仿真。🍎 往期回顾关注个人主页：Matlab科研工作室🍊个人信条：格物致知,完整Matlab代码及仿真咨询…
为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因
更多请点击： https://intelliparadigm.com 第一章：为什么你的Gemini邮件CTE低于行业均值2.8倍？：从Prompt架构到发送时序的深度归因 Gemini邮件的客户转化效率（CTE）显著偏低，根本原因常被误判为…