[squid-users] Cannot display page correctly with SSL-Bump

[Rino M Nur]

Hi,

Im trying to get ssl bump work correctly but when i get a site with https
then browser display the page with no CSS or javascript.
log :
1417149172.053175 192.168.10.10 TAG_NONE/200 0 CONNECT i.ytimg.com:443
- HIER_DIRECT/74.125.130.102 -
1417149172.145194 192.168.10.10 TAG_NONE/200 0 CONNECT i.ytimg.com:443
- HIER_DIRECT/74.125.130.102 -
1417149172.181156 192.168.10.10 TAG_NONE/200 0 CONNECT i.ytimg.com:443
- HIER_DIRECT/74.125.130.102 -
1417149172.220169 192.168.10.10 TAG_NONE/200 0 CONNECT i.ytimg.com:443
- HIER_DIRECT/74.125.130.102 -
1417149172.299348 192.168.10.10 TAG_NONE/200 0 CONNECT i.ytimg.com:443
- HIER_DIRECT/74.125.130.102 -

my configuration :
http_port 3130 ssl-bump generate-host-certificates=on
dynamic_cert_mem_cache_size=4MB key=/etc/squid/cert/private.pem
cert=/etc/squid/cert/public.pem
http_port 3128
http_port 192.168.10.50:3129 intercept

squid version :
Squid Cache: Version 3.4.9
configure options:  '--prefix=/usr' '--exec_prefix=/usr'
'--bindir=/usr/sbin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib/squid'
'--sysconfdir=/etc/squid' '--localstatedir=/var/spool/squid'
'--datadir=/usr/share/squid' '--enable-http-gzip' '--enable-async-io=24'
'--with-aufs-threads=24' '--with-pthreads' '--enable-storeio=aufs'
'--enable-linux-netfilter' '--enable-arp-acl' '--enable-epoll'
'--enable-removal-policies=heap' '--with-aio' '--enable-snmp'
'--enable-delay-pools' '--enable-htcp' '--enable-cache-digests'
'--disable-unlinkd' '--enable-large-cache-files'
'--enable-err-languages=English' '--enable-default-err-language=English'
'--with-maxfd=65536' '--enable-ssl-crtd' '--enable-zph-qos'
'--with-default-user=proxy' '--with-logdir=/var/log/squid'
'--with-pidfile=/var/run/squid.pid' '--with-swapdir=/var/spool/squid'
'--with-aufs-threads=32' '--with-dl' '--with-large-files' '--with-openssl'
'--enable-ssl' 'CFLAGS=-march=nocona -O2 -pipe' --enable-ltdl-convenience

os :
debian wheezy


the page (youtube ) is displaying like this :


   -What to Watch
   - My Subscriptions 
   - Music 


   -
  -   What to Watch  
  -   My Channel  
  -   My Subscriptions  
  -   History  
  -   Watch Later  1  
--
-  Playlists
   
-   Liked videos
  
 More
  --
-  Subscriptions 
 -JackThammarat
  
 More
  --
-
  -   Browse channels  
  -  
   Manage subscriptions
   
  
  
  -
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Existing root certificate not working with SSL Bump (squid 3.3.10)

[HaxNobody]

Alright, I figured out a possible cause. I downloaded the certificate that
the browsers were complaining about, and used openssl verify to verify
against the root certificate that I have. I got error 20, indicating that
squid must not be using the correct root certificate to generate the client
certificate on the fly, or that it is being generated incorrectly. The
generated certificate shows all the correct properties of the root
certificate that I am using, so my conclusion is that squid is incorrectly
generating the client certificate.

Question: Under what circumstances might squid incorrectly generate a bump
certificate?
Another question: Why might it be working when I use a different root
certificate?



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Existing-root-certificate-not-working-with-SSL-Bump-squid-3-3-10-tp4668515p4668527.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Existing root certificate not working with SSL Bump (squid 3.3.10)

[HaxNobody]

