从技术上讲 https://url 访问除了服务器地址被看到，其他都完全加密的是吗？

[godall]

比如 https://url?parm=1 这样访问，由于 IP 地址是 2 层的需要路由明文的，其他的 url，传参 parm 数据都是被加密的是吗？

[ruixue]

SNI 了解一下，除了 IP 地址，主机名(域名)也可以看到，后面的文件路径和参数看不到

服务器名称指示（英语：Server Name Indication，缩写：SNI ）是 TLS 的一个扩展协议，在该协议下，在握手过程开始时客户端告诉它正在连接的服务器要连接的主机名称。这允许服务器在相同的 IP 地址和 TCP 端口号上呈现多个证书，并且因此允许在相同的 IP 地址上提供多个安全（ HTTPS ）网站（或其他任何基于 TLS 的服务），而不需要所有这些站点使用相同的证书。它与 HTTP/1.1 基于名称的虚拟主机的概念相同，但是用于 HTTPS 。所需的主机名未加密，因此窃听者可以查看请求的网站。

[ch2]

你请求的域名可以看到，但是往这个域名来往发的东西，观测者看到的全是加密后的乱码
但是在你主动委托(信任证书并且将其设置为 http 代理)的情况下，观测者可以作为一个代理负责加密解密，这样他就可以看到全部内容了

[yazoox]

我们的证书，都是“所谓的第三方机构”，也就是美国的某些大公司颁发的吧？
所以，我的理解，理论上，https 的内容，对于某些“人”来说，都是可以查看的。

不知道我的理解对不对。

[baiyi]

TLS 协议握手的内容是不加密的，包括上面提到的 SNI，但是 SNI 是扩展协议，理论上没有需求是可以不用发的。

[systemcall]

@yazoox #3
至少 CDN 那边一般看得到，想要看的话
云主机的提供商也有能力看

[systemcall]

IP 和域名可以看到，别的按理来说看不到，实际上如果 mitm 的话可以看到

[chocovon]

@systemcall https 不就是防 mitm 的吗？

[lithiumii]

@yazoox 也不一定是美国的大公司

[binux]

@yazoox 不对，签发证书又不要你的私钥，怎么解密你的内容？

[weizhen199]

。。。这，好多人需要强制补习啊

[no1xsyzy]

@yazoox @binux 如果确实用的是 ICP 侧的私钥确实不能解
这里的问题是，如果证书提供商自行生成新的私钥伪造证书就可以再 sniff 了。

[eason1874]

@yazoox @binux

因为终端信任了 CA 根证书，CA 要劫持任何域名流量，自己再签一个就行了，终端访问不会有异常，不去看证书都不知道被劫持了。

前些年 wosign 劫持事件说的就是他们作为可信 CA 未经国外某些网站同意，虚假签发证书去劫持 HTTPS 流量，后来就被抵制被取消信任了。

[RickyC]

全都不是加密的吧？只是不能被抓包。

[diaryevil]

@yazoox SSL 加密过程需要一方（好像是服务端）的私钥解密，签发证书的机构不会得知你的私钥的

[no1xsyzy]

@systemcall 还有回源证书这回事儿，用回源证书的话云主机提供商不能从中间链路上截取，只能想办法读内存，这就比较混乱了。

当然回源了以后大部分人还是走本地环回或者 unix socket 来访问应用侧，不过不是 HTTP 协议，WSGI 之类的，各种协议生态比较杂，通常吃了很大力也没多少收益。

[securityCoding]

@diaryevil 是这样的 ,握手阶段的作用是得到 对称加密的密钥 ,ca 证书公钥内置到浏览器了.
客户端把对称加密密钥用 web 服务器公钥加密, 服务器用它自己的私钥解密拿到对称加密密钥

[binux]

@eason1874 要“再签”一个才能查看，而无法追溯查看过去的内容。而且你完全可以监控这个过程。

[diaryevil]

@securityCoding 哦对对对，我给忘了 SSL 握手主要是为了协商出对称密钥，多谢
然后我记得是，客户端把“预主密钥”用 web 服务器的公钥加密发送过去的过程，我记得是在 client_key_exchange 内容里的，然后两边根据“预主密钥”和两个随机数计算出共同的主密钥

[Huelse]

私钥在服务端手上，公钥随便发，
客户端拿到公钥后用公钥加密对称密钥并发给服务端，
服务端用私钥解密拿到对称密钥，然后两者就可以用对称密钥相互加密通信了

[yunyuyuan]

浏览器有内置的可信任机构列表，只认可通过这些机构颁发的证书