2

I am trying to connect to our in-house XMPP server using piding in Arch Linux, but I always get SSL Handshake Failed error in Pidgin.

These are the error lines I get when running pidgin -d:

(10:52:25) jabber: Sending (user@host): <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
(10:52:25) jabber: Recv (50): <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
(10:52:25) nss: Handshake failed  (-12173)
(10:52:25) connection: Connection error on 0x16385f0 (reason: 5 description: SSL Handshake Failed)
(10:52:25) account: Disconnecting account user@host/ (0x1820c60)

I searched for that nss error, and found here that this error means that server is using some kind of insecure key exchange (I suppose).

Anyway, I tried ssltap -s -p 5222 host:5222 and pointed Pidgin to localhost:5222 to get the log of handshake, and this is it:

Connected to HOST:5222
--> [
<?xml version='1.0' ?><stream:stream to='HOST' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>]
<-- [
<?xml version='1.0' encoding='UTF-8'?><stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="HOST" id="7d2b1460" xml:lang="en" version="1.0">]
<-- [
<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism></mechanisms></stream:features>]
--> [
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>]
<-- [
<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>]
--> [
(151 bytes of 146)
SSLRecord { [Wed Feb 24 10:44:10 2016]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 146 (0x92)
   handshake {
      type = 1 (client_hello)
      length = 142 (0x00008e)
         ClientHelloV3 {
            client_version = {3, 3}
            random = {...}
            session ID = {
                length = 0
                contents = {...}
            }
            cipher_suites[17] = {
                (0xc02b) TLS/ECDHE-ECDSA/AES128-GCM/SHA256
                (0xc02f) TLS/ECDHE-RSA/AES128-GCM/SHA256
                (0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
                (0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
                (0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
                (0xc027) TLS/ECDHE-RSA/AES128-CBC/SHA256
                (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
                (0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA
                (0xc011) TLS/ECDHE-RSA/RC4-128/SHA
                (0x009e) TLS/DHE-RSA/AES128-GCM/SHA256
                (0x0033) TLS/DHE-RSA/AES128-CBC/SHA
                (0x0032) TLS/DHE-DSS/AES128-CBC/SHA
                (0x0067) TLS/DHE-RSA/AES128-CBC/SHA256
                (0x0039) TLS/DHE-RSA/AES256-CBC/SHA
                (0x006b) TLS/DHE-RSA/AES256-CBC/SHA256
                (0x002f) TLS/RSA/AES128-CBC/SHA
                (0x0035) TLS/RSA/AES256-CBC/SHA
            }
            compression[1] = {
                (00) NULL
            }
            extensions[67] = {
              extension type server_name, length [14] = {
   0: 00 0c 00 00  09 6c 6f 63  61 6c 68 6f  73 74        | .....localhost
              }
              extension type renegotiation_info, length [1] = {
   0: 00                                                  | .
              }
              extension type elliptic_curves, length [8] = {
   0: 00 06 00 17  00 18 00 19                            | ........
              }
              extension type ec_point_formats, length [2] = {
   0: 01 00                                               | ..
              }
              extension type signature_algorithms, length [22] = {
   0: 00 14 04 01  05 01 06 01  02 01 04 03  05 03 06 03  | ................
  10: 02 03 04 02  02 02                                  | ......
              }
            }
         }
   }
}
]
<-- [
(2778 bytes of 2773)
SSLRecord { [Wed Feb 24 10:44:10 2016]
   type    = 22 (handshake)
   version = { 3,1 }
   length  = 2773 (0xad5)
   handshake {
      type = 2 (server_hello)
      length = 70 (0x000046)
         ServerHello {
            server_version = {3, 1}
            random = {...}
            session ID = {
                length = 32
                contents = {...}
            }
            cipher_suite = (0x0033) TLS/DHE-RSA/AES128-CBC/SHA
            compression method = (00) NULL
         }
      type = 11 (certificate)
      length = 2135 (0x000857)
         CertificateChain {
            chainlength = 2132 (0x0854)
            Certificate {
               size = 925 (0x039d)
               data = { saved in file 'cert.001' }
            }
            Certificate {
               size = 1201 (0x04b1)
               data = { saved in file 'cert.002' }
            }
         }
      type = 12 (server_key_exchange)
      length = 552 (0x000228)
      type = 14 (server_hello_done)
      length = 0 (0x000000)
   }
}
]
--> [
(7 bytes of 2)
SSLRecord { [Wed Feb 24 10:44:10 2016]
   type    = 21 (alert)
   version = { 3,1 }
   length  = 2 (0x2)
   fatal: illegal_parameter
}
]
Read EOF on Client socket. [Wed Feb 24 10:44:10 2016]
Read EOF on Server socket. [Wed Feb 24 10:44:10 2016]

Seems like server and client agreed on TLS/DHE-RSA/AES128-CBC/SHA, but client failed then. Is that it? I have added cert.001 and cert.002 to Certificates in Pidgin, but that doesn't help.

Because it is an in-house server, I don't need the security and I don't care about it. I modified account setting in Pidgin to Use encryption if available and also Allow plaintext auth over unencrypted streams but it does not work.

Any help on how to make Pidgin (or NSS) to accept my server is very appreciated.

Output of pidgin --version

Pidgin 2.10.12 (libpurple 2.10.12)

Output of pacman -Qi nss

Name            : nss
Version         : 3.22-1
Description     : Mozilla Network Security Services
Architecture    : x86_64
URL             : http://www.mozilla.org/projects/security/pki/nss/
Licenses        : MPL  GPL
Groups          : None
Provides        : None
Depends On      : nspr>=4.10.10  sqlite  zlib  sh  p11-kit
Optional Deps   : None
Required By     : atom-editor  firefox  jre8-openjdk-headless  libnm-glib  libpurple  qca-qt4  qca-qt5
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 5.80 MiB
Packager        : Jan Alexander Steffens (heftig) <[email protected]>
Build Date      : Fri Feb 5 15:09:40 2016
Install Date    : Mon Feb 22 17:13:39 2016
Install Reason  : Installed as a dependency for another package
Install Script  : Yes
Validated By    : Signature

EDIT:

I forgot to mention that I do not have access to server, so I can not change anything there.

3
  • The fatal parameter error means, "A field in the handshake was out of range or inconsistent with other fields. This message is always fatal." from tools.ietf.org/html/rfc5246#appendix-A.3 - this feels more like an application issue than a linux issue, may do better on SuperUser? Commented Feb 24, 2016 at 11:41
  • How may I move question to SuperUser? Commented Feb 24, 2016 at 16:46
  • I just forgot to mention that I have another Pidgin running on Ubuntu 12.04 which is working fine. I think the version is 2.10.3 or something like that, but I am not in workplace. I will confirm that when I get there. Commented Feb 24, 2016 at 16:51

0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.