Re: Question: ETA OpenSSL 3.0 Support
> On 17/10/2023 11:23 EEST Niklas Meyer wrote: > > > Hello everyone, > > i stumbled across some serious problems with decrypting of e-mails if > you use a Dovecot installation with OpenSSL 3.X so i started digging. > > It turns out that Dovecot is not OpenSSL 3.X ready yet, at least if you > compile it yourself. > > The Debian Project adapted a OpenSSL 3.X patch to their repo version of > Dovecot to make it run with Debian 12. > > Alpine Linux has not added a Workaround Patch for Dovecot yet. > > This is actually really bad if you want to Upgrade your Dovecot Server > to a Distro which has OpenSSL 3.X as the new standard and you are not > using their patched Repo Versions but instead compiling dovecot by > yourself or install it from your package repos (which are not Debian 12 > compatible also, which is probably because of OpenSSL 3.X i presume?) > > However though i think that this compatibility should be added soon as > more and more Distros are using OpenSSL 3.X. > > So: Is there a approx. ETA when the OpenSSL Compatibility the devs > worked/are working on is coming? > > Thank you for your answers. > > Kind regards from Germany > > Niklas Meyer aka. DerLinkman > > ___ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org Hi! OpenSSL 3.0 support is already in main branch and will be in 2.4 release. Aki ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot behind Reverse Proxy and IP families
On 10/13/23 06:55, Arnaud Cordier wrote:
Hi Justas,
Thank you for your answer. Unfortunately, I already have a dual stack cluster
with an IPv6 assigned to the pod:
3: eth0@if22: mtu 1430 qdisc noqueue
state UP qlen 1000
link/ether c6:90:d2:cf:b8:77 brd ff:ff:ff:ff:ff:ff
inet 10.42.4.52/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fd23:23:42:0:251d:192a:bb7f:a1f4/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::c490:d2ff:fecf:b877/64 scope link
valid_lft forever preferred_lft forever
Any additional idea?
---
Arnaud Cordier
---
CryptID
Freelance cybersecurity engineer - Pentester - Red teamer
Tel: +33 (0)6 61 44 82 04
On 10/12/23 22:54, Justas Umbrasas wrote:
Hey,
we are running a similar setup without an issue (not on k8s). I believe the
reason is that the remote dovecot pod is only binding on IPv4 and has no IPv6
configured. This is kind of a hack, however you could try binding the pod to
both IPv4 and IPv6 and see if it works.
Best,
Justas Umbrasas
On 2023-10-12 20:25, Arnaud Cordier via dovecot wrote:
Dear all,
I am running Dovecot 2.3.20 in a Kubernetes cluster. The Dovecot
container is exposed behind a Traefik load-balancer, which acts just
like HAProxy would, using the Proxy Protocol in order to allow
Dovecot to be aware of the real source IP of the client, as follows:
Internet <-> Traefik load-balancer < Proxy protocol > Dovecot
My setup works well over IPv4.
Oct 12 19:11:33 imap-login: Info: Login: user=,
method=PLAIN, rip= lip=10.42.4.21,
mpid=1369531, session=
Howevever, if the client originates from an IPv6 address, Dovecot
does not seem to take the real IPv6 origin into account and fails.
Oct 12 19:09:04 imap-login: Error: haproxy(v1): Client disconnected:
Proxied local address is invalid (address=`10.42.4.21',
rip=10.42.4.21)
A network capture shows that the proxy protocol indeed sends the real
IPv6 IP, that should be taken into account by dovecot:
..&.PROXY TCP6 2001: 10.42.4.21 20200 993
The error seems to be raised in "core/src/lib-master/master-service-
haproxy.c" line 553:
551 if (net_addr2ip(*fields, _ip) < 0 ||
552 local_ip.family != family) {
553 e_error(hpconn->event, "Client
disconnected: "
554 "Proxied local address is
invalid "
555 "(address=`%s', rip=%s)",
str_sanitize(*fields, 64),
556 net_ip2addr(real_remote_ip));
557 return -1;
558 }
559 fields++;
I suppose that the issue is related to the fact that the client
originates from an IPv6 then the reverse proxy forwards the
connection to Dovecot over IPv4, which results in the
"local_ip.family != family" condition to be true.
Why is such a restriction implemented ?
It is to be noted that I implemented the exact same load-balancer
architecture for postfix, which successfully handles an IPv6 real IP
over an IPv4 connection.
I temporarily fixed the issue by setting an IPv4 only DNS record for
my imaps domain name, however, do you think that a fix could be
implemented in Dovecot?
Kind regards,
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
OpenPGP_0xB09B2E1B5DDC756C.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
OAUTH2 tokeninfo is doing a GET instead of a POST request
Hi,
I try to setup oauth2 authentication with dovecot 2.3.21.
The debug log of dovecot shows that it tries to do a HTTP GET request to
the tokeninfo url with the token appended to the end of the URL. This
gives a 404 error. The openidconnect server I use (keycloak) tells that
this API endpoint conforms to
https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint
which specifies that the request has to be a HTTP POST request.
So dovecot is trying do to something (GET request) which the OIDC
specification does not agree with (shall be POST request).
Here is the dovecot debug log of it:
---snip---
Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: http-client[1]:
request [Req1: GET
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/tokeneyJhbGci...:
Submitted (requests left=1)
[...]
Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld:
SSL: where=0x1001, ret=1: SSLv3/TLS read server session ticket
Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld:
where=0x1002, ret=1: SSL negotiation finished successfully
Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld:
SSL: where=0x1001, ret=1: SSL negotiation finished successfully
Oct 17 12:11:19 imap syslogd: last message repeated 1 times
Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld:
SSL: where=0x1001, ret=1: SSLv3/TLS read server session ticket
Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld:
SSL: where=0x1002, ret=1: SSL negotiation finished successfully
Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: http-client: conn
:443 [1]: Got 404 response for request [Req1: GET
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/tokeneyJhbGci
---snip---
My passdb config (only showing the oauth part):
---snip---
passdb {
driver = oauth2
mechanisms = oauthbearer xoauth2
args = /usr/local/etc/dovecot/auth-oauth2.token.conf.ext
}
passdb {
driver = oauth2
mechanisms = plain
args = /usr/local/etc/dovecot/auth-oauth2.plain.conf.ext
}
---snip---
auth-oauth2.token.conf.ext:
---snip---
openid_configuration_url =
https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration
tokeninfo_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token
introspection_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/introspect
introspection_mode = post
active_attribute = active
active_value = true
client_id = myid
client_secret = mysecret
use_grant_password = no
debug = yes
username_attribute = email
pass_attrs = pass=%{oauth2:access_token}
---snip---
auth-oauth2.plain.conf.ext:
---snip---
openid_configuration_url =
https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration
#tokeninfo_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token
introspection_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/introspect
introspection_mode = post
active_attribute = active
active_value = true
client_id = myid
client_secret = mysecret
use_grant_password = yes
debug = yes
username_attribute = email
pass_attrs = host= proxy=y proxy_mech=xoauth2
pass=%{oauth2:access_token}
---snip---
On https://doc.dovecot.org/configuration_manual/authentication/oauth2/ I
can not find any way to tell that the tokeninfo url shall do a POST
request instead of a GET request.
I found something on reddit how to make it work with keycloak, but this
seems to be a workaround, and not a proper fix...
The first comment at
https://www.reddit.com/r/selfhosted/comments/omwb2j/any_one_get_dovecot_keycloak_working_for_with/
makes this work for me.
The working but not really up to the OIDC spec dovecot config is:
auth-oauth2.token.conf.ext:
---snip---
openid_configuration_url =
https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration
#tokeninfo_url =
https://oauth2.domain.tld/realms/MyRealm/Leidinger/protocol/openid-connect/token
tokeninfo_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/userinfo?trash=
introspection_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/introspect
introspection_mode = auth
#active_attribute = active
#active_value = true
client_id = myid
client_secret = mysecret
use_grant_password = no
#debug = yes
username_attribute = email
pass_attrs = pass=%{oauth2:access_token}
---snip---
auth-oauth2.plain.conf.ext:
---snip---
openid_configuration_url =
https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration
#tokeninfo_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token
tokeninfo_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/userinfo?trash=
introspection_url =
https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/introspect
introspection_mode = auth
#active_attribute = active
#active_value = true
client_id = myid
client_secret = mysecret
use_grant_password =
Question: ETA OpenSSL 3.0 Support
Hello everyone, i stumbled across some serious problems with decrypting of e-mails if you use a Dovecot installation with OpenSSL 3.X so i started digging. It turns out that Dovecot is not OpenSSL 3.X ready yet, at least if you compile it yourself. The Debian Project adapted a OpenSSL 3.X patch to their repo version of Dovecot to make it run with Debian 12. Alpine Linux has not added a Workaround Patch for Dovecot yet. This is actually really bad if you want to Upgrade your Dovecot Server to a Distro which has OpenSSL 3.X as the new standard and you are not using their patched Repo Versions but instead compiling dovecot by yourself or install it from your package repos (which are not Debian 12 compatible also, which is probably because of OpenSSL 3.X i presume?) However though i think that this compatibility should be added soon as more and more Distros are using OpenSSL 3.X. So: Is there a approx. ETA when the OpenSSL Compatibility the devs worked/are working on is coming? Thank you for your answers. Kind regards from Germany Niklas Meyer aka. DerLinkman ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: The future of SIS
On 16.10.23 13:17, Pedro Ribeiro via dovecot wrote: Hello to everyone! Ooops, we are using SIS, guess the solution for a similar optimization will be a native deduplicated filesystem. A block level de-duplicating filesystem can only deduplicate data that is aligned to block boundaries. E-mail attachments tend to move around in to a different alignment in each copy stored into a different mailbox. Unless the storage format is designed to split off the attachments into files there is not much to be gained by block level dedup. So for the foreseeable future I'll have to stay off Dovecot 3.x or add four to five times more storage to both my IMAP servers since my users love to send big documents to multiple recipients. Is this an attempt to figuring out the pain tolerance of existing users before they fork the project or pay up the Danegeld? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
