[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.
>> 
>> Regards,
>> ENI
>> 
> 
> I would perform a search of the entire local disk for libgnutls*.dll
> and provide the locations, names and sizes of the files. We can then
> offer some advice, it may be possible to copy one of the dlls you have
> installed with GnuTLS for Windows into the Claws program file
> directory and have it work for you.
> 
> The person who probably knows what is happening is Colin, I don't know
> if he is about at the moment.
> 
> Brian Morrison
> 

Brian: Thanks for your interest.

.DLL and .DEF file comparison:
	
Size in bytes, claws-mail-3.10.1-pkg56 vs. gnutls-3.2.16-w32

libgmp-10.dll          438,784 vs. 701,869
libgnutls-28.dll          1,091,072 vs. 1,504,239
libgnutls-xssl-0.dll          98,816  vs. 218,788
libhogweed-2-5.dll          162,304 vs. 4,329,793   
libnettle-4-7.dll          204,288 vs. 3,365,637

libgcc_s_sjlj-1.dll          not present vs. 489,773
libgnutls-28.def           not present vs. 34,473
libgnutls-xssl-28.def          not present vs. 259
libgnutlsxx-28.dll          not present vs. 266,807
libp11-kit-0.dll          not present vs. 875,585
libwinpthread-1.dll          not present vs. 251,290

The difference in file sizes may be expected.

The .DLLs installed by CM, are located at: 
E:\Program Files\GNU\Claws Mail\

Replacing the .DLLs with newer versions would result in a non-standard
installation, so we had chosen not to do so. However, you expressed
interest in such action, so we gave it a try.

There are dependencies. When we replaced libgnutls-28.dll, and launched
CM, we encountered an "Unable To Locate Component" dialog, which stated
"This application has failed to start because libp11-kit-0.dll was not
found. Re-installing the application may fix this problem."

We copied all of the newer files in the list above to the program
directory, overwriting those with common names. CM did launch, but it
still used an SSLv3 Record Layer; SSLv3.0 Handshake; SSLv3.0 Client
Hello, and still failed the handshake.

We have since restored the older .DLLs, and deleted the other files
that were not common to the two packages.


REVIEW for all interested:

Multiple, previously working CM installations, using POP3S (port 995),
began failing. The server responds to the Client Hello, with a Fatal
SSLv3 Record Layer Alert (Handshake Failure).

Note: The CM installations can successfully negotiate SMTP (STARTTLS)
with the same server, demonstrating some crypto functionality. 

Despite Gnutls's protocol preference order (TLS1.2, TLS1.1, TLS1.0,
SSL3.0 ... ", CM uses SSLv3 Record Layer; SSL 3.0 Handshake, and SSL
3.0 Client Hello when trying to connect with POP3S.

Thunderbird successfully uses TLSv1.2 Record Layer; TLS 1.0 Handshake,
and TLS 1.2 Client Hello.

The "gnutls-cli" utility, with .DLLs extracted from
gnutls-3.2.16-w32.zip successfully uses TLSv1.2 Record Layer; SSL 3.0
Handshake, and TLS 1.2 Client Hello.

An effort was made to utilize the "gnutls_priority" string
(gnutls_set_priority=, gnutls_priority=) within the account block of
"accountrc", located at:

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

... to alter CM's behavior, but we observed no change.

Re-running the "claws-mail-3.10.1-pkg56" installer did not resolve the
issue.

Temporarily replacing the .DLLs (and associated .DEF files) located at:
E:\Program Files\GNU\Claws Mail\ with those from gnutls-3.2.16-w32.zip
did not result in a successful POP3S handshake. The original files have
since been restored.

Open to any thoughts.

Best Regards,
ENI