[squid-users] 3.5.8 — SSL Bump questions

[Dan Charlesworth]

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> 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
> 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/3f6fd4df/attachment-0001.html>