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> 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
> 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
