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 -
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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
|
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
