透明代理与ssl协议

透明代理实质上类似一种拦截，客户端以为自己访问的是自己要访问的服务器，实际上这次访问早已被所谓的透明代理接管了，透明代理主机将用户的访问重定向到本机的应用层代理进程，从用户发出的http协议头中得到用户需要访问的地址信息，然后代理用户去访问或者按照本地的配置给予策略化的服务。一种合理的模式是vpn中的应用，为了便于管理，一般用户需要本公司的代理服务器提供互联网服务，可是如果一个用户在出差中使用公司配给的涉密笔记本电脑，他必然需要通过vpn连接到公司网络，然后再通过公司的代理服务器上网，在这种模式中，我用一种简单的方式来阐述思想，那就是暂且不考虑vpn的细节，也就是暂且不考虑网络层的事情，而集中于应用层，毕竟，代理进程都工作在应用层，我使用stunnel(在linux下先apt-get或rpm或者make install，然后man或者info一下)作为用户直接连接的代理服务器客户端，使用另一个stuunel作为服务器，两个stuunel之间通过SSL协议连接，无疑这个连接是安全的。这个连接不是长连接，而是只有在stuunel接收到用户的访问请求时才会初始化一个ssl连接到stunnel服务器，用户的访问过程通过这个ssl连接到达stunnel服务器，进而被转发到真实的服务器。这里面有几个细节，stunnel客户端如何知道用户要访问什么地址，stunnel客户端又是怎样将这个信息传给服务器，然后让服务器区代理用户访问真实地址。
如果stunnel客户端不能将用户要访问的真实地址告知stunnel服务器或者stunnel服务器不处理它，那么这只能部分实现一个反向代理，也就是事先配置，所以必然需要将用户的真实欲访问地址传达给服务器。第一个细节的解答，那就是首先将所有的访问重定向到本机(使用iptables)，然后解析用户发起的http协议的头，得到原始地址信息，如果不是http协议而是普通的tcp应用或者udp应用，由于地址信息并不一定保存在协议头中，因此必然需要用另一种方式得到原始地址信息，这就是ioctl调用，linux提供了一个netfilter命令，可以得到重定向之前的原始地址信息，包括ip地址和端口，现在无论是哪种应用，http也好，普通的tcp也好，都得到了原始地址信息，由于我们的代理服务器不在本地而在远端，所以现在解决第二个问题，之前很长时间，我们必须自己写协议来把这个信息传输给服务器，现在，不需要那么麻烦了，在ssl协议的情况下，新更新的ssl协议规范在RFC5246中介绍，client发起的hello消息中多了一个extension字段，也就是client可以在hello的时候就把一些附件信息传给server，于是完全可以在这个hello消息中将client得到的原始地址信息传输给server，这样在client和server的ssl连接初始化好了之后，server就可以使用从client-hello中得到的原始地址发起一个到真实地址的连接，从而实现一个透明代理。