Arch Linux

I am actually running an openfire server and connect via psi without any problems. It might be a certificate problem.

I am using my gmail account with kopete. No issues here.

Similiar situation:

<quote>
$ psi
qca-gnupg: disabling keyring monitoring due to buggy Qt version
Unknown signature value: 795
Unknown signature value: 795
Unknown signature value: 795
</quote>

Three jabber accuounts work (including talk.google.com), but one (internal corporative, based on ejabberd) doesn't work. It tryes to connect several minutes and then sometimes displays error dialog without any useful message.

$ pacman -Q psi qt qca qca-gnupg qca-ossl
psi 0.14-3
qt 4.6.2-4
qca 2.0.2-2
qca-gnupg 2.0.0-1
qca-ossl 2.0.0-3

status of this?

Well it doesn't work for me and many others.

Do not close this bug. It is still affecting me and at least 3 other users on IRC. Just because you can't reproduce it, doesn't mean it isn't a bug.

Kopete on gentoo works fine with my work's intranet Openfire server, and Arch's doesn't. I am not some newbie or clueless user who doesn't know what they are doing, leave this bug open so that when I find a solution other people can find it in the same place if you aren't willing to do anything about it.

Some more information, as this is still a problem for me (have been using pidgin for a few months now).

Here are some observations when connecting to my _openfire_ xmpp server:

Case 1 - Jabber id domain different than server domain (custom server (override default server information)) + SSL

Jabber id: user@gmail.com
Server: mydomain.org port: 5222

Result:
- "Unknown signature value: 795"
- Kopete DOES NOT prompt me to accept self signed certificate.


Case 2 - Jabber id domain equal to server domain + SSL

Jabber id: user@mydomain.org
Server: default settings

Result:
- No complaint about "Unknown signature value: 795"
- Kopete DOES prompt to accept self signed certificate.
- Kopete asks for password, fails to sign on, prompts again to accept self signed certificate, fails to sign on, asks for password, repeat.


Case 3 - NO SSL

Jabber id: user@mydomain.org
Server: default settings

Result:
- "Unknown signature value: 795"
- Kopete DOES prompt to accept self signed certificate... even though ssl has been unchecked (And openfire has "Optional - Clients may connect to the server using secured connections" enabled)
- Kopete asks for password, fails to sign on, prompts again to accept self signed certificate, fails to sign on, asks for password, repeat.




