这是一个创建于 3999 天前的主题，其中的信息可能已经有所发展或是发生改变。
现有两台squid组成二级缓存，child 在墙内，使用https_port作为https代理，配置parent cache_peer在墙外，根据gfw黑名单向墙外转发请求。客户端使用google-chrome --proxy-server=https://xxx.com:443进行测试。
使用版本3.3.8，应该已经修复不能重新打包https请求的bug。--enable-ssl的编译选项已打开，而且客户端直连parent squid是可以翻墙的，这点已经测试。
本以为child squid在向parent squid的https_port转发请求时会重新使用ssl加密http请求，但是实际测试结果中，parent的cache_log中出现大量的
“SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request”
换句话说，收到的仍然是http请求。这样翻墙计划就破产了…
现在child squid的cache_peer选项配置如下：
cache_peer proxy.xxx.org parent 443 0 no-query \
ssl sslflags=DONT_VERIFY_PEER
请教有经验的兄弟：是不是squid没有重新加密普通http请求的能力？
使用版本3.3.8，应该已经修复不能重新打包https请求的bug。--enable-ssl的编译选项已打开，而且客户端直连parent squid是可以翻墙的，这点已经测试。
本以为child squid在向parent squid的https_port转发请求时会重新使用ssl加密http请求，但是实际测试结果中，parent的cache_log中出现大量的
“SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request”
换句话说，收到的仍然是http请求。这样翻墙计划就破产了…
现在child squid的cache_peer选项配置如下：
cache_peer proxy.xxx.org parent 443 0 no-query \
ssl sslflags=DONT_VERIFY_PEER
请教有经验的兄弟：是不是squid没有重新加密普通http请求的能力？
 |
1
Livid MOD  1
两台机器的话，可能 host to host 的 IPSEC 会更简单一些吧。
|
 |
2
hcw1588 2014-01-06 16:50:04 +08:00 1
做过，，和楼主情况一样。。
|
 |
3
tairan2006 OP @hcw1588 你后来是在child proxy后端重新使用stunnel或者shrpx加密了一次才解决这问题的？
|
|
4
tairan2006 OP @Livid 只是打个比方，将来可能做集群的。
|
|
5
hcw1588 2014-01-06 16:56:24 +08:00
@tairan2006 嗯。。
|
|
6
tairan2006 OP 难道这个ssl选项只是在sslbump打开后，在此重新加密，而一般的http请求无法在此加密么？
|
 |
7
snnn 2016-01-12 23:29:28 +08:00
cache_peer xxx.xx.x.xxx parent 443 0 no-query ssl sslcert=/etc/squid/client.crt sslcafile=/etc/squid/ca.crt
这是 squid 4.x 的配置 |
|
8
tairan2006 OP @snnn 这都过两年了，终于有了么…不过我现在不搞这个了。嗯，这个功能还是挺有用的。
|
Select Language