mattr wrote:
So I think it is solved. But I leave my post here for anyone who has this problem in the future.
Glad to hear that you're up and running. Perhaps I can shed a little light on some of the questions you encountered along the way.
Quote:
After reading your post, I did:
(...)
- in /etc/postfix/sasl/smtpd.conf, changed saslauthd_path from /var/run/saslauthd/mux to /var/spool/postfix/var/run/saslauthd/mux
(...)
That setting, as you found out, is superfluous, since Postfix's default will work fine as long as you set the OPTIONS field in /etc/default/saslauthd appropriately as in my first post.
Remember that Postfix runs chroot'd in /var/spool/postfix. So when you included the setting, any value you put there is relative to that root. If you were going to include the setting, the right value would have been "/var/run/saslauthd/mux".
Quote:
It stopped working when I uncommented this:(which you recommended).
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
So commented it back in and it works. Maybe it is conflicting with something?
I'm not entirely sure if you are saying it works with or without that setting. Normally you comment something "out" not "in" - are you saying it fails with this line or without it?
If it only works without this line, that does seem strange, since your sender restrictions in main.cf only let mail be relayed with SASL authentication, so if that's working it would imply your client is authenticating properly, which in turn ought to satisfy these restrictions as well. So I can't say for sure why having the setting enabled causes a failure. Unless the failures were when you were also making other changes, so perhaps you'd be able to turn this back on in your final configuration.
Not having this setting does mean that you are permitting unauthenticated client connections, which may or may not be what you desire. They won't be able to relay messages but they could generate mail destined for local users, for example.
If instead you're saying that it works when you leave that line uncommented, but fails otherwise, at least on my setup, it seems to work either way. It's possible that other changes you made resulted in other restrictions if you leave it off. I don't see anything obvious in the main.cf you posted, but given that you most likely want this setting anyway (to reject unauthenticated requests), not sure it's that critical. You could try checking with "postconf | grep restrictions" when you didn't have the option enabled in master.cf to see if anything jumps out at you.
Quote:
# netstat -peln | grep saslauthd
unix 2 [ ACC ] STREAM LISTENING 5800975 11353/saslauthd /var/spool/postfix/var/run/saslauthd/mux
unix 2 [ ACC ] STREAM LISTENING 5713075 26139/saslauthd /var/run/saslauthd/mux
unix 2 [ ACC ] STREAM LISTENING 5803536 11992/saslauthd /var/spool/postfix/var/run/saslauthd/mux
Don't ask me why the second line is there. That /var/run/saslauthd folder doesn't exist anymore. Must be an old thread..
It looks like you have older copies of saslauthd still running. The number in front of the name (e.g., 11992 in "11992/saslauthd") is the process ID, so you might check those out. I don't know if saslauthd forks while running, so whether or not the two processes with the right path are correct.
I do know that on my system, after restarting saslauthd, and even during my tests when running, I never have more than one process ID shown. It's pid will be stored in in the saslauthd.pid file in its directory (/var/spool/postfix/var/run/saslauthd in your case).
I'd probably suggest either a clean reboot (if it's a test system), or kill off all the saslauthd processes you can find and then restart it cleanly.
Quote:
OK. Now, the question is, SASL works but is TLS really encrypting the traffic when I send my login to postfix? The AUTH LOGIN method is a plain text format I understand. In the mail.info log, the POP3 connections via dovecot say TLS started but the SMTP connections do not say that.
Your final update indicated that you were able to increase the logging to identify a TLS connection, so I'll skip that. Note that if you have the smtpd_tls_security_encrypt option enabled in master.conf (my example left it commented out), then you are telling Postfix to require (as opposed to just offering) TLS on connections.
For example, if I change my master.cf from my last post to include that setting, my master.cf entry becomes:
Code:
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
And a test session to my server looks like:
Code:
> telnet xxxxx 587
Trying xxxxx...
Connected to xxxxx.
Escape character is '^]'.
220 xxxxxxxxxxxxxxx ESMTP Postfix (Ubuntu)
EHLO yyyyyy
250-xxxxxxxxxxxxxxxxx
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM:<someuser@somehost>
530 5.7.0 Must issue a STARTTLS command first
AUTH PLAIN
530 5.7.0 Must issue a STARTTLS command first
Nothing works without STARTTLS first (which will then negotiate keys and encrypt the session). So with this configuration, the submission port (587) is guaranteed to use encryption, or in your case the default port 25. When locking things down, don't forget to ensure that you don't have Postfix accepting connections on other ports with weaker configurations.
You may also note that no authentication mechanisms are shown pre-TLS. What actually happens is that an SMTP client issues the STARTTLS command and then restarts a session with a new ELHO command, at which point the available authentication options are displayed, e.g.:
Code:
> openssl s_client -connect xxxxx:587 -starttls smtp
(...)
250-xxxxxxxxxxxxx
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
EHLO yyyy
250-xxxxxxxxxxxxx
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
Quote:
Quick background: I didn't really understand the way to use dovecot in postfix, which might have been faster. My postfix has both dovecot and cyrus support and I'm using cyrus. So my (maybe confused) understanding is that the postfix TLS setup is a totally separate one from the one being used by dovecot, instead of somehow hooking into dovecot's TLS.
Nope, you're basically correct in terms of the configurations being distinct.
TLS is security over individual connections, which each application will implement over its own connections. As such, there's really no concept of "hooking into dovecot's TLS", at least with respect to each connection. What you can do is share some of the data necessary to implement TLS. Each TLS connection is going to require certificates and keys (with each application having its own way of configuring references to those items). You can maintain those centrally for example, and could choose to use the same server certificate/key for both applications.
TLS is independent of the dovecot and cyrus SASL mechanisms built into Postfix. Those deal with SASL authentication using two different libraries (and thus underlying databases), but are independent from TLS. As mentioned in my last post, the SASL authentication can occur with or without TLS - if TLS is present the SASL authentication just occurs over the secured channel. The cyrus mode lets Postfix directly access sasldb files (without needing saslauthd) for example, but Postfix still has all of its own smtpd_tls_* settings for controlling how TLS is negotiated, whether or not SASL authentication is going to be used.
Quote:
I tried to check TLS is running two ways, openssl and swaks
These are great ways to test that your server supports TLS, but I agree that they won't necessarily indicate that some other client (like Outlook) is also using TLS, since enabling that is a client choice on a per-connection basis. In other words, your openssl test connection might work fine, but if you also permit unencrypted sessions, a client may just choose not to enable TLS. Having it required in your configuration covers that, as does some increased logging as you later determined.
Quote:
openssl s_client -connect host:port -starttls smtp
this showed the certificate ca was not sent maybe a problem.
(see log below, which says "No client certificate CA names sent" but does not fail so maybe that's not a problem?
No, that shouldn't be a problem. The message is referring to "certificate CA
names" and not certificates themselves.
TLS supports certificate exchanges in both directions, in which case both server and client can be authenticated. The setup you're using only has a certificate transmitted to the client. The openssl message means that your server hasn't also sent a request to the client (openssl in this case) for it to provide its own certificate.
Client authentication can further strengthen the security of a connection, but it requires that you generate certificates for clients and that they install them in whatever application they will be using. It's not that commonly used, particularly with public servers, and the client application has to support sending its own certificates.
Quote:
I am using a self-signed cert by the way, which I made like so:
mkdir /etc/postfix/sasl
cd /etc/postfix/sasl
openssl req -new -x509 -nodes -out smtpd.pem -keyout smtpd.pem -days 3650
I am using this same /etc/postfix/sasl/smtpd.pem for cert. (See at bottom, my main.cf.)
I leave you with this output from the openssl test, I'd appreciate it if you could tell me 1) is TLS working now, 2) must I add some kind of CA certificate.
1) Yes and 2) no, but you can if you want. (My guess is for your purposes, no, unless for example you'll also be offering a secure web site or other services).
The two major goals of TLS are authentication and privacy (encryption). A certificate is designed to provide authentication, as well as a starting point for negotiating the encryption key for the session. A public key within every certificate is paired with a private key (which is never released).
Using a self-signed certificate essentially bypasses authentication (your Outlook client trusts that your server is who it says it is, but has no basis for that trust, so will work when connecting to any old server), but still retains encryption. Your setup really only needs the privacy of TLS since it's the SASL authentication that controls use of the service.
A step up would be for you to create a CA certificate (essentially the same process but marking the certificate as a CA). Then, you can create other certificates and "sign" them with your CA certificate. You use the other certificates for servers like Postfix, and have your clients install your CA certificate in their applications so they can verify your server certificates.
A further step would be to use a commercial CA (Verisign, Entrust, etc...) or public CA (such as CACert) to sign a certificate for you. You then depend on your client already having the outside CA certificate installed for verification. This is how most web site certificates work.
But since you are authenticating the SMTP (or IMAP) transactions at the application level, there's not much benefit to adding complexity at the TLS level just to get further authentication.
In a lighter (maybe too silly) vein, think of it this way. Let's say we have two people, Charles (your client) and Sam (your server, with its self-signed certificate). They've never met. Sam is going to the post office and is willing to drop off additional letters for anyone who asks nicely. Charles has a letter he wants dropped off, knows how to ask nicely, and is expecting to use Sam.
Your current scenario of a self-signed certificate is like Charles approaching Sam, who says that yes, he's Sam. Charles takes his word for it, whispers his request nicely in Sam's ear, at which point Sam accepts the letter. Charles only has Sam's own word that he is in fact Sam, but Sam knows for sure that Charles asked nicely. Nobody else heard what Charles whispered.
In the next level up, let's start over but say that someone (Matt, your self-signed CA certificate) has been introduced to Charles and Sam separately. Now Charles approaches Sam, who says that yes, he's Sam. Instead of trusting him, Charles turns to Matt and asks if he's telling the truth. Matt has previously met Sam, so he confirms Sam's story, and since Charles has met Matt, he trusts him and thus trusts Sam. So he again whispers a nice request and gives Sam his mail.
The next level works very similarly, but this time, Charles has known someone else (Valerie, the Verisign CA) since high school. Sam has recently taken Valerie out for an expensive dinner, so she knows him as well. Now, when Charles approaches Sam, he can ask Valerie to vouch for Sam before handing over his letter.
In each of these cases, Sam could also have asked Charles who he was (the client certificates I mentioned earlier) which in turn could have all of the same variations for how Sam could trust Charles' answer.
In all cases, what Charles was whispering in Sam's ear was private, which includes, in your case, the users and passwords being used to authenticate with Postfix/Dovecot.
The important aspect of the latter two cases is that the client has independent information (the CA certificate) obtained before it ever tried to connect to the server, and which it can use to verify what your server is saying. The difference between creating your own CA versus using a commercial or public certificate is largely one of how the client received the original CA certificate and how much he trusts who he received it from. The big commercial CA certificates come pre-installed in browsers, for example, which is important for public web sites from a usability perspective.
In an enterprise or other closed environment, on the other hand, an internal CA can be used (and internally distributed to all clients along with client certificates) which can then fully authenticate both servers and clients. Browsers, for example, all support installing additional CA certificates as well as client certificates that can be used when authenticating an intranet for example. Another example would be how OpenVPN secures its links.
But unless your mail clients are going to reject a connection to a site using a self-signed certificate (unlikely), going the CA route will probably just add complexity without much benefit.
-- David
FAQ
Search
Members
Register
Login [ Anonymous ]
