On Fri, 3 Dec 2004, Johannes Berg wrote:
> On Do, 2004-12-02 at 22:51 +0000, Chris Edwards wrote:
> >
> > Would it be theoretically feasible to engineer this and somehow autosense
> > whether the client is doing tls-on-connect, and if not, provide a regular
> > SMTP session where ACLs force STARTTLS ?
>
> Not within exim. The TLS layer would have to recognise that the client
> is sending a HELO or EHLO string, and forward that to the upper layer.
> OpenSSL does something similar with HTTP by then signaling an error
> condition that basically says: someone tried unencrypted HTTP.
It's a bit more subtle than that.
There's a disagreement between SMTP and SSL over who talks first: in SMTP
the server starts with a greeting banner, but in SSL the client starts
straight away with a hello message. (SMTP is in this respect a very
traditional Internet protocol, whereas SSL is showing its HTTP
background.) This mismatch shows in practice if you are having problems
configuring an MUA to use secure SMTP: if you set the port to 465 and the
software to use STARTTLS, the server will wait for the SSL client hello,
but the client will wait for the SMTP server banner, and it'll time out
after a nasty delay. If you get them the other way around Exim will
complain about a protocol synchronization violation.
If you wanted to get SSL/SMTP auto-negotiation, you'd have to alter the
SMTP server to delay its banner slightly; if the client says an SSL hello
inside this delay, assume tls-on-connect, otherwise assume plaintext SMTP.
This would not be as reliable as the SSL/HTTP autonegotiation because it
depends on timing rather than protocol message analysis. The greeting
delay also implies an speed reduction for plaintext clients.
Tony.
--
f.a.n.finch <dot@???>
http://dotat.at/
MALIN HEBRIDES: NORTHEAST 4 OR 5 INCREASING 6. RAIN LATER. GOOD BECOMING
MODERATE.
