wolfSSL - Embedded SSL Library — [SOLVED] Equifax Certificate

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Mon, 09 Feb 2015 22:14:00 +0000

Yes, you are right. When I said "remote host" I merely meant that the socket connection through the modem was being disconnected from timing out.
Good to know that the handshake code is time-independent on wolfSSL's side.
You're right, there wasn't a cert. request from the server.
Ok, so using a socket timeout on the hardware-side is alright then.

Re: [SOLVED] Equifax Certificate

null@example.com (john) — Mon, 09 Feb 2015 17:09:12 +0000

You're welcome.

To answer your questions:

Vanger wrote:

Do you know what the times between CyaSSL handshake messages are?
At this point, it seems like the issue is caused by a timeout either server-side or radio-side.
It seems like the library shouldn't be causing timeout issues with it being less than a second or two to run various code segments between outputting data to the server?

It all depends on how fast your hardware is and what cipher suites you are using. The public key cryptography is slow. On a desktop PC you'd probably never see any kind of delay, but on an embedded device the RSA operation could take hundreds of milliseconds. The point in the handshake where your device was timing out was after the public key operations. I don't think Google is timing out; I added in a 3 second delay right before my client sends its Change Cipher Spec message and Google still finished the handshake.

There isn't a timeout on the handshake. If the socket closes then we'll get an error from the recv() and tear down the session.

Vanger wrote:

Is it possible that the google.com server is requesting a certificate to distinguish between clients that connect to it?

Public web servers are commonly configured to use anonymous clients without their own certificates. The server would send a Certificate Request handshake message to the client in the non-anonymous case, and from your logs there wasn't any evidence of Google doing that.

Vanger wrote:

Is there a way to tell the library to use a timeout on connections for trying to read the next record from the server? If so, where/how is it set?

This would be accomplished by setting a timeout on the socket, or using non-blocking sockets and calling select() on the socket. Or using custom I/O routines with CyaSSL (wolfSSL).

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Fri, 06 Feb 2015 22:40:27 +0000

Alright, I think I found the main issue going on. The debug prints were too slow, causing the remote host to timeout during the handshake. This in turn caused our modem to print messages to the data port which interfered with CyaSSL's handshake.
Thanks so much for all of your help with debugging the implementation of the library and the certificates John!

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Fri, 06 Feb 2015 22:03:10 +0000

Is it possible that the google.com server is requesting a certificate to distinguish between clients that connect to it? And disconnecting when it doesn't get it?

Is there a way to tell the library to use a timeout on connections for trying to read the next record from the server? If so, where/how is it set?

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Mon, 02 Feb 2015 22:50:47 +0000

Modifying the timeout values on the radio causes it to encounter the same record layer error, but earlier in the handshake protocol, which would indicate that the record layer header issue is caused by the radio sending NO CARRIER. It is not getting picked up by the radio code to notify the program that the connection has been closed.

I will debug the buffer to see if there is unread data that would be the rest of the URC from the radio.

Do you know what the times between CyaSSL handshake messages are?
At this point, it seems like the issue is caused by a timeout either server-side or radio-side.

It seems like the library shouldn't be causing timeout issues with it being less than a second or two to run various code segments between outputting data to the server?

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Mon, 02 Feb 2015 22:01:26 +0000

Checking our code, we are clearing the read buffer each time it finishes reading the data from the radio. So, it's unlikely it is leftover from something else.
The radio is supposed to be printing a debug statement if it finds the "NO CARRIER\r\n" message indicating the radio closed the connection as well.

It could be the radio is sending unsolicited codes causing the issue, so I will check that and get back to you.

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Mon, 02 Feb 2015 21:11:20 +0000

I've been getting the correct certificates for the most part (sometimes the chain is a little confusing).
And thanks for the clarification on the Record Layer Header implementation. Going on the assumption that it is correct saves alot of time trying to debug the porting to mbed.

Yes, our radio sends back "NO CARRIER\r\n" in response to the TCP connection being disconnected by the radio.
I will look into that and see what's up with the radio disconnecting/leaving data in the buffer which would cause the cyassl library to read it as records.

Re: [SOLVED] Equifax Certificate

null@example.com (john) — Mon, 02 Feb 2015 19:26:55 +0000

Vanger wrote:

