[squid-users] SSL Bump matching Subject Alternative Names

[Cohen-Rose, Adam]

On 27/02/2016 01:54, "squid-users on behalf of Amos Jeffries"
<squid-users-bounces at lists.squid-cache.org on behalf of
squid3 at treenet.co.nz> wrote:


>On 27/02/2016 6:33 a.m., Cohen-Rose, Adam wrote:
>> Amos, thanks so much for your help -- we're now seeing those requests
>>get
>> through when they were just being dropped before.
>>
>> We still have a couple of puzzles left...
>>
>>
>> Firstly, we're not seeing those cdn.teads.tv requests being marked as
>> spliced in our access log, despite including the %ssl::bump_mode
>> %ssl::>sni fields in our logformat.
>>
>> We do see some other whitelisted hosts in the access logs -- they appear
>> as a couple of lines, the first one saying "...TAG_NONE:HIER_NONE peek
>> [hostname]" and the second saying "...TCP_TUNNEL:ORIGINAL_DST splice
>> [hostname]")
>>
>> However, the cdn.teads.tv requests log the first of those lines (the
>> "...TAG_NONE:HIER_NONE peek [hostname]") followed by a second peek log
>> line "...TCP_TUNNEL:ORIGINAL_DST peek [hostname]" but no splice (even
>> though the requests do appear to be spliced as we¹re getting traffic!)
>
>
>I'm not sure about that one. Things only get logged on completion
>though, so is it possible they are just very long active connections?


We¹re still seeing this ‹ even for connections from curl where the client
process totally finishes. Not sure what¹s going on here with the logging,
but it works from a client point of view.



>>Secondly, we deal with a *lot* of traffic through our SSL bumping proxy
>> and we are finding that Squid is using a lot of memory -- often running
>> out and needing to be restarted!
>
>There are some leaks being fixed right up to the latest release.
>And OpenSSL has a tendency to attach things into sessions and contexts
>which can cause a lot of memory. We are working to minimize that, but
>its taking a while.
>
>Looking at using flags=NO_DEFAULT_CA on your http(s)_port lines if you
>have a Squid older than 4.0.4. Default CA use a lot of memory
>per-session and are useless on client connections, usually on cache_peer
>too but that latter varies.


Thank you, adding sslflags=NO_DEFAULT_CA to our https_port line made a
massive difference! CPU time and latency dropped by two thirds :-)


We¹re planning to test how switching to an SMP config affects performance
‹ will hopefully post our results when we see them.


One remaining puzzle: we see the latency creep upwards overnight when the
traffic drops ‹ reaching 140ms when it¹s normally 25ms. Is this just an
artefact of the servers being lightly loaded?


Thanks once again for your help!

Adam

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.