[squid-users] 3.5.8 — SSL Bump questions

[Amos Jeffries]

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