Re: [exim] safe handling of $tls_sni
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 Bettswrote: > > 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) >> * remove non-printing chars >> * remove 'quoting' and 'escaping' >> * make it lower case >> * only allow valid characters for a FQDN > > why remove? why not just reject if it contains any badness? > >> call it something like "safe_fqdn" and then you could do: >> >> ${if >> exists{/etc/mail/ssl/${safe_fqdn:tls_sni}.pem}{/etc/mail/ssl/${safe_fqdn:tls_sni}.pem}{/etc/mail/default-cert.pem} >> >> aren't computers are supposed to be doing the work for us...? >> > This: > > ${domain:a@$tls_sni} > > will give the domain part if the $tls_sni is syntactically correct for a > domain name else it will give the empty string. > > Is that not good enough? > > > ${if exists{/etc/mail/ssl/${domain:a@$tls_sni}.pem}\ >{/etc/mail/ssl/${domain:a@$tls_sni}.pem}\ >{/etc/mail/default-cert.pem}\ >} > > > it's going to try to use a file called /etc/mail/ssl/.pem if the sni > is empty or contains garbage, probably not a problem. > > -- > This email has not been checked by half-arsed antivirus software > > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://wiki.exim.org/ -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] safe handling of $tls_sni
On 2016-10-17, Mike Tubbywrote: > > 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 'escaping' > * make it lower case > * only allow valid characters for a FQDN why remove? why not just reject if it contains any badness? > call it something like "safe_fqdn" and then you could do: > > ${if > exists{/etc/mail/ssl/${safe_fqdn:tls_sni}.pem}{/etc/mail/ssl/${safe_fqdn:tls_sni}.pem}{/etc/mail/default-cert.pem} > > aren't computers are supposed to be doing the work for us...? > This: ${domain:a@$tls_sni} will give the domain part if the $tls_sni is syntactically correct for a domain name else it will give the empty string. Is that not good enough? ${if exists{/etc/mail/ssl/${domain:a@$tls_sni}.pem}\ {/etc/mail/ssl/${domain:a@$tls_sni}.pem}\ {/etc/mail/default-cert.pem}\ } it's going to try to use a file called /etc/mail/ssl/.pem if the sni is empty or contains garbage, probably not a problem. -- This email has not been checked by half-arsed antivirus software -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
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). -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] safe handling of $tls_sni
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 Tubbywrote: > > 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 'escaping' > * make it lower case > * only allow valid characters for a FQDN > > call it something like "safe_fqdn" and then you could do: > > ${if exists{/etc/mail/ssl/${safe_fqdn:tls_sni}.pem}{/etc/mail/ssl > /${safe_fqdn:tls_sni}.pem}{/etc/mail/default-cert.pem} > > aren't computers are supposed to be doing the work for us...? > > > Mike > > > > > On 10/17/2016 10:09 PM, 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 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." >>> >> Someone read the text I wrote! Woohoo! >> >> (It only took a few years ...) >> >> What is safest approach to handle $tls_sni when trying >>> to expand it to file on filesystem? >>> >> Use a cryptographic hash for the filename. Or base64-encode it. >> Use symlinks for human-convenience names and any aliases. >> >> Your trade-offs are: >> * a cryptographically-skilled attacker might find a collision and ... >>get you to issue, to _them_ (and only them) a certificate for a known >>system, while on their side they should be looking to validate against >>something else. Woo, they just attacked themselves: on your side, you >>don't need to care. >> * A very long SNI with base64 might look up a very long filename on >>disk. Shouldn't be an issue, unless you're mass-hosting on an OS >>which only maintains dir hashing for filenames up to a certain length >>and need to accept customer-controlled SNI names. >>Of course, the systems like that, if memory serves, broke at 32 >>characters long and a SHA1 hex digest is 40 characters long, so you'd >>also want to use ${substr...} to take the first N characters. >> * If you have a lot of similar names, sha1 will give you more >>readily-distinct values which you can tell apart at a glance. >> >>> ${sha1:${lc:mx.spodhuis.org}} >>F0DF49E8B2ACF84D5D290E89F9B673EF44B60E74 >>> ${str2b64:${lc:mx.spodhuis.org}} >>bXguc3BvZGh1aXMub3Jn >> >> So, eg, `/etc/mail/ssl/bXguc3BvZGh1aXMub3Jn.pem` should exist for this >> approach, to issue a cert for the name `mx.spodhuis.org`. >> >> Rule like: >>> ${if exists{/etc/mail/ssl/${tls_sni}.pem}{/etc/mail/ssl/${tls_sni >>> }.pem}{/etc/mail/default-cert.pem} >>> >> ${if exists{/etc/mail/ssl/${str2b64:${lc:tls_sni}}.pem}{/etc/ >> mail/ssl/${str2b64:${lc:tls_sni}}.pem}{/etc/mail/default-cert.pem} >>OR >> ${if exists{/etc/mail/ssl/${sha1:${lc:tls_sni}}.pem}{/etc/mail/ss >> l/${sha1:${lc:tls_sni}}.pem}{/etc/mail/default-cert.pem} >> >> -Phil >> >> > > -- > ## List details at https://lists.exim.org/mailman/listinfo/exim-users > ## Exim details at http://www.exim.org/ > ## Please use the Wiki with this list - http://wiki.exim.org/ > -- Brent Jones br...@brentrjones.com -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] safe handling of $tls_sni
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 'escaping' * make it lower case * only allow valid characters for a FQDN call it something like "safe_fqdn" and then you could do: ${if exists{/etc/mail/ssl/${safe_fqdn:tls_sni}.pem}{/etc/mail/ssl/${safe_fqdn:tls_sni}.pem}{/etc/mail/default-cert.pem} aren't computers are supposed to be doing the work for us...? Mike On 10/17/2016 10:09 PM, 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 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." Someone read the text I wrote! Woohoo! (It only took a few years ...) What is safest approach to handle $tls_sni when trying to expand it to file on filesystem? Use a cryptographic hash for the filename. Or base64-encode it. Use symlinks for human-convenience names and any aliases. Your trade-offs are: * a cryptographically-skilled attacker might find a collision and ... get you to issue, to _them_ (and only them) a certificate for a known system, while on their side they should be looking to validate against something else. Woo, they just attacked themselves: on your side, you don't need to care. * A very long SNI with base64 might look up a very long filename on disk. Shouldn't be an issue, unless you're mass-hosting on an OS which only maintains dir hashing for filenames up to a certain length and need to accept customer-controlled SNI names. Of course, the systems like that, if memory serves, broke at 32 characters long and a SHA1 hex digest is 40 characters long, so you'd also want to use ${substr...} to take the first N characters. * If you have a lot of similar names, sha1 will give you more readily-distinct values which you can tell apart at a glance. > ${sha1:${lc:mx.spodhuis.org}} F0DF49E8B2ACF84D5D290E89F9B673EF44B60E74 > ${str2b64:${lc:mx.spodhuis.org}} bXguc3BvZGh1aXMub3Jn So, eg, `/etc/mail/ssl/bXguc3BvZGh1aXMub3Jn.pem` should exist for this approach, to issue a cert for the name `mx.spodhuis.org`. Rule like: ${if exists{/etc/mail/ssl/${tls_sni}.pem}{/etc/mail/ssl/${tls_sni}.pem}{/etc/mail/default-cert.pem} ${if exists{/etc/mail/ssl/${str2b64:${lc:tls_sni}}.pem}{/etc/mail/ssl/${str2b64:${lc:tls_sni}}.pem}{/etc/mail/default-cert.pem} OR ${if exists{/etc/mail/ssl/${sha1:${lc:tls_sni}}.pem}{/etc/mail/ssl/${sha1:${lc:tls_sni}}.pem}{/etc/mail/default-cert.pem} -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] safe handling of $tls_sni
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 important to remember that $tls_sni is arbitrary > unverified data provided prior to authentication." Someone read the text I wrote! Woohoo! (It only took a few years ...) > What is safest approach to handle $tls_sni when trying > to expand it to file on filesystem? Use a cryptographic hash for the filename. Or base64-encode it. Use symlinks for human-convenience names and any aliases. Your trade-offs are: * a cryptographically-skilled attacker might find a collision and ... get you to issue, to _them_ (and only them) a certificate for a known system, while on their side they should be looking to validate against something else. Woo, they just attacked themselves: on your side, you don't need to care. * A very long SNI with base64 might look up a very long filename on disk. Shouldn't be an issue, unless you're mass-hosting on an OS which only maintains dir hashing for filenames up to a certain length and need to accept customer-controlled SNI names. Of course, the systems like that, if memory serves, broke at 32 characters long and a SHA1 hex digest is 40 characters long, so you'd also want to use ${substr...} to take the first N characters. * If you have a lot of similar names, sha1 will give you more readily-distinct values which you can tell apart at a glance. > ${sha1:${lc:mx.spodhuis.org}} F0DF49E8B2ACF84D5D290E89F9B673EF44B60E74 > ${str2b64:${lc:mx.spodhuis.org}} bXguc3BvZGh1aXMub3Jn So, eg, `/etc/mail/ssl/bXguc3BvZGh1aXMub3Jn.pem` should exist for this approach, to issue a cert for the name `mx.spodhuis.org`. > Rule like: > ${if > exists{/etc/mail/ssl/${tls_sni}.pem}{/etc/mail/ssl/${tls_sni}.pem}{/etc/mail/default-cert.pem} ${if exists{/etc/mail/ssl/${str2b64:${lc:tls_sni}}.pem}{/etc/mail/ssl/${str2b64:${lc:tls_sni}}.pem}{/etc/mail/default-cert.pem} OR ${if exists{/etc/mail/ssl/${sha1:${lc:tls_sni}}.pem}{/etc/mail/ssl/${sha1:${lc:tls_sni}}.pem}{/etc/mail/default-cert.pem} -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] decode exim srs From
Arkadiusz Miśkiewicz(Mo 17 Okt 2016 22:43:10 CEST): > Host A is using exim internal SRS capability to rewrite From and then forward > email to other host B. > > Now on host B I would like to rewrite From back to original form and then > make > exim all message processing (ACL, routers etc). > > srs key is known to both hosts. > > Can exim do that? I'm not sure if Exim can do it, probably if linked with the SRS libs. I'm doing reverse SRS with some small Perl utils use Mail::SRS qw(:all); In Debian there are a 'srs', and a 'libmail-srs-perl' package. -- Heiko signature.asc Description: Digital signature -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] decode exim srs From
Hi. Host A is using exim internal SRS capability to rewrite From and then forward email to other host B. Now on host B I would like to rewrite From back to original form and then make exim all message processing (ACL, routers etc). srs key is known to both hosts. Can exim do that? Thanks, -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/