Thanks for the reply. I'm aware of pinning, but this problem is happening on
small and/or insignificant sites that are certainly not pinned, as well as
the larger sites. In addition, our clients are not getting errors due to
pinning on our existing proxy setup, so we're doing something correctly
there.

Unfortunately, the squid version that I have is something that I can't
change, because it's supplied on a hardware appliance by our vendor. I can
try to get them to update it, but I don't think I will get very far. As it
is, they have done some extensive custom configuration for us, specifically
relating to the ability to use both HTTP and HTTPS traffic over the same
port while retaining full SSL interception capabilities.

The annoying thing is that none of the browsers I am using will give me any
useful information as to why they are hating my setup. I don't really know
the best way to validate the output of my proxy server. Openssl would seem
like a good place to start - is there any way to tell it to use a proxy when
I want to try using the s_client feature and see how the certificate
validates? 



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Existing-root-certificate-not-working-with-SSL-Bump-squid-3-3-10-tp4668515p4668526.html
Sent from the Squid - Users mailing list archive at Nabble.com.
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

[squid-users] Minor nit with cachemgr.cgi in 3.5.0.2

[Holger Hoffstätte]

Spam detection software, running on the system "master.squid-cache.org",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Hi, I just thought I'd give 3.5.0.2 a workout and so far it
   seems to be working fine. One minor nit I found was on the initial page of
   cachemgr.cgi: the "server" field now contains two blank lines, whereas 
previously
   it would always contain only the (correct) localhost. [...] 

Content analysis details:   (7.3 points, 5.0 required)

 pts rule name  description
 -- --
 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL
[79.245.130.44 listed in zen.spamhaus.org]
 1.3 RCVD_IN_RP_RNBLRBL: Relay in RNBL,
https://senderscore.org/blacklistlookup/
[79.245.130.44 listed in bl.score.senderscore.com]
 0.2 CK_HELO_GENERICRelay used name indicative of a Dynamic Pool or
Generic rPTR
 0.0 FREEMAIL_FROM  Sender email is commonly abused enduser mail 
provider
(holger.hoffstaette[at]googlemail.com)
 0.9 SPF_FAIL   SPF: sender does not match SPF record (fail)
[SPF failed: Please see 
http://www.openspf.org/Why?s=mfrom;id=gcwsg-squid-users%40m.gmane.org;ip=79.245.130.44;r=master.squid-cache.org]
 0.0 T_HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
domains are different
 0.0 UNPARSEABLE_RELAY  Informational: message has unparseable relay lines
 0.0 T_FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
EnvelopeFrom freemail headers are different
 1.3 RDNS_NONE  Delivered to internal network by a host with no rDNS


--- Begin Message ---

Hi,

I just thought I'd give 3.5.0.2 a workout and so far it seems to be
working fine. One minor nit I found was on the initial page of
cachemgr.cgi: the "server" field now contains two blank lines, whereas
previously it would always contain only the (correct) localhost.

After some digging the reason seems simple enough: the cachemgr.conf
by default contains two empty lines which are blindly added as
form input values.

Removing those two empty lines (or replacing them with comments)
only leaves the default "localhost" in place, just like before.

Hope that helps. :)

Thanks for squid!

-h

--- End Message ---
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Problem with digest authentification and credential backend

[wmunny william]

> 
> William to be more clear this patch is not related at all with 
> authenticate_ttl directive.
> authenticate_ttl doesn't works with Digest, but with basic and maybe another 
> (ntlm, kerberos ?) there is no precision here 
> http://www.squid-cache.org/Doc/config/authenticate_ttl/
> 
> The patch works like this:
> 
> At first banner Squid store the login/password HASH 
> http://en.wikipedia.org/wiki/Digest_access_authentication 
> http://wiki.squid-cache.org/KnowledgeBase/LdapBackedDigestAuthentication 
> 
> When nonce is stalled (nonce_max_count reached) the helper compare the 
> account stored in memory with a request to Ldap or/and when the nonce is 
> expired, the helper makes the same thing.
> 
> In this two cases there are two possibilities, the account is right or wrong 
> -> Bad password or/and bad login
> 
> - If the return is right Squid return a new nonce and there is no impact for 
> the user, I mean no banner.
> - If the return is wrong Squid present the authentication realm to the user 
> and the browser prompt for a username and password.
> 
> There is also an another situation - if squid is restarted - the browser 
> returns is HASH without banner (if the account is right of course)
> 
> So, without any change in LDAP the banner never appear, except when the 
> browser start.
> 
> Fred 
> 
> PS: About Digest you are right it's almost good now, still also a little 
> problem with nonce count but not related with this 
> 

