从技术上讲 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]

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

[zengxs]

现在有 CT 证书透明度监控，就算是 CA 想要伪造证书也很难了吧

[sujin190]

@eason1874 #12 不是再签一个就行，同时还需要流量能经过他那里，这样他才能替换证书啊，这叫中间人攻击，但首先他必须是流量的中间人，否则他就是签出花来有个啥用

[ly841000]

@eason1874 wosign 劫持张口就来??? wosign 进黑名单不是因为伪造签名时间以使用 sha1 吗???????

[dzdh]

1.SSL 证书签发不需要私钥，签发方看不到

2.CDN 需要上传私钥，能看到（废话他看不到怎么转发给你）

3.不需要考虑 CA 恶意签发证书，CDN 中间拦截的问题，因为你只能选择信任

4.当物理设备可以被控制的时候你还在考虑 SSL 安不安全？

[whee1]

@no1xsyzy #15 cloudflare 支持“无私钥（ keyless ）”模式，就是不知道国内的这些 cdn 是否支持类似的技术。这种模式估计在国内行不通吧。
keyless SSL： https://blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/

[eason1874]

@ly841000 #23 当年 wosign 是只要验证子域名，就会给根域名的证书，当然你也可以说这是他们的失误，不是他们的本意。但别人信不信，就是另一个问题。

[FucUrFrd]

@yazoox 你搞笑，中国证书机构由于管理不力不理，经常勾结公 an，所以被所有浏览器吊销证书资格，美国的管理也不力吗证据呢 360 浏览器会吊销美国公司吗

[FucUrFrd]

StartCom 和 WoSign 人类工贼，经常代理，签发诈骗和菠菜网站证书

[no1xsyzy]

@FucUrFrd 你是否还记得 [Symantec 根证书被停止][Symantec]？

[Symantec]: https://cn.starbytecomputers.com/google-will-revoke-trust-in-symantec-root-certificate

恕我中文不精，“工贼” 在这个上下文是什么含义？什么情况下会出现 “人类工贼” 的表述？

签发错误的证书（为不拥有某域名的人提供该域名的证书）是显然的失职，但签发诈骗和菠菜，那 Let's Encrypt 也这么干啊？鉴别网站性质是否合乎哪国的法律不是证书签发者的职责，阻止不合某国法律的证书也不是其义务。

[ryd994]

@whee1 keyless 也只是没有私钥，但你还是要把握手的数据给 cf，让 cf 可以解密数据
不然要 CDN 有什么用？什么都看不到，什么都控制不了，那只能全部回源

[no1xsyzy]

@FucUrFrd 另外，我记得 CNNIC 证书仍然存在于各操作系统和 Firefox 的默认根证书中，你可以查一查。
除此以外，还有 CFCA GDCA 之类的。
这些我通常删了也没什么毛病（

[SjwNo1]

如果数字证书公钥被劫持那岂不是也。

[lzlee]

这玩意肯定避免不了

只不过从之前的裸奔, 变成了少数人知道

一步一步来呗

[LukeChien]

我记得之前听说是 WoSign 签发了 gmail 的证书，被 Chrome 上报了。如果你们怕自己的域名被别的 CA 恶意签发证书，可以在 DNS 添加 CAA 记录。

[FucUrFrd]

@SjwNo1 公钥是公开的内置在 Chrome 里，除非你是山寨红芯浏览器，割韭菜专属

[damao2250]

@weizhen199 大佬开个补习班？

[Jirajine]

@no1xsyzy 这些删掉以后有些国内网站会打不开。
不过浏览器缺乏一种类似 ssh 的 trust on first use 机制，这样就导致如果哪天 wosign 这种国内 ca 如果给 GitHub 搞了劫持浏览器也不会有任何提示。

[LuciferGo]

@yazoox 好嘛，什么都美国大公司，这是已经条件反射的反美了？

[zzzmh]

这个要问是指谁看，例如我上网，我可以是可以看到服务器的传入返回参数的，一个 f12 全部看到，但例如有路由器管理权限的人，要看连在路由器上的人的数据，这就费劲了(前提是 https)

[libook]

能看到的基本上只有协议、域，这里的域是指域名+端口号，其余的就都被加密了。

在你的例子里，url 中域的部分是明文的，路径部分被加密，我举个例子：

https://baidu.com:8080/search/news?keywords=haha

这里明文的是 https 、baidu.com:8080，其他所有信息都被加密了。

[yanqiyu]

为了防止 CA 签有问题的证书被用于 mitm，于是 HSTS 有 Certificate Pinning 的扩展。