- mbed-tls - lists.trustedfirmware.org

Handshake Fails Server Side error fatal:unexpected_message

by Satya Prakash Prasad

We are testing the HosatAP module integrated with MBedTLS version 2.19.1. But we are receiving an error during the SSL handshake. In Server side we are using hostapd daemon - we see the below error: SSL: SSL_accept:SSLv3/TLS write server done OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=21 (alert/) OpenSSL: Message - hexdump(len=2): [REMOVED] SSL: (where=0x4008 ret=0x20a) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unexpected_message authsrv: local TLS alert: unexpected_message SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in error OpenSSL: openssl_handshake - SSL_connect error:141A20F4:SSL routines:ossl_statem_server_read_transition:unexpected message SSL: 7 bytes pending from ssl_out SSL: Failed - tls_out available to report error *EAP-TLS: CONTINUE -> FAILURE* OpenSSL: Session was not cached EAP: Session-Id - hexdump(len=0): [NULL] EAP: EAP entering state SELECT_ACTION EAP: getDecision: method failed -> FAILURE EAP: EAP entering state FAILURE EAP: Building EAP-Failure (id=134) In wireshark logs we see the below details: Frame 52: 226 bytes on wire (1808 bits), 226 bytes captured (1808 bits) on interface \Device\NPF_{87758CCA-2149-4961-9FDA-E59432A16D13}, id 0 Ethernet II, Src: DanfossDrive_00:8c:94 (00:1b:08:00:8c:94), Dst: Nearest-non-TPMR-bridge (01:80:c2:00:00:03) 802.1X Authentication Version: 802.1X-2004 (2) Type: EAP Packet (0) Length: 208 Extensible Authentication Protocol Code: Response (2) Id: 168 Length: 208 Type: TLS EAP (EAP-TLS) (13) EAP-TLS Flags: 0x00 0... .... = Length Included: False .0.. .... = More Fragments: False ..0. .... = Start: False Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 197 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 193 Version: TLS 1.2 (0x0303) Random: 259e9db9530f8afbc74536b9a963b4f1c4cb738bcea7403d4d606b6e074ec5d3 GMT Unix Time: Jan 1, 1990 05:30:57.000000000 India Standard Time Random Bytes: 530f8afbc74536b9a963b4f1c4cb738bcea7403d4d606b6e074ec5d3 Session ID Length: 0 Cipher Suites Length: 80 Cipher Suites (40 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xc0ad) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM (0xc09f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (0xc0af) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CCM_8 (0xc0a3) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xc0ac) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM (0xc09e) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CCM_8 (0xc0a2) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_256_CCM (0xc09d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_256_CCM_8 (0xc0a1) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_128_CCM (0xc09c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_AES_128_CCM_8 (0xc0a0) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 72 Extension: signature_algorithms (len=22) Type: signature_algorithms (13) Length: 22 Signature Hash Algorithms Length: 20 Signature Hash Algorithms (10 algorithms) Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature Hash Algorithm Hash: SHA512 (6) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha384 (0x0501) Signature Hash Algorithm Hash: SHA384 (5) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha256 (0x0401) Signature Hash Algorithm Hash: SHA256 (4) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: SHA224 ECDSA (0x0303) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: SHA224 RSA (0x0301) Signature Hash Algorithm Hash: SHA224 (3) Signature Hash Algorithm Signature: RSA (1) Signature Algorithm: ecdsa_sha1 (0x0203) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: ECDSA (3) Signature Algorithm: rsa_pkcs1_sha1 (0x0201) Signature Hash Algorithm Hash: SHA1 (2) Signature Hash Algorithm Signature: RSA (1) Extension: supported_groups (len=24) Type: supported_groups (10) Length: 24 Supported Groups List Length: 22 Supported Groups (11 groups) Supported Group: secp521r1 (0x0019) Supported Group: brainpoolP512r1 (0x001c) Supported Group: secp384r1 (0x0018) Supported Group: brainpoolP384r1 (0x001b) Supported Group: secp256r1 (0x0017) Supported Group: secp256k1 (0x0016) Supported Group: brainpoolP256r1 (0x001a) Supported Group: secp224r1 (0x0015) Supported Group: secp224k1 (0x0014) Supported Group: secp192r1 (0x0013) Supported Group: secp192k1 (0x0012) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: encrypt_then_mac (len=0) Type: encrypt_then_mac (22) Length: 0 Extension: extended_master_secret (len=0) Type: extended_master_secret (23) Length: 0 Extension: session_ticket (len=0) Type: session_ticket (35) Length: 0 Session Ticket: <MISSING> [JA4: 12i400600_9479543b8654_7b0ba9b4cf08] [JA4_r [truncated]: 12i400600_002f,0033,0035,0039,003c,003d,0067,006b,009c,009d,009e,009f,00ff,c009,c00a,c013,c014,c023,c024,c027,c028,c02b,c02c,c02f,c030,c09c,c09d,c09e,c09f,c0a0,c0a1,c0a2,c0a3,c0ac,c0ad,c0ae,c0af,cca8,cca9,ccaa_000a,000b,] [JA3 Fullstring [truncated]: 771,52392-52393-52394-49196-49200-159-49325-49311-49188-49192-107-49162-49172-57-49327-49315-49195-49199-158-49324-49310-49187-49191-103-49161-49171-51-49326-49314-157-49309-61-53-49313-156-49308-60-47-49312-255] [JA3: fee1630eb5b7688c9f8303364702933f] As you can see the Session Ticket details are missing and that Length 0 field is the last byte in the message but still in Wireshark we see other details like JA4, JA4_r etc? Is the "Client Hello" response from the client in the correct format?

1 year, 6 months

1
0
0 0

Handshake Fails Server Side error fatal:unexpected_message

by Satya Prakash Prasad

Hi, We are testing the HosatAP module integrated with MBedTLS version 2.19.1. But we are receiving an error during the SSL handshake. In Server side we are using hostapd daemon - we see the below error: random: getrandom() support available Configuration file: data/eap/hostap-standalone/hostapd_newCrt.conf Opening raw packet socket for ifindex 4 BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits) Using existing control interface directory. eaptest1: IEEE 802.11 Fetching hardware channel/rate support not supported. Completing interface initialization hostapd_setup_bss(hapd=0x564a594121c0 (eaptest1), first=1) eaptest1: Flushing old station entries eaptest1: Deauthenticate all stations Using interface eaptest1 with hwaddr 02:11:11:11:11:11 and ssid "" TLS: Trusted root certificate(s) loaded OpenSSL: tls_use_private_key_file (PEM) --> loaded eaptest1: interface state UNINITIALIZED->ENABLED eaptest1: AP-ENABLED eaptest1: Setup of interface done. ctrl_iface not configured! Received EAPOL packet eaptest1: Event NEW_STA (22) received Data frame from unknown STA 00:1b:08:00:8c:94 - adding a new STA New STA ap_sta_add: register ap_handle_timer timeout for 00:1b:08:00:8c:94 (300 seconds - ap_max_inactivity) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: start authentication EAP: Server state machine created IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state IDLE IEEE 802.1X: 00:1b:08:00:8c:94 CTRL_DIR entering state FORCE_BOTH eaptest1: hostapd_new_assoc_sta: canceled wired ap_handle_timer timeout for 00:1b:08:00:8c:94 eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=1 length=0 ignoring 42 extra octets after IEEE 802.1X packet eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAPOL-Start from STA IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state DISCONNECTED eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: unauthorizing port IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state RESTART EAP: EAP entering state INITIALIZE eaptest1: CTRL-EVENT-EAP-STARTED 00:1b:08:00:8c:94 EAP: EAP entering state SELECT_ACTION EAP: getDecision: no identity known yet -> CONTINUE EAP: EAP entering state PROPOSE_METHOD EAP: getNextMethod: vendor 0 type 1 eaptest1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 124 EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state CONNECTING IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state AUTHENTICATING IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 124) IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 6 seconds (from dynamic back off; retransCount=1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 124) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=9 ignoring 33 extra octets after IEEE 802.1X packet EAP: code=2 identifier=124 length=9 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=124 len=9) from STA: EAP Response-Identity (1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=124 respMethod=1 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE EAP-Identity: Peer identity - hexdump_ascii(len=4): 75 73 65 72 user EAP: EAP entering state SELECT_ACTION EAP: getDecision: another method available -> CONTINUE EAP: EAP entering state PROPOSE_METHOD EAP: getNextMethod: vendor 0 type 13 eaptest1: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 125 EAP-TLS: START -> CONTINUE EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 125) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 212 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=208 EAP: code=2 identifier=125 length=208 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=125 len=208) from STA: EAP Response-TLS (13)IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=125 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=208) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 SSL: (where=0x10 ret=0x1) SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:before SSL initialization OpenSSL: RX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:before SSL initialization OpenSSL: RX ver=0x304 content_type=22 (handshake/client hello) OpenSSL: Message - hexdump(len=197): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS read client hello OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/server hello) OpenSSL: Message - hexdump(len=61): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write server hello OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/certificate) OpenSSL: Message - hexdump(len=855): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write certificate OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/server key exchange) OpenSSL: Message - hexdump(len=401): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write key exchange OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/certificate request) OpenSSL: Message - hexdump(len=153): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write certificate request OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=22 (handshake/server hello done) OpenSSL: Message - hexdump(len=4): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write server done SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in SSLv3/TLS write server done SSL: SSL_connect - want more data SSL: 1499 bytes pending from ssl_out SSL: Using TLS version TLSv1.2 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 126 SSL: Generating Request SSL: Sending out 1393 bytes (106 more to send) EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 126) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=6 ignoring 36 extra octets after IEEE 802.1X packet EAP: code=2 identifier=126 length=6 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=126 len=6) from STA: EAP Response-TLS (13) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=126 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=6) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 SSL: Fragment acknowledged EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 127 SSL: Generating Request SSL: Sending out 106 bytes (message sent completely) EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 127) IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 6 seconds (from dynamic back off; retransCount=1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 127) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=6 ignoring 36 extra octets after IEEE 802.1X packet EAP: code=2 identifier=127 length=6 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=127 len=6) from STA: EAP Response-TLS (13) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=127 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=6) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in SSLv3/TLS write server done SSL: SSL_connect - want more data SSL: 0 bytes pending from ssl_out SSL: Using TLS version TLSv1.2 EAP: EAP entering state METHOD_REQUEST EAP: building EAP-Request: Identifier 128 SSL: Generating Request SSL: Sending out 0 bytes (message sent completely) EAP: EAP entering state SEND_REQUEST EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 46 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=6 ignoring 36 extra octets after IEEE 802.1X packet EAP: code=2 identifier=127 length=6 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=127 len=6) from STA: EAP Response-TLS (13) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=127 respMethod=13 respVendor=0 respVendorMethod=0 EAP: RECEIVED->DISCARD: rxResp=1 respId=127 currentId=128 respMethod=13 currentMethod=13 EAP: EAP entering state DISCARD EAP: EAP entering state IDLE EAP: retransmit timeout 3 seconds (from dynamic back off; retransCount=0) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state IGNORE IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 6 seconds (from dynamic back off; retransCount=1) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) IEEE 802.1X: 00:1b:08:00:8c:94 - (EAP) retransWhile --> 0 EAP: EAP entering state RETRANSMIT eaptest1: CTRL-EVENT-EAP-RETRANSMIT 00:1b:08:00:8c:94 EAP: EAP entering state IDLE EAP: retransmit timeout 12 seconds (from dynamic back off; retransCount=2) IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state REQUEST eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) Received EAPOL packet eaptest1: Event NEW_STA (22) received eaptest1: Event EAPOL_RX (23) received IEEE 802.1X: 212 bytes from 00:1b:08:00:8c:94 IEEE 802.1X: version=2 type=0 length=208 EAP: code=2 identifier=128 length=208 (response) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: received EAP packet (code=2 id=128 len=208) from STA: EAP Response-TLS (13)IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state RESPONSE EAP: EAP entering state RECEIVED EAP: parseEapResp: rxResp=1 rxInitiate=0 respId=128 respMethod=13 respVendor=0 respVendorMethod=0 EAP: EAP entering state INTEGRITY_CHECK EAP: EAP entering state METHOD_RESPONSE SSL: Received packet(len=208) - Flags 0x00 SSL: Received packet: Flags 0x0 Message Length 0 OpenSSL: RX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] SSL: (where=0x2001 ret=0x1) SSL: SSL_accept:SSLv3/TLS write server done OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=21 (alert/) OpenSSL: Message - hexdump(len=2): [REMOVED] SSL: (where=0x4008 ret=0x20a) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unexpected_message authsrv: local TLS alert: unexpected_message SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in error OpenSSL: openssl_handshake - SSL_connect error:141A20F4:SSL routines:ossl_statem_server_read_transition:unexpected message SSL: 7 bytes pending from ssl_out SSL: Failed - tls_out available to report error EAP-TLS: CONTINUE -> FAILURE OpenSSL: Session was not cached EAP: Session-Id - hexdump(len=0): [NULL] EAP: EAP entering state SELECT_ACTION EAP: getDecision: method failed -> FAILURE EAP: EAP entering state FAILURE EAP: Building EAP-Failure (id=128) eaptest1: CTRL-EVENT-EAP-FAILURE 00:1b:08:00:8c:94 IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state FAIL eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Sending EAP Packet (identifier 128) IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state HELD eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: unauthorizing port eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: authentication failed - EAP type: 0 (unknown) eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.1X: Supplicant used different EAP type: 13 (TLS) eaptest1: IEEE 802.1X: Force disconnection of 00:1b:08:00:8c:94 after EAP-Failure in 10 ms IEEE 802.1X: 00:1b:08:00:8c:94 BE_AUTH entering state IDLE eaptest1: IEEE 802.1X: Scheduled disconnection of 00:1b:08:00:8c:94 after EAP-Failure eaptest1: ap_sta_disconnect STA 00:1b:08:00:8c:94 reason=23 eaptest1: ap_sta_disconnect: reschedule ap_handle_timer timeout for 00:1b:08:00:8c:94 (5 seconds - AP_MAX_INACTIVITY_AFTER_DEAUTH) IEEE 802.1X: 00:1b:08:00:8c:94 AUTH_PAE entering state INITIALIZE EAP: EAP entering state DISABLED eaptest1: Deauthentication callback for STA 00:1b:08:00:8c:94 eaptest1: Removing STA 00:1b:08:00:8c:94 from kernel driver eaptest1: STA 00:1b:08:00:8c:94 MLME: MLME-DEAUTHENTICATE.indication(00:1b:08:00:8c:94, 23) eaptest1: STA 00:1b:08:00:8c:94 MLME: MLME-DELETEKEYS.request(00:1b:08:00:8c:94) eaptest1: ap_handle_timer: 00:1b:08:00:8c:94 flags=0x40000000 timeout_next=3 eaptest1: STA 00:1b:08:00:8c:94 IEEE 802.11: deauthenticated due to local deauth request ap_free_sta: cancel ap_handle_timer for 00:1b:08:00:8c:94 EAP: Server state machine removed In wireshark logs we see the below details: [image: image.png] As you can see the Session Ticket details are missing and that Length 0 field is the last byte in the message but still in Wireshark we see other details like JA4, JA4_r etc? Is the "Client Hello" response from the client in the correct format? Why does the Serve states: SSL: SSL_accept:SSLv3/TLS write server done OpenSSL: TX ver=0x0 content_type=256 (TLS header info/) OpenSSL: Message - hexdump(len=5): [REMOVED] OpenSSL: TX ver=0x303 content_type=21 (alert/) OpenSSL: Message - hexdump(len=2): [REMOVED] SSL: (where=0x4008 ret=0x20a) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unexpected_message authsrv: local TLS alert: unexpected_message SSL: (where=0x2002 ret=0xffffffff) SSL: SSL_accept:error in error OpenSSL: openssl_handshake - SSL_connect error:141A20F4:SSL routines:ossl_statem_server_read_transition:unexpected message SSL: 7 bytes pending from ssl_out SSL: Failed - tls_out available to report error *EAP-TLS: CONTINUE -> FAILURE* OpenSSL: Session was not cached EAP: Session-Id - hexdump(len=0): [NULL] EAP: EAP entering state SELECT_ACTION EAP: getDecision: method failed -> FAILURE EAP: EAP entering state FAILURE EAP: Building EAP-Failure (id=134) Regards, Prakash

