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.
Perhaps strict-sni should be defaulted?
--
Kevin
On 2017-07-26 9:53 AM, Emmanuel Hocdet wrote:
Hi Kevin,
Le 26 juil. 2017 à 18:39, Kevin McArthur <ke...@stormtide.ca> a écrit :
Interesting. I'd probably recommend not pushing this patch out then until this
can be fixed as it will be trivial to resource-exploit a haproxy instance that
is exhibiting a client-controlled retry. A quick try with a script that
generates randomized SNI names shows I can open connmax and crash the haproxy
from a single instance pretty readily.
If there's other errors that the client can control that lead to a retry like
this, they're probably worthy of a CVE.
It takes approximately 5s per connection to clear the connection in this
condition.
I'll see if retries 0 will work for our use case, but I'd hate to think we'd
have to give up non-client-controlled retry support entirely (ie for a backend
apache restart, retry to another app server...) due to this.
—
Yon can add ‘strict-sni’ on bind line to reject all requests with an unknown
sni.
Manu
