教程技术博客文档【免费下载链接】YCBlogs技术博客笔记大汇总包括Java基础线程并发数据结构Android技术博客等等常用设计模式常见的算法网络协议知识点部分flutter笔记还包括平时开发中遇到的bug汇总当然也在工作之余收集了大量的面试题长期更新维护并且修正持续完善……开源的文件是markdown格式的转载请注明出处谢谢项目地址https://gitcode.com/gh_mirrors/yc/YCBlogs点击查看免费下载导读本文以 YCBlogs 网络协议系列中的《Https详细流程分析》为骨架系统拆解 HTTPS 从“为何存在”到“如何工作”的完整链路——包括 HTTP 的三大安全缺陷、对称/非对称加密的分工、SSL/TLS 证书体系、CA 数字证书与证书链验证、完整握手流程、中间人抓包原理以及性能损耗与接入优化方案。读完本文你将能够讲清楚 HTTPS 每一层防护的动机与实现理解 Charles 等抓包工具为什么必须依赖“信任根证书”才能解密流量并掌握从网络模型视角看待 TLS/SSL 在协议栈中位置的思维方式。01 为何会有 HTTPSHTTP 的三大缺陷与应对思路HTTPS 不是凭空出现的协议它是为了补上 HTTP 在设计之初留下的安全漏洞而诞生的。在理解 HTTPS 的详细流程之前必须先认清 HTTP 到底“不安全”在哪里。1.1 HTTP 的缺点HTTP 协议存在三个与生俱来的安全缺陷通信使用明文通信使用明文意味着安全性大大降低当通信过程被窃听后无需花费额外的投入就可看到传输的数据。例如使用抓包工具无需任何配置就可查看任何使用 HTTP 协议的通信数据不验证通信方身份不验证通信方的身份将导致通信过程被窃听后可能会遭遇伪装例如使用抓包工具抓取数据后就可按照数据包的格式构造 HTTP 请求任何人都可以发送请求不管对方是谁都返回相应无法验证报文的完整性不验证报文的完整性数据在传输过程中就可能被篡改——本来看的是正常内容结果数据在传输过程中被换成了别的东西。遭到篡改即没有办法确认发出的请求/响应前后一致。1.2 HTTP 缺点的朴素解决方案针对上述三个缺陷在没有引入完整安全体系之前业界有一些朴素的应对思路通信使用明文 → 使用密文既然明文不安全那可以考虑使用密文即对通信数据进行加密。即便数据被窃听对方依然需要花费一定的投入来破解这种高昂的成本间接提高安全级别不验证通信方身份 → token 机制和服务端使用相同的算法根据网络请求参数生成一个 token请求/应答时根据 token 来确定双方的身份无法验证报文的完整性 → 散列校验使用 MD5/SHA1 等算法进行完整性验证对方接收到数据后根据同样的算法生成散列值比对发送方生成的散列值即可验证数据的完整性。1.3 HTTP 的风险把上面的缺陷翻译成安全术语HTTP 面临三大风险窃听风险HTTP 采用明文传输数据第三方可以获知通信内容篡改风险第三方可以修改通信内容冒充风险第三方可以冒充他人身份进行通信。1.4 如何避免风险SSL/TLS 协议SSL/TLS 协议就是为了解决这些风险而设计它希望达到三个目标所有信息加密传输第三方无法窃听通信内容具有校验机制内容一旦被篡改通信双方立刻会发现配备身份证书防止身份被冒充。SSL 原理及运行过程SSL/TLS 协议基本思路是采用公钥加密法最有名的是 RSA 加密算法。大概流程是客户端向服务器索要公钥然后用公钥加密信息服务器收到密文用自己的私钥解密。这里有两个关键设计防止公钥被篡改把公钥放在数字证书中证书可信则公钥可信解决公钥加密计算量大的问题公钥加密非对称加密计算量很大为了提高效率服务端和客户端都生成“对话密钥”用它加密信息而对话密钥是对称加密速度非常快公钥则用来机密对话密钥。补充阅读仓库中 请求网络过程梳理 从“浏览器输入链接”开始完整梳理了一次网络请求的链路其中明确说明“对于购物的请求往往需要进行加密传输因而会使用 HTTPS 协议”可作为理解 HTTPS 应用场景的入口。02 HTTPS 解决方案分析加密方式与 SSL/TLS2.1 HTTPS 的加密方式一句话概括HTTPS HTTP SSL。HTTPS 保证了数据传输的安全之所以能保证安全主要的原理就是利用了非对称加密算法。平常使用的对称加密算法之所以不安全是因为双方是用统一的密钥进行加密解密的只要双方任意一方泄漏了密钥那么其他人就可以利用密钥解密数据非对称加密算法之所以能实现安全传输的核心精华就是公钥加密的信息只能用私钥解开私钥加密的信息只能被公钥解开。非对称加密算法为什么安全服务端向 CA 机构申请证书获取到证书的公钥和私钥私钥只有服务器端自己知道而公钥可以告知其他人例如传给客户端。客户端通过服务端传来的公钥来加密自己传输的数据而服务端利用私钥就可以解密这个数据。由于客户端这个用公钥加密的数据只有私钥能解密而这个私钥只有服务端有所以数据传输就安全了。需要注意的是上面只是简单说明了非对称加密算法如何保证数据安全实际上 HTTPS 的工作过程远比这要复杂——后面第 05 节会展开完整握手流程。2.2 SSL/TLS 是什么HTTPS 协议中需要使用到SSL 证书。SSL 证书是一个二进制文件里面包含经过认证的网站公钥和一些元数据需要从证书经销商购买。证书有很多类型按认证级别分类类型全称说明DVDomain Validation域名认证最低级别的认证可以确认申请人拥有这个域名OVOrganization Validation公司认证确认域名所有人是哪家公司证书里面包含公司的信息EVExtended Validation扩展认证最高级别认证浏览器地址栏会显示公司名称按覆盖范围分类类型说明单域名证书只能用于单域名foo.com 证书不能用于 www.foo.com通配符证书可用于某个域名及所有一级子域名比如 *.foo.com 的证书可用于 foo.com也可用于 www.foo.com多域名证书可用于多个域名比如 foo.com 和 bar.com2.3 SSL 的原理是什么SSLSecure Socket Layer安全套接字层TLSTransport Layer Security传输层安全协议。TLS 是 SSL 的继任者。仓库 OkHttp基础知识 中对此有补充说明SSL 的版本最高为 3.0后来的版本被称为 TLS现在所用的协议版本一般都是 TLS但由于 SSL 出现的时间比较早所以现在一般说的 SSL 通常就是指 TLS。HTTPS 的安全基础是 SSL因此加密的详细内容是 SSL。03 纯 RSA 方案存在的隐患3.1 RSA 验证的隐患SSL/TLS 协议的基本思路是采用公钥加密法最有名的是 RSA 加密算法虽然采用的是非对称加密但还是存在风险隐患。身份验证和密钥协商是 TLS 的基础功能其要求的前提是合法的服务器掌握着对应的私钥。而RSA 算法无法确保服务器身份的合法性——因为公钥并不包含服务器的信息存在安全隐患。3.2 中间方伪造公钥和私钥用一个例子说明隐患是如何被利用的客户端 C 和服务器 S 进行通信中间节点 M伪造方截获了二者的通信节点 M伪造方自己制作假数据计算产生一对公钥 pub_M 和私钥 pri_MC 向 S 请求公钥时M伪造方把自己的公钥 pub_M 发给了 CC 使用公钥 pub_M 加密的数据能够被 M 解密因为 M 掌握对应的私钥 pri_M而 C 无法根据公钥信息判断服务器的身份从而 C 和 M 之间建立了“可信”加密连接中间节点 M 和服务器 S 之间再建立合法的连接因此 C 和 S 之间的通信被 M 完全掌握M 可以进行信息的窃听、篡改等操作。另外服务器也可以对自己发出的信息进行否认不承认相关信息是自己发出的。3.3 存在两类问题因此该方案下至少存在两类问题中间人攻击和信息抵赖。什么是中间人攻击就是上面中间节点 M 伪造自己的公钥和私钥然后拦截信息进行篡改什么叫信息抵赖没办法校验服务端信息不对称。04 CA 证书体系如何解决 SSL 隐患4.1 如何解决 SSL 隐患CACertificate Authority证书颁发机构的初衷就是为了解决上面非对称加密被劫持的情况。核心机制服务器申请 CA 证书时将服务器的“公钥”提供给 CACA 使用自己的“私钥”将“服务器的公钥”加密后即CA 证书返回给服务器服务器再将“CA 证书”提供给客户端。一般系统或者浏览器会内置 CA 的根证书公钥HTTPS 中 CA 证书的获取流程如下注意问题上图步骤 2 之后客户端获取到“CA 证书”会进行本地验证即使用本地系统或者浏览器中的公钥进行解密每个“CA 证书”都会有一个证书编号可用于解密后进行比对具体验证算法请查阅相关资料步骤 5 之前使用的是对称加密之后将使用对称加密来提高通讯效率。4.2 CA 证书流程原理CA 证书的基本原理为CA 负责审核信息然后对关键信息利用私钥进行“签名”公开对应的公钥客户端可以利用公钥验证签名。CA 也可以吊销已经签发的证书基本的方式包括两类CRL 文件证书吊销列表和OCSP在线证书状态协议。在这个过程需要注意几点a.申请证书不需要提供私钥确保私钥永远只能服务器掌握b.证书的合法性仍然依赖于非对称加密算法证书主要是增加了服务器信息以及签名c.内置 CA 对应的证书称为根证书颁发者和使用者相同自己为自己签名即自签名证书这也是为什么说“部署自签 SSL 证书非常不安全”d.证书 公钥 申请者与颁发者信息 签名。CA 证书链如 CA 根证书和服务器证书中间增加一级证书机构即中间证书证书的产生和验证原理不变只是增加一层验证只要最后能够被任何信任的 CA 根证书验证合法即可。以三层证书链为例a.服务器证书 server.pem 的签发者为中间证书机构 interinter 根据证书 inter.pem 验证 server.pem 确实为自己签发的有效证书b.中间证书 inter.pem 的签发 CA 为 rootroot 根据证书 root.pem 验证 inter.pem 为自己签发的合法证书c.客户端内置信任 CA 的 root.pem 证书因此服务器证书 server.pem 被信任。仓库佐证OkHttp基础知识 对“数字证书”的颁发过程有更细节的描述用户首先产生自己的密钥对并将公共密钥及部分个人身份信息传送给认证中心认证中心核实身份后将发送给用户一个数字证书该证书内包含用户的个人信息和他的公钥信息同时还附有认证中心的签名信息根证书私钥签名。证书通常包含证书颁发机构的名称、证书本身的数字签名、证书持有者的公钥、证书签名用到的 Hash 算法等。05 HTTPS 完整工作流程握手过程5.1 工作流程总览HTTPS 的一次完整通信包含证书校验、密钥协商、签名生成与对称加密传输等多个环节整体流程可以概括为五步一首先 HTTP 请求服务端生成证书客户端对证书的**有效期、合法性、域名是否与请求的域名一致、证书的公钥RSA 加密**等进行校验二客户端如果校验通过后就根据证书的公钥生成随机数随机数使用公钥进行加密RSA 加密三消息体产生后对它的摘要进行 MD5或者 SHA1算法加密此时就得到了 RSA 签名四发送给服务端此时只有服务端RSA 私钥能解密五解密得到的随机数再用 AES 加密作为密钥此时的密钥只有客户端和服务端知道。5.2 详细流程说明展开来看HTTPS 从发起请求到最终解密内容共经历七个环节客户端发起 HTTPS 请求用户在浏览器里输入一个 https 网址然后连接到 server 的 443 端口。如果有私密信息包括 url、端口、账号密码等账号密码登陆应该用的是 POST 方式所以相关的用户信息会被加载到 body 里面服务端的配置采用 HTTPS 协议的服务器必须要有一套数字证书可以自己制作也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过才可以继续访问而使用受信任的公司申请的证书则不会弹出提示页面例如 startssl 有 1 年的免费服务。这套证书其实就是一对公钥和私钥——可以把公钥私钥理解成一把钥匙和一个锁头全世界只有你一个人有这把钥匙你可以把锁头公钥给别人别人可以用这把锁把重要的东西锁起来发给你因为只有你一个人有钥匙所以只有你才能看到被锁起来的东西传送证书服务器端会有一套数字证书相当于是个钥匙模板这个证书会先发送给客户端。这个证书其实就是公钥只是包含了很多信息如证书的颁发机构、过期时间等等客户端解析证书这部分工作由客户端的 TLS 完成首先会验证公钥是否有效比如颁发机构、过期时间等等如果发现异常则会弹出一个警告框提示证书存在问题。如果证书没有问题那么就生成一个随机值然后用证书对该随机值进行加密——就好像把随机值用锁头锁起来除非有钥匙不然看不到被锁住的内容客户端传送加密信息这部分传送的是用证书加密后的随机值目的就是让服务端得到这个随机值以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了服务端解密信息服务端用私钥解密后得到了客户端传过来的随机值私钥然后把内容通过该值进行对称加密。所谓对称加密就是将信息和私钥通过某种算法混合在一起这样除非知道私钥不然无法获取内容而正好客户端和服务端都知道这个私钥所以只要加密算法够彪悍、私钥够复杂数据就够安全传输加密后的信息并解密服务端用私钥加密后的信息可以在客户端被还原客户端用之前生成的私钥解密服务端传过来的信息于是获取了解密后的内容。整个过程第三方即使监听到了数据也束手无策。06 HTTPS 真的安全吗代理与抓包6.1 HTTPS 代理的了解HTTPS 代理的作用包括提高访问速度Proxy 可以起到防火墙的作用通过代理服务器访问一些不能直接访问的网站安全性得到提高。6.2 Charles 抓包流程中间人代理原理关于抓包仓库中 Http基础详细分析 从代理角度给出了严谨的区分HTTP 代理可以分为普通代理和隧道代理两类——普通代理扮演“中间人”角色对客户端来说它是服务端对真正的服务端来说它又是客户端负责在两端之间传递 HTTP 报文。在普通代理模式下所有请求响应的数据对于代理这个“中间人”来说都是透明且可以任意操作的这就会带来各种数据安全的隐患隧道代理Web tunnel通过 HTTP 的 CONNECT 方法建立代理服务器不再作为中间人改写请求而是把客户端和终端服务器的数据原样转发这样浏览器就可以直接和终端服务器进行 TLS 握手并传输加密的数据。这也是“没有安装 Charles 证书时 HTTPS 请求依然能正常收发、只是看不到明文细节”的原因。而 Charles 对 HTTPS 的抓包走的是普通代理中间人模式大概步骤流程如下第一步客户端向服务器发起 HTTPS 请求Charles 截获客户端发送给服务器的 HTTPS 请求Charles 伪装成客户端向服务器发送请求进行握手第二步服务器发回响应Charles 获取到服务器的 CA 证书用根证书这里的根证书是 CA 认证中心给自己颁发的证书公钥进行解密验证服务器数据签名获取到服务器 CA 证书公钥。然后 Charles 伪造自己的 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 会不会显得很鸡肋其实并不会——能抓包是因为你信任了抓包工具在手机上安装了与之对应的证书你要不安装证书抓包就会失败。而且安全这个课题是在攻防中求发展没有最安全只有更安全所以将攻击的成本提高了就间接达到了安全的目标。6.3 仓库实践Android 7.0 下 HTTPS 抓包的兼容配置仓库 Charles抓包步骤 提供了完整的 HTTPS 抓包实操流程电脑端安装 Charles 根证书、设置 SSL Proxy端口 443、手机端通过chls.pro/ssl下载并安装证书等。其中有一个关键知识点与本文主题直接相关Android 7.0API 24及以上为何不能轻易抓取到 HTTPS 请求的明文数据因为 Android 7.0 引入了一个名为“Network Security Configuration”的新安全功能允许开发人员在不修改应用代码的情况下自定义网络安全设置。如果应用运行的系统版本高于或等于 24并且 targetSdkVersion 24则只有系统system证书才会被信任所以用户user导入的 Charles 根证书是不被信任的。如果要让自己开发的应用在调试期支持抓包可以通过network_security_config配置文件把 user 证书也加入信任锚点?xml version1.0 encodingutf-8? network-security-config base-config cleartextTrafficPermittedtrue trust-anchors certificates overridePinstrue srcsystem / certificates overridePinstrue srcuser / /trust-anchors /base-config /network-security-config并在清单文件中引用application android:networkSecurityConfigxml/network_security_config_debug否则会抛出java.security.cert.CertPathValidatorException: Trust anchor for certification path not found异常。反过来看这正说明了“HTTPS 在正常情况下是难以被中间人解密”的——一旦客户端严格校验证书信任链伪造证书的中间人就会暴露。07 HTTPS 性能分析7.1 HTTPS 性能损耗HTTPS 相比 HTTP 主要带来两方面性能开销增加延时分析前面的握手过程一次完整的握手至少需要两端依次来回两次通信至少增加延时 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 增加的延时主要是传输延时 RTTRTT 的特点是节点越近延时越小CDN 天然离用户最近因此选择使用 CDN 作为 HTTPS 接入的入口将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法极大减少 HTTPS 带来的延时会话缓存虽然前文提到 HTTPS 即使采用会话缓存也要至少 1*RTT 的延时但至少延时已经减少为原来的一半是明显的延时优化同时基于会话缓存建立的 HTTPS 连接不需要服务器使用 RSA 私钥解密获取 Pre-master 信息可以省去 CPU 的消耗。如果业务访问连接集中、缓存命中率高则 HTTPS 的接入能力将明显提升硬件加速为接入服务器安装专用的 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 的性能、提高下载速度等。08 从网络模型认识 HTTPS8.1 OSI 七层与 TCP/IP 五层模型网络模型一般是指 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。8.2 TLS/SSL 在协议栈中的位置再来说 TLS/SSLSSLSecure Sockets Layer是 TLSTransport Layer Security的前身可以把它们理解成同一东西的不同阶段——该协议之前叫 SSL后来改名成 TLS 了仓库 Net网络基础概念 中的 OSI 模型对照表也印证了这一点HTTP 属于应用层TCP/UDP 属于传输层IP 属于网络层。为什么要有这种协议因为 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 的安全性并不是某一项单一技术的结果而是一套层层递进的设计为什么需要HTTP 明文、不验证身份、不校验完整性带来窃听、篡改、冒充三大风险怎么加密非对称加密RSA 等解决密钥分发与身份认证对称加密AES 等解决传输效率两者各司其职如何信任纯 RSA 方案存在中间人伪造公钥的隐患于是引入 CA 数字证书与证书链用“根证书 → 中间证书 → 服务器证书”的信任链完成身份认证如何工作完整握手流程 证书校验 协商会话密钥Pre-master 签名摘要 对称加密传输攻防视角Charles 等抓包工具正是利用“客户端信任其伪造的根证书”完成中间人解密这也反向印证了 HTTPS 在严格校验下的安全性工程落地HTTPS 有真实的延时与 CPU 开销需要通过 CDN 接入、会话缓存、硬件加速、远程解密、SPDY/HTTP2 等手段优化。结合本仓库的实践文档你可以继续深入阅读 Charles抓包步骤含 Android 证书安装与 Network Security Configuration 配置、Http基础详细分析含普通代理与隧道代理的完整区分以及 OkHttp基础知识含 HTTPS 与 HTTP 的同异点、证书颁发细节从而把本文的理论流程与真实抓包、真实客户端实现串联起来。赞分享教程技术博客文档【免费下载链接】YCBlogs技术博客笔记大汇总包括Java基础线程并发数据结构Android技术博客等等常用设计模式常见的算法网络协议知识点部分flutter笔记还包括平时开发中遇到的bug汇总当然也在工作之余收集了大量的面试题长期更新维护并且修正持续完善……开源的文件是markdown格式的转载请注明出处谢谢项目地址https://gitcode.com/gh_mirrors/yc/YCBlogs点击查看免费下载相关推荐YCBlogs 网络协议知识汇总从 DNS 解析、TCP 三次握手到 HTTPS 加密的完整体系YCBlogs 网络协议知识汇总从 DNS 解析、TCP 三次握手到 HTTPS 加密的完整体系 本篇技术指南以 YCBlogs 仓库的 blog/13.网络教程技术博客文档CANN/asc-devkit向量计算APIasc_int162half 产品支持情况 | 产品 | 是否支持 | | : | : :| | term Atlas A3 训练系列产品/Atlas A3人工智能深度学习算子库CANNAscendTLS 1.3安全协议深度剖析加密与握手过程TLS 1.3安全协议深度剖析加密与握手过程 本文深入分析了TLS 1.3协议的核心架构、安全特性和性能优化。TLS 1.3作为传输层安全协议的最新版本在协文档技术博客教程知识库创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考