Re: [Fetchmail-users] Unable to fetch mail from "outlook"

[Matthias A. <mat...@gm...>]

Am 07.04.2015 um 12:22 schrieb Jerry:

> I guess I should have stated in my original post, that the ".fetchmailrc"
> file, etcetera is exactly what I have been using for two years now without a
> single problem until few days ago when I updated "openssl" on my system. You
> don't have to be genius to figure out that the cause of the problem was the
> updated "openssl"; however, what is triggering it is what I am trying to
> decipher.

You updated openssl to version 1.0.2a from ports.  The tricky part is
that typing "openssl" would grab the version from /usr/bin and not
/usr/local/bin with default PATH, so the version from "openssl version"
may not be version of the library that fetchmail is linked against.

> Or this:
> 
> openssl s_client -tls1 -crlf -showcerts -verify 5 -CAfile /usr/local/share/certs/ca-root-nss.crt -connect pop3.live.com:995  
> verify depth is 5
...

Which is again not what fetchmail would be doing, it just uses
SSLv23_*_method() without the -tls1 option.

What I know is that installing openssl as a port, rather than using the
base system's OpenSSL, has always caused strange problems for me, so
let's try something else:

> $ /usr/local/bin/openssl s_client -crlf -showcerts -verify 5 \ 
>   -CAfile  /usr/local/share/certs/ca-root-nss.crt \
>   -connect pop3.live.com:995
> CONNECTED(00000003)
> 34381952888:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:

Oops!

I can reproduce your problem if I compile fetchmail against OpenSSL
1.0.2a, and in Wireshark I see what's going on. This is what comes out
of fetchmail's calling SSLOpen() with OpenSSL 1.0.2a:

... (first frames are regular TCP connection set-up, i. e.
the normal 3-way >SYN <SYN|ACK >ACK sequence)

> Frame 4: 583 bytes on wire (4664 bits), 583 bytes captured (4664 bits) on interface 0
> ...
> Secure Sockets Layer
>     SSL Record Layer: Handshake Protocol: Client Hello
>         Content Type: Handshake (22)
>         Version: TLS 1.0 (0x0301)
>         Length: 512
>         Handshake Protocol: Client Hello
>             Handshake Type: Client Hello (1)
>             Length: 508
>             Version: TLS 1.2 (0x0303)
> ...

So OpenSSL 1.0.2a wants to negotiate TLS v1.2, with a list of ciphers,
and no DEFLATE compression support (not shown here, see attached text
file - it

And this is what Microsoft's server responds:

> Frame 5: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
> ...
> Transmission Control Protocol, Src Port: 995 (995), Dst Port: 25580 (25580), Seq: 1, Ack: 518, Len: 0
>     Source Port: 995 (995)
>     Destination Port: 25580 (25580)
>     [Stream index: 0]
>     [TCP Segment Len: 0]
>     Sequence number: 1    (relative sequence number)
>     Acknowledgment number: 518    (relative ack number)
>     Header Length: 32 bytes
>     .... 0000 0001 0001 = Flags: 0x011 (FIN, ACK)

Oops again.  The sucker of Microsoft's server doesn't like our SSL
client hello message and just hangs up without saying goodbye or telling
us of the problem.

For some unknown reason, OpenSSL makes it exceptionally hard to identify
and repeat this situation.  It does not hit the SSL error queue, it does
not end up in errno, and it takes guessing from circumstances to figure
out that the server just hung up.

As a *workaround*, try adding --sslproto tls1 (or --sslproto ssl3 if you
have to) for a workaround, or "pkg delete openssl" and rebuild fetchmail
(and all other SSL-based applications that got built after you'd
installed the OpenSSL 1.0.2+ port or package).  I'm not sure what really
causes the Microsoft server to hang up with the newer OpenSSL.  Might be
worth asking on the OpenSSL lists.


To identify "base vs. ports/packages OpenSSL",
this is what I get with ldd, most importantly, libssl goes to /usr/lib,
not /usr/local/lib (ditto for libcrypto, from /lib - not to be confused
with libcrypt (without trailing o), which does not matter here.)

$ ldd /usr/local/bin/fetchmail
/usr/local/bin/fetchmail:
	libintl.so.8 => /usr/local/lib/libintl.so.8 (0x800858000)
	libopie.so.7 => /usr/lib/libopie.so.7 (0x800a62000)
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x800c6b000)
	libkvm.so.6 => /lib/libkvm.so.6 (0x800e8b000)
	libcom_err.so.5 => /usr/lib/libcom_err.so.5 (0x801093000)
	libssl.so.7 => /usr/lib/libssl.so.7 (0x801295000)
	libcrypto.so.7 => /lib/libcrypto.so.7 (0x801500000)
	libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x8018f4000)
...

HTH!