基于 Gin 的 HTTP 中间人代理 Demo

前面实现的代理对于 HTTPS 流量是进行盲转的,也就是说直接在 TCP 连接上传输 TLS 流量,但是我们无法查看或者修改它的内容。当然了,通常来说这也是不必要的。不过对于某些场景下还是有必要的,例如使用 Fiddler 进行抓包或者监控其它电脑的流量传输等,这就需要用到中间人代理了。所以说,学习一下这一块的内容,对于更好的使用 Fiddler Charles 或者 mitmProxy 这类软件是很有帮助的。遥想起来,好几年前我还在大学的时候,学会使用 Fiddler 去抓包,当时就觉得很神奇。我当时特别喜欢使用它来学习 HTTP 协议的结构,或者开安卓模拟器来抓 APP 的包,不过我当时对于代理的概念几乎是一无所知。现在,也很少再玩这些东西了,反而对代理的了解更进一步了。

在继续阅读之前,最好还是对一下概念有一个简单的了解:

  • 非对称加密和对称加密
  • 公钥和私钥
  • 签名
  • 证书

一、中间人代理的概念

一图胜千言,我们先来看几张图片吧。
基于 Gin 的 HTTP 中间人代理 Demo_第1张图片

这是前面介绍的通过 TCP 隧道的透明代理的一个简单示意图,数据是通过 TCP 上发送的二进制 TLS 流量,代理无法解密这些数据,它只是负责对这些数据进行盲转发,所以说它是透明代理。所以即使经过了代理服务器,客户端实际上也是和服务器进行的 TLS 握手,然后通信的,这种情况下通信是安全的。

基于 Gin 的 HTTP 中间人代理 Demo_第2张图片

这是我们接下来要介绍的中间人代理了,它同样是一个代理,但是这次它会假装自己是客户端需要访问的服务器,然后客户端实际上是同中间人进行通信,代理再同服务器进行通信(甚至没有这一步!),这样就可以查看、修改客户端和服务器通信的内容了(这种情况下通信是不安全的)。

注:中间人,Man In The Middle,简称 MITM。

基于 Gin 的 HTTP 中间人代理 Demo_第3张图片

网络是分层的,这就是 HTTPS 协议的示意图。所以知乎上有一个博主说了一句话,我认为挺有道理的,大致意思是:没有 HTTPS 协议,只有 HTTP 协议。

所以对于我们接下来的内容,即实现一个中间人代理的关键是解决客户端和中间人代理之间的 TLS 握手。我们先来使用命令行看一下访问 https://www.baidu.com 的过程(大致了解一下,我也只是理解一点),首先是连接到目标主机的 443 端口,这是 TCP 连接。然后开始建立 TLS 连接,可以看到会进行协议握手(handshake)(握手就是进行协商一个双方共同接受的条件,协议版本或者密码套件之类的)。

使用浏览器访问百度,查看它的证书,这样比在命令行里面更方便一些。这里我们主要关注这个 CN 字段,其它的我也不了解。

基于 Gin 的 HTTP 中间人代理 Demo_第4张图片

前面这些图应该可以有一个大致的概念了。我们要做的就是代替真正的服务器和客户端进行握手(相当于是欺骗它我就是你需要访问的服务器),但是我们不可能搞到真正服务器的证书(私钥)的。不过,任何人都可以很方便的生成一个自己公钥和私钥,它和那些由CA签发的证书来说,区别只是它不是受信任的。

节选自 《HTTP权威指南》第 14 章节 安全的 HTTP
在发送已加密的 HTTP 报文之前,客户端需要和服务器进行一次 SSL 握手,在这个握手过程中,它们要完成以下工作:

  • 交换协议版本号
  • 选择一个两端都了解的密码
  • 对两端的身份进行验证
  • 生成临时的会话密钥,以便加密信道。

这里的第三点,对两端身份进行验证,其实通常是没有的。我们一般只对服务器的身份进行验证,即它确实是我们要访问的服务器(服务器一般不会要求验证客户端的身份)。当然也有要求客户端进行验证的,例如说 Fiddler 也抓不了支付宝的数据包。据说是因为它使用了双端验证,即使你可以假扮服务器,但是没有假扮客户端去和真正的服务器进行交互(我听说支付宝的客户端证书是内置的,所以中间人代理是没法抓到它的数据包的)。所以中间人代理实际上也就是钻了这个漏洞,否则大部分的 HTTPS 流量都难以解密了。

二、实现细节

