Warning in docs about MITM attacks for ssl

[sotpotatis]

Hi, I was reading the Micropython docs for the ssl module and came across this warning:

Some implementations of ssl module do NOT validate server certificates, which makes an SSL connection established prone to man-in-the-middle attacks.

CPython’s wrap_socket returns an SSLSocket object which has methods typical for sockets, such as send, recv, etc. MicroPython’s wrap_socket returns an
object more similar to CPython’s SSLObject which does not have these socket methods.

Of course I want to make sure that my implementation is not MITM-prone. Am I correct in my understanding that as long as a port supports cert_reqs, and I set cert_reqs=ssl.CERT_REQUIRED, I have a port which validates server certificates? (and thus I can "ignore" the warning)

My particular application is that I am using MQTT with X.509 certificates. The port I am using is the Pycom port. The client I am using is umqtt.robust. And from my understanding, umqtt passes its ssl_params to ussl.wrap_socket.

Thanks!

[shariltumin]

I don't think setting cert_reqs=ssl.CERT_REQUIRED is enough for you to get mode 2 TLS handshake; you need other parameters.

Please take a look at the "std_emqxsl.py" example script at https://github.com/shariltumin/ssl-tls-examples-micropython/tree/main/Mqtt.

If you are interested, you can find a short SSL/TLS tutorial at https://github.com/shariltumin/ssl-tls-examples-micropython.

[shariltumin]

I don't know if these are correct. Since you are using the "pycom-micropython-sigfox" distribution, I can't say. I don't even know what MCU you are using. You probably can't use the latest MicroPython because of the board you're working on.

[sotpotatis]

I don't know if these are correct. Since you are using the "pycom-micropython-sigfox" distribution, I can't say. I don't even know what MCU you are using. You probably can't use the latest MicroPython because of the board you're working on.

I understand, thanks either way. I am working with a company which has a bunch of Pycom boards stocked and a platform built around these, so switching isn't an option. Is it possible I can get some suggestions on tests I can perform to validate that cert_reqs has an impact? I have already done this test:

I did the following simple test: try to connect to external MQTT broker with ca_certs pointing to an empty file. If cert_reqs and server_hostname is not set, i.e. if I only set these parameters:

# Client keys
ssl_params["keyfile"] = PRIVKEY_FILE_LOCATION
ssl_params["certfile"] = CERT_FILE_LOCATION
# For client-server handshake
ssl_params["ca_certs"] = ROOT_CERT_FILE_LOCATION

then, even if ca_certs points to an empty file, the MQTT connection is accepted.
However, if I add

ssl_params["cert_reqs"] = ussl.CERT_REQUIRED
ssl_params["server_hostname"] = MQTT_HOST

to the bottom of this code

Then the SSL connection is not accepted if ROOT_CERT_FILE_LOCATION points to an empty file.

Aside from testing with an empty file, I also loaded up the test.mosquitto.org root certificate on the device. (I do not report telemetry to that server, so the certificate would be invalid). Without cert_reqs and server_hostname, umqtt still allows the connection, If I add the parameters, umqtt forbids it.

Doesn't that show that cert_reqs and server_hostname makes the device validate the server certificate?

[shariltumin]

Yes, that indicates that the CN (MQTT broker name) is checked against the certificate presented to the client during the TLS handshake, thus preventing MITM.

You can try setting these just for a test:

# For client-server handshake
ssl_params["ca_certs"] = ROOT_CERT_FILE_LOCATION
ssl_params["cert_reqs"] = ussl.CERT_REQUIRED
ssl_params["server_hostname"] = "This.willfail.com"

You should receive an invalid CN error or something similar. On my ESP32C3, I received the following:

ValueError:
The certificate Common Name (CN) does not match with the expected CN

One other thing: You may want to use ntptime.settime() to set the current time on your board, since we are dealing with certificates.

[sotpotatis]

You should receive an invalid CN error or something similar. On my ESP32C3, I received the following:

ValueError:
The certificate Common Name (CN) does not match with the expected CN

Not as descriptive, but there's indeed an error. OSError: -9984. It's just as nondescriptive as when I provide an invalid root cert, but whatever. It seems to work!

Regarding replay attacks; shouldn't be a problem since I am using MQTT over TLS, correct? Or is there any security parameter in the SSL config that I should invesitgate?

[shariltumin]

I don't know what your system architecture is. Are you using a private or cloud-based broker? MQTT is data agnostic; you can put anything in the payload. To add an extra layer of security, you can encrypt your payload using symmetric encryption with a shared secret key. This will provide end-to-end security between all your publishers and subscribers, regardless of what comes between them.

[andrewleech]

The pycom fork is long obsolete since the company closed. Even long before that they became very different to official micropython partially due to the way they changed the licence on their version.

You really cannot refer to any official docs when dealing with their port, they changed a lot of things; especially with networking. I would say it's almost definitely insecure by modern standards due to being unmaintained.

[sotpotatis]

I understand. I am working with a company which has a bunch of Pycom boards stocked and a platform built around these, so switching isn't an option without having to rebuild the hardware, sadly.

[Josverl]

Have they looked at creating a modern micropython board definition that fits the that hardware ?
That would get you in a much better place - but may also mean adaption of the software that runs on top
The silicon is still decent, and would not need to be discarded.

Bit the fact is that with no support, they are quite far up the proverbial smelly creek with no paddles whatsoever.
Unfortunately its time for someone to get their hands dirty.

[robert-hh]

Have they looked at creating a modern micropython board definition that fits the that hardware ?

Basically that's a ESP32 with PSRAM and 4MB flash plus the LTE modem. The ESP part is easy. The Generic ESP32 driver works at that board. One might add a pins,csv for a convenient naming of the pins, but that is the smaller problem. Using the LTE modem is more of a challenge. It uses an UART for the connection, and it is controlled via AT commands, so it could be used. But the documentation is sparse.