[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. > 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. > > 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. 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). > > 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
