Re: pre-connect and smtp ?

[Brian Stafford <brian stafford uklinux net>]

On Sun, 19 August 17:31 M . Thielker wrote:

> A very specific use of this comes to mind that may make this an option for
> some people.
> Assuming that there is an SMTP server set up to allow relaying from only
> vertain hosts, one of which runs sshd. In that case, ssh could be used as a
> username/password authentication mechanism for SMTP. Encryption is not the
> point in that case, only the port forwarding as such is relevant in this
> setup.

OK.

I really must emphasise, however, that securing one hop on SMTP does not
secure the message from sender to recipient.  This is such an important
point I will keep saying it.  To get actual confidentiality, one *must*
use encryption and to get message integrity one *must* use digital
signatures.  In other words PGP or S/MIME.  I really do worry that
people will mistakenly believe that their communications is secure because
they've used an SSH tunnel.

> > Since SMTP over a SSH tunnel is an ad-hoc solution, I will not write any
> > code
> > supporting it.  Since ssmtp is hardly deployed and I can't find a RFC
> > describing
> > it, I am unlikely to write code to support that either.
> [...]
> 
> This does not necessarily have to be in libESMTP. One could even start the
> port forwarding before Balsa and just specify the forwarded port on
> localhost as the SMTP server in Balsa. I agree that no special support for
> this borderline case is required in Balsa.

I agree that port forwarding can be started outside the program entirely.
Since this involves no code changes to balsa or libESMTP and Un*x provides
the nuts and bolts to do it I feel this is the way to implement this feature
for those who need it.  I still urge against it though.

> > tunnelling, why
> > not set up the tunnel using inetd?   Set up the inetd to respond to
> > connections on
> > port 587 by executing a shell script which in turn connects the tunnel to
> > the remote
> > server.  The script presents the SMTP session on its standard input and
> 
> That is unfortunately not an option. There is no way to forward an existing
> connection, AFAIK. ssh will create a listening port on the local host, port
> forwarding will be activated as soon as a program opens a connection to that
> socket. There may be ways around this, but it would be unrelaible at best.

Right.  Stupidly, I assumed that ssh could connect its standard input and output
via the remote sshd to a service running on the remote port.  The lack of
this ability rules out inetd as a solution.

There is another problem with port forwarding though, nothing to do with ssh.
That is port numbers are a global resource for a given host.  Once the
host is listening on the port, any user can try to connect to that port.
This may be undesirable.  Even if the port forwarding program accepts only
one connection, there is still a critical race when another client connects
before the one that set up the connection.  That client can then masquerade
as the legitimate user.  A PF_LOCAL (PF_UNIX) socket (I believe getaddrinfo
can return addressing data for PF_LOCAL sockets) might be a better solution
since the socket can be protected using file system permissions but even this
is no protection against root.  Ssh doesnt seem to be able to use a PF_LOCAL
socket on the localhost though.  This still isn't as good as forwarding
stdin/out to a remote host port, which ssh can't do either.

It seems like ssh provides an exploitable security loophole when used as a
port forwarder!  I guess port forwarding is a Bad Thing.

Brian Stafford