I'm going to try to pull more debug values from the client at various points of interest in the code, but I'm not sure what to be looking for/at.
Is there any code difference between connecting to say google.com versus wikipedia.org?
The library works consistently on certain websites and doesn't work consistently on the google.com and yahoo.com domains.
I would expect the code operates the same way for the SSL code regardless of which website it connects to, which would beg the question of what is different about the named websites that would cause a handshake failure, whereas the other websites are connecting just fine.

There shouldn't be any differences between connecting to any site. Except for the CA certificate you are loading to verify the server's certificate. Google, Wikipedia, and Yahoo! are all using different certificate issuers. Google is signed by GeoTrust, Wikipedia is signed by GlobalSign, and Yahoo! is signed by VeriSign.

Since I'm on a Mac, I get those certificates out of my KeyChain application. I save them and then covert them to PEM format, and concatenate them into a single file. With the wolfSSL client, I use the -A option to load that file.

Vanger wrote:

The record layer headers are all fine up until the client sends a ClientKeyExchange message, after which the next record layer header received from the server is: 0D,0A,4E,4F,20

That's not a record layer header from the server. That's the string "NO". Is that part of the over-the-air protocol you are tunneling the SSL through? Is the rest of the line "CARRIER" or something? Or maybe it is your option D.

As for option B, the server should be sending a clear "Change Cipher Spec" message, followed by an encrypted Finished handshake message. For all TLS records, the record header is in the clear.

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Mon, 02 Feb 2015 16:38:20 +0000

Pulling out the raw data values from the connection with google.com (using the mbed version of CyaSSL 3.3.0), I got the following read and write data calls to the radio:

=====
Sending to radio:
16 03 03 00 73 01 00 00 6F 03 03 9F 8A 7D DE AD 10 0C BC DB 10 A9 26 AC D4 1F 72 14 D3 92 88 74 72 DF F5 4C BD 72 04 81 B6 3E 15 00 00 38 C0 27 C0 23 C0 29 C0 25 C0 0A C0 05 C0 09 C0 04 C0 07 C0 02 C0 08 C0 03 C0 14 C0 0F C0 13 C0 0E C0 11 C0 0C C0 12 C0 0D 00 3D 00 3C 00 35 00 2F 00 05 00 04 00 0A 00 FD 01 00 00 0E 00 0D 00 0A 00 08 04 03 02 03 04 01 02 01
=====
=====
Reading from radio:

=====
=====
Reading from radio:

=====
=====
Reading from radio:

