On 26.07.24 10:57, Philipp wrote:
[2024-07-25 23:54] Christian Schulte <[email protected]>
On 25.07.24 16:52, Philipp wrote:
[2024-07-25 11:10] Christian Schulte <[email protected]>
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.
The documentation has been fixed.
[...]
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.
I would guess this was introduced later, because of the downgrading
bugs/attacks.
Still catching up reading documentation.
Seems AuthOptions=p makes this work in sendmail. At least it behaves the
same way OpenSMTPD does by not offering the AUTH capability without the
client having issued STARTTLS successfully before.
p don't permit mechanisms susceptible to simple passive attack (e.g.,
PLAIN, LOGIN), unless a security layer is active.
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.
When you don't offer auth before STARTTLS, limiting auth to LOGIN doesn't
change anything. When a buggy client sends it's password before STARTTLS,
there is not mutch you can do against it[0]. But limit auth to LOGIN
doesn't harm.
I ended up with PLAIN as the only mechanism. A lot seems to have
changed. For example, LOGIN and DIGEST-MD5 are obsolete. CRAM-MD5 is
"limited". PLAIN is "common".
<https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml>
Maybe those will be removed in an upcoming Cyrus SASL release.
<https://github.com/cyrusimap/cyrus-sasl/issues/791>
<https://github.com/cyrusimap/cyrus-sasl/issues/787>
..
So with PLAIN only, it should be safe for the next upgrade.
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.
Are you referencing the first example? There the password of the
client is stored in plaintext. When a client wants to use a password
to authenticate against a server, then the client allways needs the
password in plaintext. This is (more or less) true for all
authentication methods. Even with smartcards the smartcard needs access
to the raw private key.
Of course. I got confused due to remembering the discussions about
sasldb storing clear text passwords.
It got mentioned in the Cyrus SASL documentation using a bold font for
various reasons.
<https://www.cyrusimap.org/sasl/sasl/sysadmin.html#shared-secrets-mechanisms>
"This point is important, so we will repeat it: sasldb stores the
plaintext versions of all of its passwords. If it is compromised so are
all of the passwords that it stores."
On the server side this looks a bit different. For passwords the server
only needs a hash (with salt) of the password. Asuming a cryptographic
secure hash function, you can't restore the password from the hash. This
is done with the encrypt subcommand of smtpctl(8) in opensmtpd and non
hashed passwords are not supported (expect for details, to long to explain).
Got it. Maybe the best way is to give up on AUTH and just use
certificates. All AUTH is needed for is for authentication an
authorization. Can be done using certificates just as well without any
passwords anywhere.
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.
I have not talked about S/MIME. I have sugested to copy the cert of your
sendmail host to your opensmtpd host and use the ca option with this
cert. This allows your opensmtpd host to verify/authenticate your
smarthost. Normal MUAs just does this interactive. So they get the cert
whithin the tls startup and ask the user, if they want to trust them.
This is called TOFU[1]. Alternative give your smarthost a cert which is
trusted by the CA of your OS.
Philipp
[0] Maybe use tls directly, but sadly this is not specified for submission.
[1] https://en.wikipedia.org/wiki/Trust_on_first_use
Got it. No longer have no-verify in smtpd.conf. ca does the job.
Thank you very much.
Regards,
--
Christian