1 year, 6 months

1
0
0 0

MbedTLS (2.25.0) TLS handshake on FreeRTOS - PSA Crypto enabled (SE) but not used during client step 8

by hippolyte.einfalt＠viveris.fr

Greetings, ## The Setup Greetings, ## The Setup I have a RENESAS board that has an integrated crypto processor and uses MbedTLS 2.25.0. I have a SE (secure element) connected to it. I am allowing hardware acceleration and PSA crypto API inside mbedtls_config.h I registered my SE driver before calling psa_crypto_init(). The board connects to a web server and performs TLS handshake with the forced cipher `MBEDTLS_TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`. ## The issue The handshake fails during the step 8 when generating EC private key for ECDHE exchange. I have tracked the issue through debug and it unfolded as follows inside `ssl_write_client_key_exchange()`: - We enter the PSA crypto code from the pre-processor directives. - We set the key attributes after initializing them to 0. (here usage_flags, algorithm, type and bits field are set but lifetime is still 0 from init at this point, this will count later on) - The next function `psa_generate_key()` fails. ## In depth When inside the `psa_generate_key()` function, we start the key creation inside `psa_start_key_creation()`. But here, when validating the attributes of the key in `psa_validate_key_attributes()`, we are not able to rely on the SE to store the key due to it being volatile (lifetime is still 0), the driver is never called. From there the program keeps going until trying to generate the key with the crypto processor from the board which does not support this type of key and returns unsupported error. ## Main question Since the lifetime is forced to be representing a volatile key and since the driver for the SE is not called except for persistent ones, i cannot do this cryptographic step using the SE. Is the generation of the volatile key at this step meant to be handled by the MbedTLS library (software or hardware alt) and not by the PSA Crypto API (SE) due to the key being volatile ? If not, how is the Se supposed to be called in the handshake and what am i missing ? ## Discussion I can pass the handshake when disabling hardware acceleration and using the software for cryptographic steps, but in this case i am not using the SE for them. Should the SE only be used to store the client certificate for mTLS case ? ## Note I must use the MbedTLS version 2.25.0 since the SE driver I am using relies on this version.