=====
=====
Reading from radio:
16 03 03 00 4A
=====
=====
Reading from radio:
02 00 00 46 03 03 54 CF A0 7E D6 86 A9 05 86 F5 09 97 82 7E E4 42 7D F6 63 EC 93 F9 D3 E9 8D 61 9F 22 D4 E2 68 5C 20 95 7B 1D 85 8E 9F 02 09 9B 75 FA F1 F0 CC 12 86 3C BE 74 9C CC 53 94 01 F1 A5 EC FD CF B4 B5 D9 C0 13 00
=====
=====
Reading from radio:
16 03 03 0B FF
=====
=====
Reading from radio:
0B 00 0B FB 00 0B F8 00 04 7A 30 82 04 76 30 82 03 5E A0 03 02 01 02 02 08 4F 7A AD DA AD 8F AD 31 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 49 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 13 30 11 06 03 55 04 0A 13 0A 47 6F 6F 67 6C 65 20 49 6E 63 31 25 30 23 06 03 55 04 03 13 1C 47 6F 6F 67 6C 65 20 49 6E 74 65 72 6E 65 74 20 41 75 74 68 6F 72 69 74 79 20 47 32 30 1E 17 0D 31 35 30 31 31 34 31 33 31 34 31 36 5A 17 0D 31 35 30 34 31 34 30 30 30 30 30 30 5A 30 68 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 13 30 11 06 03 55 04 08 0C 0A 43 61 6C 69 66 6F 72 6E 69 61 31 16 30 14 06 03 55 04 07 0C 0D 4D 6F 75 6E 74 61 69 6E 20 56 69 65 77 31 13 30 11 06 03 55 04 0A 0C 0A 47 6F 6F 67 6C 65 20 49 6E 63 31 17 30 15 06 03 55 04 03 0C 0E 77 77 77 2E 67 6F 6F 67 6C 65 2E 63 6F 6D 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01 00 AF 3A 5D 2C 9C B4 88 99 F2 9C 2C 8F FE EA F6 EB 28 8D F5 89 3A 2B 59 55 13 14 8D FF B9 7F 06 6D AD 50 0B 0A D2 6A AF 57 F7 82 0F 31 90 B3 F0 AB DB 38 35 22 7E 12 68 D0 F8 40 A3 F4 95 6A 4A EC BE B2 41 1D 8D DE 05 1B 89 2A AE 51 C1 88 C0 14 0A 24 67 26 99 02 5E 5E C8 39 44 62 E9 29 D9 A7 96 2D 8D 73 50 A8 CF E7 34 1F 4F 2B 3D 22 25 02 2C 57 D4 04 D6 F0 12 1A A4 13 A4 ED 88 25 24 AC C1 48 EE 56 D4 01 40 FF 7D 62 8B F8 EA 28 60 D6 DD F5 23 81 B8 E9 7F F7 8C 75 7B 02 1E D2 31 E9 9F 4B 8C F1 6C 42 C3 AB 7C 52 8C FD C7 DB 31 81 07 6B 64 39 8C E8 67 A0 9E 37 B9 65 39 74 04 DA 06 AC D6 99 D5 91 56 3B 95 5D 5B 6A CA 00 79 FC 25 2A 9D 8E A2 C1 64 CB 63 B4 20 2A DA FD 8C 88 75 C5 23 A2 0D 0D A5 2A 70 CF 14 42 B6 E1 C4 DC DB 9F 51 81 9C 73 09 15 CF 17 26 C7 FE EC AE 51 02 03 01 00 01 A3 82 01 41 30 82 01 3D 30 1D 06 03 55 1D 25 04 16 30 14 06 08 2B 06 01 05 05 07 03 01 06 08 2B 06 01 05 05 07 03 02 30 19 06 03 55 1D 11 04 12 30 10 82 0E 77 77 77 2E 67 6F 6F 67 6C 65 2E 63 6F 6D 30 68 06 08 2B 06 01 05 05 07 01 01 04 5C 30 5A 30 2B 06 08 2B 06 01 05 05 07 30 02 86 1F 68 74 74 70 3A 2F 2F 70 6B 69 2E 67 6F 6F 67 6C 65 2E 63 6F 6D 2F 47 49 41 47 32 2E 63 72 74 30 2B 06 08 2B 06 01 05 05 07 30 01 86 1F 68 74 74 70 3A 2F 2F 63 6C 69 65 6E 74 73 31 2E 67 6F 6F 67 6C 65 2E 63 6F 6D 2F 6F 63 73 70 30 1D 06 03 55 1D 0E 04 16 04 14 3B F0 C2 54 CA 67 DF FA 02 33 E1 45 2B B1 CE 5B 91 E7 0E 99 30 0C 06 03 55 1D 13 01 01 FF 04 02 30 00 30 1F 06 03 55 1D 23 04 18 30 16 80 14 4A DD 06 16 1B BC F6 68 B5 76 F5 81 B6 BB 62 1A BA 5A 81 2F 30 17 06 03 55 1D 20 04 10 30 0E 30 0C 06 0A 2B 06 01 04 01 D6 79 02 05 01 30 30 06 03 55 1D 1F 04 29 30 27 30 25 A0 23 A0 21 86 1F 68 74 74 70 3A 2F 2F 70 6B 69 2E 67 6F 6F 67 6C 65 2E 63 6F 6D 2F 47 49 41 47 32 2E 63 72 6C 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 82 01 01 00 78 A4 19 93 2F 84 73 58 B1 B8 D9 93 C1 1F 6A 21 6F AC C4 7C FE FA E0 A1 80 A4 D8 04 45 17 0C F6 53 22 5E C1 EA D7 4F 78 7C 7C B1 D5 DC 0D E5 2A AE DE 0A B2 5A 0D F0 CB 40 09 FE 65 B5 98 55 03 EC 44 3A 36 7C 3C 50 C1 BB EC 05 A4 C9 53 D4 08 49 3C 5D 8B E9 CC C8 88 BF 82 1F 1A 6D B1 C6 82 28 D9 25 CD D7 7D F4 64 3D 32 B2 0B 2C A0 81 FD 91 2C EE 00 9C 44 BF D4 39 20 66 B8 6F C1 FC 08 FC DB E3 9B 3E 80 20 28 81 D8 C6 BA 7C 8E CB 47 8F 73 8B AF 97 C1 45 04 E2 FD C7 A9 BC 13 45 11 AC 40 D6 B1 E2 6D 73 AB 48 79 4E 2E 67 7A 35 85 2F C7 F9 13 48 86 A6 1D 84 99 3C B5 44 E5 CE 9D CC F3 D1 0F 62 E6 A9 77 75 8D 86 39 EA 35 54 3D D4 A2 AB D7 D7 75 48 EE BB 86 D2 AA B0 EA 27 1A 71 52 8A 7E 37 B8 10 B9 80 B0 71 05 5B 52 FC 5B 60 B4 A0 C1 D1 F8 A0 0B B4 35 7C 24 30 60 A6 BB 00 03 F4 30 82 03 F0 30 82 02 D8 A0 03 02 01 02 02 03 02 3A 76 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 42 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 16 30 14 06 03 55 04 0A 13 0D 47 65 6F 54 72 75 73 74 20 49 6E 63 2E 31 1B 30 19 06 03 55 04 03 13 12 47 65 6F 54 72 75 73 74 20 47 6C 6F 62 61 6C 20 43 41 30 1E 17 0D 31 33 30 34 30 35 31 35 31 35 35 35 5A 17 0D 31 36 31 32 33 31 32 33 35 39 35 39 5A 30 49 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 13 30 11 06 03 55 04 0A 13 0A 47 6F 6F 67 6C 65 20 49 6E 63 31 25 30 23 06 03 55 04 03 13 1C 47 6F 6F 67 6C 65 20 49 6E 74 65 72 6E 65 74 20 41 75 74 68 6F 72 69 74 79 20 47 32 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01 00 9C 2A 04 77 5C D8 50 91 3A 06 A3 82 E0 D8 50 48 BC 89 3F F1 19 70 1A 88 46 7E E0 8F C5 F1 89 CE 21 EE 5A FE 61 0D B7 32 44 89 A0 74 0B 53 4F 55 A4 CE 82 62 95 EE EB 59 5F C6 E1 05 80 12 C4 5E 94 3F BC 5B 48 38 F4 53 F7 24 E6 FB 91 E9 15 C4 CF F4 53 0D F4 4A FC 9F 54 DE 7D BE A0 6B 6F 87 C0 D0 50 1F 28 30 03 40 DA 08 73 51 6C 7F FF 3A 3C A7 37 06 8E BD 4B 11 04 EB 7D 24 DE E6 F9 FC 31 71 FB 94 D5 60 F3 2E 4A AF 42 D2 CB EA C4 6A 1A B2 CC 53 DD 15 4B 8B 1F C8 19 61 1F CD 9D A8 3E 63 2B 84 35 69 65 84 C8 19 C5 46 22 F8 53 95 BE E3 80 4A 10 C6 2A EC BA 97 20 11 C7 39 99 10 04 A0 F0 61 7A 95 25 8C 4E 52 75 E2 B6 ED 08 CA 14 FC CE 22 6A B3 4E CF 46 03 97 97 03 7E C0 B1 DE 7B AF 45 33 CF BA 3E 71 B7 DE F4 25 25 C2 0D 35 89 9D 9D FB 0E 11 79 89 1E 37 C5 AF 8E 72 69 02 03 01 00 01 A3 81 E7 30 81 E4 30 1F 06 03 55 1D 23 04 18 30 16 80 14 C0 7A 98 68 8D 89 FB AB 05 64 0C 11 7D AA 7D 65 B8 CA CC 4E 30 1D 06 03 55 1D 0E 04 16 04 14 4A DD 06 16 1B BC F6 68 B5 76 F5 81 B6 BB 62 1A BA 5A 81 2F 30 12 06 03 55 1D 13 01 01 FF 04 08 30 06 01 01 FF 02 01 00 30 0E 06 03 55 1D 0F 01 01 FF 04 04 03 02 01 06 30 35 06 03 55 1D 1F 04 2E 30 2C 30 2A A0 28 A0 26 86 24 68 74 74 70 3A 2F 2F 67 2E 73 79 6D 63 62 2E 63 6F 6D 2F 63 72 6C 73 2F 67 74 67 6C 6F 62 61 6C 2E 63 72 6C 30 2E 06 08 2B 06 01 05 05 07 01 01 04 22 30 20 30 1E 06 08 2B 06 01 05 05 07 30 01 86 12 68 74 74 70 3A 2F 2F 67 2E 73 79 6D 63 64 2E 63 6F 6D 30 17 06 03 55 1D 20 04 10 30 0E 30 0C 06 0A 2B 06 01 04 01 D6 79 02 05 01 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 82 01 01 00 27 8C CF E9 C7 3B BE C0 6F E8 96 84 FB 9C 5C 5D 90 E4 77 DB 8B 32 60 9B 65 D8 85 26 B5 BA 9F 1E DE 64 4E 1F C6 C8 20 5B 09 9F AB A9 E0 09 34 45 A2 65 25 37 3D 7F 5A 6F 20 CC F9 FA F1 1D 8F 10 0C 02 3A C4 C9 01 76 96 BE 9B F9 15 D8 39 D1 C5 03 47 76 B8 8A 8C 31 D6 60 D5 E4 8F DB FA 3C C6 D5 98 28 F8 1C 8F 17 91 34 CB CB 52 7A D1 FB 3A 20 E4 E1 86 B1 D8 18 0F BE D6 87 64 8D C5 0A 25 42 51 EF B2 38 B8 E0 1D D0 E1 FC E6 F4 AF 46 BA EF C0 BF C5 B4 05 F5 94 75 0C FE A2 BE 02 BA EA 86 5B F9 35 B3 66 F5 C5 8D 85 A1 1A 23 77 1A 19 17 54 13 60 9F 0B E1 B4 9C 28 2A F9 AE 02 34 6D 25 93 9C 82 A8 17 7B F1 85 B0 D3 0F 58 E1 FB B1 FE 9C A1 A3 E8 FD C9 3F F4 D7 71 DC BD 8C A4 19 E0 21 23 23 55 13 8F A4 16 02 09 7E B9 AF EE DB 53 64 BD 71 2F B9 39 CE 30 B7 B4 BC 54 E0 47 07 00 03 81 30 82 03 7D 30 82 02 E6 A0 03 02 01 02 02 03 12 BB E6 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 30 4E 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 10 30 0E 06 03 55 04 0A 13 07 45 71 75 69 66 61 78 31 2D 30 2B 06 03 55 04 0B 13 24 45 71 75 69 66 61 78 20 53 65 63 75 72 65 20 43 65 72 74 69 66 69 63 61 74 65 20 41 75 74 68 6F 72 69 74 79 30 1E 17 0D 30 32 30 35 32 31 30 34 30 30 30 30 5A 17 0D 31 38 30 38 32 31 30 34 30 30 30 30 5A 30 42 31 0B 30 09 06 03 55 04 06 13 02 55 53 31 16 30 14 06 03 55 04 0A 13 0D 47 65 6F 54 72 75 73 74 20 49 6E 63 2E 31 1B 30 19 06 03 55 04 03 13 12 47 65 6F 54 72 75 73 74 20 47 6C 6F 62 61 6C 20 43 41 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 82 01 0F 00 30 82 01 0A 02 82 01 01 00 DA CC 18 63 30 FD F4 17 23 1A 56 7E 5B DF 3C 6C 38 E4 71 B7 78 91 D4 BC A1 D8 4C F8 A8 43 B6 03 E9 4D 21 07 08 88 DA 58 2F 66 39 29 BD 05 78 8B 9D 38 E8 05 B7 6A 7E 71 A4 E6 C4 60 A6 B0 EF 80 E4 89 28 0F 9E 25 D6 ED 83 F3 AD A6 91 C7 98 C9 42 18 35 14 9D AD 98 46 92 2E 4F CA F1 87 43 C1 16 95 57 2D 50 EF 89 2D 80 7A 57 AD F2 EE 5F 6B D2 00 8D B9 14 F8 14 15 35 D9 C0 46 A3 7B 72 C8 91 BF C9 55 2B CD D0 97 3E 9C 26 64 CC DF CE 83 19 71 CA 4E E6 D4 D5 7B A9 19 CD 55 DE C8 EC D2 5E 38 53 E5 5C 4F 8C 2D FE 50 23 36 FC 66 E6 CB 8E A4 39 19 00 B7 95 02 39 91 0B 0E FE 38 2E D1 1D 05 9A F6 4D 3E 6F 0F 07 1D AF 2C 1E 8F 60 39 E2 FA 36 53 13 39 D4 5E 26 2B DB 3D A8 14 BD 32 EB 18 03 28 52 04 71 E5 AB 33 3D E1 38 BB 07 36 84 62 9C 79 EA 16 30 F4 5F C0 2B E8 71 6B E4 F9 02 03 01 00 01 A3 81 F0 30 81 ED 30 1F 06 03 55 1D 23 04 18 30 16 80 14 48 E6 68 F9 2B D2 B2 95 D7 47 D8 23 20 10 4F 33 98 90 9F D4 30 1D 06 03 55 1D 0E 04 16 04 14 C0 7A 98 68 8D 89 FB AB 05 64 0C 11 7D AA 7D 65 B8 CA CC 4E 30 0F 06 03 55 1D 13 01 01 FF 04 05 30 03 01 01 FF 30 0E 06 03 55 1D 0F 01 01 FF 04 04 03 02 01 06 30 3A 06 03 55 1D 1F 04 33 30 31 30 2F A0 2D A0 2B 86 29 68 74 74 70 3A 2F 2F 63 72 6C 2E 67 65 6F 74 72 75 73 74 2E 63 6F 6D 2F 63 72 6C 73 2F 73 65 63 75 72 65 63 61 2E 63 72 6C 30 4E 06 03 55 1D 20 04 47 30 45 30 43 06 04 55 1D 20 00 30 3B 30 39 06 08 2B 06 01 05 05 07 02 01 16 2D 68 74 74 70 73 3A 2F 2F 77 77 77 2E 67 65 6F 74 72 75 73 74 2E 63 6F 6D 2F 72 65 73 6F 75 72 63 65 73 2F 72 65 70 6F 73 69 74 6F 72 79 30 0D 06 09 2A 86 48 86 F7 0D 01 01 05 05 00 03 81 81 00 76 E1 12 6E 4E 4B 16 12 86 30 06 B2 81 08 CF F0 08 C7 C7 71 7E 66 EE C2 ED D4 3B 1F FF F0 F0 C8 4E D6 43 38 B0 B9 30 7D 18 D0 55 83 A2 6A CB 36 11 9C E8 48 66 A3 6D 7F B8 13 D4 47 FE 8B 5A 5C 73 FC AE D9 1B 32 19 38 AB 97 34 14 AA 96 D2 EB A3 1C 14 08 49 B6 BB E5 91 EF 83 36 EB 1D 56 6F CA DA BC 73 63 90 E4 7F 7B 3E 22 CB 3D 07 ED 5F 38 74 9C E3 03 50 4E A1 AF 98 EE 61 F2 84 3F 12
=====
=====
Reading from radio:
16 03 03 01 4D
=====
=====
Reading from radio:
0C 00 01 49 03 00 17 41 04 49 26 7D 51 38 02 34 6E 72 FE C7 C2 BD D9 09 DB D4 AF 85 59 FD 20 22 63 B4 96 1C 26 CC 2B 49 DE 6F 55 0A EF 3C 4F A9 57 13 29 D7 00 E2 D5 F5 5B 16 E0 4A D5 D6 DB 57 2A 0D 9C 82 C1 07 3B 2F F5 04 01 01 00 8B A7 06 05 11 FD A5 00 8B C4 37 36 F1 15 76 A2 13 6C 90 74 D7 C4 A1 D3 DF 93 46 89 72 E6 2C F0 AD C3 FA 7B F4 89 AF A9 24 20 4A BA DA B4 2D EE 62 27 EF D4 A7 5D 58 D4 40 50 40 81 6C 28 D8 C8 D2 0A 8C 34 4D F3 3E EB B4 4B 50 9C 82 56 F5 2E 78 FD 13 52 78 BF 3B 8C 7D E6 ED 9C EE 19 90 5A 30 51 5B 20 9F BB 0F 59 C7 FC D7 07 D0 B1 54 AD 96 77 90 E0 C4 1E 96 9F 0B 57 BD AE A0 11 EF EA BC 0A F9 1A 33 61 54 E1 D6 02 F3 7D 0C EC 86 46 B3 84 6C 07 FC ED D2 16 91 1A BC 35 EA 38 13 D9 7B 8B 0A 6C 1F 8D 51 35 07 A6 05 B7 EE D9 49 6F 2C AD FE DA BA F6 A8 72 16 E2 04 E7 C3 1E 78 97 B8 C4 5D AC C1 91 35 CE 2C 43 6F B3 56 73 63 F5 9C 17 B0 D1 01 77 8D C2 62 36 17 68 13 87 0F 2B 92 77 E7 47 EA A4 9F 3D 53 C0 58 23 00 BE FC 4B D2 9F D1 F4 7F 78 C9 7D A3 AE BA 68 CA 89 01 E4
=====
=====
Reading from radio:
16 03 03 00 04
=====
=====
Reading from radio:
0E 00 00 00
=====
=====
Sending to radio:
16 03 03 00 46 10 00 00 42 41 04 2E 82 9E 87 6E C1 3A 13 0F 57 9D 06 0D 0B 13 29 A6 EB 5E A6 82 75 E9 8B 21 5A 42 28 6A 40 B1 4D 85 21 5F 45 90 90 D5 F5 42 2F DE B6 36 AE 28 BB 82 A3 6F 6D E5 49 DE 7C 19 60 1C C5 07 58 53 A3
=====
=====
Sending to radio:
14 03 03 00 01 01
=====
=====
Sending to radio:
16 03 03 00 40 C2 63 29 2E 60 0F D6 AE 41 E5 F5 CC 6B 6F 75 19 FD 71 96 0C 79 C6 E5 6C 4C BB 2F B3 05 49 87 EB C8 48 99 4F AF CB 4B B4 2D A1 6E 54 08 12 DB 27 DD 54 D8 E3 15 6E 37 1E F5 96 E9 C3 75 01 32 41
=====
=====
Reading from radio:
0D 0A 4E 4F 20
=====
Error code [-326] is [record layer version error]

