- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Hi Patrick,
During that phase of the handshake, the client will send the following messages sequentially (from the RFC https://tools.ietf.org/html/rfc5246#page-33):
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
The server will read those messages in order and could be cancelling the handshake while processing messages before ChangeCipherSpec. Is your client using X.509 certificates? If so, the Certificate and CertificateVerify messages will also be sent and are frequently the cause of handshake failures.
Another way to get more information about the handshake failure would be to make sure you have debug logs turned on for MbedTLS and see if any TLS alerts are sent. You could also use the same AWS IoT endpoint and the same client certificates with another simple client program like openssl s_client and use the -debug or -msg flag to get more information about any TLS-layer errors. This would also rule out any issues with certificates.
-Alex
Alex,
Thanks for your reply; I have been working on pursuing your suggestions.
We are using X.509 certificates, but the failure does not produce any alert messages. I've turned on detailed logging in Mbed TLS and don't see anything useful in the output. Using the HughesNet Gen5 link, the TLS handshake goes into a read and retry loop after sending the client change cipher spec message. I've logged the network traffic with WireShark and have confirmed that the client change cipher spec message is transmitted, but no response is ever sent by AWS.
The latest thing I've been working on is modifying a sample Visual Studio project included with Mbed TLS to connect to our AWS endpoint and use the same X.509 certificates that are assigned to one of our test devices. Running on my Windows workstation, that project is able to complete the TLS handshake both via our landline ISP as well as the HughesNet Gen5 link. The implication is that the problem is timing-related, there is a subtle difference in the order of operations between the two projects, or something is wrong with Microchip's TCP/IP stack library. I'll continue digging and will add to this thread if I have additional questions or find the underlying cause.
Thanks,
Patrick
I believe my problem has been resolved. I don't yet fully understand the root cause, but I found an anomaly in the way that the first TLS handshake response from the AWS server and traced it to the size of a TCP socket read buffer. By increasing the buffer size from the default value of 1024 to >1400, the connection problems using a HughesNet satellite link disappeared. (I used a value of 1460, which is the typical max TCP MTU of 1500 less two 20 byte headers; seems to be fairly common practice)
The HughesNet transport must be doing something atypical with the packet framing that our project wasn't handling well. Increasing this internal buffer size solved the problem.
Patrick
Contenuto pertinente
- AWS UFFICIALEAggiornata 2 anni fa
- AWS UFFICIALEAggiornata 10 mesi fa
- AWS UFFICIALEAggiornata 4 mesi fa
- AWS UFFICIALEAggiornata 3 anni fa