@RE 年轻人脾气不要这么差，小心以后出去吃大亏。。

另外你还是仔细看下我下面说的内容吧，没准可以帮到你。

端口和协议所在的层级都不一样，

我顺便详细说明下吧，可能我的表达也不是很清楚

首先科普下上面为什么说 端口 和 协议 是不同层级。
首先，端口是承载信息传递的一个通道，而 协议 是传输信息的一个规范。
通俗点比喻就是，你用 QQ 跟别人聊天，双方用的是英语，还是法语还是中文。
QQ 就可以类比为端口，使用的语言就可以比喻成协议

对于一个 IP ，只要监听了端口，那么就可以传输数据，比如说之前 https://www.v2ex.com/t/348752 说的， 80 端口也可以传输非 HTTP 数据。
好了，前提结束。

我的假设是，服务器支持 SNI ，且已经有线上的业务、域名有有效证书，能提供正常的 HTTPS 服务，那么此时 443 端口是通的，且能正常服务的（标准 HTTPS 协议）。
那么对于原始 HTTPS 协议，也就是 HTTP over SSL/TLS ，此时的服务端是无脑返回设置的证书，也就是 a.a.com 的证书，此时不存在一个 IP 对应多个 HTTPS 证书。所以也就可以做到 @RE 所说的不监听 443 端口。

但是问题在于，现在 SNI 出现了，在 TLS 加密握手之前，会传输一个 common name ，也就是所谓的 host name 。然后服务端根据 host 来确定返回哪个证书。这时候， IP 和证书的关系就变成了 一对多 关系。
所以阿里的这个规则就有问题了，也就是 @just1 说的 default_server 的问题。

我们这个场景， a.a.com 是正常服务的，说明服务端已经监听了 443 端口。而此时通过 443 端口访问 b.b.com 的时候，服务端会因为找不到该 common name 对应的证书，从而返回默认证书。
这个根据不同的服务端不同，比如说 Apache2.0 时代是按照 Host name 排序，返回第一个 Host 。而 Apache2.2/2.4 Nginx 以及衍生发行版，则是采用载入配置的第一个 host 最为默认的 default server 。


所以这时候问题就产生了，因为服务器返回了一个不是 b.b.com 的有效证书（包括 common name 不匹配 和 证书不受信任）。

我想说的是这么个问题。

至于对于某位同学，我是觉得，如果有解决方法不妨分享出来，没必要搞针对攻击。大家都是在讨论这个问题而已。