Looking at just the raw data, it looks like the client initiates the connection with google with a record layer header of 16,03,03,00,73 and then waits for the response from the server.

The server responds with a record layer header of 16,03,03,00,4A followed by the data.

The server then sends another record layer header 16,03,03,0B,FF followed by the certificate for verifying google.

The server then sends another record layer message 16,03,03,01,4D (for another certificate in the chain?)

Etc, etc. The record layer headers are all fine up until the client sends a ClientKeyExchange message, after which the next record layer header received from the server is: 0D,0A,4E,4F,20

The client then runs through the "record layer version error" checking part of the code and exits.

The options I can see that would cause this behavior would be:
A) The server is responding incorrectly (unlikely)
B) The server is encrypting the next record
C) The server is still sending data corresponding to the previous message sent
D) The read data is leftover from the buffer and wasn't cleared in some fashion

Option A is very unlikely as google.com works fine for other applications such as browsers and the like.
Option B is possible, but I don't know how one would check for that issue.
Option C might be possible, but unlikely as the client CyaSSL code works for other websites (axeda.com, twitter.com, wikipedia.org,httpbin.org)
Option D might be possible as well, which I will look into, but given the way the HTTPClient library for mbed works, I would expect it to be operating "ok" given the common IPStack interface for mbed applications.

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Fri, 30 Jan 2015 23:08:48 +0000

