letsencrypt and SSL alert number 80
Hi,
I'm seeing periodic entries like this in my maillog:
Dec 12 13:12:47 xavier postfix-116/smtpd[1683671]: warning: TLS library
problem: error:0A000438:SSL routines::tlsv1 alert internal
error:ssl/record/rec_layer_s3.c:1584:SSL alert number 80:
I've searched quite a bit for more info on this error, including in the
letsencrypt and openssl blogs, and haven't been able to find much. I
previously was requiring TLS >= TLSv1.0, but have now relaxed that
restriction and still seeing these messages.
Here are my tls config options. Does anything else stand out as a possible
cause that I could troubleshoot further?
# grep -E 'tls|ssl' main.cf|grep -v '\#'
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_cert_file=/etc/letsencrypt/fullchain.pem
smtp_tls_key_file=/etc/letsencrypt/privkey.pem
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED, aNULL
smtpd_tls_security_level = may
smtpd_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED, aNULL
tls_preempt_cipherlist = yes
smtpd_tls_mandatory_ciphers = high
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/privkey.pem
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
tls_random_source = dev:/dev/urandom
smtpd_tls_session_cache_database =
btree:${data_directory}/smtpd_tls_session_cache
Thanks so much for any ideas.
Alex
What are the consequences of disabling chroot in all master services?
Dear postfix experts: While setting up postfix in a docker container, I have been getting the error "fatal: unknown service: smtp/tcp" when attempting to send an email. I investigated the issue, and it seems it has something to do with setting up chroot inside of docker container https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg The easiest solution to this problem was to just disable chroot, which worked fine. I'm considering disabling chroot for all the postfix master services. Is this a bad move considering that postfix is running in a docker container? I would appreciate your insight into this. Best regards, Sam
Re: What are the consequences of disabling chroot in all master services?
Sam:
[ text/html is unsupported, treating like TEXT/PLAIN ]
> ?html style="direction: ltr;"?
> ?head?
>
> ?meta http-equiv="content-type" content="text/html; charset=UTF-8"?
> ?style id="bidiui-paragraph-margins" type="text/css"?body p {
> margin-bottom: 0cm; margin-top: 0pt; } ?/style?
> ?/head?
> ?body bidimailui-charset-is-forced="true" style="direction: ltr;"?
> ?p?Dear postfix experts:?/p?
> ?p??br?
> ?/p?
> ?p?While setting up postfix in a docker container, I have been
> getting the error "fatal: unknown service: smtp/tcp" when
> attempting to send an email. I investigated the issue, and it
> seems it has something to do with setting up chroot inside of
> docker container?/p?
> ?p??br?
> ?/p?
> ?p??a class="moz-txt-link-freetext"
> href="https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg"?https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg?/a??br?
> ?/p?
> ?p??br?
> ?/p?
> ?p?The easiest solution to this problem was to just disable chroot,
> which worked fine. I'm considering disabling chroot for all the
> postfix master services. Is this a bad move considering that
> postfix is running in a docker container? I would appreciate your
> insight into this.?/p?
The chroot feature makes post-exploitation of bugs (in Postfix,
libraries, etc) more more difficult, because there are fewer things
that an attacker can play with. For example no set-uid root programs,
no files in /proc, and no file system races against privileged programs.
One could argue that containers provide a minimized environment,
but that is not necessarily the case. The ones that do minimize
sometimes come with crippled libc implementations that introduce
problems of their own.
By the way it is rude to post html-only email to a mailing list.
Wietse
Re: letsencrypt and SSL alert number 80
> I'm seeing periodic entries like this in my maillog:
>
> Dec 12 13:12:47 xavier postfix-116/smtpd[1683671]: warning: TLS library
> problem: error:0A000438:SSL routines::tlsv1 alert internal
> error:ssl/record/rec_layer_s3.c:1584:SSL alert number 80:
[...]
> smtp_tls_cert_file=/etc/letsencrypt/fullchain.pem
> smtp_tls_key_file=/etc/letsencrypt/privkey.pem
usually there is no need for client certificates when sending emails.
> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
> smtp_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED, aNULL
> smtpd_tls_security_level = may
> smtpd_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED, aNULL
> tls_preempt_cipherlist = yes
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/fullchain.pem
> smtpd_tls_key_file = /etc/letsencrypt/privkey.pem
Are you sure cert/key_file path is correct?
Those filenames look like they are generated by certbot, wich places files
(softlinks) in
/etc/letsencrypt/live//{fullchain.pem,privkey.pem,...},
not in /etc/letsenrypt/{fullchain.pem,...} on my server.
Did you check if the certificate is valid?
openssl x509 -text < /etc/letsencrypt/cert.pem
openssl x509 -text < /etc/letsencrypt/live//cert.pem
// cert.pem contains your public certificate only whereas fullchain.pem
// additionally contains letsencrypt's intermediate certificate.
// For verification try cert.pem for smtpd_tls_cert_file use fullchain.pem
Best regards
Gerald
Re: What are the consequences of disabling chroot in all master services?
I apologize for the email being html-only, not my intention. I'm having
trouble getting Thunderbird to do this right as I have to manually do
this for every outgoing email.
Can you please elaborate on what you mean with "problems of their own"?
Anything specific comes to mind?
This whole movement to docker is a big set of trade-offs that I'm still
researching.
Best regards,
Sam
On 13/12/2022 3:17 AM, Wietse Venema wrote:
Sam:
[ text/html is unsupported, treating like TEXT/PLAIN ]
?html style="direction: ltr;"?
?head?
?meta http-equiv="content-type" content="text/html; charset=UTF-8"?
?style id="bidiui-paragraph-margins" type="text/css"?body p {
margin-bottom: 0cm; margin-top: 0pt; } ?/style?
?/head?
?body bidimailui-charset-is-forced="true" style="direction: ltr;"?
?p?Dear postfix experts:?/p?
?p??br?
?/p?
?p?While setting up postfix in a docker container, I have been
getting the error "fatal: unknown service: smtp/tcp" when
attempting to send an email. I investigated the issue, and it
seems it has something to do with setting up chroot inside of
docker container?/p?
?p??br?
?/p?
?p??a class="moz-txt-link-freetext"
href="https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg"?https://serverfault.com/questions/1052329/fatal-unknown-service-smtp-tcp-from-postfix-in-docker-using-start-fg?/a??br?
?/p?
?p??br?
?/p?
?p?The easiest solution to this problem was to just disable chroot,
which worked fine. I'm considering disabling chroot for all the
postfix master services. Is this a bad move considering that
postfix is running in a docker container? I would appreciate your
insight into this.?/p?
The chroot feature makes post-exploitation of bugs (in Postfix,
libraries, etc) more more difficult, because there are fewer things
that an attacker can play with. For example no set-uid root programs,
no files in /proc, and no file system races against privileged programs.
One could argue that containers provide a minimized environment,
but that is not necessarily the case. The ones that do minimize
sometimes come with crippled libc implementations that introduce
problems of their own.
By the way it is rude to post html-only email to a mailing list.
Wietse
Re: What are the consequences of disabling chroot in all master services?
I apologize for the email being html-only, not my intention. I'm having trouble getting Thunderbird to do this right as I have to manually do this for every outgoing email. Tools > Settings > Composition > Sending Format > (Automatic || Only Plain Text) and Tools > Account Settings > Composition & Addressing > Compose messages in HTML format
postfix with LDAP, handles mutiple domains
luckydog xf 11:15 AM (4 minutes ago) to postfix-users Hello, list. # Here is my ldap query bind = no version = 3 server_host = ldap://172.16.232.201:389 start_tls = no search_base = cn=users,cn=accounts,dc=ipa,dc=pthl,dc=hk scope = sub query_filter = (|(displayName=%s)(initials=%s)) result_attribute = displayName, initials result_format = %s # my ldap, actually it's FreeIPA. # just a sample, please ignore the key name. displayName: u...@abc.com initials: u...@xyz.com displayName and initials are two different email addresses. One is u...@abc.com, while the other is u...@xyz.com. I use postmap -q 'u...@abc.com', it returns two addresses. If I set one result_attribute , I can only get one email address. How to return the only one based on query input ? E.g when the user's input is u...@abc.com, it returns u...@abc.com, vice versa. Thanks.
Re: postfix with LDAP, handles mutiple domains
On Tue, Dec 13, 2022 at 11:23:55AM +0800, luckydog xf wrote: > # Here is my ldap query > bind = no > version = 3 > server_host = ldap://172.16.232.201:389 > start_tls = no > search_base = cn=users,cn=accounts,dc=ipa,dc=pthl,dc=hk > scope = sub > query_filter = (|(displayName=%s)(initials=%s)) > result_attribute = displayName, initials > result_format = %s In a well-designed email LDAP schema there are two single-valued valued attributes for each user (atribute names may vary, but the semantics remain the same): * mail - primary (canonical) email address of the user * mailRoutingAddress (sometimes "maildrop", ...) - The routing address of the underlying mailbox. There are then also frequently multi-valued attributes that hold one or more email addresses under which the user receives mail: * mailAlternateAddress (or with "smtp:" prefix proxyAddresses, ...) - All or additional to "mail" addresses. See LDAP_README for examples. https://www.postfix.org/LDAP_README.html > How to return the only one based on query input? E.g when the user's > input is u...@abc.com, it returns u...@abc.com, vice versa. See ldap_table(5) for the supported result format syntax, this describes some selectors based on the key rather than the lookup result https://www.postfix.org/ldap_table.5.html -- Viktor.
Re: letsencrypt and SSL alert number 80
On Mon, Dec 12, 2022 at 01:27:59PM -0500, Alex wrote:
> Dec 12 13:12:47 xavier postfix-116/smtpd[1683671]: warning: TLS library
> problem: error:0A000438:SSL routines::tlsv1 alert internal
> error:ssl/record/rec_layer_s3.c:1584:SSL alert number 80:
Some remote client encountered an internal (to it) error and decided to
politely abandon the TLS handshake by announcing this fact, rather than
just drop the connection. Newsflash: something's broken on the Internet!
No, wait, perhaps that's not news...
> smtp_tls_cert_file=/etc/letsencrypt/fullchain.pem
> smtp_tls_key_file=/etc/letsencrypt/privkey.pem
You probably don't need these.
> smtp_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED, aNULL
> smtpd_tls_exclude_ciphers = MD5, RC4, 3DES, IDEA, SEED, aNULL
And don't need to exclude aNULL for either the server or the client.
> smtpd_tls_session_cache_database =
> btree:${data_directory}/smtpd_tls_session_cache
And don't need this either, because session tickets work better.
--
Viktor.
Re: What are the consequences of disabling chroot in all master services?
This is not specific to postfix, but I cannot pass this opportunity to remind/inform people that chroot is itself a potential source of security vulnerabilities: Please enjoy studying this beautiful local privilege escalation bug in FreeBSD's ftpd, which was enabled by chroot jail: https://www.zerodayinitiative.com/blog/2020/12/21/cve-2020-7468-turning-imprisonment-to-advantage-in-the-freebsd-ftpd-chroot-jail > On 2022-12-13 00:17, Wietse Venema wrote: The chroot feature makes post-exploitation of bugs (in Postfix, libraries, etc) more more difficult, because there are fewer things that an attacker can play with. For example no set-uid root programs, no files in /proc, and no file system races against privileged programs. One could argue that containers provide a minimized environment, but that is not necessarily the case. The ones that do minimize sometimes come with crippled libc implementations that introduce problems of their own. By the way it is rude to post html-only email to a mailing list. Wietse
