Bug 3684 - Socket error with POP3 using TLS client certificate
Summary: Socket error with POP3 using TLS client certificate
Status: RESOLVED FIXED
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: POP3 (show other bugs)
Version: 3.14.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2016-09-02 09:49 CEST by Thomas Orgis
Modified: 2016-09-18 11:51 CEST (History)
0 users

See Also:


Attachments
3684-fix-v1 (5.10 KB, patch)
2016-09-18 04:00 CEST, Andrej Kacian
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Orgis 2016-09-02 09:49:47 CEST
I am trying to access a POP3 account using a client certificate. The following works:

shell$ openssl s_client -starttls pop3 -connect example.org:110 -key username.key -cert username.cert
[...]
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2939 bytes and written 1856 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: [...]
    Session-ID-ctx: 
    Master-Key: [...]
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket: [...]

    Compression: 1 (zlib compression)
    Start Time: 1472801489
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---
+OK Dovecot ready.
USER username
+OK
PASS blabla
+OK Logged in.
LIST
+OK 128 messages:
1 2120
2 13332
3 1040
[...]
.
QUIT
DONE

I tried using the client certificate in claws and failed so far. I figured out that I apparently need to concatenate the key and cert into one file, otherwise claws gives a parsing error. Now it seems to be happy with the key, but the connection fails with this debug output:

** Message: Account 'XXXXXXXX': Connecting to POP3 server: example.org:110...

session.c:202:session (0x2b71d60): connected
[09:45:05] POP3< +OK Dovecot ready.
[09:45:05] POP3> STLS
[09:45:06] POP3< +OK Begin TLS negotiation now.
ssl.c:237:waiting for SSL_connect thread...
passwordstore.c:184:Getting password 'recv_cert' from block (1/35)
passwordstore.c:196:Password 'recv_cert' in block (1/35) not found.
ssl_certificate.c:258:got 1 certs in crt_list! 0xXXXXXXXX
ssl_certificate.c:315:got key! 0xXXXXXXX
ssl.c:255:SSL_connect thread returned -50

** (claws-mail:32617): WARNING **: SSL connection failed (The request is invalid.)

** (claws-mail:32617): WARNING **: couldn't start TLS session.
session.c:376:session (0x2b71d60): closed


Did I still do something wrong? Other people successfully fetch their mail from that server using mpop.
Comment 1 Paul 2016-09-02 10:05:54 CEST
Did you try it with gnutls-cli instead of openssl? Claws Mail uses GnuTLS and not OpenSSL.
Comment 2 Thomas Orgis 2016-09-02 22:26:26 CEST
It also works with gnutls-cli:

shell$ gnutls-cli -s -p 110 --insecure --x509keyfile=username.key --x509certfile=username.cert example.org
Processed 0 CA certificate(s).
Processed 1 client X.509 certificates...
Resolving 'example.org'...
Connecting to '123.123.123.123'...

- Simple Client Mode:

+OK Dovecot ready.
stls
+OK Begin TLS negotiation now.
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 1 certificates.
- Certificate[0] info: [...]
- Status: The certificate is NOT trusted. The certificate issuer is unknown. The name in the certificate does not match the expected. 
*** PKI verification of server certificate failed...
- Successfully sent 1 certificate(s) to server.
- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
- Session ID: [...]
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.2
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-SHA256
- Client Signature: RSA-SHA512
- Cipher: AES-256-GCM
- MAC: AEAD
- Compression: NULL
- Options: safe renegotiation,
USER username
+OK
PASS blabla
+OK Logged in.
list
+OK 148 messages:
1 2120
2 13332
3 1040
4 995
5 1280
6 29042
[...]
.
quit
+OK Logging out.
- Peer has closed the GnuTLS connection
Comment 3 Paul 2016-09-03 09:52:52 CEST
Did you use the 'Client certificates' options in the Account Preferences on the SSL page?
Comment 4 Thomas Orgis 2016-09-03 13:07:24 CEST
Yes, that is where I put in the path to the file containing the key and cert (concatenated). The key is not protected by a passphrase, so the password field is empty. When I only put in the cert file, claws gives a parsing error and the failure is different.
Comment 5 Thomas Orgis 2016-09-03 13:08:45 CEST
And: Blocking or non-blocking SSL does not make a difference.
Comment 6 Paul 2016-09-03 16:27:56 CEST
You're using the STARTTLS option in claws-mail?
Perhaps if you provide all the necessary details in relation to the server someone can test.
Comment 7 Thomas Orgis 2016-09-03 17:54:19 CEST
Yes, I am using STARTTLS in claws-mail, with port 110. I thought
that is obvious from the openssl and gnutls tests als well as the
debug log:

[09:45:05] POP3> STLS
[09:45:06] POP3< +OK Begin TLS negotiation now.

What settings are missing? This is a dovecot server that accepts
client certificates, I tried all variations of options in claws
(STARTTLS, non-blocking) … I don't see any further settings to
tweak. Perhaps somebody can provide logs from a working session
with client certificates so that one can spot a difference
(probably also the gnutls-cli test to see details about the
encryption). So far I only have a report from another user trying
claws-mail with that very same server and the same results.

I do not have prior experience with client certificates for mail,
nor other servers to test. People report success using mpop with
this server. I hoped to be able to use claws to fetch from that
account together with all the others.
Comment 8 Thomas Orgis 2016-09-14 08:51:57 CEST
Sorry for bumping, but the sudden silence suprises me. Any reproduction of this issue yet?
Comment 9 Andrej Kacian 2016-09-18 04:00:27 CEST
Created attachment 1683 [details]
3684-fix-v1

If you're running GnuTLS 3.0 or newer, and are able to compile Claws Mail for testing, please try this patch.
Comment 10 Thomas Orgis 2016-09-18 09:38:39 CEST
I got gnutls-3.4.14 (update to 3.4.15 pending) and with this patch, I can fetch the mail using the client certificate. Thanks!
Comment 11 Andrej Kacian 2016-09-18 10:51:00 CEST
Thanks for testing, I cleaned up the patch a bit and committed it to our git. The fix will be included in the next release.
Comment 12 users 2016-09-18 10:51:03 CEST
Changes related to this bug have been committed.
Please check latest Git and update the bug accordingly.
You can also get the patch from:
http://git.claws-mail.org/

++ ChangeLog	2016-09-18 10:51:03.052559317 +0200
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=6eea5b249c34d9abd73f43ad987df4a667c10882
Merge: 471adf7 a05eeae
Author: Colin Leroy <colin@colino.net>
Date:   Sun Sep 18 10:51:02 2016 +0200

    Merge branch 'master' of file:///home/git/claws

http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=a05eeae0e79999d34dd02d733fc83e9d04082b03
Author: Andrej Kacian <ticho@claws-mail.org>
Date:   Sun Sep 18 10:46:58 2016 +0200

    Fix using client TLS certificates for GnuTLS 3.0 and up.
    
    3.0 introduced new API for setting client certificates,
    gnutls_certificate_set_retrieve_function2().
    
    This fixes bug #3684.