所以我们要做的工作也就大致清晰了,下面是一个简单的示意图,圆角矩形表示这中间的协议变化。
首先客户端通过 HTTP 协议和代理服务器建立 TCP 连接(在 Go 中,是通过 Hijack 获取底层 TCP 连接的)。之后客户端会在这个 TCP 连接上发送 TLS 的内容。所以我们把这个连接转成 TLS 连接(就是说和客户端进行握手),如果成功之后我们就会被认为是真的服务器了(实际上是假的),因为现在就是单纯的 HTTP 通信了,所以可以自由的查看和修改报文的内容了。

基于 Gin 的 HTTP 中间人代理 Demo_第5张图片

生成本地的自签名证书,这里的 CN 字段,指定为 baidu.com

基于 Gin 的 HTTP 中间人代理 Demo_第6张图片

然后我们来看一下,关于中间人代理这块的代码:

这里的变化也就是多加了这一个函数,也就是在劫持获得 TCP 连接后,把它作为参数传入这个函数。这个函数的功能主要就是加载公钥和私钥,然后把 TCP 连接变成 TLS 连接,接着就可以进行 HTTP 的请求和响应了。

func mitm(conn net.Conn) error {
	tlsCert, err := tls.LoadX509KeyPair(certFile, keyFile)
	if err != nil {
		return err
	}
	// 再把底层连接转换成 tls 连接,然后再封装成 http request
	tlsConn := tls.Server(conn, &tls.Config{ // 这里有一个概念叫 客户端连接和服务端连接
		PreferServerCipherSuites: true,
		MaxVersion:               tls.VersionTLS13,
		Certificates:             []tls.Certificate{tlsCert}, // 这里最关键的是这个证书的配置
	})
	defer tlsConn.Close()

	// 封装成 http request
	var req *http.Request
	if req, err = http.ReadRequest(bufio.NewReader(tlsConn)); err != nil {
		return err
	}

	req.RequestURI = ""      // 这里创建一个新的请求或者把这个设置为 空,不然会报错
	req.URL.Scheme = "https" // 中途转换的 Request 丢失了一些信息,居然没有 scheme 了
	req.URL.Host = req.Host

	var resp *http.Response
	if resp, err = proxyHttpClient.Do(req); err == nil {
		err = resp.Write(tlsConn)
	}

	return err
}

我之前一直没有想明白这一块,我也看了很多其它人的实现,但是就是这一点没有想明白。然后昨天看了一个外国的博文,发现居然就是这样的,还是对这个网络这一块的了解太少了,哈哈。我刚开始想到了把它转成 TLS 连接,但是我在想那怎么再变成 HTTP 连接呢?但是,仔细一想,HTTP 是一个文本协议,实际上我可以直接对这个 TLS 连接上读取或者返回符合 HTTP 报文格式的数据,所以最后写入响应数据就是 resp.Write(tlsConn),虽然这只是简短的一行,却困惑了我好久!!!

Talk is cheap, show me your code

我就是看的这篇博客然后才了解了最后困扰我的那部分内容,这个作者写的真的不错!

Go and Proxy Servers: Part 2 - HTTPS Proxies

注:这里使用的是 tls.Server,这个包下还有一个 tls.Client 的方法。所以它这里是为了区分客户端连接和服务端连接。我的理解是这样的,如果你打算发起一个请求,你肯定需要的是客户端连接。反过来,如果你已经得到了一个请求,你打算处理它,它就是服务端连接。

三、完整代码和测试

package main

import (
	"bufio"
	"crypto/tls"
	"io"
	"log"
	"net"
	"net/http"
	"strings"

	"github.com/gin-gonic/gin"
)

const (
	RPOXY_SERVER  = "CrazyDragonHttpProxy" // it is just a kidding, but Only HTTP!
	TUNNEL_PACKET = "HTTP/1.1 200 Connection Established\r\nProxy-agent: CrazyDragonHttpProxy\r\n\r\n"
	certFile      = "./server.crt"
	keyFile       = "./server.key"
)

var proxyHttpClient = http.DefaultClient

func main() {
	r := gin.Default()
	r.Use(recordReq)      // 使用 gin 的中间件简单打印请求的信息
	r.NoRoute(routeProxy) // NO Route is every Routes!!!
	r.Run(":8888")
}