1 year, 6 months

2
5
2 0

Release all memory held by mbedtls_ssl_context

by Satya Prakash Prasad

Hi, We are writing a client code which can accept or decline connection to the server - so for each connection I understand there is a mbedtls_ssl_context data established. Once the same is closed or not required we need to do deinitialize or free memory allocated to its member variables like - we need to free all memory allocated since we need it back else our application will run out of memory like: os_free(mbed_ctx->handshake); os_free(mbed_ctx->transform_negotiate); os_free(mbed_ctx->session_negotiate); os_free(mbed_ctx->in_buf); os_free(mbed_ctx->out_buf); But there are many member variables which also need to free memory if allocated and assigned to it. Is there a function / method that can free all memory for mbedtls_ssl_context instance variable? Thanks in advance. Regards, Prakash

1 year, 6 months

3
3
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next Monday at 10:00am PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year, 6 months

1
3
0 0

Building mbedtls-2.19.1

by Satya Prakash Prasad

Hi, Please note that I needed to compile and work with MBed TLS version 2.19.1 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.19.1 However I am unable to compile the code / examples in it - i get below error: *$ cmake .CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required): Compatibility with CMake < 2.8.12 will be removed from a future version of CMake. Update the VERSION argument <min> value or use a ...<max> suffix to tell CMake that the project does not need compatibility with older versions.-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.22631.CMake Error at CMakeLists.txt:192 (add_subdirectory): add_subdirectory given source "crypto/3rdparty" which is not an existing directory.CMake Error at CMakeLists.txt:199 (add_subdirectory): add_subdirectory given source "crypto/library" which is not an existing directory.CMake Error at CMakeLists.txt:200 (add_subdirectory): add_subdirectory given source "crypto/include" which is not an existing directory.CMake Warning (dev) at programs/ssl/CMakeLists.txt:37 (target_sources): Policy CMP0076 is not set: target_sources() command converts relative paths to absolute. Run "cmake --help-policy CMP0076" for policy details. Use the cmake_policy command to set the policy and suppress this warning. An interface source of target "ssl_client2" has a relative path.This warning is for project developers. Use -Wno-dev to suppress it.CMake Warning (dev) at programs/ssl/CMakeLists.txt:44 (target_sources): Policy CMP0076 is not set: target_sources() command converts relative paths to absolute. Run "cmake --help-policy CMP0076" for policy details. Use the cmake_policy command to set the policy and suppress this warning. An interface source of target "ssl_server2" has a relative path.This warning is for project developers. Use -Wno-dev to suppress it.CMake Warning (dev) at programs/test/CMakeLists.txt:31 (target_sources): Policy CMP0076 is not set: target_sources() command converts relative paths to absolute. Run "cmake --help-policy CMP0076" for policy details. Use the cmake_policy command to set the policy and suppress this warning. An interface source of target "query_compile_time_config" has a relative path.This warning is for project developers. Use -Wno-dev to suppress it.* I tried removing the errors from the CmakeFile.txt but now get below error: *$ cmake --build .Microsoft (R) Build Engine version 16.11.2+f32259642 for .NET FrameworkCopyright (C) Microsoft Corporation. All rights reserved.MSBUILD : error MSB1009: Project file does not exist.Switch: ALL_BUILD.vcxproj* Also make all Makefile:84: ../crypto/3rdparty/Makefile.inc: No such file or directory make[1]: *** No rule to make target '../crypto/3rdparty/Makefile.inc'. Stop. Makefile:19: recipe for target 'lib' failed make: *** [lib] Error 2 Please let me know how to resolve them and compile MBedTLS version 2.19.1 code? Thanks in advance. Regards, Prakash

