Copyright © https://mongoose-os.com

Mongoose OS Forum

frame

RPC Security with mTLS

13

Comments

  • SergeySergey Dublin, Ireland
    edited February 14

    Yes. MQTT supports "last will message". Check it out what it does.

  • @Sergey said:
    Yes. MQTT supports "last will message". Check it out what it does.

    I'm working on the project and everything's perfect. Thanks for all your useful help!

  • SergeySergey Dublin, Ireland

    You're welcome.
    Is your project personal or commercial, btw?

  • iH8c0ff33iH8c0ff33 Italy
    edited February 16
    Sergey said:

    You're welcome.
    Is your project personal or commercial, btw?

    I'm not sure about that. If it would be used by other people (other schools could build the same project and use the client, which uses mongoose-os, and server I wrote), but I won't sell it, or earn anything from it, that shouldn't be a commercial project, am I correct?

  • SergeySergey Dublin, Ireland

    Yeah, it does sound like an educational, non-commercial project.

    Let me know on the progress please. Feel free to ask any project-related questions, we'll help. I'd appreciate if you promote your project and mongoose-os as much as possible.

  • iH8c0ff33iH8c0ff33 Italy
    edited March 17

    @Sergey said:
    Yeah, it does sound like an educational, non-commercial project.

    Let me know on the progress please. Feel free to ask any project-related questions, we'll help. I'd appreciate if you promote your project and mongoose-os as much as possible.

    Hi Sergey,
    Yesterday I finally had some time to test the mqtt configuration, but I have another ssl related problem. I generate ca, server and client certificates using the method described in the docs, but then my esp cannot connect to the server beacuse of an ssl error:

    mg_ssl_if_mbed_err   0x3fff0aa4 SSL error: -27136
    

    Do you know why is that happening? (i'm connecting to the broker using the same hostname as in the certificate CN field)

  • rojerrojer Dublin, Ireland

    that... is a weird error that should not happen.
    can you set debug.level=4 and debug.mbedtls_level=4 and post the (very verbose) log here?

  • @rojer said:
    that... is a weird error that should not happen.
    can you set debug.level=4 and debug.mbedtls_level=4 and post the (very verbose) log here?

    I'll do that in an hour when I get back home. Is there a documentation about these errors? I would like to understand if the error is because of me before annoying you with useless posts when it's probably my fault. Thanks anyway for all the help you're giving, I will promote this project since it has great capabilities and it has a perfect support.

  • rojerrojer Dublin, Ireland

    -27136 is -0x6a00 hex and is MBEDTLS_ERR_SSL_BUFFER_TOO_SMALL.
    however, in our version of mbedTLS it is not supposed to happen, so i'd like to see the logs of the session.

  • @rojer said:
    -27136 is -0x6a00 hex and is MBEDTLS_ERR_SSL_BUFFER_TOO_SMALL.
    however, in our version of mbedTLS it is not supposed to happen, so i'd like to see the logs of the session.

    That's the really verbose logs for the problem, just tell me if I cut something interesting or it's all there.

    mg_do_connect        0x3fff0aa4 tcp://5.95.152.33:1883
    mg_lwip_if_connect_t 0x3fff0aa4 tcp_bind = 0
    mg_lwip_if_connect_t 0x3fff0aa4 tcp_connect 0x3fff2684 = 0
    mg_add_conn          0x3ffeed8c 0x3fff0aa4
    mg_call              0x3fff25fc after user flags=2050 rmbl=44 smbl=0
    mg_close_conn        0x3fff25fc 2050 1073684852
    mg_lwip_if_destroy_c 0x3fff25fc udp_remove 0x3fff23ac
    mg_call              0x3fff25fc user ev=5 ev_data=0x0 flags=2050 rmbl=44 smbl=0
    mg_resolve_async_eh  ev=5 user_data=0x0
    mg_call              0x3fff25fc after user flags=2050 rmbl=44 smbl=0
    mg_lwip_tcp_conn_cb  0x3fff0aa4 connect to 5.95.152.33:1883 = 0
    mg_lwip_tcp_write    0x3fff2684 tcp_write 137 = 0
    ssl_socket_send      0x3fff0aa4 137 -> 137
    ssl_socket_recv      5 - nothing to read
    mg_lwip_ssl_do_hs    0x3fff0aa4 24 0 -1
    mg_lwip_tcp_sent_cb  0x3fff0aa4 0x3fff2684 137
    mg_call              0x3fff0aa4 proto ev=4 ev_data=0x3ffffef0 flags=24 rmbl=0 smbl=40
    mg_call              0x3fff0aa4 after proto flags=24 rmbl=0 smbl=40
    mg_lwip_tcp_recv_cb  0x3fff0aa4 0x3fff2684 968 0
    ssl_socket_recv      5 968 968 968
    ssl_socket_recv      0x3fff0aa4 <- 5
    ssl_socket_recv      81 968 963 968
    ssl_socket_recv      0x3fff0aa4 <- 81
    ssl_socket_recv      5 968 882 968
    ssl_socket_recv      0x3fff0aa4 <- 5
    ssl_socket_recv      868 968 877 968
    ssl_socket_recv      0x3fff0aa4 <- 868
    ssl_socket_recv      5 968 9 968
    ssl_socket_recv      0x3fff0aa4 <- 5
    ssl_socket_recv      4 968 4 968
    ssl_socket_recv      0x3fff0aa4 <- 4
    mg_ssl_if_mbed_err   0x3fff0aa4 SSL error: -27136
    mg_lwip_ssl_do_hs    0x3fff0aa4 2072 0 -3
    mg_if_connect_cb     0x3fff0aa4 connect, err=-3
    mg_call              0x3fff0aa4 proto ev=2 ev_data=0x3ffffef0 flags=2064 rmbl=0 smbl=40
    mgos_mqtt_ev         MQTT Connect (0)
    mg_call              0x3fff0aa4 after proto flags=2064 rmbl=0 smbl=40
    mg_close_conn        0x3fff0aa4 2064 1073679148
    mg_lwip_if_destroy_c 0x3fff0aa4 tcp_close 0x3fff2684
    mg_call              0x3fff0aa4 proto ev=5 ev_data=0x0 flags=2064 rmbl=0 smbl=40
    mgos_mqtt_ev         MQTT Disconnect
    mqtt_global_reconnec MQTT connecting after 3616 ms
    
  • rojerrojer Dublin, Ireland

    that log doesn't have the mbedtls out, which is what i'm after. you forgot debug.mbedtls_level=4

  • @rojer said:
    that log doesn't have the mbedtls out, which is what i'm after. you forgot debug.mbedtls_level=4

    Ok that makes it really long, should I paste it here?

  • rojerrojer Dublin, Ireland

    yeah, that's more like it :) use pastebin or gist

  • rojerrojer Dublin, Ireland

    thank you. the server you're talking to does not support any of secure key exchange algorithms (DHE, ECDHE) - you might want to look into that, connections are less secure because of that. however, it should still work, and there was a bug in our implementation on mbedtls non-DH handshake. i fixed it and pushed out a new image in commit 87e868b.

  • @rojer said:
    thank you. the server you're talking to does not support any of secure key exchange algorithms (DHE, ECDHE) - you might want to look into that, connections are less secure because of that. however, it should still work, and there was a bug in our implementation on mbedtls non-DH handshake. i fixed it and pushed out a new image in commit 87e868b.

    Thanks, I'll flash the new firmware. I think I should also configure my mqtt broker to use proper ciphers.

  • rojerrojer Dublin, Ireland

    here are suggested cipher lists for openssl and mbedtls.

    also, standard port for MQTT+TLS is 8883, 1883 is traditionally non-TLS.

  • @rojer said:
    here are suggested cipher lists for openssl and mbedtls.

    also, standard port for MQTT+TLS is 8883, 1883 is traditionally non-TLS.

    Yes, I know. I did not change it because it was just for testing.
    Thanks I'll set the reccomended cipher list.

  • rojerrojer Dublin, Ireland

    cool. let me know if it works for you.

  • iH8c0ff33iH8c0ff33 Italy
    edited March 17

    @rojer said:
    cool. let me know if it works for you.

    Now I get this: https://gist.github.com/iH8c0ff33/3f135faa4a8802732a02264030c99ffc (updated)

    ciphers are:

    ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
    
  • rojerrojer Dublin, Ireland
    edited March 17

    looks like you used the modern settings but the server probably uses OpenSSL, which requires specifying DH params for DHE to be usable.
    better use "intermediate" settings (a bit below).

  • @rojer said:
    looks like you used the modern settings but the server probably uses OpenSSL, which requires specifying DH params for DHE to be usable.
    better use "intermediate" settings (a bit below).

    It now gives me an MBEDTLS_SSL_ALERT_MSG_UNKNOWN_CA error, I think it's a problem with my certificate

  • rojerrojer Dublin, Ireland

    yes, that's a certificate problem.

  • @rojer said:
    yes, that's a certificate problem.

    Is the tutorial on the docs correct for this? https://mongoose-os.com/docs/#/http/tls.md/

  • rojerrojer Dublin, Ireland

    yes, though device in this case is a server.
    try with openssl s_client, make sure you can successfully connect and verify (Verify return code: 0 (ok)) with -CAfile ca.crt

  • @rojer said:
    yes, though device in this case is a server.
    try with openssl s_client, make sure you can successfully connect and verify (Verify return code: 0 (ok)) with -CAfile ca.crt

    I don't know what cipher to use, it keeps telling me:

    12179:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s3_pkt.c:1145:SSL alert number 40
    12179:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.50.6/src/ssl/s23_lib.c:185:
    
  • rojerrojer Dublin, Ireland

    hm. i'm not really sure. cipher is negotiated, but then server drops connection with a fatal error for some reason. perhaps server logs have more information?
    it's hard to tell.

  • @rojer said:
    hm. i'm not really sure. cipher is negotiated, but then server drops connection with a fatal error for some reason. perhaps server logs have more information?
    it's hard to tell.

    Ok, problem in esp was due to capath option in mosquitto broker, probably I didn't generate the hashes correctly (using c_rehash on mac).

  • rojerrojer Dublin, Ireland

    packet capture seems to suggest that the server expects client to send a certificate and is unhappy when the client doesn't send one.

  • @rojer said:
    packet capture seems to suggest that the server expects client to send a certificate and is unhappy when the client doesn't send one.

    Oh yes... the client must send a certificate since i wanted to use mutual TLS authentication, but I just forgot about it when using openssl client on the mac

Sign In or Register to comment.