// 这样就可以处理所有的请求了,在这里区分是 http 还是 https,https 会通过 CONNECT 来建立隧道,所以就通过它来区分。
func routeProxy(c *gin.Context) {
	req := c.Request
	if req.Method == http.MethodConnect {
		httpsProxy(c, req) // 处理 HTTPS 请求(HTTPS => TCP <-> TLS <-> HTTP )
	} else {
		httpProxy(c, req) // 处理 HTTP 请求
	}
}

func httpsProxy(c *gin.Context, req *http.Request) {
	c.Status(200) // 不加也没有问题,只是说记录的日志状态码都会变成 404.
	// 这里接管这个 http 连接,然后将它劫持为一个 TCP 连接
	hj, ok := c.Writer.(http.Hijacker)
	if !ok {
		http.Error(c.Writer, "webserver doesn't support hijacking", http.StatusInternalServerError)
		return
	}
	clientConn, _, err := hj.Hijack()
	if err != nil {
		http.Error(c.Writer, err.Error(), http.StatusInternalServerError)
		return
	}
	// 建立隧道之后,发送一个连接建立的响应(其实,只要状态码是 200 就可以了)
	if _, err = clientConn.Write([]byte(TUNNEL_PACKET)); err != nil {
		log.Printf("Response Failed: %v", err.Error())
	} else {
		log.Println("Response Success.")
	}
	// 因为我们知道了客户端需要访问的 HOST+PORT,所以现在我们需要来模拟一个假的服务器(即中间人)来和它进行对话。
	// 所以这里的关键是这个模拟的服务需要有证书,不然无法和客户端进行握手。
	err = mitm(clientConn)
	if err != nil {
		log.Println(err)
		return
	}
}

func httpProxy(c *gin.Context, req *http.Request) {
	req.RequestURI = "" // 这里创建一个新的请求或者把这个设置为 空,不然会报错
	resp, err := proxyHttpClient.Do(req)
	if err != nil {
		log.Println(err)
		return
	}
	defer resp.Body.Close()
	c.Status(resp.StatusCode) // 修改状态码,因为默认的是 404(我是在 NoRoute 里面处理的)。
	for k, v := range resp.Header {
		c.Header(k, strings.Join(v, ",")) // 写入头部(全部写入严格来说是不对)。
	}
	c.Header("Server", RPOXY_SERVER) // haha, it just a kidding!!!
	io.Copy(c.Writer, resp.Body)     // 响应数据给客户端
}

func recordReq(ctx *gin.Context) {
	log.Printf("Method: %s, Host: %s, URL: %s, Version: %s\n", ctx.Request.Method, ctx.Request.Host, ctx.Request.URL.Path, ctx.Request.Proto)
}

func mitm(conn net.Conn) error {
	tlsCert, err := tls.LoadX509KeyPair(certFile, keyFile)
	if err != nil {
		return err
	}
	// 再把底层连接转换成 tls 连接,然后再封装成 http request
	tlsConn := tls.Server(conn, &tls.Config{ // 这里有一个概念叫 客户端连接和服务端连接
		PreferServerCipherSuites: true,
		MaxVersion:               tls.VersionTLS13,
		Certificates:             []tls.Certificate{tlsCert}, // 这里最关键的是这个证书的配置
	})
	defer tlsConn.Close()

	// 封装成 http request
	var req *http.Request
	if req, err = http.ReadRequest(bufio.NewReader(tlsConn)); err != nil {
		return err
	}

	req.RequestURI = ""      // 这里创建一个新的请求或者把这个设置为 空,不然会报错
	req.URL.Scheme = "https" // 中途转换的 Request 丢失了一些信息,居然没有 scheme 了
	req.URL.Host = req.Host

	var resp *http.Response
	if resp, err = proxyHttpClient.Do(req); err == nil {
		err = resp.Write(tlsConn)
	}

	return err
}

启动代码后,使用 curl 访问 https://www.baidu.com,这里要加 -k 参数跳过证书验证(我这个自签名证书是不受信任的,默认是关闭连接的)。

基于 Gin 的 HTTP 中间人代理 Demo_第7张图片

如果不加 -k 的话,证书验证过不去,连接会被终止。

启动代码后,配置好代理的配置(可以看前面的博客的配置,注意端口号这里我换了,因为 8888 被占用了),使用浏览器访问 https://www.baidu.com

基于 Gin 的 HTTP 中间人代理 Demo_第8张图片
遇到问题了,使用不受信任的证书,浏览器禁止我访问百度了,因为它采用了更严格的安全策略 HSTS。因为通常情况下,即使证书不安全,我也可以坚持访问的。不过现在这样还就是麻烦了呢。

