[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
>

To all:

We downloaded the latest "GnuTLS for Windows" to get a copy of
"gnutls-cli".

When we ran "gnutls-cli" from within the extracted group of downloaded
files, we were able to connect to the server via POP3S:

gnutls-cli -p 995 <server-name-redacted>

Processed 135 CA certificate(s).
Resolving '<server-name-redacted>'...
Connecting to '<ip-address-redacted>:995'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
<redacted>
- Status: The certificate is trusted.
- Description: (TLS1.2)-(RSA)-(AES-256-CBC)-(SHA256)
- Session ID: <redacted>
- Version: TLS1.2
- Key Exchange: RSA
- Cipher: AES-256-CBC
- MAC: SHA256
- Compression: NULL
- Handshake was completed
- Simple Client Mode:
+OK POP3 Ready <redacted>

When we tried to run "gnutls-cli" from within the Claws Mail Program
Files folder, we were presented with an "Entry Point Not Found" error
dialog stating: 

"The procedure entry point gnutls_pkcs11_set_token_function could not
be located in the dynamic link library libgnutls-28.dll.'

Don't know if the version (newest) of gnutls-cli is relevant to the
presentation of the error dialog.

Did notice that several of the extracted (downloaded) .dll files have
the same names as those in the program folder, but are of significantly
different sizes.

Re-ran the "claws-mail-3.10.1-pkg56" installer, and none of those .dll
files changed, including libgnutls-28.dll. The installation still fails
the POP3S SSL handshake.

Any additional thoughts would be appreciated.

Best Regards,
ENI