<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This:</div><div class=""><div style="margin: 0px; font-size: 12px; font-family: Menlo; color: rgb(248, 248, 248); background-color: rgb(16, 16, 16);" class="">08/Sep/2015-17:41:38 11049 10.0.1.7 TCP_TUNNEL 200 12871 CONNECT <a href="http://api.github.com" class="">api.github.com</a>:443 <a href="http://api.github.com" class="">api.github.com</a> - 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 -</div></div><div class=""><br class=""></div><div class="">Compared to this:</div><div class=""><div style="margin: 0px; font-size: 12px; font-family: Menlo; color: rgb(248, 248, 248); background-color: rgb(16, 16, 16);" class="">08/Sep/2015-17:04:17 13359 10.0.1.7 TCP_TUNNEL 200 13741 CONNECT 192.30.252.126:443 <a href="http://api.github.com" class="">api.github.com</a> - splice - ORIGINAL_DST/192.30.252.126 -</div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 8 Sep 2015, at 5:39 pm, Dan Charlesworth <<a href="mailto:dan@getbusi.com" class="">dan@getbusi.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks Amos.</div><div class=""><br class=""></div><div class="">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 <i class="">intercepted</i> spliced connections.</div><div class=""><br class=""></div><div class="">Wondering why a spliced connection doesn't log a UA when an explicit CONNECT does.</div><br class=""><blockquote type="cite" class="">On 8 Sep 2015, at 5:17 pm, Amos Jeffries <<a href="mailto:squid3@treenet.co.nz" class="">squid3@treenet.co.nz</a>> wrote:<br class=""><br class="">On 8/09/2015 5:36 p.m., Dan Charlesworth wrote:<br class=""><blockquote type="cite" class="">Hello all<br class=""><br class="">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.<br class=""><br class="">First, here’s my config (shout out to James Lay):<br class=""><br class="">acl tcp_level at_step SslBump1<br class="">acl client_hello_peeked at_step SslBump2<br class="">acl bump_bypass_domains ssl::server_name “/path/to/some/domains.txt"<br class="">ssl_bump splice client_hello_peeked bump_bypass_domains<br class="">ssl_bump bump client_hello_peeked<br class=""><br class="">1. Why don’t spliced connections get a user agent logged like explicit CONNECTs do?<br class=""></blockquote><br class="">If you are talking about the synthetic CONNECT created on intercepted<br class="">traffic it is because there is no User-Agent header and nothing to<br class="">create one from.<br class=""><br class="">If you are seeing explicit CONNECT come in and not have a User-Agent<br class="">header when they are spliced. That would seem to be a bug. The<br class="">splice/bump stuff should not be affecting the original CONNECT message<br class="">the client sent.<br class=""><br class=""><blockquote type="cite" class=""><br class="">2. Safari produces this error visiting all sorts of websites (github, wikipedia, gmail):<br class="">Error negotiating SSL connection on FD 15: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback (1/-1)<br class=""><br class="">… whereas Chrome and Firefox do not. What’s the story with this one?<br class=""></blockquote><br class="">"inappropriate fallback" means the client is claiming it has been forced<br class="">down to the SSLv3 (or some low/insecure TLS version) because no more<br class="">secure version was permitted. But the server is aware that it does<br class="">support a higher version.<br class=""><br class="">It can happen two ways:<br class="">1) somebody is MITM'ing the connection and performing the POODLE attack.<br class=""><br class="">2) client has misconfigured TLS/SSL support.<br class=""><br class=""><br class="">TLS agents are supposed to support a _continuous_ range of protocol<br class="">versions from the set { SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3<br class="">}, the client states what it highest is and if it is in the servers set<br class="">that gets used. If it gets rejected the client has to fallback to its<br class="">next-lower version and try again.<br class=""><br class="">(2) happens when somebody pokes a hole by disabling one of the protocol<br class="">versions in the middle of their otherwise supported range. Usually it is<br class="">the client, but servers can do it too. When the 'hole' overlaps with the<br class="">highest supported version of the other end the fallback mechanism breaks<br class="">with the behaviour you see.<br class=""><br class=""><br class="">The solution is to ensure the TLS versions supported by the client are a<br class="">continuous range.<br class=""><br class="">* SSLv2 should be dead and buried. Disabled everywhere. Kill it ASAP if<br class="">you see it enabled anywhere.<br class=""><br class="">* SSLv3 _should_ be disabled now too. Using it is actively dangerous. In<br class="">the event that it cannot be disabled then TLSv1.0 through to the highest<br class="">supported TLS version also *need* to be enabled. No poking holes to<br class="">disable TLSv1.0 with SSLv3 still active.<br class=""><br class="">* TLSv1.0 is a good idea to disable. It is not dangerous yet but very<br class="">will soon be, and there are a lot of its ciphers which _are_ actively<br class="">dangerous and require disabling if its going to be allowed. The only<br class="">reasons to have it enabled are old TLSv1.0-only software or when SSLv3<br class="">is required.<br class=""><br class=""><br class="">Amos<br class="">_______________________________________________<br class="">squid-users mailing list<br class=""><a href="mailto:squid-users@lists.squid-cache.org" class="">squid-users@lists.squid-cache.org</a><br class=""><a href="http://lists.squid-cache.org/listinfo/squid-users" class="">http://lists.squid-cache.org/listinfo/squid-users</a><br class=""></blockquote><br class=""></div></div></blockquote></div><br class=""></body></html>