Postfix Dovecot enable user authentication by encrypted password


#1

Hi friends,
I’ve just set up my first Postfix/dovecot email server using Workaround Jessie Guide; now all works fine, except for the authentication user method, that work on plain text but not on encrypted mode.

All seem (at least to me) configured well:

/etc/postfix/master.cf
smtpd_tls_security_level = may smtpd_tls_key_file = /etc/letsencrypt/live/server.sio4.org/privkey.pem smtpd_tls_cert_file = /etc/letsencrypt/live/server.sio4.org/fullchain.pem smtpd_tls_auth_only = yes

/etc/postfix/master.cf
submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject

/etc/shorewall/rules
ACCEPT net $FW tcp 25 #POSTFIX

But, I’m unable to connect using “openssh”:
openssl s_client -connect server.sio4.org:25 -starttls smtp

I’m wondering if the issue could be the letsencrypt certificate, whom doesn’t include the correct domain or a bad Postfix configuration. Because all seem fine to me, but it is also true that this is the first time that I set an email server :flushed:


#2

interesting - it works for me

Can you reach the server in general ? or is there any firewall / routing issue blocking access.

p.s. your certificate is due for renewal on 9 March


#3

The server is on a VPS and the only active firewall is by Shorewall.
I’ve restart Shorewall and tested again the 587 port:

openssl s_client -connect server.sio4.org:587 -starttls smtp

and work fine:

[..] ehlo server.sio4.org 250-server.sio4.org 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN

Then I’ve tested 110 port and work fine

but (if possible) could you suggest me witch ports I should verify/open?

PS
About the certificate renewal I know. I’m only waiting if the cron script make well its work :wink:

many many thanks!


#4

For the ports, it depends what you have set up

SMTP - 25 and then possibly 465 or 587
POP3 - 110
IMAP - 143, 993

I’ve just tested 25, 110, 143, 993 and all were fine, providing the same cert


#5

Thanks for your help, even if the argument is not entirely relevant (perhaps) :wink:

I’ve check and the only closed port was 465, now open and now is possible to send using encrypted password, and a result we brought it home (I do not know if it says so in your country) :wink:

now remains the reception (pop and imap) problem of reception. Do it need a special port to handle encrypted login?

I appreciate the help you gave me in any case so far, hopefully I will open a specific request on the mailing list of postfix (although I don’t know how they’ll take with a beginner like me :smiley: )


#6

The standard ports are 995 (Secure POP3) and 993 (Secure IMAP).


#7

Well, but the problem for the pop/imap doesn’t change…

I will open a specific topic on Postfix ML and if i will get to the bottom of something, I write here the solution (if I have time in a month):wink:

many thanks again


#8

…I’m going on and I’ve found this error trying to connect to Dovecot using openssl:

openssl s_client -connect pop.pergraziaricevuta.it:pop3s
[..]
Verify return code: 20 (unable to get local issuer certificate)

I’ve set on “/etc/dovecot/conf.d/10-auth.conf”

auth_mechanisms = plain login cram-md5

but for the moment (only for the moment :wink: ) no result on the crypted password login.

Could be the error above a way to follow?

many thanks!


#9

Why do you want an encrypted password through the auth mechanisms? Isn’t a secure channel (TLS) enough?


#10

Yes your question centers on problem!

For this reason essentially:

I’m not sure (through ignorance I suppose) if the only ssl can prevent the “men in the middle” attack.

Thanks!


#11

TLS should be more than enough.


#12

The cause of the “man in the middle” attack is that one party is unsure of the other’s identity. In TLS we solve this through certificates signed by a trusted third party, the Certificate Authority. A Certificate Authority’s job is to issue certificates only to the legitimate subjects of those certificates. The Web PKI (HTTPS web sites but also TLS in other places on the Internet) uses a group of public CAs which agree to follow some basic practices for how to validate the subjects of certificates they issue. Let’s Encrypt is one of those CAs. So, when the remote Dovecot server presents a certificate from Let’s Encrypt saying “I am really this Dovecot server imap.example.com, not an imposter” it is very reasonable to believe that is the case.

