I decided to start a new thread devoted to TLS issues. I have been monitoring TLS connections using wireshark specifically the negotiation between Claws Mail and Microsoft Hotmail. (pop3.live.com). In the client hello part of the TLS protocol Claws Mail sends 66 cipher suites to chose from: Code: Cipher Suites Length: 132 Cipher Suites (66 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc086) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 (0xc087) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc072) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc073) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc08a) Cipher Suite: TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xc08b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc076) Cipher Suite: TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc077) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc07a) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xc07b) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041) Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00ba) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084) Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00c0) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc07c) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384 (0xc07d) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0x00be) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088) Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0x00c4) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (0x00a2) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (0x00a3) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256 (0xc080) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384 (0xc081) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256 (0x00bd) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087) Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 (0x00c3) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_DHE_DSS_WITH_RC4_128_SHA (0x0066) The hotmail server response is to choose; Code: Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) I then did some searching and I learned that claws mail uses GnuTLS and I came across this post, http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/8132 describing a similar issue when connecting to email servers using GnuUtils. The server also chooses RSA with MD5. That post said GnuTLS does not support MD5 by default but I think they must be mistaken as the RSA MD5 cipher suite is in my clients cipher suite list. I think more to the point, why are Hotmail and other email servers choosing this same cipher when there are much better ones to choose from ?
Probably because the weaker encryption consumes less CPU time on their server, not some grand conspiracy. It is free email after all, they're trying to save where they can. And you know Microsoft's reputation for security.
Well that isn't how the TLS protocol is designed, the server is supposed to pick the best one it supports. I tested gmail their server picks a better cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
I haven't used gmail before i just set up the account to see which cipher it's server would use. I left that account set up in Claws Mail, it checks for new email every 15 minutes. So it's been doing that for several hours then a few minutes ago Claws mail popped up a warning that the server certificate has changed. I never had this happen before in any of my other email accounts in Claws mail. The warning shows details of both certificates. The original one, Owner Name: pop.gmail.com Organization: Google Inc Location: Mountain View, US Signer Name: Google Internet Authority G2 Organization: Google inc Location: US Status Fingerprint: MD5: 77:2E:83:46:B7:FA:A7:8E:16:30:20:BC:32:4A:B7:5D Fingerprint: SHA1: 7E:FE:1A:5A:FD:15:1F:63:70:B9:81:9A:C9:EA:EF:EC:4A:42:59:46 Signature status: Correct Expires on: 08/31/2015(Mon) 1900 The new one has identical information except for the fingerprints which are Fingerprint: MD5: AD:6F:0E2:CB:34:65:CC:09:AB:7B:75:5C:8F:73:29 Fingerprint: SHA1: B7:85:23:59:EF:182:43:F5:5C:FE:B7:1E:80:49:337:B3:30:94 Signature status: Correct Expires on: 08/31/2015(Mon) 1900 Those stupid smiley things interfere with the hex numbers anyway I canceled the connection that time and since then Claws Mail has continued to check for email using the original cert.
There seems to be scant information about hardening TLS in email clients and other apps that use TLS but I found a snippet of information about claws mail mentioning hidden settings called gnutls_priority. The GnuTLS developers manual describes GnuTLS priority strings so I entered the keywords from the GnuTLS manual into the claws mail configuration file and voila they work. It appears claws mail supports the configuration described on this page of the GnuTLS manual. I have only tested this on Linux but Claws mail is cross platform so the same should be true for Windows. In Linux open the hidden config file ./.claws-mail/accountrc (requires root). Change the two settings, gnutls_set_priority and gnutls_priority to; gnutls_set_priority=1 gnutls_priority=the settings described on this page You will notice these settings are per account, so you can set up the TLS settings individually for each email server. So for example. set_gnutls_priority=1 gnutls_priority=SUITEB192 That would use only ciphers that conform to NSA (RFC5430) SuiteB encryption at 192bits or higher. Most regular email providers will not support the necessary cipher suites to meet this level of encryption but the more security oriented ones might do. Gmail works with gnutls_priority=SECURE256 This means only cipher suites offering security of 192 bits or higher are offered. I tested the above by capturing the negotiation packets and it works the way it is described in the GnuTLS manual. With SUITE192 only one cipher suite was offered and it was the most secure cipher suite GnuTLS currently supports: Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c). As I expected, the connection failed with that setting because Gmail doesn't support that cipher suite. With gnutls_priority=SECURE256 20 cipher suites are offered to the server, the weakest being: Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 (0x00c3) The Gmail server chose Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) I have an issue with this though and it is with the list order. The RSA cipher suites are higher in the list than the DHE_RSA cipher suites. The client's cipher suite list is presented to the server to represent the client's order of preference so the server would assume the client would rather use, Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) in preference over, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) The enumeration also puts the DHE suite lower. I do not understand why this should be so, surely the DHE one is better for the forward secrecy ? There are a lot of other settings you can use in gnutls_priority including the NONE keyword followed by explicit preferences rather than predefined ones like the two I mentioned. I haven't tried that yet but I think you can set the protocol to be used, as well as the cipher suite parameters. A note about the cipher suite list order. The cipher suite will not necessarily be chosen based on it's order in the client list although it can be. It depends on the server which can be configured to prioritize by its own list. In other words a server that supports strong cipher suites but would prefer to use weak ones could use a list of cipher suites in reverse order, prioritize according to that list and therefore use the first cipher in it's list that is supported by the client. All the more reason not to send a complete list of supported cipher suites and only those which we consider secure. Ideally we should know the strongest cipher a server supports and only offer that cipher. This is possible but as far as I know, only by offering the server each cipher suite one at a time from best to worst until it accepts one.
You know, the more I look into this the more I'm realizing what a bunch of crap it is. Example, Certificate fingerprints. (The reason I'm using Claws Mail most of the time for this testing is because it pins the server cert to the email account and compares it to the one it receives. If they do not match it alerts the user.) So in the scenario the fingerprint is suspicious you verify it manually right ? How hard can that be, just go to the site it represents and look up their certificates ... I tried this with google's pop3 cert because so far in the past week I have received 3 different certs all claiming to be the pop.gmail.com certificate. Could not find any mention of their certificate fingerprints on the gmail site so I said well ok I'll go to the certificate issuer's site (Google Internet Authority G2) and look it up on there. For some reason I imagined certificate issuers would maintain a database where users could look up certificates ... silly me. So then I googled it, surely someone knows how to verify a certificate fingerprint manually and I found nothing but other frustrated people's questions about doing the same thing. So after two days of wild goose chasing google links the only answer I found was to email the administrators of the site in question and ask them to verify their own certificate fingerprints. So I did go to the gmail site and all I could find was their questions forum. I posted the information of the different certs I received and asked them to verify. The only response I got was from a "google expert" who said, the rest of the information on the certs match ( expiry dates, issuer etc) so therefore they must be ok and I should accept them. I said WHAT ? Are you effing serious ? I mean really.
@RockLobster This is an interesting subject. I hope there is much more input, but I barely know where to start with all this certificate/signing/encryption scenario. Would this thread be an appropriate place to lay down the basics of how it all works and fits together?
Yes, please post anything you think is relevant. I think it is an interesting subject too I have been trying to figure it all out. I looked in my email clients certificate folder and I found a certificate chain. I assume Claws Mail got it from the gmail server. It has, gmail's pop3 server verified by Google Internet Authority G2 Google Internet Authority G2 verified by GeoTrust Global CA GeoTrust Global CA verified by [Blank] So I assumed that means GeoTrust Global CA is the root certificate ? I then went to the GeoTrust site (which apparently is now owned by Symantec) To look for the GeoTrust Global CA root certificate. I found it here GeoTrust Root Certificates I expected the fingerprints for GeoTrust Global CA on the certificate chain I have would match the GeoTrust Global CA root certificate on the GeoTrust site. But it doesn't so I am still none the wiser. I attached the X.509 certificate chain in PEM format in case anyone wants to check it. I added .txt to the end of the filename because Wilders upload manager restricts the type of files, remove .txt from the filename and it should view with all its details in a certificate viewer.
