Adds TLS-PSK support to Python SSL context - #14396

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.43%. Comparing base (55e75c4) to head (3ecb741).
⚠️ Report is 2264 commits behind head on master.

@@           Coverage Diff           @@
##           master   #14396   +/-   ##
=======================================
  Coverage   98.42%   98.43%           
=======================================
  Files         161      161           
  Lines       21253    21278   +25     
=======================================
+ Hits        20919    20944   +25     
  Misses        334      334           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64: +3080 +0.368% standard[incl +224(data) +32(bss)]
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2: +1464 +0.167% RPI_PICO_W[incl +24(bss)]
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS

@aminop1us since this would be a new feature, could you add a test (see tests/multi_net for examples) so the code coverage can pass, thanks 👍🏼

@aminop1us since this would be a new feature, could you add a test (see tests/multi_net for examples) so the code coverage can pass, thanks 👍🏼

thank for your suggestion, I will add a new test case.

@aminop1us since this would be a new feature, could you add a test (see tests/multi_net for examples) so the code coverage can pass, thanks 👍🏼

I added the test and updated the pull request

please let me know if there is anything else I can do

Thank you for the contribution, this is a good feature that's definitely very useful in embedded contexts.

Please see a prior attempt at this in #5544.

I did not realise that CPython had very recently added support for PSK. That's great... although we did move to a custom tls module so we could implement things like PSK and DTLS (see #10062) without having to wait for CPython do it.

So, since we have our own tls module, we can implement PSK in the best (minimal) way for embedded, ie we don't need to follow CPython's API. Then the ssl wrapper code in micropython-lib can be updated to support the CPython compatible PSK API (which I think requires calling ssl_context.set_ciphers("PSK")).

@aminop1us for your use case, do you find it beneficial for your MicroPython code to use PSK in a CPython compatible way, ie with this callback function? Or would you be just as happy using a custom MicroPython tls PSK API? Eg maybe instead of a callback function one just passes in a dictionary mapping the identity to the key, like ssl_context.psk_keys = my_dict. In your use case is a dict of identity/key pairs good enough, or do you use the full power of a callback?

For reference, this is the PR that added PSK support in CPython: python/cpython#103181

Thank you for the contribution, this is a good feature that's definitely very useful in embedded contexts.

Please see a prior attempt at this in #5544.

I did not realise that CPython had very recently added support for PSK. That's great... although we did move to a custom tls module so we could implement things like PSK and DTLS (see #10062) without having to wait for CPython do it.

So, since we have our own tls module, we can implement PSK in the best (minimal) way for embedded, ie we don't need to follow CPython's API. Then the ssl wrapper code in micropython-lib can be updated to support the CPython compatible PSK API (which I think requires calling ssl_context.set_ciphers("PSK")).

@aminop1us for your use case, do you find it beneficial for your MicroPython code to use PSK in a CPython compatible way, ie with this callback function? Or would you be just as happy using a custom MicroPython tls PSK API? Eg maybe instead of a callback function one just passes in a dictionary mapping the identity to the key, like ssl_context.psk_keys = my_dict. In your use case is a dict of identity/key pairs good enough, or do you use the full power of a callback?

As long as it is possible for us to write a wrapper to be CPython compatible, we are fine with that.

Hey @aminop1us and @dpgeorge I was just inquiring what the status here was and if you wanted anyone to jump in to finish this task out?

Having a PSK would micropython to fully support DTLS which we merged the main work for earlier this year in #15764.

Our project previously implemented a similiar version of this in the way that @dpgeorge described above I think spread through these commits:

• Ribbit-Network@8dbcda5
• Ribbit-Network@f1d2b81
• Ribbit-Network@88ae0b1

If it is useful for someone help complete this, I'm happy to jump in or submit our work in a new PR or whatever is most useful to see this closed out.

Thanks all!

I am assuming the original author does not intend to finish this, so I'll try to pick it up.

I have a draft of the approach suggested by @dpgeorge above here: #17074.

If that looks in line with your suggested approach, I'm happy to clean up the PR (docs, squash commits) so it's ready for merge.

Hey @dpgeorge ! Just wondering if you had a chance to look at the progress in #17074 and if that seems in line with the direction you would like to head?

Just to catch up where TLS-PSK is at between this PR and #17074, as it would be great to have this support in MicroPython:

On balance we either need the CPython-style callbacks built-in, or (as @dpgeorge and @aminop1us have commented) we need a design which can implement a CPython compatibility layer on top of whatever we have in MicroPython. This PR has CPython-style callbacks already and looks to be pretty lightweight, so that actually seems pretty good to me.

One thing I'm unsure about: do we also need a version of CPython's ctx.set_ciphers('PSK') that calls through to mbedtls_ssl_conf_ciphersuites() and limits the accepted ciphers to only PSK ones (as implemented in #17074)? It's unclear to me if calling mbedtls_ssl_conf_psk() enforces a PSK requirement on both client and server, or if this leaves a gap where a connection using a non-PSK suite could be accepted (therefore breaking the expectation of mutual auth). The mbedTLS ssl_client2.c and ssl_server2.c examples don't seem to do anything special unless the user also passes a ciphersuite on the command line, but that's example code not a production application. 🤷

Related point, it's fantastic this PR has a test (thank you) but probably we also need some basic "adversarial" testing for cases like the above (i.e. that a PSK-enabled client won't connect to a non-PSK server, and vice versa).

As no one is actively working on this I'm going to take it off the next milestone, but TLS-PSK support would be very welcome if someone does want to pick it up and submit a new PR which takes the above into consideration.

To add to @projectgus 's comments above, I think it is very useful to allow a callback for the server side (at the very least so we can implement CPython compatible set_psk_server_callback() in ssl.py).

This PR already implements a server callback, but if we want to do that in a more MicroPython-y way, as mentioned in #14396 (comment), we could have an attribute to which you store a dictionary that maps identity string to the required PSK:

ssl_ctx.server_psk_keys = dict

Allowing this also allows callbacks to user code: the user could pass in an object that implements __getitem__ like this:

class PSKDict:
    def __getitem__(self, identity_str):
        # called when mbedTLS needs a PSK for the given identity_str
        return ...

ssl_ctx.server_psk_keys = PSKDict()

This approach is relatively minimal, allows the simple case of supplying a fixed key (or keys per client), but also allows a callback if needed.

Note: I haven't tested this idea and maybe there are some caveats that make it unworkable.

Closing in favour of #17074.