It would be tremendously difficult to forge the certificate (it is our intention that it should be impractical even for a nation state adversary, such as the NSA, with access to billions of dollars of equipment and very smart people) but it might be possible to influence a CA to issue without proper validation. If you have very sensitive information, you should consider that.

Most IMAP client software today offers a mode where it will prompt you if it is presented with a certificate that is not from one of the Web PKI Public CAs like Let’s Encrypt. For example a “self-signed” certificate produced locally. In this case you can only reasonably be assured that you’re really talking to the intended machine if you examine this certificate carefully to check it is exactly as expected. So long as you trust public CAs to do their job, you don’t need to perform this inspection on certificates they’ve signed, so by default most software will trust these implicitly.


#13

What is unclear for me is if the password (plain text) travels inside the TLS tunnel,
I think I got it from you that works like this.

right? :slight_smile:

…and sorry for the off topic


#14

What exactly is unclear? Sorry, I’m not quite able to decipher your English :blush:


#15

Oh, I’m sorry, but you’re right, my English is really difficult to decipher …even here in LetsEncript :grin:

Only I would like to be sure if the password travels encrypted, using TLS even if the client send it as plain text.

I hope I was understandable now :slight_smile:


#16

When TLS is applied, the password travels encrypted yes. That’s the whole purpose of TLS :slight_smile: Everything inside the TLS secured channel is encrypted, the e-mail itself, the password before that.

Most commonly used protocols use just one connection, such as HTTP(S), SMTP, IMAP… There are exceptions to this of course, such as FTP. FTP uses two TCP connections: one command and one data connection. With FTPS, “”“secure FTP”"", many times only the command connection is secured with TLS. Luckily, the password is send through this secured command connection, but all the data subsequently send isn’t secured. But as said, this isn’t the case for the many common protocols we’re talking about here (web/email).


#17

Very very thanks Osiris, and many thanks also to everyone else who helped me to better understand this topic :wink:


#18

I add a piece of information just received from the Dovecot mailing list, always in relation to the question object.

From the Dovecot mailing list, Steffen Kaiser, to enable the password encrypted mode (now, through you, I know that this is a feature even excessive, but I want to understand), suggest me to add the “ssl_ca” to the Dovecot configuration (/etc/dovecot/conf.d/10-ssl.conf:ssl_key I suppose).

Now the question is:

for Letsencrypt the “ssl_ca” correspond to chain.pem?

Thank you all again for all the time that you’re dedicating to me (and hope to all those who might be interested in this topic) :slight_smile:


#19

From the Dovecot documentation:

Client certificate verification/authentication

If you want to require clients to present a valid SSL certificate, you'll need these settings:

ssl_ca = </etc/ssl/ca.pem
(...)

So: no, you don’t need ssl_ca, as you don’t want to enable client certificate verification/authentication, because that’s impossible with DV certificates like Let’s Encrypt issues.

Also, the problem you’re mentioning in your question to the Dovecot mailing list (“Verify return code: 20 (unable to get local issuer certificate)”) has nothing to do with using encrypted passwords!
OpenSSL produced that error. OpenSSL is only the TLS client and it has nothing to do with the underlying protocol, such as IMAP or SMTP, which are in charge of the plaintext or encrypted password handling!

Also, my openssl outputs " Verify return code: 0 (ok)". So it’s probably more likely your OpenSSL can’t find the root certificate store of your OS. Try connecting to this forum:

openssl s_client -connect community.letsencrypt.org:https -servername community.letsencrypt.org

Do you get a code 20 too? Or a code 0?


#20

from community.letsencrypt.org again:

Verify return code: 20 (unable to get local issuer certificate)

I had added this information for more complete information to the mailing list, it was not clear if things were linked together.

So do you think that the Steffen Kaiser answer does not apply to the subject?