However I have a good news. I found that it was possible to access the
connection from the verify callback! With a connection comes the ability
to place a specific error code which we can verify later. So I did this,
1) add a new error code for a wrong certificate, and 2) add the check for
this specific use case (ie: cert name verification failed against a non-
hardcoded value, so fail immediately). It now immediately reports the
503 and you don't have the retries anymore.
This patch is working flawlessly.
+1 to adding all three patches to master.
--
Kevin
On 2017-07-26 11:27 AM, Willy Tarreau wrote:
On Wed, Jul 26, 2017 at 09:58:57AM -0700, Kevin McArthur wrote:
This seems to stop the primary vector. I can still tie up a valid sni with a
misconfigured backend, but I'm not sure that would be a client-controlled
condition.
And more importantly, the client's SNI is not the only source of SNI,
there are other valid use cases.
Perhaps strict-sni should be defaulted?
No, it would be a pain to a lot of people (ie making it impossible for
a hosting provider to present an error page by default). And as mentionned
above, it would only address the issue in your use case, not all of them.
However I have a good news. I found that it was possible to access the
connection from the verify callback! With a connection comes the ability
to place a specific error code which we can verify later. So I did this,
1) add a new error code for a wrong certificate, and 2) add the check for
this specific use case (ie: cert name verification failed against a non-
hardcoded value, so fail immediately). It now immediately reports the
503 and you don't have the retries anymore.
I'm attaching the two patches that I intend to merge if there's no
objection.
Willy
