Re: [exim] safe handling of $tls_sni

2016-10-19 Thread Mike Brudenell
Hah! That would be a good reason! :-) And re-reading the *Specification* I now spot it saying "The string must consist entirely of decimal digits." (Sigh!) I was led astray because when I searched with Google I didn't find mention of Base62 only converting numbers, and indeed I found a web page

Re: [exim] safe handling of $tls_sni

2016-10-19 Thread Felipe Gasper
base62 only encodes numerals, though. -FG > On Oct 19, 2016, at 4:16 AM, Mike Brudenell wrote: > > Or perhaps just use Exim's existing base62 and base62d expansion operators? > :-) > >

Re: [exim] safe handling of $tls_sni

2016-10-18 Thread Phil Pennock
On 2016-10-18 at 08:28 +0200, Arkadiusz Miśkiewicz wrote: > On Monday 17 of October 2016, Phil Pennock wrote: > > Or base64-encode it. > > "/" is part of base64 alphabet, so would have to replace that with other > character, too. You're quite right. I was thinking of the `base64url` encoding

Re: [exim] safe handling of $tls_sni

2016-10-18 Thread Arkadiusz Miśkiewicz
On Monday 17 of October 2016, Phil Pennock wrote: > On 2016-10-12 at 14:50 +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

Re: [exim] safe handling of $tls_sni

2016-10-17 Thread Felipe Gasper
FWIW, I’d much rather that invalid characters in $tls_sni prompt an error. There seems no reason to serve up meaningful content to someone who’s sending a malformed SNI header. -Felipe Gasper Mississauga, ON > On Oct 17, 2016, at 11:42 PM, Jasen Betts wrote: > > On

Re: [exim] safe handling of $tls_sni

2016-10-17 Thread Jasen Betts
On 2016-10-17, 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: > > * remove white space (tab, space, etc) > *

Re: [exim] safe handling of $tls_sni

2016-10-17 Thread Phil Pennock
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,

Re: [exim] safe handling of $tls_sni

2016-10-17 Thread Brent Jones
I'd like that - and if we were at it, I'd want a safe $sender_host_address so we can use RHS expansion without modifying the Makefile :) On Mon, Oct 17, 2016 at 2:53 PM, Mike Tubby wrote: > > Couldn't we have - per perhaps shouldn't we have - a "safe domain name" > function in

Re: [exim] safe handling of $tls_sni

2016-10-17 Thread Mike Tubby
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: * remove white space (tab, space, etc) * remove non-printing chars * remove 'quoting' and

Re: [exim] safe handling of $tls_sni

2016-10-17 Thread Phil Pennock
On 2016-10-12 at 14:50 +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

[exim] safe handling of $tls_sni

2016-10-12 Thread Arkadiusz Miśkiewicz
Hi. 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