代理服务器在代理https请求时会做什么？

Question

代理服务器在代理https请求时会做什么？

3

我使用以下设置使用Apache构建正向代理服务器：

<VirtualHost *:8088>
    ServerAdmin test@gmail.com
    DocumentRoot "E:/test"
    ServerName www.test.com
    ServerAlias test.com
    ErrorLog "logs/test.com-error.log"
    CustomLog "logs/test.com-access.log" common
    <Directory "E:/test">
        Options FollowSymLinks
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>

    ProxyRequests On
    ProxyVia Off
    ProxyTimeout 10

    <Proxy *>
        Order deny,allow
        Deny from all
        Allow from 127.0.0.1
    </Proxy>
</VirtualHost>

主机文件

127.0.0.1 localhost

接下来我使用curl测试代理服务器

curl.exe -v https://www.google.com.hk -x localhost:8088

输出结果

* About to connect() to proxy localhost port 8088 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8088 (#0)
* Establish HTTP proxy tunnel to www.google.com.hk:443
> CONNECT www.google.com.hk:443 HTTP/1.1
> Host: www.google.com.hk:443
> User-Agent: curl/7.21.7 (amd64-pc-win32) libcurl/7.21.7 OpenSSL/0.9.8r zlib/1.
2.5
> Proxy-Connection: Keep-Alive
>
< HTTP/1.0 200 Connection Established
< Proxy-agent: Apache/2.2.25 (Win32) PHP/5.4.21
<
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: D:\curl-ssl\curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.googl
e.com.hk
*        start date: 2013-11-20 14:47:22 GMT
*        expire date: 2014-03-20 00:00:00 GMT
*        subjectAltName: www.google.com.hk matched
*        issuer: C=US; O=Google Inc; CN=Google Internet Authority G2
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.21.7 (amd64-pc-win32) libcurl/7.21.7 OpenSSL/0.9.8r zlib/1.
2.5
> Host: www.google.com.hk
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 05 Dec 2013 02:21:27 GMT
< Expires: -1
< Cache-Control: private, max-age=0
< Content-Type: text/html; charset=Big5
< Set-Cookie: PREF=ID=12cdbbbf43c234b5:FF=0:NW=1:TM=1386210087:LM=1386210087:S=B
HZ4WAj3fqZicDa_; expires=Sat, 05-Dec-2015 02:21:27 GMT; path=/; domain=.google.c
om.hk
< Set-Cookie: NID=67=EvwPZiG49GZO1AMLw7cTY1Azrqzb77uTpCUv9rOECEJh4PRB523yMIJm8L5
OxxWBeq44qM-Dn8xYUijDmBrvXfL504U4_FSunEfG5UUIDveWbHG2BirORx5Jqk9MVFkd; expires=F
ri, 06-Jun-2014 02:21:27 GMT; path=/; domain=.google.com.hk; HttpOnly
< P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/
bin/answer.py?hl=en&answer=151657 for more info."
< Server: gws
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
< Alternate-Protocol: 443:quic
< Transfer-Encoding: chunked
<
...  The google home page HTML ...

我认为https代理的流程如下：

向代理服务器发送一个CONNECT http请求
代理服务器将此CONNECT请求转发到www.google.com.hk:443
www.google.com.hk:443返回一个200 Connection Establish响应给代理服务器
代理服务器将响应转发给curl
curl开始向代理服务器发送TLS握手数据报（可能是加密的？）
代理服务器不知道有关数据报的任何信息，因为数据报已加密，代理服务器仅使用先前发送CONNECT请求的套接字将此数据报转发到www.google.com.hk:443。
www.google.com.hk:443将加密的TLS握手数据报发送给代理服务器
代理服务器将加密数据转发给curl而不进行解密
......经过多次握手后，握手完成并开始发送GET请求
curl向代理服务器发送一个GET请求，此请求数据报被加密
代理服务器使用上述提到的套接字将加密的数据报转发到www.google.com.hk:443
www.google.com.hk:443返回一个加密的响应
代理服务器将响应转发给curl
curl解密响应并显示HTML

我不知道我的理解是否正确，尤其是在第3步之后，curl收到了200 CONNECTION ESTABLISHED响应。

我想知道的是代理服务器在收到200 CONNECTION ESTABLISHED响应后会做什么，代理服务器是否解密请求数据报？

- Alexis

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Eugene Mayevski 'Callback · Accepted Answer

HTTPS代理可以连接到任何远程资源。如果它连接到HTTPS服务器，则不会看到200响应，因为响应已加密。

通常，CONNECT动词的意思是“建立一个不透明的隧道，并让我知道何时准备就绪”。所以服务器通过连接到远程服务器来建立一个隧道，一旦建立连接，代理就向客户端发送积极的响应。之后，客户端可以向代理发送任何数据，代理将简单地将数据中继到远程服务器，接收来自服务器的数据并将其发送回客户端。

这种方案使得人们可以使用HTTPS代理连接到任何类型的服务器，而不仅仅是HTTP/HTTPS。