[squid-users] 3.5.8 — SSL Bump questions

[Dan Charlesworth]

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 <dan at 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 <squid3 at treenet.co.nz <mailto:squid3 at 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 at lists.squid-cache.org <mailto:squid-users at lists.squid-cache.org>
>> http://lists.squid-cache.org/listinfo/squid-users
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20150908/be6fa92e/attachment.html>