HTTPS原理详解


=Start=

缘由:

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

正文:

参考解答:

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

参考链接:

=END=

,

《“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。安全性就更强了。
    `

  2. 三种解密 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 来解决。
    `

  3. 通过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 搜索支持的域名。
    `

  4. 应用层传输安全
    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 协议
    ____* 握手协议
    ____* 记录协议
    ____* 会话恢复
    * 权衡
    ____* 密钥泄露伪装攻击
    ____* 握手消息的隐私
    ____* 完全正向加密
    ____* 零往返恢复
    * 其他参考信息
    * 脚注
    `

  5. 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

  6. 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指纹作为一种流量识别的手段,作为一种辅助措施,应用于流量安全、风险控制等场景。
    `

  7. 以前感觉 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 历史帖,发现是同步公司代码到个人手机的拿位。。
    `

  8. 攻防对抗之如何检测加密流量?| 总第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:可能做的是流量周边特征识别或者类似技术,给出一些可疑告警,而不是密文内容的识别。

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

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

  9. 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流量。
    `

  10. 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.
    `

回复 hi 取消回复

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