I figured out that I was using the wrong location for the certificate and that the test client ran perfectly on a linux VM; (got the 404 response http code from google.com both with and without certificate verification using the appropriate certs).

I'm going to try to pull more debug values from the client at various points of interest in the code, but I'm not sure what to be looking for/at.

Is there any code difference between connecting to say google.com versus wikipedia.org?
The library works consistently on certain websites and doesn't work consistently on the google.com and yahoo.com domains.
I would expect the code operates the same way for the SSL code regardless of which website it connects to, which would beg the question of what is different about the named websites that would cause a handshake failure, whereas the other websites are connecting just fine.

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Fri, 30 Jan 2015 21:47:16 +0000

I have built the test client example on linux and am able to get the 404 code from google.com when testing a GET request, but I am unable to get the client to load a certificate to use for verifying the google.com server.
I tried putting it in the /certs/
folder, but it keeps giving me the error:
"yassl error: can't load ca file, Please run from CyaSSL home dir"

I am inside of the (cyassl_roots_ folder when I run the client command, so am I placing the certificate in the wrong location?

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Fri, 30 Jan 2015 20:57:32 +0000

I was printing the version values from within GetRecordHeader(), as that is the location where the record header check is occuring.
I found that for all of the handshake operations (first_message, first_message_reply, second_message_reply, etc.) the versions for the record layer headers would be set to 3,3 inside of the XMEMCPY() operation (at the beginning of the GetRecordHeader() function).
For the final hanshake operation (FINISHED_DONE) the XMEMCPY() would write 10,78 as the values instead of 3,3.

I have not tried the example client from the command line, as I had to cut out those files in order to compile the library to mbed.org's online compiler.

I will proceed to run it and make sure that all of the files are working, but I don't see how the mbed code will be comparable with the linux build with only the source files being copied.

I will also attempt to get a log of printf statements on the record layer header data during the handshake exchange.

static int GetRecordHeader(CYASSL* ssl, const byte* input, word32* inOutIdx,
                           RecordLayerHeader* rh, word16 *size)
{
    if (!ssl->options.dtls) {
#ifdef HAVE_FUZZER
        if (ssl->fuzzerCb)
            ssl->fuzzerCb(ssl, input + *inOutIdx, RECORD_HEADER_SZ, FUZZ_HEAD,
                    ssl->fuzzerCtx);
#endif
        XMEMCPY(rh, input + *inOutIdx, RECORD_HEADER_SZ);
        *inOutIdx += RECORD_HEADER_SZ;
        ato16(rh->length, size);
    }
    else {
#ifdef CYASSL_DTLS
        /* type and version in same sport */
        XMEMCPY(rh, input + *inOutIdx, ENUM_LEN + VERSION_SZ);
        *inOutIdx += ENUM_LEN + VERSION_SZ;
        ato16(input + *inOutIdx, &ssl->keys.dtls_state.curEpoch);
        *inOutIdx += 4; /* advance past epoch, skip first 2 seq bytes for now */
        ato32(input + *inOutIdx, &ssl->keys.dtls_state.curSeq);
        *inOutIdx += 4;  /* advance past rest of seq */
        ato16(input + *inOutIdx, size);
        *inOutIdx += LENGTH_SZ;
#ifdef HAVE_FUZZER
        if (ssl->fuzzerCb)
            ssl->fuzzerCb(ssl, input + *inOutIdx - LENGTH_SZ - 8 - ENUM_LEN -
                           VERSION_SZ, ENUM_LEN + VERSION_SZ + 8 + LENGTH_SZ,
                           FUZZ_HEAD, ssl->fuzzerCtx);
#endif
#endif
    }
    printf("rh Major:%d, rh Minor:%d, client major:%d, client minor:%d\r\n",rh->pvMajor, rh->pvMinor, ssl->version.major, ssl->version.minor);
    /* catch version mismatch */
    if (rh->pvMajor != ssl->version.major || rh->pvMinor != ssl->version.minor){
        if (ssl->options.side == CYASSL_SERVER_END &&
            ssl->options.acceptState == ACCEPT_BEGIN)
            CYASSL_MSG("Client attempting to connect with different version");
        else if (ssl->options.side == CYASSL_CLIENT_END &&
                                 ssl->options.downgrade &&
                                 ssl->options.connectState < FIRST_REPLY_DONE)
            CYASSL_MSG("Server attempting to accept with different version");
        else {
            CYASSL_MSG("SSL version error");
            return VERSION_ERROR;              /* only use requested version */
        }
    }

Re: [SOLVED] Equifax Certificate

null@example.com (john) — Wed, 28 Jan 2015 22:16:59 +0000

When you got the 10/78, were you printing out the version numbers from inside the DoFinished() function or were you looking at them in the data stream?

Have you tried the connection using the example client from the command line?

Re: [SOLVED] Equifax Certificate

null@example.com (Vanger) — Wed, 28 Jan 2015 21:08:42 +0000

We have a switch statement to choose which method function based on user choice, but for testing purposes we are using:
SSLmethod = CyaTLSv1_2_client_method()

Wireshark would be hard to implement, as the connection is through a cellular modem attached to the NucleoF401RE board. (would need to proxy the connection through a server before connecting to google)

I can get logs of the data traffic being passed through the modem, but can't specifically use wireshark (easily at least).

When I was debugging before, the versions for the handshake were consistent right up until the last handshake FINISHED_DONE case, where the version(s) flipped from major 3, minor 3 to major 10, minor 78

Would raw data from the radio be useful? If so, I will pull it out of the connection attempt.
I can also insert print statements for various values that would be helpful of indicating the problem.

Re: [SOLVED] Equifax Certificate

null@example.com (john) — Wed, 28 Jan 2015 19:54:41 +0000

Which "method" function are you using to make your CyaSSL_CTX object?

I can connect to Google with our example client using SSLv3 (0), TLSv1.0 (1), TLSv1.1 (2), and TLSv1.2 (3):

% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 0
% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 1
% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 2
% ./examples/client/client -g -h www.google.com -p 443 -A equifax-for-google.pem -v 3

And I get the 404 response for each of those, decoded.

Could you capture the network traffic for the connection attempt using Wireshark?