On Thu, Aug 20, 2020 at 04:59:49PM +0300, Thorsten Habich wrote:
> > - Do FAILURES happen ONLY after a session is RESUMED.
>
> Sorry, no. The first connection decides if the problem occurs or not.
> If the session is resumed the error only occurs *if the first
> connection failed*.
Thanks for the answer. This means that there are no issues recording
the proper validation status in the session cache, and the issue is
entirely validation failure on initial handshake.
I don't recall seeing any logging posted showing those initial
validation failures. This might be as good a time as any to address
that (the failure logs for the initial connection should have been part
of the post that started this thread).
> If the first connection was successful the error will not appear. The
> status then seem to change in case of a restart (as clarified by Victor
> that clears the session cache) or after I assume
> tlsproxy_tls_session_cache_timeout (default: 3600).
>
> In the examples I found in our logs, after a failed connection, the
> first successful delivery without a restart was made after 1h + x minutes.
This is of course expected. With a 1h session cache lifetime, new full
handshakes happen only after the previous saved session has expired. I
would recommend a shorter session lifetime for now. It will help to get
a better handle on the problem, by doing the initial handshake more
frequently.
> For sessions which do not get resumed at all the error occurs
> frequently, too.
Yes, that's why you're seeing problems on resumption.
> If I remember correctly the certificate verification with connection
> reuse (so the tlsproxy gets involved) was fixed with:
You keep talking about connection reuse, as though it were somehow
relevant, even though I haven't seen anything in this thread that
suggests that connection reuse is in any involved. Why do you
believe that connection reuse is a factor in this issue?
I hope you're not still conflating session resumption with connection
reuse.
--
Viktor.