Hi,

Ok, thanks,

Tested with both nonce_count and nonce_max_duration, no problem. Do you known 
if it works with squid 3.5 ?

___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] squid 3.5x: Active Directory accounts with space issue

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/11/2014 12:01 a.m., David Touzeau wrote:
> Hi
> 
> We have connected 3.5.0.2-20141121-r13666 with Active Directory. It
> seems where there are spaces in login account squid use only the
> last argument.
> 
> For example for an account "Jhon smith" squid use "smith" only For
> example for an account "Dr Jhon smith" squid use "smith" only
> 
> In 3.3.13 there is no such issue, a "Jhon smith" account is logged
> as "Jhon smith" and sended as Jhon%20smith to helpers

Any information about the auth Scheme being performed?
 the helpers being used?
 and what is being sent to/from the helpers in 3.5 different from the
3.3 version?

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUdasMAAoJELJo5wb/XPRjRPUH/2aVKrtNdmJzupzsN9JtcOK0
1e+NIxNSaDiyu9R03eJrwlAy7g9zFGEj+0dI1HgJz36Mf2i03ahbyinD4GwFDVPh
a6iYyCPrhy2XDeL16qcSqsX0i2e8yXO/WRbFTJymKMOFhVDS05Bg6KuE1FroNjHG
OkhpzN/T3O1fUW2k0XSRZEWFV1YnriwcCLdKXdsXEXEIIA3J9ZN0WQZ8I/oGXfWV
S4xHKh4jnDFJCEO5lwYxT1CDe53CCHnPfV9Uf1Dhq6AkKnDZAR8U53Uyhji4V6ck
UzwZEPMAtK73O3uXn0J2l2S9v0ga5ymHRhiWADG2jC/8dyAc0ICaWFjK7o6wMfE=
=GaV2
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] External ACL with an HTTP reply header format doesn't

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25/11/2014 9:53 a.m., Jorge Iván Burgos Aguilar wrote:
> Hi again,
> 
> Solved by using %<{Content-Type} log format instead of the one with
> an additional h with it (recommend while running squid -k parse). 
> Actually is a bug in the code handling the parsing of the external
> acl's but here is not the place to discuss it, i will open a new
> one bug report asap on bugs.squid-cache.org
> 

For the record Jorge opened
http://bugs.squid-cache.org/show_bug.cgi?id=4148

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUdaaRAAoJELJo5wb/XPRj7nkH/jVAKc4/IQx1MdfUbSQvmtSy
1GpkJOW0XzqoYgU4tU7v5d1pbPHHGHlE1d5lNx5hgUfEW8bTlOz5KkZJe6CdLja4
z7g96hzz8ih5XvVlwKLD+Vxp+eSR7YuZUpHr60wQPOqxn7GA7eh04Ch7kXmVx7nk
G3W4o3BBJwlFC16H+xAP+B7YU3V20Rn4/NagH4LGWDkcuunLZVZosSWb8r4w68tK
X7kbdIHpQ9zJjuHEvq4LZ9EfJKM4vo+NZgUpfq3JHxmRq9QoUvianpjG7B4enNON
MNIXiAtphD0vI3r7kUY5I2AYd90DyHvP4EJ2kUJJgT6YxPHFck3Zn832HL0/iHs=
=/vKz
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Existing root certificate not working with SSL Bump (squid 3.3.10)

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/11/2014 5:38 a.m., HaxNobody wrote:
> Hello,
> 
> We are trying to configure Squid with SSL bump in order to filter
> traffic with a content filter. We have an existing self-signed root
> certificate and private key that we use successfully with other
> similar proxy software, and we wish to re-use it with Squid so that
> we don't have to distribute a new root certificate to our clients.
> 
> However, when we try to use our existing root with Squid, we get
> SSL errors from the browser and we are quite stumped as to why they
> are happening.

