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? > > Also, should we expect to see the terminated requests being logged? IIRC terminated requests not being logged is an open bug. > > 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. > > We’re currently using multiple squid instances as per > http://wiki.squid-cache.org/MultipleInstances to handle the traffic. Would > we be better using SMP Squid as per > http://wiki.squid-cache.org/Features/SmpScale ? > Either or both. They each have different benefits, which may or may not be a priority for you. > And what are some good ways to inspect or manage the squid instances’ > memory usage? And what rough level of memory usage should we expect? All > our cacheing is turned off -- we’re just using squid as access control. SNMP reports querying both squid and the machine itself are good. The squid cachemgr 'mem' report is a good snapshot for spot checking whats causing teh most usage if you know there is a problem already. > > > Thank you once again! Happy to help with more details of our config if > required. > > Adam > > > > > > On 25/02/2016 22:18, "squid-users on behalf of Amos Jeffries" > <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx on behalf of > squid3@xxxxxxxxxxxxx> wrote: > >> On 26/02/2016 12:38 a.m., Cohen-Rose, Adam wrote: >>> We¹re trying to use SSL bump to splice traffic from a CDN (cdn.teads.tv) >>> >>> The CDN server certificate uses Subject Alternative Names in its >>> certificate to identify the cdn.teads.tv domain rather than the Common >>> Name (which is set to aka.proceau.net). >>> >>> Can we use SSL bump to splice requests to cdn.teads.tv or do we need to >>> use the CN domain to identify the CDN? >> >> Yes the ssl::server_name ACL type matches SubjectAltName in the server >> certificate during *step 3* of the ssl_bump process. >> >> You first have to peek/stare at the serverHello data to get it. >> >> >>> >>> >>> We¹d like to terminate other connections so our current SSL Bump config >>> is: >>> >>> acl tcp_level at_step SslBump1 >>> acl client_hello_peeked at_step SslBump2 >>> ssl_bump peek tcp_level all >> >> NP: the " all" is meaningless. >> >>> >>> acl to_teads_tv_ssl ssl::server_name cdn.teads.tv >>> >>> ssl_bump splice client_hello_peeked to_teads_tv_ssl >>> >> >> That deals with the cases where SNI matched. But the serverHello is >> still not known yet, so the SubjectAtName is not known. >> >> The terminate will happen on step2 if the SNI did not match. You need to >> peek/stare again to move on to the cert details. >> >>> ssl_bump terminate all >>> >> >> >> Why dont you try this: >> >> # splice whenever cdn.teads.tv is identified >> ssl_bump splice to_teads_tv_ssl >> >> # peek at both clientHello or serverHello data >> acl hello at_step SslBump1 SslBump2 >> ssl_bump peek hello >> >> # otherwise terminate >> ssl_bump terminate all >> >> >> Amos >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users > > 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 o ffice at Grant Way, Isleworth, Middlesex TW7 5QD. > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
