Re^3: [Oberon] SMTP/SSH tunnel

[W B Hacker]

peasthope at cablelan.net wrote:
> Bill,
> 
> wh> ... hostnames and IP's not just 'H' and 'W' and 'P'.
> 
> Sorry.  Here is more info.
> 
> P = cablelan.net 
>   = ISP machine or cluster.

'dig any mx cablelan.net'

- shows a cluster of 4 mail servers for *at least* incoming.

They may or may not use the same ones to send out from, and you may or may not 
be connecting direclty to the sending boxes in any case.

>   I do not know 
>   the OS for certain.  The Web server appears 
>   to be MS, so my first guess is that the mail 
>   server is MS also.
>  

Highly unlikely, not that it matters.

Though that would explain the dodgy submission security - a concept Microsoft is 
still trying to avoid facing.

> H = joule.cablelan.net, dynamic IP address on eth0,
>     192.168.1.1 on eth1
>   = my home Debian server with exim4 and ipmasq.

ACK.

> 
> W1 = heaviside.cablelan.net, local address 
>      192.168.1.3 on my home LAN
>    = home workstation 
>    = ETH Oberon / PC Native 05.01.2003.
>

ACK.

> W2 = cantor.pathology.ubc.ca, local address 
>      192.168.1.7 on my work LAN
>    = "work" workstation
>    = ETH Oberon / PC Native 05.01.2003.
> 
> wh> ... amazed thay accept your relay on port 25.
> 
> At a conceptual level: I am a customer of 
> cablelan and joule is directly connected to 
> their MAN.  Why not accept all my messages 
> from joule including messages originating 
> from a machine connected to joule?
> 

Because firewalling port 25 outright as a destination is easier than 'capturing' 
it to their own servers, AND frees them from being beaten-up on their own b/w 
if/as/when their customers Windows boxen get infected with spambots.

Whci, ISTR is now down to under 12 seconds after initial conenciton to the 'net.

> At a presentation/session/transport(?) 
> level: joule runs ipmasq.  For all I know, 
> ipmasq is involved for the relay to work.
> 
> wh> 'H' can have more than one set of interface ports and protocols, ...
> 
> Yes, H has eth0, connected to P, and eth1, 
> connected to my LAN.
> 
> wh> ... odder still that it fails when you are accessing 
> a box back of the relay host from different places ...
> 
> Probably simply that exim4 and the tunnel 
> are not connected properly.
>

ACK.


> wh> Oberon will need fixed port numbers at both 
> ends, and Exim can 'meet' it there, ...
> 
> After reading all the documentation which has 
> turned up in the last three weeks, two questions 
> still baffle me.
> 
> - Encryption and port forwarding are entirely 
> distinct concepts.  Why are they implemented 
> together in SSH?

They usually aren't.  They can be with options.

>  Is it just that both are used 
> in a tunnel?  (No offense to Guenter.)
> 

ACK.  It is 'stunnel' that combines them.

> - Suppose the Oberon MUA issues a message with 
> port = 25 and tunneling is working.  Each SMTP  
> packet is wrapped inside a SSH packet (marked 
> port 22 according to the list I've seen).

22 is indeed the SSH port, but that is for terminal session.
(SSH = Secure SHell)

Stunnel uses the same SSL/TLS protocol and encryption, but not (ordinarily) on 
port 22.

 > At the
> outlet end of the tunnel, the SSH wrapper is 
> removed.  So the unwrapped SMTP packet should be 
> just as when it left the MUA.   So how is exim
> aware of the tunnel 

By either:

- Using the expected TLS ('negotiated'  SSL3 with added 'advertising', 
HELO/EHLO, and handshakes) on the 'standard' ports - i.e. 587, in which case you 
need only to tell Exim to:

a) Specify which IP to listen on:

	local_interfaces = 203.194.153.81


b) and which ports to use:

	daemon_smtp_ports = 25 : 465 : 587 : 666


b) Enable tls. which needs a certificate:

tls_certificate = /usr/local/etc/exim/certs/3638581a.0


c) Advertise or 'Offer' TLS to all, or selected comers:

tls_advertise_hosts = *


d) Optional - keep state:

tls_remember_esmtp = yes


e) Recommended - accept AUTH (your login with password) ONLY over encryption:

auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}


Exim will then advertise and negotiate TLS when requested on all such ports, 
i.e. server-to-server and user's MUA to Exim.

Key phrase is: *When Requested*.

The arriving critter has to have a full TLS implementation so it can do the 
HELO/EHLO as well as the protocol negotiation and key generation/exchanges.

Dunno if Oberon.Aos has that.

Very much doubt it, or we would not be having this chat.

*OR* as I suspect, Oberon only has the older SSL capability, not STARTTLS.

all of the above *plus* 'forcing' one of more ports to NOT advertise or expect 
STARTTLS but instead await ONLY an arriving SSL session.  i.e. 'always on' SSL/TLS.

NB: SSL/SSH does a *lot* of handshaking of its own.  Try an ssh connection with 
-v or -vv or -vvv optioned.


'Forced' TLS is still called 'SSL only' in most MUA, but not limited to the 
legacy port 465. One does an over-ride.

BEWARE that this critter (SSL or 'tls_on_connect') cannot, and will not 
'downshift' to 'proper' negotiated TLS, or (hopefully) to plain text, either.

Which can be a good thing, but is why you might NOT want it on port 587, where 
TLS is 'ass u  me 'ed' to be available.

tls_on_connect_ports = 465 : 666

NB: Port 666 is *actually* assigned to something else not in common use, but 
exploited by a WinCrobe, so usually firewalled shut on any server but your own.

 > and why is the packet treated
> differently from a packet from a MUA connected 
> without a tunnel?
>

Not a 'packet-level' issue.  The connection itself.

It is all up to what 'services' the MTA is advertising, and which of those the 
call-er selects.

It could, for example, be failing because you have no cert in place.

Essentially TLS allows tunnel-on-demand  (STARTTLS), so ONE port can be used all 
the time. Each session will adapt to what the two ends negotiate.

SSL was tunnel-or-nothing, so had to have more ports, ELSE coudl not accpet 
unencrypted connecitons at all. See also POP and IMAP use of SSL).

> I am unlikely to progress far with the tech
> -nicalities before understanding the elementary 
> concepts.  Probably at least a few others are
> benefiting from this discussion.
> 

More would do so with even modest Googling.

But on 'TLS' 'Exim' and such.

Not on *my* name!

;-)

Search the exim archives.

Bill Hacker

> Thanks,       ... Peter E.
> 
> Desktops.OpenDoc  http://carnot.pathology.ubc.ca/
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>