ASPIRE

HTTPS原理详解

=Start=

缘由：

想深入了解一下HTTPS的原理，方便以后给别人讲解。

正文：

参考解答：

主要内容是参考的「图解HTTPS」这一篇文章，虽然讲的比较简单，但大部分的知识点都已经提到了，作为一般科普性的了解已经完全够了；如果想要进一步了解的话，推荐阅读Bugly社区的文章「全站HTTPS来了」；如果想要了解HTTPS对性能的影响，可以参考百度运维的文章「大型网站的 HTTPS 实践（二）——HTTPS 对性能的影响」；可以参考一下imququ的「关于启用 HTTPS 的经验分享」系列文章进行学习。

参考链接：

=END=

admin

,

《 “HTTPS原理详解” 》 有 15 条评论

  1. 聊聊 HSTS 下的 HTTPS 降级问题
    http://www.barretlee.com/blog/2017/04/01/hsts-downgrade/
    `
    HSTS 的作用是为了在用户通过 HTTP 访问网站时不需要服务器做 301/302 跳转，直接一个 307 本地强制使用 HTTPS 访问网站，这可以防止用户在第一次发出请求时被劫持，也减少了一次请求。
    HSTS 是服务器（如 Nginx）通过一个 Strict-Transport-Security 请求响应头写入到客户端的，所以用户至少要访问一次这个网站，HSTS 才会生效。HSTS 还可以申请内置到浏览器中，Chrome 维护了 HSTS Preload List 名单，允许用户在从未访问某网站的情况下，第一次访问时就自动使用 HTTPS。安全性就更强了。
    `

    回复

  4. HTTPS 可能被这样劫持吗？
    https://www.zhihu.com/question/22795329

    HTTPS 中间人攻击及其防范
    https://segmentfault.com/a/1190000013075736

    HTTPS原理以及HTTPS中间人攻击
    https://ifunbox.top/security-https-and-MITM

    浅析HTTPS中间人攻击与证书校验
    http://www.droidsec.cn/%E6%B5%85%E6%9E%90https%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB%E4%B8%8E%E8%AF%81%E4%B9%A6%E6%A0%A1%E9%AA%8C/

    HTTPS原理以及HTTPS中间人攻击
    https://blog.blogbins.com/2018/07/13/https%E5%8E%9F%E7%90%86%E4%BB%A5%E5%8F%8Ahttps%E4%B8%AD%E9%97%B4%E4%BA%BA%E6%94%BB%E5%87%BB/

    常见的HTTPS攻击方法 | WooYun知识库
    https://drops.secquan.org/tips/4403

    Android安全开发之安全使用HTTPS
    https://zhuanlan.zhihu.com/p/24093848

    浅析SSL SSH加密原理
    https://endlesslethe.com/simple-introduction-to-ssl-ssh-encryption.html

    回复

  5. 三种解密 HTTPS 流量的方法介绍
    https://imququ.com/post/how-to-decrypt-https.html
    `
    Man-in-the-middle
    RSA Private Key
    SSLKEYLOGFILE
    # 总结
    Fiddler 这类工具通过往系统导入根证书来实现 HTTPS 流量解密，充当中间人角色。要防范真正的 HTTPS 中间人攻击，网站方需要保管好自己的证书私钥和域名认证信息，为了防范不良 CA 非法向第三方签发自己的网站证书，还要尽可能启用 Certificate Transparency、HTTP Public Key Pinning 等策略；用户方不要随便信任来历不明的证书，更不要随意导入证书到根证书列表，还要养成经常检查常用网站证书链的习惯。

    RSA 密钥交换没有前向安全性，这意味着一旦私钥泄漏，之前所有加密流量都可以解开。为此，网站方需要启用使用 ECDHE 作为密钥交换的 CipherSuite，或者直接使用 ECC 证书；用户方需要弃用不支持 ECDHE 的古董操作系统及浏览器。

    对于浏览器而言，HTTPS 毫无秘密，通过浏览器生成的 SSLKEYLOGFILE 文件，Wireshark 可以轻松解密 HTTPS 流量。另外，如果浏览器被安装恶意扩展，即使访问安全的 HTTPS 网站，提交的数据一样可以被截获。这种客户端被攻击者控制引发的安全问题，无法通过 HTTPS 来解决。
    `

    回复

  7. 通过HSTS实现浏览器自动跳转https（非服务器响应跳转）
    http://www.rootop.org/pages/4514.html
    https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/
    `
    全称 HTTP Strict Transport Security

    HSTS目的是让浏览器在访问网站的时候浏览器内部自动实现https协议访问（不需要服务器告诉浏览器跳转https）。
    在没有hsts功能时，需要自己在nginx里配置http跳转https。
    但是这样每个请求（可能）都需要nginx告诉浏览器你访问的地址需要跳转到https，这样就浪费了时间。

    hsts需要在第一次访问https时，服务器返回一个指定的响应头，用于告诉浏览器你可以用hsts功能。
    然后后续的访问都会自动走https，而不需要跳转了（浏览器内部自己跳转）。

    nginx配置：
    # 首先配置 http跳转https
    if ($scheme = http) {
    return 301 https://$host$request_uri;
    }

    # 添加hsts响应头，可以在server{}段，或者location中。
    add_header Strict-Transport-Security “max-age=86400; includeSubdomains; preload”;

    chrome浏览器里可以通过访问： chrome://net-internals/#hsts 搜索支持的域名。
    `

    回复

  8. 应用层传输安全
    https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security?hl=zh-cn
    https://cloud.google.com/security/encryption-in-transit/application-layer-transport-security/resources/alts-whitepaper.pdf?hl=zh-cn
    `
    * 面向首席信息官级别领导人的摘要
    * 简介
    * 应用级安全与 ALTS
    ____* 为什么不选择 TLS？
    ____* ALTS 设计
    * ALTS 信任模型
    ____* ALTS 凭据
    ____* ALTS 政策执行
    ____* 证书撤消
    * ALTS 协议
    ____* 握手协议
    ____* 记录协议
    ____* 会话恢复
    * 权衡
    ____* 密钥泄露伪装攻击
    ____* 握手消息的隐私
    ____* 完全正向加密
    ____* 零往返恢复
    * 其他参考信息
    * 脚注
    `

    回复

  9. HSTS详解｜洞见
    https://mp.weixin.qq.com/s/ztMN2T6bpmvGfNNGigE3OA
    `
    既然建立HTTPS连接之前的这一次HTTP明文请求和重定向有可能被攻击者劫持，那么解决这一问题的思路自然就变成了如何避免出现这样的HTTP请求。我们期望的浏览器行为是，当用户让浏览器发起HTTP请求的时候，浏览器将其转换为HTTPS请求，直接略过上述的HTTP请求和重定向，从而使得中间人攻击失效，以规避风险。

    第1步：用户在浏览器地址栏里输入网站域名，浏览器得知该域名应该使用HTTPS进行通信
    第2步：浏览器直接向网站发起HTTPS请求
    第3步：网站返回相应的内容

    那么问题来了，浏览器是如何做到这一点的呢？它怎么知道哪个网站应该发HTTPS请求，哪个网站应该用HTTP请求呢？此时就该HSTS闪亮登场了。

    HSTS的全称是HTTP Strict-Transport-Security，它是一个Web安全策略机制（web security policy mechanism）。

    HSTS最为核心的是一个HTTP响应头（HTTP Response Header）。正是它可以让浏览器得知，在接下来的一段时间内，当前域名只能通过HTTPS进行访问，并且在浏览器发现当前连接不安全的情况下，强制拒绝用户的后续访问要求。

    =

    细心的你可能发现了，HSTS存在一个比较薄弱的环节，那就是浏览器没有当前网站的HSTS信息的时候，或者第一次访问网站的时候，依然需要一次明文的HTTP请求和重定向才能切换到HTTPS，以及刷新HSTS信息。而就是这么一瞬间却给攻击者留下了可乘之机，使得他们可以把这一次的HTTP请求劫持下来，继续中间人攻击。

    Preload List：让防御更加彻底

    针对上面的攻击，HSTS也有应对办法，那就是在浏览器里内置一个列表，只要是在这个列表里的域名，无论何时、何种情况，浏览器都只使用HTTPS发起连接。这个列表由Google Chromium维护，FireFox、Safari、IE等主流浏览器均在使用。
    `

    HSTS 详解，让 HTTPS 更安全
    https://mp.weixin.qq.com/s/GpxxHfUvuFpA0hcP_sEYPg

    回复

  10. JA3 is a standard for creating SSL client fingerprints in an easy to produce and shareable way.
    https://github.com/salesforce/ja3

    利用JA3和JA3S实现TLS指纹识别
    https://xz.aliyun.com/t/3889

    TLS Fingerprinting with JA3 and JA3S
    https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/

    JA3 Fingerprint
    https://developers.cloudflare.com/bots/concepts/ja3-fingerprint/

    v2ray的TLS流量可被简单特征码匹配精准识别（附PoC) #704
    https://github.com/v2ray/discussion/issues/704

    The use of TLS in Censorship Circumvention
    https://tlsfingerprint.io/static/frolov2019.pdf

    `
    # 什么是TLS指纹

    TLS指纹指的是服务器或客户端在进行TLS握手过程中的某种特定的、可以识别的行为模式，可以分为客户端指纹和服务器指纹两种。客户端/服务器支持的加密套件列表、压缩算法列表和扩展方法，因各平台和框架的实现与偏好不同而不同，形成了显著的差异，从而可以被追溯和跟踪。

    TLS指纹是由 ClientHello 和 ServerHello 的特定区域形成的，那么通过对这些特定的区域进行加工和处理（例如使用散列算法对这些区域进行演算），我们就能实现给定一个 ClientHello/ServerHello 数据包，或者给定一个经过的TLS数据流，我们就能算出它的指纹。

    业界常用的TLS指纹计算规则是由Salesforces公司提出的JA3（https://github.com/salesforce/ja3），基于MD5哈希算法，将形态各异的数据包统一变成一个32位的十六进制字符串，例如Tor洋葱浏览器的TLS指纹是e7d705a3286e19ea42f587b344ee6865等。对于JA3指纹，在GitHub上有一些公开的数据，也有一个叫做JA3er的网站（https://ja3er.com）提供指纹的在线查询和数据下载等操作。

    TLS指纹有以下几个特点：

    1. 不同编程语言的软件的TLS指纹一般不同。例如，用Java写的程序在进行TLS网络请求时，它发出的ClientHello包的对应部分就会与Python写的程序的部分有所不同，其根本原因是各个语言的基础设施差异；

    2. 同一软件的不同版本的TLS指纹也可能不同。例如，Chrome低版本的TLS指纹会与Chrome高版本的指纹不同，Firefox低版本的指纹会与Firefox高版本的指纹不同，其根本原因在于技术的更迭以及密码学等的进步；

    3. TLS指纹具有隐蔽性和持久性。例如，即使作弊者使用了IP代理池等技术，只要作弊者没有意识到TLS指纹这件事情（就像刚刚我们在面试题里没有意识到还有HTTPS那样），TLS指纹是不会变的。

    根据TLS指纹的这几个特性，我们可以将TLS指纹作为一种流量识别的手段，作为一种辅助措施，应用于流量安全、风险控制等场景。
    `

    回复

  11. 以前感觉 HTTPS 很安全，现在有一点点改变看法了。
    https://www.v2ex.com/t/922534
    `
    topic:
    HTTPS 安全是因为有 SSL 加密，网管直接抓包是看不到具体内容的。

    但是，我发现 chrome 会把很安全的 SSL 密钥导出到明文，仅仅只需要设置一个系统环境变量(SSLKEYLOGFILE)，就能轻易做到！

    这意味着，公司网管只要在我机器上简简单单配置一个环境变量，我电脑上 chrome 浏览的所有网站，用户密码，他都能直接看到。并且 chrome 浏览器毫无风险提示信息，让人非常没有安全感。

    answers:
    这压根不是 HTTPS 的职责范围。你都突破物理隔离了，即便不用环境变量装个抓包证书就可以吧，或者替换个加了后门的魔改版浏览器也可以吧。

    HTTPS 有效的前提是你信任你的浏览器和操作系统。
    ==
    公司的电脑，装 1 ～ 2 个普通的网管监控软件是很正常的。电脑算公司的财产，不是完全个人所有。

    还有些公司用的是瘦客户端，更没有主导权了。

    我是觉得 chrome 不应该把密钥那么重要的东西，就直接静默导出，至少弹出一个确认对话框吧。
    ==
    你都装监控软件了，不加这个变量，直接给你套个 Charles 不是一样的吗？
    ==
    Chrome 确实有些设计不合理的地方，不过你要知道，它只是个浏览器，这就决定了它的安全性设计仅满足于浏览器本身的需求。
    所以涉及到敏感信息的情况，我通常不会使用普通浏览器，比如密码管理。

    不过不管怎么说，你讲的也都不属于 HTTPS 的功能范围。安全向来都是相对而言的，还是得自己了解其中的原理，然后再根据需求慎重决策。
    ==
    设备都已经受控了，HTTPS 再牛逼也保不住你啊…
    ==
    IE 确实不会导出到明文，因为为了看你的通信内容，监控软件压根就不需要 SSL 密钥。。。
    ==
    如果是中间人代理，我反倒不怕，在 chrome 看一下网站根证书就知道是被监控了。

    我怕的是在自己不知情的时候，被监控。

    以前看 HTTPS 文档有说到，内存里的握手密钥，在建立连接后，都是需要马上销毁的，chrome 怎么还能保存到明文呢，真是晕过去。
    ==
    ssl 确实不安全，只要有人拿刀架我脖子上，我啥都说了。
    ==
    你都装监控软件了，还费什么劲拿 SSL ，直接监控你屏幕，直接 hook 你浏览器拿网页，有的是办法搞你。
    你能说出这话说明你完全没理解 HTTPS 安全在哪里。
    ==
    不来个 LD_PRELOAD 呢
    ==
    https 是个通信协议，跟你本地安全不安全和这个有啥关系，你能都在 client 端操作了，基本就是所见即所得。导出 SSLKEYLOGFILE 只不过是 ssl 库的一个方便本地抓包调试的特性罢了。 你认真说的话，在客户端那没啥安全的了，就算没有 SSLKEYLOGFILE 也能有 100 种方法获取到你的通信内容，用 epbf hook 系统调用，一切皆可见。
    ==
    翻完帖子才明白楼主说的是 https 中的协商出来的对称加密密钥可以导出来

    感觉楼主确实没太理解 https ，https 安全的前提是设备必须安全可信，没有这个前提，哪来的安全

    你提的问题只能表明 Chrome 不安全，而不是 https 不安全

    另外，苹果手机加密，如果加密过程中也像 Chrome 能导出密钥或者留有后门什么的，一样也是不安全的，并不存在什么绝对安全……
    ==
    本地安全关 https 什么事，人家保障的通信链路的安全，退一万步讲，这是浏览器的策略，和 https 也完全不搭边
    ==
    楼主理解错了安全
    以及 https 的安全

    https 保护的是网络中传输的安全问题
    并不保护你电脑本地的数据安全

    你说的问题是你电脑本地的安全

    一个整体安全的系统,是由多个安全模块共同组成的
    每个模块之间往往也是安全漏洞容易爆发的点

    根签名也可以直接给伪装网站发签名
    你作为终端用户也不是一下子就可以看穿,chrome 也没提示的

    所以无论如何也是需要时刻警惕的
    ==
    看 title 还以有 zero day
    看到内容
    ……
    sslkeylogfile 又不是近期才加上的，已存在多少年的旧手法。。

    OP 说 IE 安全？
    …… Windows schannel 了解下，同样 client 无感拿 exchange key

    大型软件的功能都置有 access point ，能接触到 terminal 做任何安全都没用，总有手段拿出来，没绝对的手法
    况且窃取 TLS 在 server/client 有多种，远不止于当前，dump memory/function hooking 等等很多无感的方法，都有成熟的工具，IT 要搞你，手法千千万

    回复前翻了下 OP 历史帖，发现是同步公司代码到个人手机的拿位。。
    `

    回复

  12. 攻防对抗之如何检测加密流量？| 总第206周
    https://mp.weixin.qq.com/s/cOuYGWfB3xE76NmEKvYjKA
    `
    话题：目前大家加密流量怎么检测的？效果如何？

    A1：https协议，统一在dmz区用NGinx进行ssl加解密，后端业务区流量http，但是别的协议加密难搞，报文加密也难受，最常见是APP的sign加密，现在头疼的是应用级别字段级的加密，完全无解，只能靠rasp来解决。

    Q：业务区http流量过WAF么？

    A2：过，现在有两种方案在测试，一是用商业产品放在在卸载设备后面防护http数据，二是某家免费waf，集成waf和nginx反代理。

    A3：我们是第一种，卸载后的流量进出业务区都过waf。如果不考虑拦截，只检测，过了前置，用NTA之类的看就行了。

    A4：我们用的某家商业waf，出现了误报但没有记录log的事件，比较离谱，所以没办法才去看其它方案：
    有条件推荐SSLO，核心就两个功能，流量编排+证书卸载或加载。
    条件不允许，就在边界负载均衡处做证书卸载。如果边界没有负载均衡产品，就用nginx这类做证书卸载，或者用waf做。如果不是DH这类算法，探针加载证书也行。

    A5：国内自主可控产品也有支持SSL卸载的网关/负载均衡产品，我们用了有两三年。

    A6：加密流量解密对抗是大家的痛点，以下几种方案供参考：
    **
    * 基础组件完备，直接用一套大nginx和根证书解流量。
    * 不支持统一架构，但证书相对统一或可收集，可以收集到一些安全产品（waf、nginx等做统一卸载，内网明文）。
    * 架构不统一，证书难收集，nids上加载能收集到证书，能覆盖多少是多少。
    * 什么都不健全，套用hids探针，能抓一小部分，不过性能问题不会很理想。
    **

    A7：技术上有把证书托管到安全设备的做法，产品也都支持。我看到有些安全厂家在预研究通过在主机部署agent方式，去提取https流量密钥，这样避免部分场景无法通过证书解密。

    A8：我们目前是互联网边界LTM统一卸载，进来后一方面以代理方式发给WAF检测防护，另一方面由TAP搜集相关流量汇总后发给探针检测。

    本地数据中心的加密流量检测好弄一点，云上出站的加密流量检测更不好弄。对于出站，我们做了白名单，能控制一些风险，如果在白名单内的加密流量暂时没有好的办法了。

    A9：个人理解和大家都差不多，入的话两个途径。一般是边界卸载解密，上流量检测设备。二是上了云原生那套的，内部一般有个流量劫持代理，在进送容器前检测例如蚂蚁的mson，出向的话，搞代理检测（出向的确没什么好办法，一般都是白名单了）。

    Q：国密改造后，我们有部分流量直接从客户端到服务端是报文加密的，服务器端去调密管平台解密，客户端到服务端就确实没法监测，有啥好方法？

    A10：看到一些加密流量检测产品方案，没实际使用。

    Q：这技术的检测能力在日常安全运营上有流量威胁检出率的提升吗？

    A11：得实际试试，比较考验主机终端安全的运营能力，要能快速定位排查。

    A12：个人觉得这样玩没戏。加密流量的外围检测，一般是用在监管那种，大概率隔靴搔痒。有这个功夫，把流量解密，得到的收益高多了。就是NSA/CIA，也在拼命想办法做解密功夫，**旁路加密检测属于有余力的非主要路径**。

    A13：一些厂商的产品可以拿来测一测，之前了解过一些关于加密流量特征检测技术的学术性，一直比较好奇实际的收益。

    A14：可能做的是流量周边特征识别或者类似技术，给出一些可疑告警，而不是密文内容的识别。

    **感觉加密流量监测，不解开密文，单单靠猜流量的行为，实际效果有限**，加密协议随时可能变，例如我们的商密，你原来学习到的那些行为模型完全就失效了。

    说白了是发现已知加密流量工具。对那些常见的黑客工具的流量传输特征好像做了检测模型。
    `

    回复

  13. SSLKEYLOGFILE
    https://everything.curl.dev/usingcurl/tls/sslkeylogfile
    `
    Support for SSLKEYLOGFILE is provided by libcurl itself – making it possible for you to trace and inspect the TLS network data for any application built to use libcurl – not just the curl command line tool.
    libcurl 本身提供了对 SSLKEYLOGFILE 的支持——这使得您可以跟踪和检查任何使用libcurl构建的应用程序的TLS网络数据——而不仅仅是curl命令行工具。

    限制-Restrictions
    The support for SSLKEYLOGFILE requires that curl was built with a TLS backend that supports this feature. The backends that support SSLKEYLOGFILE are: OpenSSL, libressl, BoringSSL, GnuTLS and wolfSSL.
    If curl was built to use another backend, you cannot record your curl TLS traffic this way.

    对SSLKEYLOGFILE的支持要求curl使用支持该特性的TLS后端构建。支持SSLKEYLOGFILE的后端有:OpenSSL、libressl、BoringSSL、GnuTLS和wolfSSL。
    如果curl构建为使用另一个后端，则不能以这种方式记录curl TLS流量。
    `

    回复

  14. K50557518: Decrypt SSL traffic with the SSLKEYLOGFILE environment variable on Firefox or Google Chrome using Wireshark
    https://my.f5.com/manage/s/article/K50557518

    Decrypt SSL traffic with the SSLKEYLOGFILE environmental variable
    https://www.youtube.com/watch?v=CMbehohHj7c

    K10209: Overview of packet tracing with the ssldump utility
    https://my.f5.com/manage/s/article/K10209

    How to Decrypt SSL using Chrome or Firefox and Wireshark in Linux
    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wkvECAQ

    TLS Decryption
    https://wiki.wireshark.org/TLS
    `
    Wireshark supports TLS decryption when appropriate secrets are provided. The two available methods are:

    * Key log file using per-session secrets (#Usingthe (Pre)-Master Secret).
    * Decryption using an RSA private key.
    `

    Wireshark and SSL/TLS Master Secrets
    https://docs.mitmproxy.org/stable/howto-wireshark-tls/

    Welcome to sslkeylog’s documentation!
    https://sslkeylog.readthedocs.io/en/latest/
    https://github.com/segevfiner/sslkeylog
    `
    This is an implementation of the SSLKEYLOGFILE facility, available in Firefox and Chromium/Google Chrome, that is supported by Wireshark in order to decrypt SSL/TLS connections even when you don’t have the private key, or when using key exchange methods that will prevent decryption even if you do (Such as Diffie-Hellman).

    This is for the standard library ssl module, it won’t work for other ssl modules.
    `

    回复

  15. TLS/SSL overview (Schannel SSP)
    https://learn.microsoft.com/en-us/windows-server/security/tls/tls-ssl-schannel-ssp-overview

    Overview of TLS – SSL (Schannel SSP)
    https://learn.microsoft.com/en-us/windows-server/security/tls/what-s-new-in-tls-ssl-schannel-ssp-overview

    Decrypting Schannel TLS traffic. Part 1. Getting secrets from lsass
    https://b.poc.fun/decrypting-schannel-tls-part-1/

    Decrypting Schannel TLS traffic. Part 2. Session resumption
    https://b.poc.fun/decrypting-schannel-tls-part-2/

    About HTTPS, SChannel, TLS, CAPI, SSL Certificates and their keys
    https://techcommunity.microsoft.com/t5/iis-support-blog/about-https-schannel-tls-capi-ssl-certificates-and-their-keys/ba-p/815200

    截获TLS密钥——Windows Schannel
    https://www.freebuf.com/articles/network/262202.html
    https://cloud.tencent.com/developer/article/1799041

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注