The TLS protocol has many options. A TLS connection starts with a
handshake whose role is mostly for the client and the server to agree on
these options. The ciphersuite is one of these options. It determines
which cryptographic primitives will be used for the various security
properties (data confidentiality, data integrity, server authentication,
etc.).
A ciphersuite mismatch, or more generally a mismatch of some option of
the protocol, or a certificate mismatch, would normally result in the
dissatisfied party closing the connection. For a ciphersuite mismatch,
the server should send an alert "handshake failure". For a certificate
mismatch, there are several alerts ("bad certificate", "certificate
expired", etc.).
The first tool to turn to when debugging a TLS connection is Wireshark.
Compare a failing connection with a successful connection with similar
settings (preferably to the same server). Keep in mind that there can be
many legitimate differences, so the first difference might not be the
source of the problem. You can try connecting with
programs/ssl/ssl_client2 from the mbedtls source tree with different
sets of options.
For some background on how a TLS connection should work, I suggest
starting with Wikipedia, then
https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work
and https://tls.ulfheim.net/ (The Illustrated TLS Connection — note that
while it's a very good explanation, it's for a specific choice of
ciphersuite and other options).
--
Gilles Peskine
Mbed TLS developer
On 29/06/2020 03:02, Thompson, Jeff via mbed-tls wrote:
> Another baby step in discovering what's happening. The last message
> from the server tells the client to change ciphersuites. I don't even
> know what a ciohersuite actually is—something like RSA, AES, or
> DES?—never mind how to change mine, though I have seen the list; my,
> what a lot of conditionals it has.
>
> So, am I still dealing with a certificate issue? Where do I go from here?
>
> Get Outlook for Android
https://aka.ms/ghei36
>
> ------------------------------------------------------------------------
> *From:* mbed-tls
mbed-tls-bounces@lists.trustedfirmware.org on
> behalf of Thompson, Jeff via mbed-tls
mbed-tls@lists.trustedfirmware.org
> *Sent:* Friday, June 26, 2020 12:52:27 PM
> *To:* mbed-tls@lists.trustedfirmware.org
>
mbed-tls@lists.trustedfirmware.org
> *Subject:* Re: [mbed-tls] Choosing a cipher
>
>
> A little progress. I figured out where—ssl_encrypt_buf() in
> ssl_tls.c—to output the name of the offending ciphersuite, which is
> included in all 3 of the preconfigure Google Cloud SSL policies.
>
>
>
> So what’s going on here? Why should the mbedTLS client wait forever
> for 5 bytes it will never get, stalling the connection, instead timing
> out or otherwise detecting an error it could return?
>
>
>
> I’m totally at a loss for what to do with this, other than looking for
> a commercially supported alternative, which I don’t think would be
> received very well by my manager.
>
>
>
> *Jeff Thompson* | Senior Electrical Engineer-Firmware
> +1 704 752 6513 x1394
> www.invue.com
>
>
>
> *From:* Thompson, Jeff
> *Sent:* Friday, June 26, 2020 09:40
> *To:* mbed-tls@lists.trustedfirmware.org
> *Subject:* Choosing a cipher
>
>
>
> The TLS handshake between my device and ghs.googlehosted.com gets
> stalled when the server sends the device a Change Cipher Spec
> message—the device waits forever, wanting 5 more bytes. From what I
> Google’d, I need to change the cipher suite I’m using. How do I know
> which cipher the server doesn’t like (so I can avoid that in future),
> and which one I should be using—there are scores of these available in
> the config file, though some of them clearly should not be used, as
> they are commented that way..
>
>
>
> *Jeff Thompson* | Senior Electrical Engineer-Firmware
> +1 704 752 6513 x1394
> www.invue.com
>
>
>
>
Gilles Peskine