> Not exactly. The upstream destination still requires SSL connectivity to be usable - and the client will be faced with certificate domain does not match errors unless yoru peer is also able to perform server-forst bumping when it gets contacted by your Squid.
>
> It looks to me like your peer is receiving plain-HTTP and cannot be "bumped" to supply SSL server cert details.
I have the following setup:
[Internet]
|
[Proxy A]
|
[Proxy B]
|
[Client]
Proxy B has "never-direct allow all" set, so all requests will go via
proxy A.
With SSL bump-server-first disabled, everything works as expected - the
client connects to proxy B and issues a CONNECT command, proxy B
connects to proxy A and issues a CONNECT command, proxy A connects to
the server and the client and server negotiate their SSL sessions
opaquely over the established tunnel.
With SSL bump-server-first enabled, the client connects to proxy B and
issues a CONNECT command, proxy B connects to proxy A and then bombs
with "assertion failed: forward.cc:769: "peer->use_ssl"". Proxy B never
issues a CONNECT to proxy A.
If proxy B is configured to go direct to the server instead of via proxy
A, it behaves correctly.
-- - Steve Hill Technical Director Opendium Limited http://www.opendium.com Direct contacts: Instant messager: xmpp:steve_at_opendium.com Email: steve_at_opendium.com Phone: sip:steve_at_opendium.com Sales / enquiries contacts: Email: sales_at_opendium.com Phone: +44-844-9791439 / sip:sales_at_opendium.com Support contacts: Email: support_at_opendium.com Phone: +44-844-4844916 / sip:support_at_opendium.comReceived on Mon Nov 26 2012 - 22:03:35 MST
This archive was generated by hypermail 2.2.0 : Tue Nov 27 2012 - 12:00:08 MST