Le 09/02/2016 09:04, Willy Tarreau a écrit :
thanks for this. It looks clean enough to be merged.
I'm a little bit concerned with the addition of conn->ssl_detection_exp
because we try to keep the connection struct as small as possible. But
in this case there's no other place to store it. Thus I would change it
to "exp" and ensure it can be used by whatever requires an expiration in
the connection. That may be used in the future to wait for the proxy
protocol header or for outgoing connection timeout for example.
That also makes me wonder how we currently deal with a timeout during the
SSL handshake, I'll have to check this. Maybe something is redundant, I
don't remember.
There's something interesting in your approach. When we started to implement
SSL, I wondered if we could have a "tcp-request connection" rule such as
"expect-ssl" or something like this so that we could decide whether or not
we'll use SSL based on some ACLs. One of the difficulties I didn't solve
was the ability to specify the SSL parameters in the rule.
With your model we could easily imagine having a bind option to disable the
SSL upgrade by default, and only enable it once the correct rule has been
matched in tcp-request connection.
Hi Willy,
Thanks !
About the fallback timeout, maybe I missed something, but I didn't found
any parameter to set a timeout on the SSL handshake.
By the way, good point about the renaming of 'ssl_detection_exp' into
'exp'. It is always good to take a step back and think a minute on
possible extension :)
--
Christopher