So there is obviously some conflict between certificates (maybe only self signed ones, as connection to Gtalk (jabber/ssl) works fine....? I'll look into getting my certificate signed and report back).

Pidgin and kopete on opensuse are working.

Kopete on arch linux/kde 4.5 (testing) is not working.


Is there any more information that I can try to provide to finally axe this bug...?

Thanks guys.

Hello from afar. I thought I'd share a solution I discovered for this problem while trying to figure out what broke Psi on my Gentoo install.

This bug report led me to the solution: https://support.process-one.net/browse/EJAB-877

See the attached patch for qca-ossl. Reading through EJAB-877, it looked like adding SSL_OP_NO_TICKET to the SSL context would resolve the issue, but for whatever reason, this didn't work for me. I'm not sure why. For the heck of it, I then tried changing the SSL method from SSLv23_server_method() to SSLv3_server_method(), which seems to have fixed the problem. I'm able to connect to SSLv3 servers as well as TLSv1 servers. I don't know what the OpenSSL-internal difference is between SSLv23_server_method() and SSLv3_server_method(), besides the obvious fact that one permits SSLv2, SSLv3, and TLSv1, while the other permits only SSLv3 and TLSv1. Perhaps this has something to do with SSLv2 being thrown out of OpenSSL 1.x? Anyway. See if the above fixes the issue for you folks. It's a starting point, anyway.

Hi Steven, thanks for your efforts into fixing this bug. Your patch did not work for my problem of kopete (kdenetwork-kopete 4.5.1-1) connecting to openfire (openfire 3.6.4-2). Error: Unknown signature value: 795. Which client/protocol are you using?

At least one report of this patch working with some unspecified client/protocol: https://bugs.kde.org/show_bug.cgi?id=221533

Oddly enough, Psi (which also depends on qca/qca-ossl) works fine with patched and unpatched qca-ossl (2.0.0-3).

Hi there. In my case I was originally using Psi with an unpatched qca-ossl. It failed if the openfire server was set to accept TLS connections only, but with my patch applied, it connected fine.

The "unknown signature value" errors aren't fatal, by the way. They're printed whenever the CSR (not applicable), CRL, or certificate has a signature method that qca-ossl isn't aware of. What _really_ matters is that OpenSSL is aware of it.

Looking up 795, it seems that qca-ossl didn't understand what a DSA with SHA384 signature is:
tycho@mjollnir /usr/include/openssl $ grep 795 *
obj_mac.h:#define NID_ecdsa_with_SHA384 795

But whatever, like I said, it's not a fatal error.

You should probably add some debug printouts to find the real critical error. Chances are that SSL_get_error() returns SSL_ERROR_SSL at some point during the Connect, Accept or Handshake stages, and you need to know what the exact error was. Try the attached patch and see what Kopete prints to stderr then.

Slightly more verbose version of the above qca-ossl-debug.patch file. Instead of just printing the reason, print the full error summary.

Let me know what you get out of Kopete with this.

SSL_get_error returned 2. which is SSL_ERROR_WANT_READ

Have played around with the setup of the ssl context with no success. Ideas?

What? SSL_ERROR_WANT_READ is covered by an if condition before the printouts. It's supposed to return TryAgain if that happens. Are you sure you applied the patch correctly?

Indeed. Forgot to mention doConnect() was failing at the first condition... so I commented this out and your debugging code then printed out the error. qca-ossl-fix.patch and the second qca-ossl-debug.patch have both been applied.

Do you have any experience with this error? Thanks Steven.

Failing at the SSL_ERROR_WANT_READ condition? In what way? That condition _should not_ be commented out. It's _supposed_ to 'return TryAgain;'

Leave both patches applied but don't make any of your own changes (if something breaks, let me know what it is), then watch the stderr output from Kopete/Psi.

SSL_ERROR_WANT_READ is the error that keeps doConnect() returning TryAgain. Kopete (+ patched qca-ossl) does not progress any further (ie to doHandshake()).

Both Kopete and Psi return the same output with your patched qca-ossl: "Unknown signature value: 795". Psi connects, kopete does not.

With some small changes (only print statements), maybe some more interesting output:

Kopete output (fails to connect):
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
Unknown signature value: 795
doConnect: SSL_get_error returned 2.

Psi's output (connects fine):
Unknown signature value: 795
doConnect: SSL_get_error returned 2.
doConnect: SSL_get_error returned 2.
doConnect: SSL_get_error returned 2.
in doHandshake

Aha, that _is_ interesting.

May I ask what the address is of the Jabber server you're using? I'd like to see if I can debug it locally.

On second thought, the behaviour Kopete exhibits is very strange. Are your Psi and Kopete linked to the same qca-ossl?

Both clients are using the same qca-ossl. Will be in contact with you shortly with account details. Thanks.

I think the attached patch for OpenSSL fixes the issue on all clients (I had this problem occur with Gajim too). The issue has been languishing on the OpenSSL bug tracker for several months: http://rt.openssl.org/Ticket/Display.html?id=2240&user=guest&pass=guest

I can confirm that the patch named "qca-ossl-fix.patch" works. I have rebuild qca-ossl with the following PKGBUILD file, and Kopete now works with my OpenFire server: http://pastie.org/1217911

Jeppe, could you try the t1_lib.c.patch on OpenSSL? I believe it fixes the root issue instead of working around it (qca-ossl-fix.patch is poorly named, as it's a workaround rather than a fix).

I have rebuild the openssl package now with the patch, and it works. I reinstalled qca-ossl from the repository first, and confirmed that I was not able to connect to the Jabber server prior to testing this out.

Awesome to hear that. I recommend sending a "hey, your patch on issue 2240 worked for me, please put it in mainline" to the guy who made the patch (see the above rt.openssl.org link for the author, etc)

I rebuilt openssl with the t1_lib.c.patch and still can't connect to openfire with kopete.

James, can you give the debug output with only the t1_lib.c.patch and qca-ossl-debug.patch (without the qca-ossl-fix.patch)? It'd be ideal to know what behaviour it's exhibiting.

(And I think I need to add a debug printout for what protocol and cipher are being used. We need to pinpoint the differences here in everyone's case.)

I'll get onto it now.

Output:

Unknown signature value: 795
Unknown signature value: 795

etc.

I rebuilt openssl with the patch then qca-ossl with the qca-ossl-debug.patch. Can upload the PKGBUILD sources I modified to the AUR if anyone wants them.

I started kopete on the command line like this:

kopete

Did I miss something? I was expecting more output.

James:

The output there doesn't make sense if the SSL/TLS negotiation failed, and the qca-ossl-debug.patch has been applied. The qca-ossl-debug.patch prints out detailed error messages if something blows up during the negotiation process. Are you sure you applied the patch and ran kopete with that version of qca-ossl?

Okay just tried it with t1_lib.c.patch, qca-ossl-debug.patch and qca-ossl-fix.patch.

Same behaviour.

Using correct qca-ossl yes:

% strings /usr/lib/qt/plugins/crypto/libqca-ossl.so | grep "SSL_get_error"

gives:

SSL_get_error
SSL_get_error returned %d.

openssl PKGBUILD: http://pastie.org/1235526
qca-ossl PKGBUILD: http://pastie.org/1235530

Interesting.

How is Kopete behaving? Does it say SSL/TLS negotiation failed? I ask because it should have printed out an error if it didn't negotiate properly. It's entirely possible you're hitting a different bug altogether.

No dialogue from kopete. My account just never connects. Worked in gentoo.. switched to same version of kopete in arch and it has never worked since.

I tried applying gentoo qca-ossl/openssl patches but with no help.

Hmm, let's figure out if it's a qca-ossl/openssl or kopete issue. Can you try Psi, just for kicks?

Psi works fine.

I still get "Unknown signature value: 795" but it connects anyway.

Yes, the "Unknown signature value" isn't relevant. It just means qca-ossl doesn't recognize the algorithm being used, but what matters is that OpenSSL itself recognizes the algorithm.

If Psi works, it's a Kopete thing. Now we just need to discover why. Is Kopete statically linked to qca-ossl or OpenSSL, perhaps?

When I ldd psi I can see it dynamically links against libqca whereas kopete doesn't.

That would mean the qca-ossl-debug patch would have no effect until recompiling kopete. In addition since kopete uses ssl through qca-ossl it wouldn't pick up the openssl fix.

Then again kopete might dlopen libqca at runtime.. I'm not sure.

I could nm for common symbols but I'm recompiling kopete right now.

Recompiled kopete against qca-ossl-debug + openssl patched.. no difference.

I just tried locally on a fresh Arch install. Both Kopete and Psi work fine for me with the t1_lib.c.patch applied to OpenSSL. I don't know what to tell you.

I switched my jabber/xmpp port from 5222 to 5223 and am now able to connect

People who experiencing problems with GTalk in Kopete - do you have option "Allow plain-text password authentication" checked in Google Talk account settings? If no, check it and verify it helps. It helped for me (Arch Linux x64_86, testing enabled).

I just save it here ;)
With this package (instead openssl from repository) psi-plus and kopete works normally

A little summary for those who still cannot get kopete and PSI connecting:

1. t1_lib.c.patch cannot be applied to the newest openssl. As I looked at code it seems to be applited little other way. -> No patching needed.
2. qca-ossl-fix.patch, which in fact looks like a workaround WORKS, but...
* to get PSI working: as long as PSI is dynamically linked to libqca, you just have to install patched version of this package and you're done.
* to get kopete working: after installing patched qca-ossl, you have to recompile kopete (in fact, whole kdenetwork which kopete is part of).

Hope that helps someone.

Status?

Connecting to an openfire jabber server with kopete stopped working after kde update to 4.8.3.

So this can be closed?

I use psi-plus from AUR and see this message in cli, too.