<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    -----BEGIN PGP SIGNED MESSAGE----- <br>
    Hash: SHA256 <br>
     <br>
    No, the problem in another place.<br>
    <br>
    This option about ICQ, not about Skype.<br>
    <br>
    29.06.2016 22:58, Renato Jop пишет:<br>
    <span style="white-space: pre;">> I've installed squid4 and the
      problems still persists. I've added the following acl:<br>
      > # define what Squid errors indicate receiving non-HTTP
      traffic:<br>
      > acl foreignProtocol squid_error ERR_PROTOCOL_UNKNOWN
      ERR_TOO_BIG<br>
      > # define what Squid errors indicate receiving nothing:<br>
      > acl serverTalksFirstProtocol squid_error
      ERR_REQUEST_START_TIMEOUT<br>
      > # tunnel everything that does not look like HTTP:<br>
      > on_unsupported_protocol tunnel foreignProtocol<br>
      > # tunnel if we think the client waits for the server to talk
      first:<br>
      > on_unsupported_protocol tunnel serverTalksFirstProtocol<br>
      > # in all other error cases, just send an HTTP "error page"
      response:<br>
      > on_unsupported_protocol respond all<br>
      ><br>
      > Renato Jop<br>
      ><br>
      > On Wed, Jun 29, 2016 at 8:21 AM, Renato Jop
      <<a class="moz-txt-link-abbreviated" href="mailto:renjop@gmail.com">renjop@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:renjop@gmail.com"><mailto:renjop@gmail.com></a>> wrote:<br>
      ><br>
      >     I've installed LibreSSL 2.2.9 and the issue still
      persists.<br>
      >     I think I am going to have install squid4 even if it's
      still in beta to solve this issues.<br>
      >     Thanks for your help.<br>
      ><br>
      ><br>
      >     Renato Jop<br>
      ><br>
      >     On Mon, Jun 27, 2016 at 9:36 AM, Renato Jop
      <<a class="moz-txt-link-abbreviated" href="mailto:renjop@gmail.com">renjop@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:renjop@gmail.com"><mailto:renjop@gmail.com></a>> wrote:<br>
      ><br>
      >         Is there a way to verify that the SSL library doesn't
      support SSLv3?<br>
      ><br>
      >         Renato Jop<br>
      ><br>
      >         On Mon, Jun 27, 2016 at 8:43 AM, Yuri
      <<a class="moz-txt-link-abbreviated" href="mailto:yvoinov@gmail.com">yvoinov@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><mailto:yvoinov@gmail.com></a>> wrote:<br>
      ><br>
      >             Looks like your SSL library does not contain
      SSLv3 protocol support already, but site announce it.<br>
      ><br>
      ><br>
      >             27.06.2016 20:42, Renato Jop пишет:<br>
      >>             I removed the NO_SSLv2, NO_SSLv3 however,
      right before the SSL3_GET_<a class="moz-txt-link-freetext" href="RECORD:wrong">RECORD:wrong</a> version number the SSL
      routines:SSL23_GET_SERVER_HELLO:unknown protocol is shown.<br>
      >><br>
      >>             Renato Jop<br>
      >><br>
      >>             On Mon, Jun 27, 2016 at 8:29 AM, Yuri
      <<a class="moz-txt-link-abbreviated" href="mailto:yvoinov@gmail.com">yvoinov@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><mailto:yvoinov@gmail.com></a>> wrote:<br>
      >><br>
      >>                 Try to remove NO_SSLv2,NO_SSLv3 from
      options. SSLv2 already not supported everywhere, RC4/3DES is SSLv3
      ciphers, so it can be confuse software. I.e., you use custom
      ciphers/protocols combinations, which can lead issue.<br>
      >><br>
      >><br>
      >>                 27.06.2016 20:25, Renato Jop пишет:<br>
      >>>                 Thank you both for your valuable
      help.<br>
      >>>                 I've configured the tls-dh param with
      a strong Diffie-Hellman group (2048 bits) and configured the
      cipher as Yuri specified and I was able to get pass the unknown
      cipher, however now I get a "SSL routines:SSL3_GET_<a class="moz-txt-link-freetext" href="RECORD:wrong">RECORD:wrong</a>
      version number". Here's the configuration I changed:<br>
      >>>                 
      cipher=HIGH:MEDIUM:RC4:3DES:!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!SRP:!DSS
      dhparams=/etc/dh-parameters.2048
      options=NO_SSLv2,NO_SSLv3,SINGLE_DH_USE
      tls-dh=/usr/local/etc/squid/dhparams.pem<br>
      >>><br>
      >>><br>
      >>><br>
      >>>                 Renato Jop<br>
      >>><br>
      >>>                 On Sat, Jun 25, 2016 at 11:34 AM,
      Yuri Voinov <<a class="moz-txt-link-abbreviated" href="mailto:yvoinov@gmail.com">yvoinov@gmail.com</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:yvoinov@gmail.com"><mailto:yvoinov@gmail.com></a>> wrote:<br>
      >>><br>
      >>><br>
      ><br>
      ><br>
      > 25.06.2016 <a class="moz-txt-link-rfc2396E" href="tel:25.06.2016"><tel:25.06.2016></a> 23:09, Amos Jeffries пишет:<br>
      > > On 26/06/2016 4:32 a.m., Yuri Voinov wrote:<br>
      > >><br>
      > >> Amos, you are a wrong.<br>
      > >><br>
      > >> No Squid-4. It's unstable and not ready for
      production. Whenever it's<br>
      > >> features.<br>
      ><br>
      > > So some beta software has bugs therefore nobody should
      ever use it for<br>
      > > anything. I find that to be a strange and sad view of
      the world.<br>
      ><br>
      > > Care to guess why I listed it as the last option amongst
      several?<br>
      > >  Or why 4.0.11 exists as a beta still?<br>
      > > It *is* an option for the mentioned problem(s) though
      whatever its<br>
      > utility.<br>
      > Agreed.<br>
      ><br>
      ><br>
      ><br>
      > >><br>
      > >> Some time ago I have the same issue and know what
      happens exactly.<br>
      > >><br>
      > >> Skype initial connection site uses RC4 cipher. Which
      is disabled in most<br>
      > >> squid's configuration.<br>
      ><br>
      > > Your "know what happens exactly" differs from at least
      two other peoples<br>
      > > debugging experiences with Skype.<br>
      ><br>
      > > RC4 is on the hitlist for most of the big vendors for
      the past year or<br>
      > > so. IIRC there were several Windows Updates to remove it
      and other<br>
      > > broken bits from a lot of things over the past year.<br>
      > > If Skype is still using RC4 it might be part of this
      problem.<br>
      > I'm sure this is problem and this problem exists. MS do
      nothing to make<br>
      > they sites/services more secure. BTW, MS Updates uses RC4
      ciphers itself<br>
      > this time. With strong siphers there is no way to setup WU
      via Squid.<br>
      > I've spent much time to identify this problem in my setup and
      find<br>
      > working workaround.<br>
      ><br>
      > Another part of problem is: MS often uses it's own
      self-signed roots,<br>
      > which is exists in Windows, but nowhere else. And which has
      not<br>
      > cross-signed by well-known root CA's. They think it make MS
      services<br>
      > more secure. They wrong. But we can't do anything with it.
      So, this is<br>
      > forced us to add self-signed MS roots to our Squid's CA
      bundles to<br>
      > bump/splice.<br>
      ><br>
      ><br>
      > >><br>
      > >> To make it works (as by as most M$ update sites)
      it's require simple use<br>
      > >> this cipher's suite:<br>
      > >><br>
      > >>
      HIGH:MEDIUM:RC4:3DES:!aNULL:!eNULL:!LOW:!MD5:!EXP:!PSK:!SRP:!DSS<br>
      > >><br>
      > >> That works for me in 5 SSL bumped setups. There is
      no matter which squid<br>
      > >> version installed.<br>
      ><br>
      > > Thank you. Thats another option then. I'd rate that
      below trying the EC<br>
      > > ciphers, and above library updates.<br>
      > You are welcome.<br>
      ><br>
      > Just for information: MS has own IT infrastructure, with some
      strange<br>
      > configured and non well-managed elements. I can't guarantee
      this<br>
      > workaround will work everywhere or for every MS service.<br>
      ><br>
      > When I made my research, I've seen some strange security TLS<br>
      > combinations on MS sites/services. I.e., for example,
      RC4+ECDSA+TLSv1.2.<br>
      > Or, for example, RC4+MD5+TLSv1. And some similar. Very
      idiotic and<br>
      > potentially dangerous combinations. And - they support
      ignores all<br>
      > requests. As usual.<br>
      ><br>
      > To my regret, I can not order all of its users to abandon the
      use of<br>
      > Windows. So far, in my infrastructure have machines with
      Windows XP.<br>
      ><br>
      > With this nothing can be done, it is necessary only to weaken
      the<br>
      > security - for the sake of compatibility.<br>
      ><br>
      ><br>
      > > Amos<br>
      > > _______________________________________________<br>
      > > squid-users mailing list<br>
      > > <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto:squid-users@lists.squid-cache.org></a><br>
      > > <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      ><br>
      >>><br>
      >>><br>
      >>>                    
      _______________________________________________<br>
      >>>                     squid-users mailing list<br>
      >>>                     <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
      <a class="moz-txt-link-rfc2396E" href="mailto:squid-users@lists.squid-cache.org"><mailto:squid-users@lists.squid-cache.org></a><br>
      >>>                    
      <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
      >>><br>
      >>><br>
      >><br>
      >><br>
      ><br>
      ><br>
      ><br>
      ></span><br>
    <br>
    -----BEGIN PGP SIGNATURE-----
<br>
    Version: GnuPG v2
<br>
     <br>
    iQEcBAEBCAAGBQJXdAMLAAoJENNXIZxhPexG418IAMQwpVRq1iFSGRCVAA9mIcHc
<br>
    1ru7T00FRr3wKNrm6hCaeI3TgW9eAMguYG7wYbFqbOOZMWp0k/sFYqAGWwxhZGA4
<br>
    +lEB/P5/+PJbg89MSYvTPjRrmf0XYtgwwCuZD+7oC0VSmdldhhaXgJYTi+lfVKZQ
<br>
    p+P0X41y2Alfzjl2NqqJGN7Oyc35Av617YzsrjKN3MgSH6LDh+h7vhin75q/zXD8
<br>
    TsRYAlqxsXAA5pvTbUrjVG7lruuavTGmKFpa79jZpkzlbkMEUW+088LeunkdP+V9
<br>
    e2L6MlY6J10Jir3vwHFHYJJh4hbGYkJf4TdnZuV3itD937GebNOjqChMm8h7ER8=
<br>
    =ThrU
<br>
    -----END PGP SIGNATURE-----
<br>
    <br>
  </body>
</html>