If what we're saying is that Exim needs to be virtual host capable then
I think that we're on the edge of needing a proper virtual hosts
sub-system that deals with:
1. naming the virtual host
2. configuring certificates
3. configuring TLS options (ciphers, etc)
4. configuring a logging location
Mike
On 10/19/2016 10:10 AM, Viktor Dukhovni wrote:
> 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.
>
