error connecting to IMAPs via gateway (core 8.6.81.416)
-
I know the search in this forum isn’t great, but this has actually already been discussed recently: https://forum.kopano.io/topic/1750/kopano-gateway-don-t-listen-on-993
-
@fbartels
I am very sorry, I really did try searching. But couldn’t find it. Thank you. That solved the first problem. I know appear to have another issue with ssl.I now get the following error using my same -unchanged- SSL Certificate from letsencrypt:
Fri Sep 28 13:21:12 2018: [=======] Starting kopano-gateway version 8.6.81 (pid 4271 uid 0) Fri Sep 28 13:21:12 2018: [info ] Coredump status left at system default. Fri Sep 28 13:21:12 2018: [error ] ECChannel::HrSetCtx(): cannot open key file Fri Sep 28 13:21:12 2018: [error ] Error loading SSL context, POP3S and IMAPS will be disabled Fri Sep 28 13:21:12 2018: [debug ] Reexecing /usr/sbin/kopano-gateway Fri Sep 28 13:21:12 2018: [=======] Starting kopano-gateway version 8.6.81 (pid 4271 uid 999) Fri Sep 28 13:21:12 2018: [info ] Coredump status left at system default. Fri Sep 28 13:21:12 2018: [error ] ECChannel::HrSetCtx(): cannot open key file Fri Sep 28 13:21:12 2018: [error ] Error loading SSL context, POP3S and IMAPS will be disabled Fri Sep 28 13:21:12 2018: [info ] Logger process started on pid 4274I know that I had a similar issue with kopano core a few months ago and I had to merge
cat cert.pem privkey.pem >> kopano.pembut using kopano.pem only gives me:
Fri Sep 28 13:19:12 2018: [error ] SSL CTX private key file error: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch -
@fbartels Hi Felix, could it be that the kopano-gateway has trouble opening the certificates if they are symbolic links? I can use the ssl context without problems by specifying the file directly
-
I had a similar problem a few weeks ago, I was also using a symlink. But it might also have just been the permissions. Something changed in kopano and if i remember correctly I changed the certificate files so that the kopano user could read them instead of just root. It was a bit weird and my memory of what I had done to fix it is cloudy. But it was something about either the symlink or the permissions or both :-)
And it was just for my IMAP server! The other components still worked fine when I encountered this issue…
-
-
symbolic links work for me:
root@ucs-4570 /etc/kopano $ netstat -tulpen | grep kopano tcp 0 0 0.0.0.0:236 0.0.0.0:* LISTEN 0 615833 13797/kopano-server tcp 0 0 0.0.0.0:237 0.0.0.0:* LISTEN 0 615836 13797/kopano-server tcp6 0 0 :::110 :::* LISTEN 0 620285 14564/kopano-gatewa tcp6 0 0 :::143 :::* LISTEN 0 620295 14564/kopano-gatewa tcp6 0 0 :::8080 :::* LISTEN 0 616810 13925/kopano-ical tcp6 0 0 :::2003 :::* LISTEN 0 617348 13978/kopano-dagent tcp6 0 0 :::8443 :::* LISTEN 0 616815 13925/kopano-ical tcp6 0 0 :::993 :::* LISTEN 0 620300 14564/kopano-gatewa tcp6 0 0 :::995 :::* LISTEN 0 620290 14564/kopano-gatewa root@ucs-4570 /etc/kopano $ grep ssl gateway.cfg # Warning: the value "ssl_private_key_file" has been set via UCR variable "kopano/cfg/gateway/ssl_private_key_file" ssl_private_key_file = /etc/kopano/ssl/link-private.key # Warning: the value "ssl_certificate_file" has been set via UCR variable "kopano/cfg/gateway/ssl_certificate_file" ssl_certificate_file = /etc/kopano/ssl/link-cert.pem #ssl_verify_client = no #ssl_verify_file = #ssl_verify_path = #ssl_protocols = #ssl_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL #ssl_prefer_server_ciphers = no root@ucs-4570 /etc/kopano $ ls -la /etc/kopano/ssl total 28 drwxr-xr-x 2 kopano kopano 4096 Oct 4 08:33 . drwxr-xr-x 6 root root 4096 Oct 4 08:33 .. -rw-r----- 1 kopano kopano 5488 Oct 3 16:59 cert.pem lrwxrwxrwx 1 root root 8 Oct 4 08:32 link-cert.pem -> cert.pem lrwxrwxrwx 1 root root 11 Oct 4 08:33 link-private.key -> private.key lrwxrwxrwx 1 root root 10 Oct 4 08:33 link-server.pem -> server.pem -rw------- 1 kopano kopano 1679 Oct 3 16:59 private.key -rw------- 1 kopano kopano 7167 Oct 3 16:59 server.pem root@ucs-4570 /etc/kopano $ dpkg -l | grep kopano-gateway ii kopano-gateway 8.6.81.475-0+86.1 amd64 POP3 and IMAP Gateway for Kopano Core -
@fbartels that is very strange, it does not work for me. I am using the standard letsencrypt folder structure. If I copy the files manually and not use a symlink it works.
-
@yep_dd you are probably missing permissions for the user your kopano-gateway is running with to access all of the folders leading to the actual certificate (to resolve the symlink)
-
@fbartels true it was a permission problem of the letsencrypt folder, but I wonder why Kopano Server runs without issues as kopano users using the same certificate? That’s why I didn’t expect that and also why did it run with a previous kopano-core build (8.6.80.752) was the last one I used.
-
That cannot really be, since the requirement to resolve the ssl certificate is the same across all services and has been there since (but that is a guesstimate, did not check changelogs) 8.4.x.
-
We’ve just upgraded one of our servers to Kopano 8.6.x and had problems with this. Can I ask why the behaviour was changed? I consider this a bug, as to enable SSL/TLS in any Kopany services I now need to make the private key files readable by the unprivileged kopano user. Isn’t the purpose of using an unprivileged user to avoid private information getting out in the event of a security issue? All other daemon processes that I know of use privileged access to open the key files on startup, keeping them secure, before transferring process ownership over to the unprivileged user. I suspect that many Kopano users use the same certificate for SMTP and HTTPS as they do for Kopano, which makes Kopano the weakest link as far as security is concerned.
-
@kitserve said in error connecting to IMAPs via gateway (core 8.6.81.416):
Isn’t the purpose of using an unprivileged user to avoid private information getting out in the event of a security issue?
No. Never really was. Not in Kopano, not in operating systems, not even in the analog life. Whoever holds the money is in a position to spend it.
use privileged access to open the key files on startup, keeping them secure, before transferring process ownership over to the unprivileged user.
Red herring. The contents are already in memory (gotta do the encryption somehow) — it could leak from there. This is even the most probable attack vector, since kopano-server and postfix do not open arbitrary paths in direct consequence of a client asking for it.
httpd is a different matter, becauseGET /index.htmltranslates outright to/srv/www/htdocs/index.htmlin the general case. Moreover, you could still exploit the memory of the httpd process to get at the key. With mod_php being installed almost everywhere, that is the first thing I’d try to break… -
With respect, I must disagree. I take your point that the keys must live in memory, but attacking the memory isn’t necessarily that easy. (Kopano does use ASLR, right?). By contrast, attacking the filesystem is trivial. The Kopano user can read the Kopano config files, which are in a known location, and read the location of the certificates from them. Of course Kopano, Postfix, etc, aren’t supposed to access arbitrary files, but bugs do happen. With all due respect to the Kopano devs, who’ve achieved great things over the years, I trust Postfix’s security record a lot more than Kopano’s.
Most Kopano processes have to launch as root in order to open privileged ports (236/237, POP3/S, IMAP/S) before dropping privileges to the Kopano user. Why not load the keys into memory at the same time, the same as EVERY other program does? Apache, Dovecot, Postfix, ProFTPd, etc all take this approach. What is the compelling reason that Kopano should do things differently? Are all of these other programs doing it wrong?
Quite apart from the (arguable) security issues, this is making my life as a sysadmin more difficult. We use Let’s Encrypt certificates, which are only readable by root. Unless we use separate dedicated certificates for Kopano to the ones that we use for everything else, our certificates will only be readable by root. All other daemon processes that use them work in the way I’ve described above. What is the recommendation to get around this issue? The only obvious options seem to be to run Kopano as root (not a good idea), write some kind of cron job to periodically make the key readable for the Kopano user (hacky), or use a separate certificate for Kopano (extra admin work).
What I’m really not seeing here is a positive reason why Kopano’s behaviour has been changed. It seems like a change for change’s sake that hasn’t been demonstrated to improve Kopano for its users or administrators, although perhaps it makes life easier for the developers. I am open to hearing a clear rationale of why things have changed, and a sensible way of working round the change. In the absence of either of those, I suspect that I’m not the only one who would greatly prefer that this particular change be reverted.
-
Kopano does use ASLR, right?
The KC build uses the distro defaults in that regard.
attacking the memory isn’t necessarily that easy.
Nor is it with files in “[daemons that] aren’t supposed to access arbitrary files”: To change the buffer that eventually contains the in-filesystem name, you would need, you guessed it, a memory attack at just the right time.
Postfix’s security record a lot more than Kopano’s.
Well what can I say, KC undoubtedly descended from a codebase that had its head sooo deep in Windows-isms…
All other daemon processes that use them work in the way I’ve described above. [certs owned by root]
Certs owned by root also render certificate reloading useless, instead necessiting a restart of the entire service. postfix and httpd work around this by keeping one of their processes running as root. KC on the other hand completely switches away from root after the sockets are obtained. Those installations which are not listening on a privileged port number, or are using socket-based activation, can even start it with an unprivileged random UID from the get-go; despite me not changing it specifically for the purpose of Docker, I am being told it unfolded nicely for that case.
What is the recommendation to get around this issue?
setfacl -m u:kopano:r /etc/that/sslcert.keyreason why Kopano’s behaviour has been changed.
Since you don’t trust KC as much as postfix, doing less of the initialization (openssl, mysql, gsoap, setrlimit) as root should fit your case. ;-)
-
Thanks, very informative, you raise good points. Unfortunately we don’t have ACL set up so it looks as though I’m going to have to get a separate certificate for Kopano. I appreciate you taking the time to explain why things have changed, even if I’m still not sure I support it!
-
anyhow. …
I know that I had a similar issue with kopano core a few months ago and I had to merge
cat cert.pem privkey.pem >> kopano.pemshould be at least.
cat privkey.pem cert.pem >> kopano.pemAlways first key then cert in combined certificate.
ssl_private_key_file = /etc/letsencrypt/live/domain.xx/privkey.pem #ssl_private_key_file = /etc/kopano/gateway/privkey.pem #File with certificate for SSL ssl_certificate_file = /etc/letsencrypt/live/domain.xx/cert.pemThe CA is already integrated in /etc/ssl/cert/ca-certificates.
Just point the CA to that file or point to one in letsencrypt.
