This: 08/Sep/2015-17:41:38 11049 10.0.1.7 TCP_TUNNEL 200 12871 CONNECT api.github.com:443 api.github.com - peek Mozilla/5.0%20(Macintosh;%20Intel%20Mac%20OS%20X%2010.10;%20rv:40.0)%20Gecko/20100101%20Firefox/40.0 HIER_DIRECT/192.30.252.127 -
Compared to this: 08/Sep/2015-17:04:17 13359 10.0.1.7 TCP_TUNNEL 200 13741 CONNECT 192.30.252.126:443 api.github.com - splice - ORIGINAL_DST/192.30.252.126 - > On 8 Sep 2015, at 5:39 pm, Dan Charlesworth <d...@getbusi.com> wrote: > > Thanks Amos. > > To clarify about the user agents: I’m talking about anything with a (logged) > SSL bump mode of “splice” — I’m not expecting to see one for the synthetic > (“peek") connections. In this case it’s actually intercepted spliced > connections. > > Wondering why a spliced connection doesn't log a UA when an explicit CONNECT > does. > >> On 8 Sep 2015, at 5:17 pm, Amos Jeffries <squ...@treenet.co.nz >> <mailto:squ...@treenet.co.nz>> wrote: >> >> On 8/09/2015 5:36 p.m., Dan Charlesworth wrote: >>> Hello all >>> >>> I’ve been testing out an SSL bumping config using 3.5.8 for the last week >>> or so and am scratching my head over a couple of things. >>> >>> First, here’s my config (shout out to James Lay): >>> >>> acl tcp_level at_step SslBump1 >>> acl client_hello_peeked at_step SslBump2 >>> acl bump_bypass_domains ssl::server_name “/path/to/some/domains.txt" >>> ssl_bump splice client_hello_peeked bump_bypass_domains >>> ssl_bump bump client_hello_peeked >>> >>> 1. Why don’t spliced connections get a user agent logged like explicit >>> CONNECTs do? >> >> If you are talking about the synthetic CONNECT created on intercepted >> traffic it is because there is no User-Agent header and nothing to >> create one from. >> >> If you are seeing explicit CONNECT come in and not have a User-Agent >> header when they are spliced. That would seem to be a bug. The >> splice/bump stuff should not be affecting the original CONNECT message >> the client sent. >> >>> >>> 2. Safari produces this error visiting all sorts of websites (github, >>> wikipedia, gmail): >>> Error negotiating SSL connection on FD 15: error:140A1175:SSL >>> routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback (1/-1) >>> >>> … whereas Chrome and Firefox do not. What’s the story with this one? >> >> "inappropriate fallback" means the client is claiming it has been forced >> down to the SSLv3 (or some low/insecure TLS version) because no more >> secure version was permitted. But the server is aware that it does >> support a higher version. >> >> It can happen two ways: >> 1) somebody is MITM'ing the connection and performing the POODLE attack. >> >> 2) client has misconfigured TLS/SSL support. >> >> >> TLS agents are supposed to support a _continuous_ range of protocol >> versions from the set { SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3 >> }, the client states what it highest is and if it is in the servers set >> that gets used. If it gets rejected the client has to fallback to its >> next-lower version and try again. >> >> (2) happens when somebody pokes a hole by disabling one of the protocol >> versions in the middle of their otherwise supported range. Usually it is >> the client, but servers can do it too. When the 'hole' overlaps with the >> highest supported version of the other end the fallback mechanism breaks >> with the behaviour you see. >> >> >> The solution is to ensure the TLS versions supported by the client are a >> continuous range. >> >> * SSLv2 should be dead and buried. Disabled everywhere. Kill it ASAP if >> you see it enabled anywhere. >> >> * SSLv3 _should_ be disabled now too. Using it is actively dangerous. In >> the event that it cannot be disabled then TLSv1.0 through to the highest >> supported TLS version also *need* to be enabled. No poking holes to >> disable TLSv1.0 with SSLv3 still active. >> >> * TLSv1.0 is a good idea to disable. It is not dangerous yet but very >> will soon be, and there are a lot of its ciphers which _are_ actively >> dangerous and require disabling if its going to be allowed. The only >> reasons to have it enabled are old TLSv1.0-only software or when SSLv3 >> is required. >> >> >> Amos >> _______________________________________________ >> squid-users mailing list >> squid-users@lists.squid-cache.org <mailto:squid-users@lists.squid-cache.org> >> http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users