Re: [squid-users] ssl-bump, server-first

On 20/03/2013 9:48 a.m., Alex Rousskov wrote:
> On 03/19/2013 01:27 PM, Delton wrote:
>> Dear,
>>
>> I compiled Squid 3.3.3 on a Debian 7 with the --enable-ssl and
>> --enable-ssl-crtd.
>>
>> I wish Squid exhibit an error message to the user to access a blocked
>> page, for example https://www.facebook.com
>>
>> It worked more or less: imported the root certificate in the browser and
>> access an HTTPS site when the certificate is displayed correctly.
> Do you meant that everything works for non-blocked sites?
>
>
>> With the option 'ssl-server-first bump all' active site is not displayed
>> correctly.
> There is no "ssl-server-first" directive in Squid. Did you mean
> "ssl_bump ssl-server-first all"? You configuration shows:
>
>> ssl_bump first-server all
> There is no "first-server" option for ssl_bump. Did you mean "server-first"?
>
> Please fix your configuration and retest. If you are still having
> problems, please clarify what works, what does not, and what
> configuration (or request) changes result in problems.
>
>
>> The logs showed, for example:
>>
>> 1363716588.893 364 192.168.0.52 TCP_MISS/200 24765 GET
>> https://www.google.com.br/ - PINNED/2800:3f0:4001:804::101f text/html
>>
>> Then I applied the following patch:
>>
>> http://master.squid-cache.org/ amosjeffries ~ / patches /
>> pinning_hier_note.patch
>>
>> Now there is no more PINNED displayed in the logs, but even so the sites
>> do not display correctly.
> You should see PINNED for requests sent over correctly bumped SSL
> connections. AFAIK, Amos' patch fixes the wrong IPv6 address. The
> "PINNED" part before that IPv6 address was not wrong.
>
> Amos, will your pinning_hier_note.patch patch log forward bumped
> requests as non-PINNED?

The patch just causes the actually selected peer information to be
displayed instead of the next-retry peer. Initial testing of that patch
showed a second bug that the server connection was not marked PINNED
properly when the pinning was performed - so it showed as DIRECT in the
log mostly.

>
>> By accessing facebook.com first is the message's default browser: there
>> are connection problems. Pressing F5 displays properly Squid page with
>> the message Access Denied.
> Interesting. I do not know what exactly can cause that,

The difference is that F5 invokes the browser cache to be overridden.
There must be something stored there which is joining the transaction -
ie revalidating a cached object over the HTTPS connection making squids
error response act like a revalidate failed instead of a fetch failed.

> but let's start
> with fixing your configuration as discussed above.
>
>
> Thank you,
>
> Alex.
>

Amos
Received on Wed Mar 20 2013 - 05:20:01 MDT