From: Phillip S. <ps...@ir...> - 2007-07-16 20:39:37
|
Matthias Andree wrote: > See the socket error? Apparently the server drops the connection. > > Try 6.3.8 - the non-SSL fallback is fixed there (at the expense of not > encrypting the connection though, so don't do that over WLAN with just WEP > or via public access networks). I can force fetchmail to not use ssl at all and it works, but I'd like it to use ssl. I have managed to successfully connect to the server from my windows machine running thunderbird, and I have packet captures of the conversation and compared them to the packet capture from fetchmail. It appears that for fetchmail, the server closes the connection after sending the certificate, but I notice that it negotiates a different cipher than thunderbird, which works. Thunderbird negotiates the TLS_RSA_WITH_RC4_128_MD5 ( 0x0004 ) cipher, but fetchmail does not list this as a cipher it supports in its client HELLO frame, so the server answers with TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA ( 0x0016 ) as the negotiated cipher, then the next frame it sends its certificate and a two alerts, one fatal, one a warning, both saying Close Notify. This leads me to believe that the server does not like any of the ciphers that fetchmail supports. Does this make sense, and how can I get fetchmail to use the TLS_RSA_WITH_RC4_128_MD5 cipher? |