Handshake error: -0x7280 EOF

Mbed TLS Crypto and SSL questions
1

Hello,

I am new to Mbed TLS and have been tasked with using it to replace our current TLS architecture. As a starting point, I am using ssl_client2 to try to communicate with our test server, but I am receiving an error. I have modified ssl_client2 to parse my root certificate, device certificate, and key file. I’m also forcing the only ciphersuite that our server uses. When attempting to connect to my local test server, I am receiving the following:

Last error was: -0x7280 - SSL - The connection indicated an EOF

Here is the output with debug_level=5:

. Seeding the random number generator… ok
. Loading the CA root certificate …MBEDTLS_CERTS_C not defined. ok (1 skipped)
. Loading the client cert. and key… ok (key type: EC)
. Connecting to tcp/10.0.2.15/8080… ok
. Setting up the SSL/TLS structure… ok
. Performing the SSL/TLS handshake…ssl_tls.c:8781: |2| => handshake
ssl_cli.c:3818: |2| client state: 0
ssl_tls.c:3070: |2| => flush output
ssl_tls.c:3082: |2| <= flush output
ssl_cli.c:3818: |2| client state: 1
ssl_tls.c:3070: |2| => flush output
ssl_tls.c:3082: |2| <= flush output
ssl_cli.c:0825: |2| => write client hello
ssl_cli.c:0863: |3| client hello, max version: [3:3]
ssl_cli.c:0745: |3| client hello, current time: 1556761122
ssl_cli.c:0872: |3| dumping ‘client hello, random bytes’ (32 bytes)
ssl_cli.c:0872: |3| 0000: 5c ca 4a 22 e7 7e 11 52 82 b8 0a d4 cc 4a 55 94 .J".~.R…JU.
ssl_cli.c:0872: |3| 0010: d6 11 84 3a 6d 64 f3 e8 ea f3 28 11 36 a1 6a be …:md…(.6.j.
ssl_cli.c:0925: |3| client hello, session id len.: 0
ssl_cli.c:0926: |3| dumping ‘client hello, session id’ (0 bytes)
ssl_cli.c:0973: |3| client hello, add ciphersuite: c0ae
ssl_cli.c:0985: |3| client hello, got 1 ciphersuites (excluding SCSVs)
ssl_cli.c:0994: |3| adding EMPTY_RENEGOTIATION_INFO_SCSV
ssl_cli.c:1043: |3| client hello, compress len.: 1
ssl_cli.c:1045: |3| client hello, compress alg.: 0
ssl_cli.c:0111: |3| client hello, adding server name extension: sepServer
ssl_cli.c:0228: |3| client hello, adding signature_algorithms extension
ssl_cli.c:0313: |3| client hello, adding supported_elliptic_curves extension
ssl_cli.c:0378: |3| client hello, adding supported_point_formats extension
ssl_cli.c:0627: |3| client hello, adding session ticket extension
ssl_cli.c:1122: |3| client hello, total extension length: 82
ssl_tls.c:3499: |2| => write handshake message
ssl_tls.c:3658: |2| => write record
ssl_tls.c:3738: |3| output record: msgtype = 22, version = [3:3], msglen = 131
ssl_tls.c:3741: |4| dumping ‘output record sent to network’ (136 bytes)
ssl_tls.c:3741: |4| 0000: 16 03 03 00 83 01 00 00 7f 03 03 5c ca 4a 22 e7 ….J".
ssl_tls.c:3741: |4| 0010: 7e 11 52 82 b8 0a d4 cc 4a 55 94 d6 11 84 3a 6d ~.R…JU…:m
ssl_tls.c:3741: |4| 0020: 64 f3 e8 ea f3 28 11 36 a1 6a be 00 00 04 c0 ae d…(.6.j…
ssl_tls.c:3741: |4| 0030: 00 ff 01 00 00 52 00 00 00 0e 00 0c 00 00 09 73 …R…s
ssl_tls.c:3741: |4| 0040: 65 70 53 65 72 76 65 72 00 0d 00 16 00 14 06 03 epServer…
ssl_tls.c:3741: |4| 0050: 06 01 05 03 05 01 04 03 04 01 03 03 03 01 02 03 …
ssl_tls.c:3741: |4| 0060: 02 01 00 0a 00 18 00 16 00 19 00 1c 00 18 00 1b …
ssl_tls.c:3741: |4| 0070: 00 17 00 16 00 1a 00 15 00 14 00 13 00 12 00 0b …
ssl_tls.c:3741: |4| 0080: 00 02 01 00 00 23 00 00 …#…
ssl_tls.c:3070: |2| => flush output
ssl_tls.c:3089: |2| message length: 136, out_left: 136
ssl_tls.c:3094: |2| ssl->f_send() returned 136 (-0xffffff78)
ssl_tls.c:3122: |2| <= flush output
ssl_tls.c:3791: |2| <= write record
ssl_tls.c:3635: |2| <= write handshake message
ssl_cli.c:1157: |2| <= write client hello
ssl_cli.c:3818: |2| client state: 2
ssl_tls.c:3070: |2| => flush output
ssl_tls.c:3082: |2| <= flush output
ssl_cli.c:1550: |2| => parse server hello
ssl_tls.c:4626: |2| => read record
ssl_tls.c:2841: |2| => fetch input
ssl_tls.c:3002: |2| in_left: 0, nb_want: 5
ssl_tls.c:3034: |2| in_left: 0, nb_want: 5
ssl_tls.c:3035: |2| ssl->f_recv(_timeout)() returned 0 (-0x0000)
ssl_tls.c:5288: |1| mbedtls_ssl_fetch_input() returned -29312 (-0x7280)
ssl_tls.c:4659: |1| ssl_get_next_record() returned -29312 (-0x7280)
ssl_cli.c:1557: |1| mbedtls_ssl_read_record() returned -29312 (-0x7280)
ssl_tls.c:8791: |2| <= handshake
failed
! mbedtls_ssl_handshake returned -0x7280

Last error was: -0x7280 - SSL - The connection indicated an EOF

ssl_tls.c:9650: |2| => free
ssl_tls.c:9715: |2| <= free

Not sure if this makes a difference, but the original device certificate was in a .p7b file, which I believe is not supported. Hence, I extracted the certificate and have it in PEM format. I’m also working in a Ubuntu 16.04 VM.

I’ve only been working with TLS in general for a couple weeks, so I apologize in advance if I haven’t included enough information or - better yet - there is a simple configuration I’m missing.

Thanks!

2

Hi @akagan!

The error you are receiving indicates that the server terminated the connection.

Although you didn’t get a fatal alert from the server, my best guess is that the server couldn’t accept one or more of the parameters in your client Hello message.

I recommend you first try to connect the server using the default configuration, and narrow down the options.
I suggest you read this article for additional information.
Regards,
Mbed TLS Team member
Ron

3

Hi Ron, thank you for your response!

I’ve looked at the article you linked. Here are my results from following the steps:

  1. ssl_client2 and ssl_server2 perform the handshake correctly (as expected)
  2. running ssl_client2 with my test server causes the following error:

. Seeding the random number generator… ok
. Loading the CA root certificate … failed
! mbedtls_x509_crt_parse returned -0x2562

Last error was: -0x2562 - X509 - The extension tag or value is invalid : ASN1 - ASN1 tag was of an unexpected value

This occurs with the test certificates because the test server only accepts one ciphersuite (c0ae). My gut feeling is that this is just due to the device certificate being incorrect in some way. I extract the certificate using the following openssl command:

openssl pkcs7 -in mydevicecert.p7b -print_certs > mydevicecert.pem

Is there something else I need to do with this certificate in order for it to work?

  1. When attempting to use my client application with ssl_server2 it gives a bad client hello error, which is expected as the client application is using the .p7b extension (the only one it supports as far as I can tell) which is not supported. When I attempt to use mydevicecert.pem, the certificate extracted from the p7b file, it hangs at this point:

ssl_tls.c:0090: |3| set_timer to 0 ms
. Waiting for a remote connection … ok
. Performing the SSL/TLS handshake…ssl_tls.c:8771: |2| => handshake
ssl_srv.c:4312: |2| server state: 0
ssl_tls.c:3060: |2| => flush output
ssl_tls.c:3072: |2| <= flush output
ssl_srv.c:4312: |2| server state: 1
ssl_tls.c:3060: |2| => flush output
ssl_tls.c:3072: |2| <= flush output
ssl_srv.c:1251: |2| => parse client hello
ssl_tls.c:2841: |2| => fetch input
ssl_tls.c:3002: |2| in_left: 0, nb_want: 5

Any additional help would be great! Thanks.

4

Hi @akagan

My gut feeling is that this is just due to the device certificate being incorrect in some way. I extract the certificate using the following openssl command:
openssl pkcs7 -in mydevicecert.p7b -print_certs > mydevicecert.pem

You are probably correct. Have you tried the following command?

openssl pkcs7 -print_certs -in mydevicecert.p7b -out mydevicecert.pem

Could you please explain the authentication model? Is the device certificate the client or server certificate? Does the server request for a client certificate? Have you set the proper trusted root CA certificate in your client?

When attempting to use my client application with ssl_server2 it gives a bad client hello error, which is expected as the client application is using the .p7b extension (the only one it supports as far as I can tell) which is not supported.

This is strange, the certificate is not sent in the client hello message. Can I assume that the certificate is the server certificate, and the server hangs when trying to parse it?

Regards,
Ron

5

Hi Ron,

ssl_client2 with my server

Yes, I tried that command and the same issue occurred.

The device certificate is the client certificate. My server requests a client certificate. Yes, I have set the root CA properly for ssl_client2. I was able to get the root CA and key to load but it still has the ASN1 parsing error for the device certificate.

I was able to get a certificate that is directly PEM and is not extracted from a p7b file. However, the same issue occurs. I’ve traced the parsing function to where I believe the issue lies. Even in my root certificate, which does successfully load, after the mbedtls_asn1_get_tag() function is called the ret value is 98. After the x509_crt_parse_der_core() function, the ret value is 8576. I did not find those error codes defined. The total_failed value in the while loop within mbedtls_x509_crt_parse() is 1. The root certificate loads after this. Why/how is it causing an error yet still loading?

When loading the device certificate, after asn1_get_tag() the value is also 98. After x509_crt_parse_der_core() it returns with a value of 9570. The total_failed value in the while loop within mbedtls_x509_crt_parse() is 1.

ssl_server2 with my client

I was able to resolve my client talking to the ssl_server2 application. After analyzing the connection with Wireshark, the server was hanging because it was expecting these extra parameters:

-Extension: server_name
-Encrypt_then_mac
-Extended_master_secret
-SessionTicket TLS

After disabling these in the config.h file, it worked up until after the server hello done message, with the error “Fatal, Description: Bad Certificate”. This is expected as I can’t load the certificates onto the server either as the same ASN1 parsing error is given.

So either my certificates don’t include some information or the sample client/server aren’t meant to work without additional modifications for the ciphersuite that I’m using? The ciphersuite I am using is MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.

Please let me know if anything is unclear. Thanks in advance for the help!

Edit

Within mbetls_asn1_get_tag(), in the conditional if(**p != tag) is true and throws the MBEDTLS_ERR_ASN1_UNEXPECTED_TAG error, which has a value of 0x62 or 98 in decimal, which is where that value comes from.

After perusing the parsing function and using cert_write() to generate a certificate, I believe I found the parameters that are required in my certificate but are not yet included. They are:

-A field for Certificate Policies
-Giving a critical value to the basic_constraints field

As far as my understanding goes, the reason for my certificates having issues with mbed TLS is because they include these parameters that are not yet supported. So to include them I have to modify the certificate writing and parsing functions for them to work (similar to this post and this PR). Is my understanding correct?

Edit 2

Although the certificate generator cannot support the extensions I need, I somehow missed a critical #define in the config.h file. The following extension was commented out by default:

MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION

When I uncommented it all my certificate parsing problems went away :slight_smile:

6

Hi @akagan
Thank you for your information!!

As an FYI, there is a utility program

programs/utils/strerror

That will print the human readable values of the error codes.

Yes, if a certificate includes critical extensions that are not supported by Mbed TLS, an error will ha
ppen, unless MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION is configured. As documented:

\warning Depending on your PKI use, enabling this can be a security risk!

hence it is not configured by default. In addition, it basically ignores parsing errors of critical extensions.
I believe that this PR will help you.

Regards,
Mbed TLS Team member
Ron