1 year, 6 months

1
0
0 0

EAP TLS

by Satya Prakash Prasad

Hi, I am working on an issue related to memory leak in MBedTLS. We have integrated MBedTLS code for below 3rd party HostAPD code integration . https://github.com/prplfoundation/hostap [Hostapd] Please refer to the Hostapd peer code implementation as provided in the link below: https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… The main function code snippet is provided below: https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… if (eap_example_peer_init() < 0 || eap_example_server_init() < 0) return -1; do { printf("---[ server ]--------------------------------\n"); res_s = eap_example_server_step(); printf("---[ peer ]----------------------------------\n"); res_p = eap_example_peer_step(); } while (res_s || res_p); Since we are implementing code for peers hence we have removed the server step. Now we need to keep monitoring for new connections / failed connections and act accordingly we have modified the code to something like below - if (eap_example_peer_init() < 0 || eap_example_server_init() < 0) return -1; do { res_p = eap_example_peer_step(); if (eap_ctx.eapNoResp || eap_ctx.eapFail) { eap_client_peer_deinit(); eap_client_peer_init(); } } while (1); We have modified the loop such that it will keep iterating for new connections and in case of failure, re-initialization is required. Is my understanding correct? The issue I am facing is that the client peer deinit method is not releasing all memory allocated during eap_example_peer_step() function ( I understand while processing the EAP TLS server request). The deinit is purely implemented to deallocate memory initially allocated for a new connection using TLS? void eap_client_peer_deinit(void) { eap_peer_sm_deinit(eap_ctx.eap); eap_peer_unregister_methods(); wpabuf_free(eap_ctx.eapReqData); os_free(eap_ctx.eap_config.identity); os_free(eap_ctx.eap_config.password); os_free(eap_ctx.eap_config.cert.ca_cert); os_free(eap_ctx.eap_config.cert.client_cert); os_free(eap_ctx.eap_config.cert.private_key); } where void eap_peer_sm_deinit(struct eap_sm *sm) { if (sm == NULL) return; eap_deinit_prev_method(sm, "deinit"); eap_sm_abort(sm); if (sm->ssl_ctx2) tls_deinit(sm->ssl_ctx2); tls_deinit(sm->ssl_ctx); eap_peer_erp_free_keys(sm); os_free(sm); } Can you please let me know whether we are deallocating memory correctly? Thanks in advance. Regards, Prakash

