教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载本文是 tech-interview-for-developer 知识库「计算机科学 / 网络」模块的核心主题之一围绕 HTTP HTTPS.md 展开先剖析 HTTP 作为纯文本协议存在的窃听、伪装、篡改三大安全弱点再顺着 HTTPS 的 11 步通信流程讲清楚 CA 证书、公钥/私钥、pre-master-secret-key、session-key 的来龙去脉。读完本文你将能够回答面试中最常见的「为什么需要 HTTPS」「HTTPS 如何保证安全」「HTTPS 一定安全吗」等问题并具备向他人讲解 HTTPS 握手全过程的表达能力。一、HTTP基于文本交换的通信协议HTTPHyperText Transfer Protocol超文本传输协议是互联网上客户端与服务器之间交换资源的通信规则。它是应用层协议定义了请求报文与响应报文的格式承载着从网页、图片到 API 数据的全部传输工作。HTTP 的本质特点是文本交换请求和响应内容以明文形式在网络上传输。这意味着只要有人能够在网络链路上截获信号例如在 Wi-Fi 环境、ISP 链路或中间节点上抓包就能直接看到报文内容进而引发严重的安全问题。关于 HTTP 请求的完整方法体系GET / POST / PUT / DELETE / HEAD / OPTIONS / CONNECT / TRACE / PATCH 等可参考仓库中的 HTTP Request Methods.md关于响应语义的完整状态码分类2xx 成功、3xx 重定向、4xx 客户端错误、5xx 服务器错误可参考 HTTP status code.md。二、HTTP 的三大安全弱点原文档明确指出HTTP 之所以不安全是因为它同时存在以下三个可被利用的弱点1. 可被窃听EavesdroppingHTTP 以**明文평문**通信报文在网络传输过程中不经过任何加密攻击者只要在链路上截取信号即可还原内容。针对窃听的解决思路有两类对整个通信过程本身进行加密——这正是 HTTPS 的做法仅对传输的数据内容进行加密——但此时接收方在拿到数据后还需要额外的解密处理密钥管理与实现成本更高。2. 可被伪装MasqueradingHTTP 在建立通信时不验证通信对方的身份客户端无法确认与自己对话的服务器是否就是目标服务器因此存在与伪装者通信的风险。HTTPS 的应对手段是引入CACertificate Authority证书只有持有受信任 CA 签发的证书的服务器才能被客户端认定为「经过认证的通信对象」。3. 可被篡改TamperingHTTP不保证报文的完整性완전성报文在传输途中可能被中间人修改而不被察觉。HTTPS 通过MACMessage Authentication Code消息认证码与电子签名Digital Signature等机制检测报文是否被改动从而抵御篡改。这三条弱点对应的解法正好构成 HTTPS 的核心设计目标机密性Confidentiality 身份认证Authentication 完整性Integrity。可对照仓库中的 CSRF XSS.md 理解「即使传输加密应用层攻击依然存在」的现实——加密解决的是传输链路安全并不能替代 Web 应用自身的安全防护。三、HTTPS在 HTTP 之上叠加 SSL/TLS 加密HTTPSHyperText Transfer Protocol Secure使用SSLSecure Sockets Layer协议对传输的信息进行加密是「HTTP SSL/TLS」的叠加方案也是 HTTP 三大弱点的系统性解药。HTTPS 对文本进行加密采用的正是公钥加密非对称加密方式。要理解 HTTPS 的完整流程需要先掌握两类加密算法的区别仓库中的 대칭키 공개키.md 对此有专门讲解算法类型加密/解密密钥优点缺点对称密钥Symmetric Key加解密使用同一个密钥速度非常快密钥分发过程中易遭窃取密钥分配困难公钥/非对称密钥Asymmetric Key加密用公钥、解密用私钥二者分离解决了对称密钥的分配难题只需公开公钥加解密运算非常复杂、速度慢由于对称加密快而公钥加密慢HTTPS 并没有全程使用公钥加密而是采用了混合hybrid方案只在交换对称密钥的阶段使用公钥加密之后的数据通信全程使用对称加密。原文档给出的混合流程如下A 用 B 的公钥加密通信要使用的对称密钥并发送给 BB 收到密文后用自己的私钥解密得到对称密钥B 用该对称密钥加密发给 A 的报文A 用自己的对称密钥解密密文此后双方一直用这个对称密钥进行加密通信。这套「用公钥加密传递对称密钥、用对称密钥加密业务数据」的混合思路正是SSL 诞生的起点也是下面 HTTPS 通信流程的理论基础。四、HTTPS 通信完整流程11 步详解原文档给出了 HTTPS 从证书申请到会话密钥建立的全过程这是本文的核心以下按步骤完整展开。阶段 A服务器的密钥对与证书申请第 13 步生成密钥对应用服务器记为 A的所属企业为了应用 HTTPS先自行生成一对密钥——公钥public key与私钥private key。私钥严格保存在服务器本地公钥则用于对外加密通信。选择并委托 CA企业选择一家可信的 CA 机构签订合同把公钥交给 CA 托管与管理。CA 是什么CA 即Certificate Authority证书颁发机构是经过公信力验证、为服务器存储并签发公钥的民间企业。CA 的角色本质是「公证人」为服务器身份做担保。CA 签发证书签约完成后CA 制作一张证书certificate其中包含三样关键信息该企业的名称、A 服务器的公钥、公钥的加密方法。随后 CA 用自己的私钥对这张证书进行签名加密再交给 A 服务器持有。阶段 B证书下发与客户端验证第 46 步服务器持有证书A 服务器获得被 CA 私钥签名过的证书。此后当客户端发来的不是「用 A 的公钥加密的 HTTPS 请求」时A 服务器就把这份加密证书交给客户端。客户端收到证书假设客户端向 A 服务器请求main.html文件。由于该请求不是 HTTPS 请求客户端收到的响应中会附带这份「由 CA 私钥加密、内含 A 服务器信息」的证书。关键前提CA 的公钥浏览器早已内置。因为 CA 是全球公认的可信机构浏览器预置了它们的公钥所以在拿到证书后浏览器可以自行搜索并尝试解密——这正是证书链信任的起点。客户端解密取得公钥浏览器用内置的 CA 公钥成功解密证书校验其有效性后从中获得了A 服务器的公钥。阶段 C密钥协商与会话建立第 711 步生成并加密 pre-master-secret-key客户端在与服务端的握手过程中双方各自生成随机数난수。客户端将这些随机数组合生成pre-master-secret-key预主密钥然后用第 6 步得到的 A 服务器公钥对其加密发送给服务器。服务器解密取得同一密钥A 服务器用自己的私钥解密收到的密文得到与客户端一致的 pre-master-secret-key。派生 master-secret-key客户端与服务器各自将 pre-master-secret-key 加工生成master-secret-key主密钥——这一步是本地计算双方无需再传输该密钥本身。生成 session-key 并开始对称通信双方基于 master-secret-key 生成session-key会话密钥此后所有业务数据都用这把对称密钥进行加密通信对称加密阶段速度快、开销小。会话结束销毁密钥每次通信结束时双方都会销毁本次使用的 session-key下一次会话重新协商从而保证密钥的时效性降低长期使用同一密钥带来的泄露风险。流程要点小结全程只有公钥在网络上传递客户端 → 服务器方向被公钥加密的 pre-master-secret-key私钥始终不离开服务器窃听者即使截获全部报文没有服务器私钥就无法还原 pre-master-secret-key也就无法推导出 session-key业务数据依然不可读混合加密让「非对称加密建立信任、对称加密保证性能」各司其职。五、从 11 步流程看 TLS/SSL 握手原文档的流程本质上是TLS HandshakeTLS 握手的通俗化描述。仓库中的 TLS HandShake.md 以更标准的术语还原了同一条链路可与上文互相对照客户端发送client hello携带协议版本、支持的密码套件암호 알고리즘、压缩方式等信息服务器回应server hello附带会话 ID 与CA 公开证书证书内含后续握手阶段用于加密的公钥客户端在本地 CA 列表中校验服务器证书的有效性信任确认后客户端生成随机字节用服务器的公钥加密后发送对应 11 步流程中的第 7 步该随机字节将用于确定对称密钥若服务器在第 2 步要求客户端证书双向 TLS客户端需同时发送自己的证书以及用客户端私钥加密的随机字节串服务器用私钥解密随机字节参与对称主密钥的生成客户端发送finished消息并把此前所有交换内容做哈希后以对称密钥加密一并发出服务器对交换内容做同样哈希并比对一致后同样以刚建立的对称密钥加密发送finished客户端用对称密钥解密并确认对方可信此后双方即用该对称密钥传输数据。由此可见HTTPS 的握手既完成了身份认证证书校验也完成了密钥协商pre-master-secret → master-secret → session-key是原文档 11 步流程在协议层面的规范形态。在此基础上HTTPS 的可靠性还依赖 TCP 连接的成功建立可进一步阅读仓库中的 TCP 3 way handshake 4 way handshake.md 理解传输层连接建立与释放机制。六、HTTPS 也并非绝对安全原文档特别强调了一个容易被忽略的事实HTTPS 并不保证 100% 安全。典型场景是当服务器使用的是非受信任 CA 签发的自签名证书self-signed certificate时浏览器无法在内置 CA 列表中完成校验。此时尽管地址栏显示的是 HTTPS浏览器仍会弹出주의 요함注意、안전하지 않은 사이트不安全的站点等警告提示用户该连接不受信任。这类情况下的 HTTPS 只保证了「传输被加密」却没有完成「身份可信」的验证——攻击者完全可以用自己伪造的证书建立一条加密通道使加密本身失去意义。因此判断 HTTPS 是否可靠除了看协议更要看证书链是否由受信任 CA 签发。七、面试要点速查HTTP 与 HTTPS 的本质区别HTTP 明文传输、无认证、无完整性校验HTTPS 通过 SSL/TLS 加密、以 CA 证书完成身份认证、以 MAC/数字签名保证完整性。三大安全弱点及其对策窃听 → 通信加密伪装 → CA 证书认证篡改 → MAC 与电子签名。混合加密策略公钥加密只用于安全分发对称密钥业务数据始终用对称加密兼顾安全与性能。密钥派生链路客户端随机数 服务端随机数 → pre-master-secret-key → master-secret-key → session-key会话结束即销毁 session-key。CA 的角色受信任的第三方机构用自己的私钥签发服务器证书浏览器预置 CA 公钥完成验签从而建立对服务器身份的信任。HTTPS 的局限自签名证书或不受信任 CA 签发的证书无法通过浏览器校验即使协议是 HTTPS 也会被标记为不安全。如需继续深入可依次阅读仓库中的 대칭키 공개키.md加密算法基础、TLS HandShake.md握手协议细节、HTTP Request Methods.md 与 HTTP status code.mdHTTP 语义体系以及 Cookie Session.md 理解 HTTPS 之上的会话状态管理从而构建完整的网络与安全知识闭环。赞分享教程知识库【免费下载链接】tech-interview-for-developer 신입 개발자 전공 지식 기술 면접 백과사전 项目地址https://gitcode.com/GitHub_Trending/te/tech-interview-for-developer点击查看免费下载相关推荐TLS/SSL Handshake 全流程详解HTTPS 连接建立与证书信任链tech-interview-for-developerTLS/SSL Handshake 全流程详解HTTPS 连接建立与证书信任链tech interview for developer TLS/SSL H教程知识库Claude Code Router加密传输TLS/SSL安全通信配置Claude Code Router加密传输TLS/SSL安全通信配置 ? 安全通信的重要性 在现代AI应用开发中Claude Code Router作为L后端API网关LLM 网关大模型Front-end-Developer-Interview-Questions网络篇HTTP、HTTPS、CORS面试重点解析Front end Developer Interview Questions网络篇HTTP、HTTPS、CORS面试重点解析 想要在前端面试中脱颖而出掌握教程前端上一篇Python小红书数据采集入门指南3分钟掌握xhs工具核心用法下一篇怎样高效采集小红书数据5个实战技巧掌握Python开源工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考