sni+tomcat漏洞复现

sni

SNI产生背景

SSL以及TLS（SSL的升级版）为客户端与服务器端进行安全连接提供了条件。但是，由于当时技术限制，SSL初期的设计顺应经典的公钥基础设施 PKI(Public Key Infrastructure)设计，PKI 认为一个服务器只为一个域名提供服务，从而一个服务器上也就只能使用一个证书。这样客户端在发送请求的时候，利用DNS域名解析，只要向解析到的IP地址（服务器地址）发送请求，然后服务器将自身唯一的证书返回回来，交给客户端验证，验证通过，则继续进行后续通信。然后通过协商好的加密通道，获得所需要的内容。这意味着服务器可以在 SSL 的启动动阶段发送或提交证书，因为它知道它在为哪个特定的域名服务。

随着HTTP 服务器开启虚拟主机支持后，每个服务器通过相同的IP地址可以为很多域名提供服务。这种为虚拟主机提供通信安全的简单途径，却经常导致使用了错误的数字证书，因为服务器端无法知道客户端到底请求的是哪个域名下的服务，从而导致浏览器对用户发出警告。

不幸的是，当设置了 SSL加密，服务器在读取HTTP请求里面的域名之前已经向客户端提交了证书，也就是已经为默认域提供了服务。但是，一个服务器可能为上千个域名提供服务，不可能将所有证书都发送给客户端，让客户端一一验证，找到与请求域名对应的证书。SNI的设计目的是为了让服务器根据请求来决定为哪个域服务，这个信息通常从HTTP请求头获得。

前置环境搭建：

[root@localhost nginx]# mkdir certificate[root@localhost nginx]# cd certificate/[root@localhost certificate]# openssl genrsa -des3 -out ssl.key 4096 [root@localhost certificate]# openssl req -new -key ssl.key -out aaa.csr[root@localhost certificate]# openssl x509 -req -days 365 -in aaa.csr -signkey ssl.key  -out aaa.crt[root@localhost certificate]# openssl genrsa -des3 -out ssl2.key 4096 [root@localhost certificate]# openssl req -new -key ssl2.key -out bbb.csr[root@localhost certificate]# openssl x509 -req -days 365 -in bbb.csr -signkey ssl2.key -out bbb.crt

[root@localhost certificate]# cd /var/www/[root@localhost www]# mkdir aaa[root@localhost www]# mkdir bbb[root@localhost www]# echo "this is a" > /var/www/aaa/index.html[root@localhost www]# echo "this is b" > /var/www/bbb/index.html

修改本机hosts文件在C:\Windows\System32\drivers\etc下