浅谈Charles抓取HTTPS原理
在关于HTTPS,你需要知道的全部中,分析了HTTPS的安全通信过程,知道了HTTPS可以有效防止中间人攻击。但用过抓包工具的人都知道,比如Charles,Fiddler是可以抓取HTTPS请求并解密的,它们是如何做到的呢?
首先来看Charles官网对HTTPS代理的描述:
Charles can be used as a man-in-the-middle HTTPS proxy, enabling you to view in plain text the communication between web browser and SSL web server.` Charles does this by becoming a man-in-the-middle. Instead of your browser seeing the server’s certificate, Charles dynamically generates a certificate for the server and signs it with its own root certificate (the Charles CA Certificate). Charles receives the server’s certificate, while your browser receives Charles’s certificate. Therefore you will see a security warning, indicating that the root authority is not trusted. If you add the Charles CA Certificate to your trusted certificates you will no longer see any warnings – see below for how to do this.
Charles作为一个“中间人代理”,当浏览器和服务器通信时,Charles接收服务器的证书,但动态生成一张证书发送给浏览器,也就是说Charles作为中间代理在浏览器和服务器之间通信,所以通信的数据可以被Charles拦截并解密。由于Charles更改了证书,浏览器校验不通过会给出安全警告,必须安装Charles的证书后才能进行正常访问。
下面来看具体的流程:
客户端向服务器发起HTTPS请求Charles拦截客户端的请求,伪装成客户端向服务器进行请求服务器向“客户端”(实际上是Charles)返回服务器的CA证书Charles拦截服务器的响应,获取服务器证书公钥,然后自己制作一张证书,将服务器证书替换后发送给客户端。(这一步,Charles拿到了服务器证书的公钥)客户端接收到“服务器”(实际上是Charles)的证书后,生成一个对称密钥,用Charles的公钥加密,发送给“服务器”(Charles)Charles拦截客户端的响应,用自己的私钥解密对称密钥,然后用服务器证书公钥加密,发送给服务器。(这一步,Charles拿到了对称密钥)服务器用自己的私钥解密对称密钥,向“客户端”(Charles)发送响应Charles拦截服务器的响应,替换成自己的证书后发送给客户端至此,连接建立,Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥,之后就可以解密或者修改加密的报文了。
HTTPS抓包的原理还是挺简单的,简单来说,就是Charles作为“中间人代理”,拿到了 服务器证书公钥 和 HTTPS连接的对称密钥,前提是客户端选择信任并安装Charles的CA证书,否则客户端就会“报警”并中止连接。这样看来,HTTPS还是很安全的。
原文
PS Http的connect Method
Http CONNECT相当于客户端和目标服务器之间建立的一个隧道,而通过这个隧道的请求是加密的,所以CONNECT方式的请求使用抓包是抓不到的。
扩展http proxy原理
connect方法
http 1.1定义了8种方法,connect为其中之一,HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接(经由非加密的HTTP代理服务器)。
并非所有的http隧道支持connect方法,Http隧道分为两种:
不使用CONNECT的隧道
不使用CONNECT的隧道,实现了数据包的重组和转发。在Proxy收到来自客户端的Http请求之后,会重新创建Request请求,并发送到目标服务器,。当目标服务器返回Response给Proxy之后,Proxy会对Response进行解析,然后重新组装Response,发送给客户端。所以,在不使用CONNECT方式建立的隧道,Proxy有机会对客户端与目标服务器之间的通信数据进行窥探,而且有机会对数据进行串改。使用CONNECT的隧道
而对于使用CONNECT的隧道则不同。当客户端向Proxy发起Http CONNECT Method的时候,就是告诉Proxy,先在Proxy和目标服务器之间先建立起连接,在这个连接建立起来之后,目标服务器会返回一个回复给Proxy,Proxy将这个回复转发给客户端,这个Response是Proxy跟目标服务器连接建立的状态回复,而不是请求数据的Response。在此之后,客户端跟目标服务器的所有通信都将使用之前建立起来的建立。这种情况下的Http隧道,Proxy仅仅实现转发,而不会关心转发的数据。这也是为什么在使用Proxy的时候,Https请求必须首先使用Http CONNECT建立隧道。因为Https的数据都是经过加密的,Proxy是无法对Https的数据进行解密的,所以只能使用CONNECT,仅仅对通信数据进行转发。
注意,proxy代理的是客户端发起的TCP连接,以下是wiki的解释
the client, using the “CONNECT” HTTP method, asks an HTTP Proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the Proxy server continues to proxy the TCP stream to and from the client. Note that only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection.This mechanism is how a client behind an HTTP proxy can access websites using SSL (i.e. HTTPS).
/wiki/HTTP_tunnel
与proxy相关字段
X-Forwarded-For(XFF)是用来识别通过HTTP代理或负载均衡方式连接到Web服务器的客户端最原始的IP地址的HTTP请求头字段; Squid 缓存代理服务器的开发人员最早引入了这一HTTP头字段,如果没有XFF或者另外一种相似的技术,所有通过代理服务器的连接只会显示代理服务器的IP地址(而非连接发起的原始IP地址),这样的代理服务器实际上充当了匿名服务提供者的角色,如果连接的原始IP地址不可得,恶意访问的检测与预防的难度将大大增加。
X-Forwarded-Host和X-Forwarded-Proto分别记录客户端最原始的主机和协议。
Proxy-Authorization:连接到proxy的身份验证信息
Proxy-connection:它不是标准协议的一部分,标准协议中已经存在一种机制可以完成此协议头的功能,这就是Connection头域,与Proxy-Connection头相比,Connection协议头几乎提供了相同的功能,除了错误部分。而且,Connection协议头可用于任意连接之间,包括HTTP服务器,代理,客户端,而不是像Proxy-Connection一样,只能用于代理服务器和客户端之间。
http 1.1其余7种方法
OPTIONS:这个方法可使服务器传回该资源所支持的所有HTTP请求方法。用’*'来代替资源名称,向Web服务器发送OPTIONS请求,可以测试服务器功能是否正常运作。HEAD:与GET方法一样,都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部份。它的好处在于,使用这个方法可以在不必传输全部内容的情况下,就可以获取其中“关于该资源的信息”(元信息或称元数据)。GET:向指定的资源发出“显示”请求。使用GET方法应该只用在读取数据,而不应当被用于产生“副作用”的操作中,例如在Web Application中,其中一个原因是GET可能会被
网络蜘蛛等随意访问。POST:向指定资源提交数据,请求服务器进行处理(例如提交表单或者上传文件)。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源,或二者皆有。PUT:向指定资源位置上传其最新内容。DELETE:请求服务器删除Request-URI所标识的资源。TRACE:回显服务器收到的请求,主要用于测试或诊断。