# OpenSSL 1.x and kmail/kopete [solved]

## Hamlet

Hello,

I have had major problems when upgrading OpenSSL to 1.x, coming from the 0.9.8x family.

In my understanding, they have killed by default the advertising of SSL v2 (I ask forgiveness, I am basically parroting other posts - especially a Gentoo bug I can't find anymore).

And it seems that the main IMAP servers I use (one via SSL authentication, the other two via TSL) and one at least of the POP servers (namely, Gmail's) don't accept my login anymore (I am using kmail as local e-mail client).

I reverted to 0.9.8o and it seems to work again, although there are packages that pull OpenSSL 1.x back in (or better, they pull in the OpenSSL with slot number 0.9.8, plus a slot 0, OpenSSL 0.9.8o-r2, since I masked 1.x).

I am afraid that if I allow OpenSSL 1.x to be pulled in, kdepidlib will be linked against them and the nightmare will be back.

I don't know if it's possible to force my applications (mainly kmail, kopete) to require SSL v3 instead, and I don't know if the servers I use support it.

So I would like somebody to describe which is the status of SSL in Gentoo (and maybe outside it), the expected behavior (has anybody experienced Gmail breakup? with kmail? which packages installed?) and what, in short, I should do.

I had at a certain point a configuration with OpenSSL 1.0.0-r3 (slot 0) and 0.9.8o-r2 (slot 0.9.8?) and I couldn't access mail (also after recompiling kmail, libkdepim, kdepimlibs and kdebase-kioslaves).

Thank you for your attention.

Using: Linux 2.6.35; KDE 4.4.5Last edited by Hamlet on Thu Aug 26, 2010 7:24 pm; edited 1 time in total

----------

## Hu

Assuming you are correct that SSLv2 is now disabled by default and further assuming that this is the problem, the short answer is that those servers are either misconfigured or badly out of date.  It seems unlikely that such a statement would be true about Gmail, so this may not be the problem.  SSLv2 has been deprecated for a very long time.  If I recall correctly, the Mozilla project switched it off by default in Firefox 3.0 (or earlier?).  Any servers which still require SSLv2 to work correctly are a bad sign.

As a quick test, please collect a packet capture showing a successful and failed login.  Before you post its contents, ensure that all captured packets are SSL encrypted and that neither your username nor password are visible anywhere in the capture.  When used without SSL, both IMAP and POP can send passwords cleartext, so if your mail client fell back to non-SSL, posting the capture could reveal your credentials.  Clients should not do this on their own, but it is better to be safe.

----------

## Hamlet

Ok, then probably it's not about the dropped SSL version.

I upgraded OpenSSL again (1.0.0-r3), and it fails again.

I have installed net-analyzer/wireshark and started listening to everything related to one of my mail servers.

This is an extract of whet I get when I try to read the mailbox (47721 is probably the local port I am using?):

```
TCP  47721 > imap [SYN]

TCP  imap > 47721 [SYN,ACK]

TCP  47721 > imap [ACK]

IMAP Response: * OK
```

(I assume we could estabilish a connection to the server)

```
TCP  47721 > imap [ACK]

IMAP Request: 0 CAPABILITY

TCP  imap > 47721 [ACK]

IMAP Response: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY UNSELECT SORT LANGUAGE STARTTLS XSENDER X-NETSCAPE XSERVERINFO X-SUN-SORT X-SUN-IMAP X-ANNOTATEMORE X-UNAUTHENTICATE XUM1 LOGINDISABLED
```

(what can you do? this and that)

```
IMAP Request: 1 STARTTLS

TCP  imap > 47721 [ACK]

IMAP Response: 1 OK COMPLETED
```

(let's speak garbage! ok, I'm in)

```
TCP  47721 > imap [ACK]

TCP  47721 > imap [FIN,ACK]

TCP  47721 > imap [ACK]

TCP  47721 > imap [FIN,ACK]

TCP  47721 > imap [ACK]
```

Then kmail informs me that his slave has died ("The process for the imap://myserver protocol died").

I could give the twi IMAP commands directly to the server (via telnet), but then I have no idea how to proceed, so I dropped it.

I can't understand much of this, but it seems everything looks ok on the network side...

I still think is something related to SSL (as in, when I downgrade it works...).

But I can't get any hint. kmail is not linked to OpenSSL, kio_imap.so is not either. revdep-rebuild is happy.

I have learned that kio_imap.so or something like that segfaults (signal 11). I can't learn why.

----------

## Hu

A segfault makes this much easier.  Rebuild the affected component with debug information, collect the core file, and post the backtrace.  See How to get meaningful backtraces in Gentoo for details.

----------

## Hamlet

It's not much easier, since the crashing object (kio_imap.so) is not directly called.

In addition to the documentation that you linked (which is not optional), also see Debugging IOSlaves.

This debugging path would have probably helped, but fortunately for me a person in the KDE forums informed me that KDE relies on Qt for SSL interface (that's also why almost no KDE component is linked to OpenSSL, I guess) and suggested to "look down there".

I re-emerged libQtNetwork.so (currently in x11-libs/qt-core; for reference, I'm using 4.6.3) and now it seems to work.

Thank you for your support, I learned a lot from this discussion.

(edit)

All in all, now this is the working configuration:

OpenSSL 0.9.8o-r2 [slot 0.9.8]

OpenSSL 1.0.0a-r3 [slot 0]

KDE 4.4.5

Qt 4.6.3

----------

## Hu

 *Hamlet wrote:*   

> It's not much easier, since the crashing object (kio_imap.so) is not directly called.

 If a core file is generated, it does not matter much whether the crashed program was called directly.  The point is that having a core file gives a specific site of failure, rather than just an error code. *Hamlet wrote:*   

> I re-emerged libQtNetwork.so (currently in x11-libs/qt-core; for reference, I'm using 4.6.3) and now it seems to work.

 Some versions of OpenSSL make silent ABI changes.  This can cause code which calls it to require a rebuild before it works correctly.  Not being familiar with exactly which components would require this, I assumed you had caught it in your rebuild described in the first post.

----------

