Discussion:
[squid-users] Very basic peek & splice
Ralf Hildebrandt
2018-09-27 08:43:20 UTC
Permalink
I recompiled my squid-5 with openssl and added

ssl_bump peek all
ssl_bump splice all

to my squid.conf. What logging should I expect to verify it's actually
working?
--
Ralf Hildebrandt Charite Universitätsmedizin Berlin
***@charite.de Campus Benjamin Franklin
https://www.charite.de Hindenburgdamm 30, 12203 Berlin
Geschäftsbereich IT, Abt. Netzwerk fon: +49-30-450.570.155
Amos Jeffries
2018-09-27 09:45:45 UTC
Permalink
Post by Ralf Hildebrandt
I recompiled my squid-5 with openssl and added
ssl_bump peek all
ssl_bump splice all
to my squid.conf. What logging should I expect to verify it's actually
working?
Depends on what you mean by 'working'.

Splicing will show up as access.log CONNECT messages to raw-IP on port
443 with 0ms duration and probably TCP_NONE status. Followed by CONNECT
from same client IP with either raw-IP or a domain, TCP_TUNNEL status
and non-0 duration.
These pairs may only be identifiable by using the duration to find that
they started at identical time from the same client. The log entries
will be separated by that duration.


'working' can also mean detecting TLS errors and rejecting them. Which
shows up as https:// requests being bumped and denied with a 5xx error
status.


Amos
Alex Rousskov
2018-09-27 16:07:34 UTC
Permalink
Post by Ralf Hildebrandt
I recompiled my squid-5 with openssl and added
ssl_bump peek all
ssl_bump splice all
to my squid.conf. What logging should I expect to verify it's actually
working?
Logging %ssl:bump_mode may be a good idea.

For a particular _spliced_ transaction, logging the server-provided
certificate details (e.g., %ssl::<cert_subject) would confirm that Squid
peeked at the certificate before splicing.

Besides %ssl:bump_mode, reliably distinguishing spliced connections from
bumped connections is difficult AFAICT because Squid does not have a
%code for Squid-sent server certificate details.

Please note that a successful splice using your configuration should
result in two CONNECT access.log entries. I am focusing on the second
one. See Amos response for more details regarding these two entries.


FWIW, I recommend using a few test cases to double check that your
verification method (whatever it is) works well for step3 splicing:

1. Successful splice with a trusted TLS server.
2. Failed splice with an untrusted TLS server.
3. Failed splice with a non-TLS (e.g., an HTTP) server.
4. Failed splice with a TLS server rejecting your TLS client.
5. Failed splice with a down server.
6. Failed splice with a server having an unresolvable DNS name.
...


HTH,

Alex.

Loading...