[发明专利]基于TLS协议SNI机制实现自定义代理隧道协议的方法

说明书

本发明公开的基于TLS协议SNI机制实现自定义代理隧道协议的方法，包括以下步骤：1)客户端向代理服务端发送握手请求要求SSL握手，并通过服务器扩展项来指明真实服务器地址及协议类型；2)代理服务端对服务器扩展项进行解析，并对解析结果的类型进行检测，若符合要求，则将该连接打上标记，并将解析结果进行存储；3)客户端向代理服务端发起HTTP业务请求；4)代理服务端检测该HTTP业务请求所在的连接是否存在标记，若存在，则对访问目标进行修改，将解析结果与当前请求的路径地址进行拼接得到真实的服务地址。本发明实现基于TLS协议SNI机制，解决了原有自定义代理隧道协议带来协议复杂性问题。

技术领域

本发明涉及网络通讯协议技术领域，尤其涉及一种基于TLS协议SNI机制实现自定义代理隧道协议的方法。

背景技术

在WEB世界中，代理技术被广泛使用，其中正向代理便是代理技术中的一种，所谓正向代理是指代理服务器位于客户端和真实服务器之间，为了从原始服务器获取内容，客户端向代理服务器发送请求并指定真实服务器地址，然后由代理服务器向真实服务器转发请求并将获取的响应内容返回给客户端。然而使用正向代理要求客户端必须显式设置代理服务器地址，从用户使用角度而言，较为不便。

透明正向代理可以解决上述问题，透明正向代理可以根据预先定义的策略，由代理服务器对客户端请求地址进行改写来得到真实服务器地址。因此，客户端根本不需要知道代理服务器的存在，所以也就避免进行显式设置的烦琐。

而在实现具备HTTPS功能的透明正向代理时，预先定义的策略要求SSL客户端能够通知代理服务器最终所需连接的真实服务器地址。传统的方法是实现一种基于HTTP的自定义代理隧道协议(TUNNEL协议)，在SSL握手开始之前(也即ClientHello之前)进行通讯，其流程具体为：参见图1，首先SSL客户端向SSL服务端发送TUNNEL请求，SSL服务端接收到TUNNEL请求后响应，并将TUNNEL响应返回给SSL客户端；接着，SSL客户端向SSL服务端发送ClientHello，SSL服务端接收到ClientHello后进行响应，将ServerHello返回给SSL客户端；最后，SSL客户端与SSL服务端之间进行后续的SSL握手过程。然而，这种实现方式强行在TCP握手和SSL握手之间插入了非标准的自定义协议类型，进一步增加了协议复杂性。而协议复杂性的增加，不仅给编写无bug代码增加了难度，而且容易导致用户和后期维护者产生困惑。同时，由于增加了问题排查涉及面，也不利于使用过程中问题的排查。因此，对这种自定义代理隧道协议实现方式的改进是非常必要的。

TLS协议于2006年引入了Server Name Indication(SNI)机制，用于解决以下问题：SSL客户端向SSL服务器发出的ClientHello请求中并不包含服务器的域名，这种情况下一台SSL服务器只能使用一张站点证书，对外只能提供一个网站服务。否则，SSL服务器会分不清应该向SSL客户端提供哪一个网站的数字证书。但这对于使用虚拟主机的用户来说很不方便。比如：一台服务器中有两个虚拟主机，分别是alipay.com和baidu.com，若SSL客户端不能指明要访问的主机名，则服务器无法判断应该回复支付宝证书还是百度证书。通过SNI机制，SSL客户端可以在ClientHello请求中通过ServerName扩展项来指明所要连接的服务器的HostName。也就是说通过ServerName这个扩展项，可以让服务器在众多虚拟主机中找到各自对应的站点证书。

对于客户端告知代理服务器所需访问的真实服务器地址的需求，SNI机制已具雏形。但标准的ServerName值类型为HostName，默认只能根据HostName在多台服务器间进行区分。而对代理服务器来说，若要使用SNI机制作为客户端通告代理服务器所需访问真实地址的手段，还需要解决以下问题：

1、支持多种协议类型，代理服务器不仅仅是http代理，对于其他代理类型也要提供代理支持；

2、支持非默认的协议端口号，由于网络安全和端口号资源被占用等原因，相当一部分的应用服务器在对外提供服务时使用了非默认的协议端口号。