1 year, 6 months

1
0
0 0

Handshake is successful if the intermediate CA is revoked.

by singaravelu Balasubramani

I am checking the certificate revocation with below scenario. I have Root CA, Intermediate CA and device certificate is signed by Intermediate CA. I am makeing chain certificate by combining Root CA, Intermediate CA and this chain certificate is my active CA certificate and loaded this and device certificate to the drive. From client, I am creating client certificate which is signed by same intermeidate CA. Making ssl handshake. Handshake is success as expected. Now i am revoking the intermediate CA and creating the crl which is signed by the Root CA. This crl has the serial number of intermediate CA. Now loading the CRL to the drive and setting the crl in "mbedtls_ssl_conf_ca_chain". Now i am establishing the ssl connection with the same client ceritificate and expecting the ssl handshake failure due to intermediate CA revoked. But i get handshake is success. Is my understanding right about intermediate CA revocation? I did little background debug, and my obervation is During handshake , it goes to static int x509_crt_verify_chain function in mbedtls. Its trying to find the parent using x509_crt_find_parent for the client certificate and get intermediate CA. During this time, parent_is_trusted is set as true. after this x509_crt_verifycrl is called with client certificate (child), intermediate CA (parent) and crl(has the intermediate CA serial number-issued by Root CA). During x509_crt_verifycrl check, it check for CRL issuer with ca subject and return 0, as its not matching. now in x509_crt_verify_chain , /* prepare for next iteration */ ., they are marking child_is_trusted = parent_is_trusted and child = parent, parent = NULL; and while loop continues, in loop, x509_crt_verify_chain checks for child_is_trusted is true and return as 0. But its not checking that intermediate CA is revoked or not. /* Stop here for trusted roots (but not for trusted EE certs) */ if( child_is_trusted ) return( 0 );

