PolarSSL is now part of ARM Official announcement and rebranded as mbed TLS.

MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED


Feb 8, 2018 12:30
Antonio

Hi all,

I have a small problem with ECC. I managed to make ECC work in my platform, MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED works well, either with my server or with an external server. However, when I enable MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED I am able to communicate with my server, but NOT when I try to connect my application to www.google.com, I get an error -0x7780 (MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE)

Does google support MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED ??

Although I am already satisfied with ECDHE_RSA, my goal is to use smaller certificate sizes, which ECDHE_ECDSA offers..

Here is my log

===>LWIP_HTTPS::  WiFi connection...[2.803,233] CONNECT:c0:56:27:b8:52:4a
[5.333,195] NOTIFY:DHCP:1
[5.380,932] NOTIFY:DHCP:8
[6.324,167] NOTIFY:DHCP:10
MYIP 172.28.49.47
 OK [HEAP]-34912.

  . RNG..  ok
  . CA root cert... ok (0 skipped)
  . tcp/www.google.se/443... ok
  . SSL/TLS ...  ok
  . SSL/TLS handshake... 2 src/ssl_tls.c: 6593 => handshake
 2 src/ssl_cli.c: 3369 client state: 0
 2 src/ssl_tls.c: 2418 => flush output
 2 src/ssl_tls.c: 2430 <= flush output
 2 src/ssl_cli.c: 3369 client state: 1
 2 src/ssl_tls.c: 2418 => flush output
 2 src/ssl_tls.c: 2430 <= flush output
 2 src/ssl_cli.c: 728 => write client hello
 3 src/ssl_cli.c: 766 client hello, max version: [3:3]
 3 src/ssl_cli.c: 775 dumping 'client hello, random bytes' (32 bytes)
 3 src/ssl_cli.c: 775 0000:  5a 02 2d 0a d3 a2 06 83 e1 2d 35 ed 0e cf 23 e3  Z.-......-5...#.
 3 src/ssl_cli.c: 775 0010:  d3 6f 1a c3 ea f7 71 a2 9e 63 1a 50 9c 02 a1 a8  .o....q..c.P....
 3 src/ssl_cli.c: 828 client hello, session id len.: 0
 3 src/ssl_cli.c: 829 dumping 'client hello, session id' (0 bytes)
 3 src/ssl_cli.c: 896 client hello, add ciphersuite: c02b
 3 src/ssl_cli.c: 929 client hello, got 2 ciphersuites
 3 src/ssl_cli.c: 960 client hello, compress len.: 1
 3 src/ssl_cli.c: 962 client hello, compress alg.: 0
 3 src/ssl_cli.c: 73 client hello, adding server name extension: localhost
 3 src/ssl_cli.c: 187 client hello, adding signature_algorithms extension
 3 src/ssl_cli.c: 272 client hello, adding supported_elliptic_curves extension
 3 src/ssl_cli.c: 337 client hello, adding supported_point_formats extension
 3 src/ssl_cli.c: 553 client hello, adding extended_master_secret extension
 3 src/ssl_cli.c: 1034 client hello, total extension length: 46
 2 src/ssl_tls.c: 2703 => write record
 3 src/ssl_tls.c: 2840 output record: msgtype = 22, version = [3:1], msglen = 95
 4 src/ssl_tls.c: 2843 dumping 'output record sent to network' (100 bytes)
 4 src/ssl_tls.c: 2843 0000:  16 03 01 00 5f 01 00 00 5b 03 03 5a 02 2d 0a d3  ...._...[..Z.-..
 4 src/ssl_tls.c: 2843 0010:  a2 06 83 e1 2d 35 ed 0e cf 23 e3 d3 6f 1a c3 ea  ....-5...#..o...
 4 src/ssl_tls.c: 2843 0020:  f7 71 a2 9e 63 1a 50 9c 02 a1 a8 00 00 04 c0 2b  .q..c.P........+
 4 src/ssl_tls.c: 2843 0030:  00 ff 01 00 00 2e 00 00 00 0e 00 0c 00 00 09 6c  ...............l
 4 src/ssl_tls.c: 2843 0040:  6f 63 61 6c 68 6f 73 74 00 0d 00 06 00 04 04 03  ocalhost........
 4 src/ssl_tls.c: 2843 0050:  03 03 00 0a 00 04 00 02 00 17 00 0b 00 02 01 00  ................
 4 src/ssl_tls.c: 2843 0060:  00 17 00 00                                      ....
 2 src/ssl_tls.c: 2418 => flush output
 2 src/ssl_tls.c: 2437 message length: 100, out_left: 100
 2 src/ssl_tls.c: 2443 ssl->f_send() returned 100 (-0xffffff9c)
 2 src/ssl_tls.c: 2462 <= flush output
 2 src/ssl_tls.c: 2852 <= write record
 2 src/ssl_cli.c: 1060 <= write client hello
 2 src/ssl_cli.c: 3369 client state: 2
 2 src/ssl_tls.c: 2418 => flush output
 2 src/ssl_tls.c: 2430 <= flush output
 2 src/ssl_cli.c: 1453 => parse server hello
 2 src/ssl_tls.c: 3723 => read record
 2 src/ssl_tls.c: 2210 => fetch input
 2 src/ssl_tls.c: 2368 in_left: 0, nb_want: 5
 2 src/ssl_tls.c: 2392 in_left: 0, nb_want: 5
 2 src/ssl_tls.c: 2393 ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
 2 src/ssl_tls.c: 2405 <= fetch input
 4 src/ssl_tls.c: 3480 dumping 'input record header' (5 bytes)
 4 src/ssl_tls.c: 3480 0000:  15 03 03 00 02                                   .....
 3 src/ssl_tls.c: 3489 input record: msgtype = 21, version = [3:3], msglen = 2
 2 src/ssl_tls.c: 2210 => fetch input
 2 src/ssl_tls.c: 2368 in_left: 5, nb_want: 7
 2 src/ssl_tls.c: 2392 in_left: 5, nb_want: 7
 2 src/ssl_tls.c: 2393 ssl->f_recv(_timeout)() returned 2 (-0xfffffffe)
 2 src/ssl_tls.c: 2405 <= fetch input
 2 src/ssl_tls.c: 4055 got an alert message, type: [2:40]
 1 src/ssl_tls.c: 4063 is a fatal alert message (msg 40)
 1 src/ssl_tls.c: 3741 mbedtls_ssl_read_record_layer() returned -30592 (-0x7780)
 1 src/ssl_cli.c: 1460 mbedtls_ssl_read_record() returned -30592 (-0x7780)
 2 src/ssl_tls.c: 6603 <= handshake
  failed  -0x7780

2 src/ssl_tls.c: 7380 => free
 2 src/ssl_tls.c: 7451 <= free

  [->]===>LWIP_HTTPS:: closing
===>LWIP_HTTPS:: exiting
^CReading trace...
 
Feb 11, 2018 12:15
Ron Eldor

HI Antonio,
I am glad you managed to make your ECC work!
According to your description, the server doesn't accept the ClientHello message your client is sending. It could be a variety of reasons, but it is most likely that it doesn't support the single cipher suite you are sending.
If you use the SSL Labs tool , you will see that the server only has certificates signed with RSA 2048 bits, and that ECDHE_ECDSA based ciphersuite is not supported by the server.
Regards,
Mbed TLS Team member
Ron

 
Feb 12, 2018 12:04
Antonio

Hi Ron,

Thanks for your help. You are right, I found another webpage that I could talk to normally. However, I am still using test Certificates, and now I want to tackle verification.

Why in your applications the Certificate Verification pass, while the same code on my case fails.. I for example get this code error

  . Verifying peer X.509 certificate... failed (8)
  ! The certificate is not correctly signed by the trusted CA

Well, I am communicating with the TestServer and using exactly your certificates, only change is that the application runs on my platform.

thanks again for your help.

 
Feb 12, 2018 14:06
Ron Eldor

Hi Antonio,
The verification error flag you are encountering is returned as a generic failure of verification. There could be several reasons for it. As first step, I would compare the configuration file on your platform, and on your test application. IT could be some missing configuration on your platform.

  • Do you know what is the certificate that is sent? Is it RSA or ECDSA signed?
  • Could it be that your ECC implementation still has some flaws?
  • Have you set the correct ca_chain using mbedtls_ssl_conf_ca_chain API?

In addition, it could be a memory issue, causing the verification to fail.
Regards,
Mbed TLS Team member
Ron

 
Feb 12, 2018 15:21
Antonio

Hi Ron,

1 I am sending a ECDSA signed certificate. Before I sent an RSA signed and got same error.

2 I believe I set the * mbedtls_ssl_conf_ca_chain* correctly..

mbedtls_ssl_conf_ca_chain( &conf, &cacert, NULL );

3 memory? maybe..but not likely. I will try updating to V2.7 and see if the error persists.

Thanks anyhow.. gonna check what I can do.

Best,

 
Feb 14, 2018 11:45
Ron Eldor

HI Antonio,
Thank you for your information. Since both RSA and ECDSA certificates fail, then it is probably a matter of configuration or memory.
Since you are using the test certificates, please verify you have MBEDTLS_CERTS_C defined in your system (in addition to the RSA and ECDSA ones). In addition, you should check full logs, to understand reason for failure. Please enable debug_level to 5, for debugging.
Regards,
Mbed TLS Team member
Ron