HSTS(HTTP Strcit-Transport-Securit)即 HTTP 严格传输安全, 是一种 Web 安全策略机制,可保护网站免受协议降级攻击和 cookie 劫持、中间人攻击。它允许 Web 服务器声明浏览器(或其他符合要求的用户代理)应用使用安全的 HTTPS 连接与交互,而不是通过不安全的 HTTP 协议。

HSTS 详解,让 HTTPS 更安全

不过幸好,这个是可以关闭的。我用的是 edge 浏览器,输入下面的网址进入这个页面,在下面输入百度的域名,删除动态的 HSTS。不过它也提示了预加载的是没有用的。这个应该是临时的,最好还是开启它,因为这是涉及安全的问题!

基于 Gin 的 HTTP 中间人代理 Demo_第9张图片

好了,现在终于可以访问了 www.baidu.com 了,这里只是打开了首页截了几张图片。

基于 Gin 的 HTTP 中间人代理 Demo_第10张图片

基于 Gin 的 HTTP 中间人代理 Demo_第11张图片

基于 Gin 的 HTTP 中间人代理 Demo_第12张图片

四、信任证书和证书链

证书通常是由某些很权威的机构来颁发的,一般称为 CA。这里的颁发,指的是用 CA 的私钥来对证书进行签名(这样别人就无法伪造证书了,因为没有办法签名)。验证证书就是用 CA 的公钥对证书进行解密并验证。 并且逻辑上证书是一条链的结构,首先是根证书,然后是中间证书,最后是服务端证书。

根证书 --> 中间证书 --> 服务端证书

这样是从颁发证书的角度看的,实际上验证证书的时候是反过来的,从服务端证书开始,一直到根证书,都验证通过了才是通过。

现在这个代理服务器,还是有很多问题的,首先它只能访问 https://www.baidu.com,其次它会报红色警告。第一个是因为我只是生成了一个假的 baidu.com 的证书,所以对于其它的网址直接是过不去检验的(会检查域名和CN的匹配关系,然后是校验证书的有效性)。如果域名和证书不匹配,那么直接就是错误了,如下图。

在这里插入图片描述

这个红色警告是因为这个证书是自签名证书,天然就是不被信任的,当然也有解决办法了。我们来看看 Fiddler 是怎么解决的,它是把自己的证书安装到了系统的根证书(根证书是默认信任的)中,然后用这个来给我们访问的域名签发假的证书(可以看到全部是假的证书,而且它的名字叫 不要信任 Fiddler 根证书)。这里就没有中间证书了,证书校验就是服务端证书和根证书了。

基于 Gin 的 HTTP 中间人代理 Demo_第13张图片

基于 Gin 的 HTTP 中间人代理 Demo_第14张图片

我这里只是用了一个自签名证书,因为我只演示了百度这一个域名,所以就不需要再弄一个根证书了。而且,我也不想安装把这个安装到系统的根证书,因为这样很危险。所以,如果想要访问各种不同的网站,需要自己来为每一个访问的域名签发证书,这就需要一个 CA 证书来操作了,这样只需要把一个证书加入系统根证书就好了。如果想要扩展的话,应该会用到下面这个方法来动态的生成证书,不过这个主题的探索对于我来说已经差不多要结束了,因为关于证书这一块还是挺多不熟悉的。如果你也阅读到这里,相信你对于 Fiddler、Charles 和 MitmProxy 的也会有更多的理解,对于我们使用这些工具是很有帮助的。

基于 Gin 的 HTTP 中间人代理 Demo_第15张图片

这一块的内容还是挺多的,我也只是了解一点,如果想要看更多的内容的话,可以看下面的这两个技术博客,写得很好。

证书链简介

HTTPS 精读之 TLS 证书校验

五、总结

这篇博客和上一篇博客之间已经隔了好久了。因为理解这个中间人代理的过程遇到了困难,再加上时间不是很充足,也就没有继续写这个主题的内容。最近刚好又有了时间了,所以就集中时间看了很多内容,测试代码(因为 TSL 发生了错误基本上看不懂什么意思,感觉自己掌握的知识和工具还是太少了,很多错误只能束手无策了),也算是对这个东西有了一个新的理解。我其实还是更喜欢盲转发的代理,因为那样实现起来更简单,可以做一些上网行为统计的小工具玩一玩。对于这种中间人代理,因为已经有了很成熟的工具了,所以就当做是了解怎么样更好的使用这些工具了。

你可能感兴趣的:(网络编程,代理服务器,Golang,gin,http,网络协议,中间人代理)