[Users] POP3S - SSL Handshake Failures.

[ENI]

>> 
>> Background
>> 
>> We've been using Claws Mail (Win32) to reliably send/receive mail for
>> ~2 years. Two weeks ago (8/17), the server-side certificate used for
>> POP3S and SMTP (STARTTLS) expired. We believe Claws Mail (CM)
>> successfully stored the new certificate for both functions, as we
>> were able to send/receive securely thereafter. Although, we did see
>> the signature status change from “Correct”, to “No certificate issuer
>> found”. The POP3S server certificate has since been deleted from the
>> “Saved SSL Certificates” list during our investigation of the
>> following issue. We're not sure if it is relevant, but thought it
>> best to disclose recent events.
>> 
>> 
>> Issue - SSL Handshake Failures
>> 
>> On the evening of 8/23, we were able to retrieve mail via POP3s. On
>> the morning of 8/24 we were not. We are experiencing SSL handshake
>> failures.
>> 
>> A Wireshark capture shows the server responding to the SSLv3 Client
>> Hello, with a Fatal SSLv3 Record Layer Alert (Handshake Failure).
>> 
>> Claws Mail 3.10.1 (Win32), indicates the following in it's Network
>> Log:
>> 
>> * Account '<redacted>': Connecting to POP3 server:
>>   <server-name-redacted>:995... 
>> *** SSL handshake failed
>> 
>> Thunderbird 31.0 succeeds with a TLSv1.2 handshake, whereas CM fails
>> with a SSLv3 handshake (per Wireshark capture). The cypher suite
>> negotiated (TLS RSA with AES 256 CBC SHA) in the Thunderbird session,
>> is supported by CM.
>> 
>> Thunderbird: POP3 Mail Server Settings | Security Settings |
>> Connection Security | SSL/TLS (selected)
>> 
>> CM: SSL | POP3 | Use SSL for POP3 connection (selected)
>> CM: SSL | Send (SMTP) | Use STARTTLS command to start SSL session
>> (selected)
>> 
>> We have three Win XP3 systems configured with CM. There have been no
>> recent config changes to CM. Each send via SMTP (STARTTLS)
>> successfully, but each are experiencing POP3S SSL handshake failures.
>> 
>> During our diagnostic efforts, the POP3S server certificate was
>> deleted in CM, with the expectation that it would be presented again
>> during the next session setup, but the SSL handshake fails before
>> that can occur.
>> 
>> We've submitted a ticket to our service provider, and are trying to
>> determine whether there have been any changes on the server side that
>> would cause the recent SSLv3 handshake failures. We are inclined to
>> think that they may point to CM, as Thunderbird succeeds (via
>> TLSv1.2).
>> 
>> Any thoughts on how we can diagnose the situation further on our end?
>> 
>> Best Regards,
>> ENI
>> 
> 
> Use the hidden account prefs to specify manually the priority string
> used. Quit Claws, open ~/.claws-mail/accountrc, find your account
> block, set 'gnutls_set_priority' to 1, and put your priority string
> in 'gnutls_priority'.
> 
> You could use the gnuTLS command line program to investigate this
> first.
> 
> with regards
> 
> Paul
> 
> 
> The last commit in Claws Mail GIT repository might resolve your issue.
> 
> regards
> 
> Paul
> 

Paul:

Thank you for your interest in our issue, and the suggestions offered.

Initially, we were focused on trying to restore prior functionality,
characterized by SSLv3 Record Layer version SSL 3.0, and Handshake
Protocol version SSL 3.0, as observed with Wireshark.

After doing some reading we decided that it might be preferable to use
the 'gnutls_priority' string you identified, to achieve the same setup
that Thunderbird uses successfully, characterized by TLSv1.2 Record
Layer version TLS 1.0, and Handshake Protocol version TLS 1.2. 

We located the appropriate account block within the "accountrc" file
located at:

C:\Documents and Settings\user-name-redacted\Application
Data\Claws-mail\accountrc

... and tried a couple of different "gnutls_priority" strings. On each
occasion, we quit Claws Mail, edited and saved the file, then
relaunched CM.

Initial Configuration
gnutls_set_priority=0
gnutls_priority=

Trial # 1
gnutls_set_priority=1
gnutls_priority=%LATEST_RECORD_VERSION

Expectation: a transition from an SSLv3 Record Layer, to a TLSv1.2
Record Layer.
Observation: CM still used the SSLv3 Record Layer, and failed the
handshake.

Trial # 2
gnutls_set_priority=1
gnutls_priority=NORMAL:%LATEST_RECORD_VERSION

Expectation: Same as above.
Observation: CM still used the SSLv3 Record Layer, and failed the
handshake.
Note: We tried a different syntax, by including "NORMAL:".

Trial # 3
gnutls_set_priority=1
gnutls_priority=NORMAL:-VERS-SSL3.0

Expectation: a transition to TLS1.0, TLS1.1, or TLS1.2.
Observation: CM still used the SSLv3 Record Layer, and failed the
handshake.

Trial #4
gnutls_set_priority=1
gnutls_priority=SECURE256

Expectation: a reduction in the number of cipher suites offered.
Observation: The same 28 suites were offered, as with NORMAL.
Note: This test was just to see if we could bring about any change in
behavior with a priority string.

It appears that our priority strings are not being read or utilized. Is
there something about our syntax that is incorrect?


The GnuTLS Manual, which does not indicate a software revision number,
made the following statements in Section 5.10 Priority strings:

"Priority strings are not constant between gnutls versions".

"Unless the initial keyword is "NONE" the defaults (in preference
order) are for TLS protocols TLS1.2, TLS1.1, TLS1.0, SSL3.0 ... ".

We are not sure why SSL3.0 is being used, when these other protocols
are supposed to have preference.


We searched for the "gnutls-cli" command line program, but it was not
found on our Win32 system. Perhaps this utility is not included in the
CM (Win32) installer.

Any additional thoughts would be appreciated.

Regards,
ENI