Bug 311990 - Problem connetcing to dovecot-managesieve with STARTTLS and auth=CRAM-MD5 /LOGIN
Summary: Problem connetcing to dovecot-managesieve with STARTTLS and auth=CRAM-MD5 /LOGIN
Status: CONFIRMED
Alias: None
Product: kmail2
Classification: Applications
Component: sieve (show other bugs)
Version: 5.7.3
Platform: Other Linux
: NOR normal with 101 votes (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-12-20 16:01 UTC by Pal Körössy
Modified: 2019-08-15 12:29 UTC (History)
16 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot of kmail sieve manager dialog (19.47 KB, image/png)
2016-03-16 17:56 UTC, Alex Potter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pal Körössy 2012-12-20 16:01:22 UTC
I cannot connect to dovecot-managesieve service with client settings= STARTTLS; auth=CRAM-MD5
Kmail says: "Failed to fetch the list of scripts" in "Manage Sieve scripts" menu. 
The IMAP account in KMail is confugured to use the same login settings for Sieve.
Log of dovecot:
Dec 20 15:32:12 server dovecot: managesieve-login: Disconnected (auth failed, 1 attempts in 2 secs): user=<kp>, method=CRAM-MD5, rip=10.0.0.89, lip=10.0.0.249, TLS: Disconnected, session=<TxiomEnRvgAKAABZ>

STARTTLS and auth=login is also problematic:
Dec 20 15:35:45 server dovecot: managesieve-login: Disconnected (client didn't finish SASL auth, waited 0 secs): user=<>, method=LOGIN, rip=10.0.0.89, lip=10.0.0.249, TLS: Disconnected, session=<eSd0pUnRxwAKAABZ>

Connecting to dovecot IMAP with the same settings works without any problem:
Dec 20 15:48:03 server dovecot: imap-login: Login: user=<kp>, method=CRAM-MD5, rip=10.0.0.89, lip=10.0.0.249, mpid=3295, TLS, session=<SBJt0UnRhwAKAABZ>

Reproducible: Always
Comment 1 Pal Körössy 2012-12-21 09:14:03 UTC
Have tried to connect to managesieve on the same server with Thunderbird client using SARTTLS and login=CRAM-MD5 without problem:

Dec 21 10:11:58 server dovecot: managesieve-login: Login: user=<kp>, method=CRAM-MD5, rip=10.0.0.89, lip=10.0.0.249, mpid=3030, TLS, session=<NyhcPVnRhwAKAABZ>
Comment 2 regi.hops 2012-12-27 09:19:48 UTC
Same problem with DIGEST-MD5 / CRAM-MD5 / LOGIN methods.
Only PLAIN is working properly.

System:
KDE 4.9.4 / openSUSE 12.2 x86_84

Dovecot 2.1.12 reports on CRAM-MD5:
dovecot: auth: cram-md5(info,12.34.56.78,<xxxxxxxxxxxxxxxxx>): password mismatch
dovecot: auth: Debug: client passdb out: FAIL#0111#011user=info
dovecot: managesieve-login: Disconnected (auth failed, 1 attempts in 2 secs): user=<info>, method=CRAM-MD5, rip=12.34.56.78, lip=12.34.56.78, TLS: Disconnected, session=<xxxxxxxxxxxxxxxx>

With DIGEST-MD5 (same as with LOGIN):
dovecot: managesieve-login: Disconnected (client didn't finish SASL auth, waited 0 secs): user=<>, method=DIGEST-MD5, rip=12.34.56.78, lip=12.34.56.78, TLS: Disconnected, session=<xxxxxxxxxxxxxxxx>
dovecot: auth: Debug: client in: CANCEL#0111
Comment 3 Thomas Berger 2013-02-01 15:53:33 UTC
This problem exists since at least KDE 4.3.
Comment 4 Florian Staudacher 2013-03-13 11:45:27 UTC
I can confirm this issue with current Fedora Packages

$ kmail --version
Qt: 4.8.4
KDE Development Platform: 4.9.5
KMail: 4.9.5
Comment 5 mase 2013-10-22 19:21:15 UTC
I can also confirm this! Plaintext login works.
Comment 6 Laurent Montel 2013-10-23 12:46:39 UTC
Ok but I can't test...
need a server for it.
Comment 7 regi.hops 2013-10-23 17:46:35 UTC
(In reply to comment #6)
> Ok but I can't test...
> need a server for it.

I can give you an account on my server if you like.
Comment 8 Laurent Montel 2013-10-23 19:05:02 UTC
It's possible :)
Not sure that I fix it this week but yes please (in private of course)
Comment 9 Nigel Kukard 2014-10-19 20:38:10 UTC
Seems I've ended up with exactly the same problem.

1. I have a password file dovecot auth, the password entry is CRAM-MD5

2. dovecot settings
disable_plaintext_auth = yes
auth_mechanisms = cram-md5

3. kmail is set to "use host and login configuration" on port 4190


IMAP authentication works without a hitch, however sieve gets an authentication error...
Oct 19 19:43:35 gbr dovecot: managesieve-login: Disconnected (auth failed, 1 attempts in 3 secs): user=<xxx@yyy>, method=CRAM-MD5, rip=105.x.x.x, lip=217.x.x.x, TLS: Disconnected, session=<zzz>
Comment 10 Martin 2015-01-03 23:06:54 UTC
Looks like it's still around in KMail 4.14.1.

A long week!
Comment 11 Alexander Görtz 2015-01-23 21:20:31 UTC
Confirmed the bug still exists:
Qt: 4.8.6
KDE: 4.14.3
KMail: 4.14.3
So switching from LOGIN to PLAIN worked for me.
Comment 12 Alex Potter 2016-03-16 17:56:53 UTC
Created attachment 97927 [details]
Screenshot of kmail sieve manager dialog

This bug exists on KMail 5.0.2 on Kubuntu 15.10 AMD 64. The login to sieve succeeds, data is returned, but is inaccessible to kmail, as can be seen in the attached screenshot
Comment 13 Alex Potter 2016-03-16 18:00:45 UTC
Version here is 15.08.2-0ubuntu1
Comment 14 Nikolay Brookstein 2016-12-19 23:14:51 UTC
*** This bug has been confirmed by popular vote. ***
Comment 15 Nikolay Brookstein 2016-12-19 23:17:34 UTC
KMail 5.3.3
Kolab 16 server with TLS/STARRTLS

log on the server side:
Dez 19 23:29:51 test.com sieve[7287]: inittls: Loading hard-coded DH parameters
Dez 19 23:29:51 test.com sieve[7287]: STARTTLS failed
Dez 19 23:29:51 test.com sieve[7287]: Lost connection to client -- exiting

problem still persists!
Comment 16 Nikolay Brookstein 2016-12-19 23:33:53 UTC
Some logging from the kmail side:

log_kmanagersieve: "session1" connect to host url:  QUrl("sieve://alice%40test.com@mail-01.test.com:4190?x-mech=PLAIN")
log_kmanagersieve: "session1" void KManageSieve::Session::scheduleJob(KManageSieve::SieveJob*) KManageSieve::SieveJob(0x5607dd4137e0)
log_kmanagersieve: "session1" void KManageSieve::Session::killJob(KManageSieve::SieveJob*, KJob::KillVerbosity) KManageSieve::SieveJob(0x5607dd4137e0)
log_kmanagersieve: "session1" void KManageSieve::Session::scheduleJob(KManageSieve::SieveJob*) KManageSieve::SieveJob(0x5607dd115640)
log_kmanagersieve: S:  "\"IMPLEMENTATION\" \"Cyrus timsieved 2.5.10-55-gb6dbffa-Kolab-2.5.10-6.1.el7.kolab_16\""
log_kmanagersieve: 1 "IMPLEMENTATION" "Cyrus timsieved 2.5.10-55-gb6dbffa-Kolab-2.5.10-6.1.el7.kolab_16" "" 0
log_kmanagersieve: S:  "\"SASL\" \"\""
log_kmanagersieve: 1 "SASL" "" "" 0
log_kmanagersieve: "session1" Connected to Sieve server:  "Cyrus timsieved 2.5.10-55-gb6dbffa-Kolab-2.5.10-6.1.el7.kolab_16"
log_kmanagersieve: S:  "\"SIEVE\" \"comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy date\""
log_kmanagersieve: "session1" Server SASL authentication methods:  ()
log_kmanagersieve: 1 "SIEVE" "comparator-i;ascii-numeric fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy date" "" 0
log_kmanagersieve: S:  "\"STARTTLS\""
log_kmanagersieve: "session1" Server script capabilities:  ("comparator-i;ascii-numeric", "fileinto", "reject", "vacation", "imapflags", "notify", "include", "envelope", "body", "relational", "regex", "subaddress", "copy", "date")
log_kmanagersieve: 1 "STARTTLS" "" "" 0
log_kmanagersieve: S:  "\"UNAUTHENTICATE\""
log_kmanagersieve: "session1" Server supports TLS
log_kmanagersieve: 1 "UNAUTHENTICATE" "" "" 0
log_kmanagersieve: S:  "OK"
log_kmanagersieve: "session1" Unrecognised key  "UNAUTHENTICATE"
log_kmanagersieve: 2 "OK" "" "" 0
log_kmanagersieve: "session1" Sieve server ready & awaiting authentication.
log_kmanagersieve: C:  "STARTTLS"
log_kmanagersieve: S:  "OK \"Begin TLS negotiation now\""
log_kmanagersieve: 2 "OK \"Begin TLS negotiation now\"" "" "" 0
log_kmanagersieve: SessionThread::doStartSsl()
log_kmanagersieve: void KManageSieve::SessionThread::slotSocketError() "Unknown error"
log_kmanagersieve: "session1" No job for reporting this error message! "Could not connect to host Unknown error."
log_kmanagersieve: Initial SSL handshake failed. cipher.isNull() is true , cipher.usedBits() is 0 , the socket says: "Unknown error" and the list of SSL errors contains 0 items.
log_kmanagersieve: "session1" TLS negotiation done.
log_kmanagersieve: "session1" TLS negotiation done, m_state= 2
log_kmanagersieve: Initial SSL handshake failed. cipher.isNull() is true , cipher.usedBits() is 0 , the socket says: "Unknown error" and the list of SSL errors contains 0 items.
log_kmanagersieve: "session1" TLS negotiation done.
log_kmanagersieve: "session1" TLS negotiation done, m_state= 2

It looks like we have several problems here.
- First of all is probably wrong interprets a username from the imap, so instead of "alice@test.com" we getting "alice%40test.com@mail-01.test.com"
- Second one, that "SessionThread::doStartSsl()" fails

I can make a email account to a KDE developer if it helps to debug.
Comment 17 Laurent Montel 2016-12-20 17:09:20 UTC
For sure I can't investigate this week (Christmas holidays for me) but indeed an account which can provide error will help me to investigate for sure.
Comment 18 Nikolay Brookstein 2016-12-20 18:48:01 UTC
(In reply to Laurent Montel from comment #17)
> For sure I can't investigate this week (Christmas holidays for me) but
> indeed an account which can provide error will help me to investigate for
> sure.

That would be great!

Than I will create an account for you and send you login data.
Can I use your *@kde.org address for this?

Merry Christmas

P.S. Probably the majority is busy with holidays && famirly && friends this week :D
So I have expected that only after 1-2 weeks it will be possible to try to find out what is going wrong here.
Comment 19 Laurent Montel 2016-12-21 11:45:41 UTC
(In reply to Nikolay Brookstein from comment #18)
> (In reply to Laurent Montel from comment #17)
> > For sure I can't investigate this week (Christmas holidays for me) but
> > indeed an account which can provide error will help me to investigate for
> > sure.
> 
> That would be great!
> 
> Than I will create an account for you and send you login data.
> Can I use your *@kde.org address for this?

Yep montel@kde.org

> 
> Merry Christmas

Thanks :)

> 
> P.S. Probably the majority is busy with holidays && famirly && friends this
> week :D
> So I have expected that only after 1-2 weeks it will be possible to try to
> find out what is going wrong here.
Comment 20 Michael Chalvatzis 2018-05-14 13:26:16 UTC
I still can confirm this bug and I hit this even with version 5.7.3 (included with kubuntu 18.04). When will there be a fix for this?
My investigation shows, that the client response of the md5 challenge is wrong by  kmail. Doing the steps manually works perfect.

here some log entries of the (dovecot-)sieve server that shows the error:
auth: Debug: client in: AUTH#0111#011CRAM-MD5#011service=sieve#011secured#011session=TJDeHydsngDAqLKz#011lip=192.168.xxx.xxx#011rip=192.168.xxx.xxx#011lport=4190#011rport=53662
auth: Debug: client passdb out: CONT#0111#011PDA0NDIzNjg4NDE3NTgzMDcuMTUyNjI5MDE3N0BtYXN0ZXJibGFzdGVyLmhvbWxxxxxxxx==
auth: Debug: client in: CONT#0111#011Y2hhbHZhdHogMDE5YzU0MjcyOTM4MGFjNmVhMDkxMTg4YTU1Nzxxxxxxx= <-- this is wrong answer! recreating the challenge response manually produces a different output!!
auth: Debug: passwd-file(username,192.168.xxx.xxx,<TJDeHydsngDAqLKz>): lookup: user=username file=/etc/dovecot/users
auth: Debug: password(username,192.168.xxx.xxx,<TJDeHydsngDAqLKz>): Credentials: dxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
auth: cram-md5(username,192.168.xxx.xxx,<TJDeHydsngDAqLKz>): password mismatch
auth: Debug: client passdb out: FAIL#0111#011user=username
Comment 21 aeris 2019-08-15 10:13:24 UTC
Same here.
When debugging, I notice the returned CRAM-MD5 is always the same, whatever the challenge the server send.

Aug 15 10:10:49 kamino dovecot[25805]: auth: Debug: client passdb out: CONT        1        PDE2MzYzMDkzMDA4MTM5MTYuMTU2NTg2Mzg0OUBrYW1pbm8+
Aug 15 10:10:49 kamino dovecot[25805]: auth: Debug: client in: CONT        1        YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx= (previous base64 data may contain sensitive data)
Aug 15 10:11:00 kamino dovecot[25805]: auth: Debug: client passdb out: CONT        1        PDU3NjA0MjQyNTkyMzAwMzEuMTU2NTg2Mzg2MEBrYW1pbm8+
Aug 15 10:11:00 kamino dovecot[25805]: auth: Debug: client in: CONT        1        YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx= (previous base64 data may contain sensitive data)

Notice the 2 challenges PDE2MzYzMDkzMDA4MTM5MTYuMTU2NTg2Mzg0OUBrYW1pbm8+ and PDU3NjA0MjQyNTkyMzAwMzEuMTU2NTg2Mzg2MEBrYW1pbm8+, but the same response YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx
Comment 22 aeris 2019-08-15 10:43:50 UTC
Seems the used challenge is empty string

./gen-auth.pl CRAM-MD5 "aeris" "$PASS" ""
YWVyaXMgMTliMTYxYjNkMGI4YWY3OGRlNjkwNDFkNWQ4Zmxxxx=

Which is the same as the always sent token in my case
Comment 23 aeris 2019-08-15 11:49:36 UTC
Trouble is here: https://github.com/KDE/libksieve/blob/master/src/kmanagesieve/sessionthread.cpp#L265-L266

Seems strange, the challenge is expected to be read *before* the AUTHENTICATE command…
Comment 24 aeris 2019-08-15 12:29:17 UTC
Ok, here is the root cause: https://github.com/KDE/libksieve/blob/master/src/kmanagesieve/session.cpp#L171

With CRAM-MD5, the challenge is on the `response.key()`, not on the `data` field, which is here empty. Don't know how to fix this without breaking other auth type…