基于TLS协议SNI机制实现自定义代理隧道协议的方法技术

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

【技术实现步骤摘要】
基于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年引入了ServerNameIndication(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、支持非默认的协议端口号，由于网络安全和端口号资源被占用等原因，相当一部分的应用服务器在对外提供服务时使用了非默认的协议端口号。为此，申请人进行了有益的探索和尝试，找到了解决上述问题的办法，下面将要介绍的技术方案便是在这种背景下产生的。
技术实现思路
本专利技术所要解决的技术问题：提供一种基于TLS协议SNI机制实现自定义代理隧道协议的方法。本专利技术所解决的技术问题可以采用以下技术方案来实现：基于TLS协议SNI机制实现自定义代理隧道协议的方法，包括以下步骤：1)客户端向代理服务端发送握手请求要求SSL握手，并通过服务器扩展项来指明最终要连接的真实服务器地址及要使用的协议类型；2)代理服务端接收到客户端发送过来的握手请求后，对服务器扩展项进行解析，并对解析结果的类型进行检测，若检测到解析结果的类型符合要求，则将该客户端与代理服务端之间所形成的连接打上标记，并将解析结果进行存储；3)客户端在SSL握手完成后在该连接上向代理服务端发起HTTP业务请求；4)代理服务端在处理客户端HTTP业务请求时，检测该HTTP业务请求所在的连接是否存在标记，若检测到连接存在标记，则对访问目标进行修改，将先前从服务器扩展项解析并存储的解析结果与当前请求的路径地址进行拼接得到真实的服务地址。由于采用了如上的技术方案，本专利技术的有益效果在于：1、实现基于TLS协议SNI机制，解决了原有自定义代理隧道协议带来协议复杂性问题；2、重新定义了ServerName值类型，允许代理服务器对多种协议类型和非默认端口提供支持。附图说明为了更清楚地说明本专利技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本专利技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。图1是现有的基于HTTP的自定义代理隧道协议在SSL握手开始之前进行通讯的流程图。图2是本专利技术的流程图。具体实施方式为了使本专利技术实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合具体图示，进一步阐述本专利技术。HTTPS建立在SSL/TLS协议的基础上，它要求客户端与代理服务端建立起TCP连接以后，由客户端向代理服务端发起SSL握手，SSL握手完成后才能发送HTTP数据请求。在此过程中，可使用TLS协议SNI机制实现SSL客户端通知代理服务器最终所需连接的真实服务器地址的功能。参见图2，本专利技术的基于TLS协议SNI机制实现自定义代理隧道协议的方法，包括以下步骤：1)客户端向代理服务端发起握手请求，例如ClientHello消息要求SSL握手，客户端通过ServerName扩展项来指明最终要连接的真实服务器地址及要使用的协议类型，其形式为：ServerName：scheme://host:port；2)代理服务端收到客户端发送过来的ClientHello消息后，通过SSL_CTX_set_tlsext_servername_callback回调指令对ServerName扩展项进行解析，并对解析结果的类型进行检测，即检测ServerName值类型是否为scheme://host:port，若判定为是，则将客户端与代理服务端之间所形成的连接打上标记A，并存储解析结果，即存储scheme、host、port信息；3)客户端在SSL握手完成后在该连接上向代理服务端发起HTTP业务请求；4)代理服务端在处理客户端HTTP业务请求时，检测该HTTP业务请求所在的连接是否存在标记A，若检测到连接存在标记A，则对访问目标进行修改，将先前从ServerName解析并存储的scheme、host、port信息与当前请求的路径地址request_path进行拼接得到真实的服务地址，形式如：scheme://host:p本文档来自技高网...

【技术保护点】
基于TLS协议SNI机制实现自定义代理隧道协议的方法，其特征在于，包括以下步骤：1)客户端向代理服务端发送握手请求要求SSL握手，并通过服务器扩展项来指明最终要连接的真实服务器地址及要使用的协议类型；2)代理服务端接收到客户端发送过来的握手请求后，对服务器扩展项进行解析，并对解析结果的类型进行检测，若检测到解析结果的类型符合要求，则将该客户端与代理服务端之间所形成的连接打上标记，并将解析结果进行存储；3)客户端在SSL握手完成后在该连接上向代理服务端发起HTTP业务请求；4)代理服务端在处理客户端HTTP业务请求时，检测该HTTP业务请求所在的连接是否存在标记，若检测到连接存在标记，则对访问目标进行修改，将先前从服务器扩展项解析并存储的解析结果与当前请求的路径地址进行拼接得到真实的服务地址。

【技术特征摘要】
1.基于TLS协议SNI机制实现自定义代理隧道协议的方法，其特征在于，包括以下步骤：1)客户端向代理服务端发送握手请求要求SSL握手，并通过服务器扩展项来指明最终要连接的真实服务器地址及要使用的协议类型；2)代理服务端接收到客户端发送过来的握手请求后，对服务器扩展项进行解析，并对解析结果的类型进行检测，若检测到解析结果的类型符合要求，则将该客户端与代...

【专利技术属性】
技术研发人员：贺红杰，掌晓愚，卫杰，
申请(专利权)人：上海格尔软件股份有限公司，
类型：发明
国别省市：上海,31