1 year, 6 months

2
2
0 0

Question about mbedtls_x509_parse_subject_alt_name

by Roman Janota

Hello, I would like to parse certificate's SAN fields in my application. In the documentation of the struct mbdetls_x509_crt for its member subject_alt_names the following is stated: "Optional list of raw entries of Subject Alternative Names extension. These can be later parsed by mbedtls_x509_parse_subject_alt_name.". I was using the latest development branch and tried to call the function, however, I found out I can not, because it is defined in the x509_internal.h private header. I later found out that the definition was moved from the public to the private header in the commit 25b282e <https://github.com/Mbed-TLS/mbedtls/commit/25b282ebfe5cb84e73d6194e83dc8d6c…> (partly thanks to the issue #459 <https://github.com/Mbed-TLS/mbedtls/issues/459>). So I switched to the 3.5.2 release and everything worked fine. Why was this change made? Will it be kept so that I'd have to implement my own parsing? Or was it a mistake? Thank you for clarifying, Roman.

1 year, 7 months

1
0
0 0

SHA-256 mismatch for mbedtls-3.5.2.tar.gz

by Wojtek Porczyk

Hello, list, Release notes for Mbed TLS 3.5.2 [0] have this: The SHA256 hashes for the archives are: 35890edf1a2c7a7e29eac3118d43302c3e1173e0df0ebaf5db56126dabe5bb05 mbedtls-3.5.2.tar.gz 55c1525e7d5de18b84a1d1e5540950b4a3bac70e02889cf309919b2877cba63b mbedtls-3.5.2.zip However, attempting to download mbedtls-3.5.2.tar.gz yields a file with hash: eedecc468b3f8d052ef05a9d42bf63f04c8a1c50d1c5a94c251c681365a2c723 What's going on with those hashes? [0]: https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.5.2 https://web.archive.org/web/20240126105153/https://github.com/Mbed-TLS/mbed… -- pozdrawiam / best regards Wojtek Porczyk Gramine / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov

1 year, 7 months

3
7
0 0

2025

2024

2023

2022

2021

2020

mbed-tls