On Wed, Oct 12, 2016 at 02:50:41PM +0200, Arkadiusz Miśkiewicz wrote:
> Docs say that $tls_sni has raw data from client:
>
> "Great care should be taken to deal with matters of case, various injection
> attacks in the string (../ or SQL), and ensuring that a valid filename can
> always be referenced; it is important to remember that $tls_sni is arbitrary
> unverified data provided prior to authentication."
While we're on the topic of Exim and SNI, I just interacted with
a user who rather admirably was monitoring his DANE TLSA records,
but his monitoring script was not sending the SNI extension as
required by RFC 7672. Sadly, his MX host was configured to respond
with a different (non-default) certificate when the SNI matched
the actual MX hostname. Consequently, the monitoring was flawed,
and missed a problem with certification rotation.
So please keep in mind that SNI makes things a bit more complex
from a monitoring perspective. Avoid SNI if you can, use with
care if you must.
--
Viktor.
