[squid-dev] [RFC] simplifying ssl_bump complexity
Amos Jeffries
squid3 at treenet.co.nz
Sat Nov 19 10:07:58 UTC 2016
Since ssl_bump directive went in my original opinion of it as being too
complicated and confusing has pretty much been demonstrated as correct
by the vast amount of misconfigurations and failed attempts of people to
use it without direct assistance from those of us involved with its design.
Since we are also transitioning to a world where 'SSL' does not exist
any longer I think v5 is a good time to rename and redesign the
directive a bit.
I propose going back to the older config style where each step has its
own directive name which self-documents what it does. That will reduce
the confusion about what is going on at each 'step', and allow us a
chance to have clearly documented default actions for each step.
For example:
tls_new_connection
- default: peek all
- or run ssl_bump check if that directive exists
tls_client_hello
- default: splice all
- or run ssl_bump check if that directive exists
tls_server_hello
- default: terminate all
- or run ssl_bump check if that directive exists
The main consideration here is that the default behaviour/actions are
both a) that legal in almost all jurisdictions users will be working in,
and b) let client connections work if the admin does not configure
anything different (ie peek + splice).
Those for whom even peeking is not wanted can configure
'tls_new_connection splice all'.
The terminate on step3/server_hello is so that if the admin configures
the earlier steps in a broken way without also configuring what to do at
the later step it shows up as an immediate connection failure.
Amos
More information about the squid-dev
mailing list