[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:
  - default: peek all
  - or run ssl_bump check if that directive exists

  - default: splice all
  - or run ssl_bump check if that directive exists

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


More information about the squid-dev mailing list