maemo.org Bugzilla – Bug 11035
Encrypted XMPP connection does not respect certificates installed via the Certificate Manager
Last modified: 2010-08-15 11:53:16 UTC
You need to log in before you can comment on or make changes to this bug.
After upgrading to PR1.2 the Jabber connection got a checkbox for "Secure Connection only" and "Ignore SSL errors". The latter is checked by default. However, if I untick that (which should be the default anyway, because it undermines the users security because she can be man-in-the-middled trivially) the Jabber connection can't be established. I receive "Network error". The Debug Log is here: Jul 27 13:29:15 Nokia-N900 telepathy-gabble[1719]: GLIB DEBUG tp-glib/presence - tp_presence_mixin_simple_presence_set_presence: called. Jul 27 13:29:15 Nokia-N900 telepathy-gabble[1719]: GLIB DEBUG tp-glib/presence - check_for_status: Found status "available", checking if it's available... Going to connect to jabberd.jabber.ccc.de:5222 Trying 217.10.10.196 port 5222... Connection success (1). SEND: ----------------------------------- <?xml version='1.0' encoding='UTF-8'?> ----------------------------------- *** b_written: 38 *** wrote 38 bytes *** Sending stream header SEND: ----------------------------------- <stream:stream version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" to="jabber.ccc.de" id="793100801484"> ----------------------------------- *** b_written: 136 *** wrote 136 bytes RECV [171]: ----------------------------------- '<?xml version='1.0'?><stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='2587321471' from='jabber.ccc.de' version='1.0' xml:lang='en'>' ----------------------------------- *** Read: 171 chars LM-PARSER: ATTRIBUTE: xmlns = jabber:client LM-PARSER: ATTRIBUTE: xmlns:stream = http://etherx.jabber.org/streams LM-PARSER: ATTRIBUTE: id = 2587321471 LM-PARSER: ATTRIBUTE: from = jabber.ccc.de LM-PARSER: ATTRIBUTE: version = 1.0 LM-PARSER: ATTRIBUTE: xml:lang = en LM-PARSER: Trying to close node: stream:stream LM-PARSER: Have a new message *** New message with type="stream:stream" from: jabber.ccc.de *** XMPP 1.0 stream received: 2587321471 RECV [271]: ----------------------------------- '<stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/><mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'><mechanism>DIGEST-MD5</mechanism><mechanism>PLAIN</mechanism></mechanisms><register xmlns='http://jabber.org/features/iq-register'/></stream:features>' ----------------------------------- *** Read: 271 chars LM-PARSER: ATTRIBUTE: xmlns = urn:ietf:params:xml:ns:xmpp-tls LM-PARSER: Trying to close node: starttls LM-PARSER: ATTRIBUTE: xmlns = urn:ietf:params:xml:ns:xmpp-sasl LM-PARSER: Trying to close node: mechanism LM-PARSER: Trying to close node: mechanism LM-PARSER: Trying to close node: mechanisms LM-PARSER: ATTRIBUTE: xmlns = http://jabber.org/features/iq-register LM-PARSER: Trying to close node: register LM-PARSER: Trying to close node: stream:features LM-PARSER: Have a new message *** New message with type="stream:features" from: unknown SEND: ----------------------------------- <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls" id="936486936677"></starttls> ----------------------------------- *** b_written: 80 *** wrote 80 bytes RECV [50]: ----------------------------------- '<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>' ----------------------------------- *** Read: 50 chars LM-PARSER: ATTRIBUTE: xmlns = urn:ietf:params:xml:ns:xmpp-tls LM-PARSER: Trying to close node: proceed LM-PARSER: Have a new message *** New message with type="proceed" from: unknown *** Setting up SSL... *** Hooray! SSL! LM-SSL: lm-ssl-openssl.c: Cipher: TLSv1/SSLv3/AES256-SHA/256 LM-SSL: lm-ssl-openssl.c: SSL_get_verify_result() = 19 LM-SSL: lm-ssl-openssl.c: server = 'jabber.ccc.de', cn = 'jabber.ccc.de' LM-SSL: lm-ssl-openssl.c: Issuer: /O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root Subject: /C=DE/ST=Hamburg/L=Hamburg/O=Chaos Computer Club e.V./CN=jabber.ccc.de For: jabber.ccc.de Jul 27 13:29:17 Nokia-N900 telepathy-gabble[1719]: GLIB DEBUG gabble - do_auth: authenticating with username: n900test, password: <hidden>, resource: Maemo Jul 27 13:29:17 Nokia-N900 maemo-launcher[973]: child (pid=1722) terminated due to exit()=0 Jul 27 13:29:18 Nokia-N900 telepathy-gabble[1719]: GLIB DEBUG gabble - connection_ssl_cb: called: An unknown SSL error occurred. Jul 27 13:29:18 Nokia-N900 telepathy-gabble[1719]: GLIB MESSAGE default - lm-ssl-openssl.c: Issued for CN: jabber.ccc.de *** Could not begin SSL *** SSL certificate verification failed Freeing up IOChannel and file descriptor Jul 27 13:29:18 Nokia-N900 telepathy-gabble[1719]: GLIB DEBUG gabble - connection_disconnected_cb: called with reason 3 As you can see, the certificate for jabber.ccc.de is signed by CACert. I have imported the CACert root certificates with the certificate manager and expected the Jabber client to connect just fine. However, it does not. Similar bugs might be bug 9262 or bug 8276. I solved the problem by patching loudmouth so that it populates the certificates in /home/user/.maemosec-certs/ssl-ca to OpenSSL. loudmouth-1.4.1/loudmouth/lm-ssl-openssl.c around line 327 contains the calls and the new version should o smth like + cert_path = g_build_filename (/*g_get_user_config_dir (), + "telepathy", "certs", + */ + g_get_home_dir (), + ".maemosec-certs", "ssl-ca", I am sorry to not provide a properly formatted patch but you can download the patched sources here: https://muelli.cryptobitch.de/loudmouth_1.4.1-0osso10+0m6.tar.gz Or a compiled version: https://muelli.cryptobitch.de/libloudmouth1-0_1.4.1-0osso10+0m6_armel.deb
Sounds like bug 9355 to me, though I notice you're already CCed on it. Is the SSL_CERT_DIR workaround not working on PR1.2 any longer?
Hm. Looks as if this is indeed bug 9355. The workaround works, too. I don't necessarily think it's a good approach though. Hardcoding /home/user/.maemosec-certs/ssl-ca for all processes doesn't feel quite right. But it's relatively unintrusive. Sadly, nobody has built a .deb for those new .defs though. Anyway, feel free to close as dup of bug 9355. I'll probably go with my patched version of loudmouth though.
(In reply to comment #2) > Hm. Looks as if this is indeed bug 9355. The workaround works, too. Thanks, resolving. > I don't > necessarily think it's a good approach though. Hardcoding > /home/user/.maemosec-certs/ssl-ca for all processes doesn't feel quite right. Well, it is the platform's default cert store after all, and is already hardcoded for all processes that use libnss3. It's just libssl-linked binaries that are left out (ok, GnuTLS too, but that is not officially supported so out of scope here). *** This bug has been marked as a duplicate of bug 9355 ***