On 25.07.24 16:52, Philipp wrote:
[2024-07-25 11:10] Christian Schulte <schulte...@gmail.com>
I'd like to setup opensmtpd on my laptop to use a self hosted smarthost.
In smtpd.conf I have:
action "outbound" relay host smtp+tls://user@smarthost:587 auth
<secrets> tls no-verify
The no-verify is due to the smarthost using a self signed certificate.
There is a (currently not fully documented) ca option for the relay
action. You can use this to verify the smarthost.
Thanks. Was searching the man page for a way to verify the certificate
in some way. That would have helped.
[...]
Jul 25 10:57:52 x500 smtpd[29053]: 7ebb7ff8c6ccd82b mta error reason=no
supported AUTH method
[...]
250-AUTH DIGEST-MD5 CRAM-MD5
250-STARTTLS
250-DELIVERBY
250 HELP
Is DIGEST-MD5 and CRAM-MD5 supported by OpenSMTPD?
No only "auth plain" and "auth login" is suported.
Read smtp_session.c by now myself.
I would not want to
enable clear text passwords on the smarthost. How to setup OpenSMTPD to
talk to that smarthost using STARTTLS and the supported AUTH methods?
First of all it's not a good idea to allow auth without tls. Also MD5
is not considered secure anymore.
The smarthost is a sendmail setup I am using since 2003 - 2 decades.
That setup has grown over time and had to deal with plenty of issues.
Mainly with broken MUAs. Enabling LOGIN and PLAIN, I am a bit paranoid I
am opening a can of worms I closed years ago. Haven't read sendmails
op.me for nearly 15 years. Enabled LOGIN and PLAIN, disabled CRAM-MD5
and DIGEST-MD5 and made sendmail refuse to accept those base64 based
mechanisms without STARTTLS. This is working now. I am not sure when
this option got introduced. Maybe I just oversaw it 2 decades ago. Maybe
that option got introduced somewhen without me noticing it. By can of
worms I am talking about things like
<https://marc.info/?l=bugtraq&m=113028017608146&w=2>
Just one example. There had been plenty of issues with Thunderbird,
Outlook and whatever MUA misbehaving, downgrading to plaintext passwords
without anyone noticing. I did not follow those issues over time. If I
remember correctly, enabling PLAIN and LOGIN made most of those auto
account setup dialogs "enter your email address and password and I will
setup everything automatically for you" features setup things in the
most insecure ways possible. That's the reason only CRAM-MD5 and
DIGEST-MD5 were allowed. I remember, there was in issue with PLAIN and
clients sending AUTH PLAIN base64(username:password) on one line before
the MSA could reject by telling them to use STARTTLS before. OpenSMTPD
does not send anything like that. I am a bit confused if I better not
offer PLAIN and only LOGIN. There is not much you can do about MUAs
behaving in those ways which is perfectly valid according to the RFCs.
Veryfied the setup with telnet and sendmail does not offer AUTH until
STARTTLS has been called and refuses to accept anything without
authentication. That's pretty much what I needed it to do.
So for your problem: In general there are two ways for remote password
auth. Send the plaintext password ower an encrypted channel or use some
challenge response method (i.e. cram or digets) to keep the password
secret from listeners. In both cases the channel must be authenticated
to be secure against active attacker.
The plain version has the benefit that you can store a hash of the password
on the server. So when somehow your database leaks an attacker can't use
the password. With the challenge response method your server must store
the password in plaintext.
This has been discussed to death on the SASL mailing list somewhen
around 2002. Sendmail is using SASL. Everyone complained about e.g.
sasldb storing plaintext passwords. I am wondering why the smtpd.conf
man page has exactly this in the examples. Would be better, if that man
page would not encourage anyone to store plaintext passwords in database
files and instead give examples on how to avoid that. Reading it, I just
remembered those complaints about sasldb and plaintext passwords and
just did not think about it.
Because with server authentication you get encryption for free[0] it's
consider more secure to use plain text auth and store only a hash of
the password. This is also secure with self signed certs, because most
user agents use trust on first use when the server use a self signed
cert.
So I would sugguest to copy your cert to the client and configure a ca
to verify the server. Keep in mind your cert needs to have the hostname
in the subject or subjectAltName. Then hash the passwords on the server
and change the authentication methode to plain or login.
Philipp
[0] I assume over the Internet
Deploying certificates and encouraging users to use S/MIME never worked
out. It's just to complex to setup for the average user. Would go that
route personally, of course.
Regards,
--
Christian