The story begins here:
https://www.imperialviolet.org/2011/05/04/pinning.html

.. the other browsers picked up and also started pinning domain
certificates some time ago.

The rest of the story is that Squid 3.3 is now quite old and in terms
of ssl-bump specifically is it outright obsolete technology. Your best
chance is to upgrade to the latest release and try again. A fix will
only be worth fixing (or even investigating) if the problem persists
with the latest Squid-3.5 (beta) ssl-bump features.

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUdaEkAAoJELJo5wb/XPRjCqEH/AhtJLeDaFEJfNDodZkcPLU/
KlvBtvPKQBkint01uNYONNSH5VEIRGBwoDcLmMeczswforgUjQPB6RfQEFbf0KU0
6vGT2c7i2l+vYHY4OBEkCFN1DklW/Z/caPjKfN8C2bJw863CtYLoMi3LUHH46txC
3xLeRHGerWY6AGUcSwvw0V33zGrhxXHgPugii6iTQ6juaCOJxpKiEyftwYGuCZxa
y1r4htpskSUjlJBX1N6Fj1cSuJ8L9rpsubEts/ENDeuPWj/YXHPX/N9iFhLQ6Trr
bMH9zc/CHOpxYJNJQIjnowQNMh2oeEc3pISnSRSgoEDEXZ28kg9qi97SdeR8ayQ=
=N4Au
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Re: [squid-users] Transparent proxy with Peek and Splice feature.

[Amos Jeffries]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26/11/2014 7:22 a.m., Vadim Rogoziansky wrote:
> Hello All.
> 
> My goal is to do ssl bumping in transparent proxy mode with domain 
> exclude possibility. Let me tell you about squid's strange
> behaviour when I'm trying to do it.
> 
> In browsers it says something like this: /This server could not
> prove that it is www.ukr.net; its security certificate is
> from212.42.76.253. This may be caused by a misconfiguration or an
> attacker intercepting your connection.// 
> //NET::ERR_CERT_COMMON_NAME_INVALID// //Subject: 212.42.76.253// / 
> Looks like squid takes the CN from the certificate as IP address of
> the destination domain.

Squid takes the IP address from the TCP packet. Which is all that is
available in NAT intercepted traffic at bumping step #1.

The ACLs you have therefore determine that "bump" action is to happen.
Correct?

The cert details are therefore mimic'ed from what gets delivered by
the server.

It may be that the server is depending on SNI to generate its own
cert, but since Squid deos not have that domain name already an
IP-based cert comes back.

It may also be that some ISP upstream of you is bumping the encryption
with client-first method.



> But, everything works smoothly when I use proxy in non transparent
> mode and put it to the browser directly .

In which case the browser sends domain name to the proxy in its
CONNECT message starting the HTTPS. The possible results are very
different.

Amos

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUdZ5sAAoJELJo5wb/XPRj0qIIANBjuFvq45hPmcaj/NYL6bza
7ttt5Gn+tn8E5KH7T4wfQhUXr91UIsYWfOswfnVAAlBevIO/iFVoDN5hAOveuhIl
ra/0eGti1EpZ3LHJiAqmo0mHsrz3v9+PAduVrXgUJLyYDiM0xctg0nRhj2u166VX
j0IL3g8CKEw+KiWVJM9HdLaDEz9fYtHBO8UHhKDDE94O9yxScIvB+GAhN4YlTtrE
z65VJkSCEw+3vH6XcrrkF2aEnB20jeEGiV5puO2cPoJpgcg3ic8sMVEfa/Z1qwqa
KCkj2XI28wBCIovCV+AfBhpvW0o8eVFbt4ESodLTmwjUvU+m8zxky/9cjO5kyLE=
=kgug
-END PGP SIGNATURE-
___
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users