Re: [exim] safe handling of $tls_sni

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: Mike Tubby
CC: exim-users
Subject: Re: [exim] safe handling of $tls_sni
On 2016-10-17 at 22:53 +0100, Mike Tubby wrote:
> Couldn't we have - per perhaps shouldn't we have - a "safe domain name"
> function in Exim that could be used for this and elsewhere where an
> untrusted domain name enters - it would:


Exim is a volunteer open source project. Patches are welcome, as are
new contributors. If this is the itch for you to scratch to get
involved, then take a look at src/expand.c

>     * remove white space (tab, space, etc)
>     * remove non-printing chars
>     * remove 'quoting' and 'escaping'


Any security function should _whitelist_, not blacklist.

This is the advantage of hashing or base64-encoding: it moves the
character-set of files in the local filesystem to be guaranteed safe,
easily scriptable without having to worry about extra `$` signs or
backticks or other malarkey from remote data.

This is a pattern used in various secure designs. I was asked for the
safest approach, so I gave the safest. If instead you want an approach
which is "probably pretty safe, but still looks a bit like the original
name for most cases" then you can use escaping mechanisms and hope that
no corner cases were missed (empty string but present `$tls_sni` and so
forth).

> aren't computers are supposed to be doing the work for us...?


They do. I provided an answer which matches the approach for handling
user-data which I've seen at some big sites. Don't ever trust user-data
as safe for a filename on local disk.

Really, this goes in as a step in your configuration build process when
building the set of files to be deployed to the mail-server. A
filename transform step is simple (as is having some symlinks for
user-friendliness if you have humans regularly logging in to look around).