net: enable extended master secret

[sam-golioth]

Extended Master Secret is a DTLS extension that ensures the Master Secret is tied to the handshake parameters and is used to prevent certain Man in the Middle attacks.

Confirmed with wireshark that the extension is present from Client and Server during handshake and communication with Golioth proceeds as normal.

Closes golioth/firmware-issue-tracker#224

[github-actions]

Visit the preview URL for this PR (updated for commit 2ab7986):

https://golioth-zephyr-sdk-doxygen-dev--pr432-enable-extended-gyb3h862.web.app

_{(expires Wed, 18 Oct 2023 19:49:03 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: a389eefadf4b4b68a539327b3459dd66c142cf49}

[mniestroj]

Is this Extended Master Secret enforced by the client? What happens if server respond without this option, would client drop the connection as being potential man-in-the-middle attack?

[sam-golioth]

Is this Extended Master Secret enforced by the client? What happens if server respond without this option, would client drop the connection as being potential man-in-the-middle attack?

Hmm, that's a good question. I did some searching around and I'm not sure. I hope it drops it, otherwise it's not a very good protection, but I can't confirm.

[mniestroj]

Is this Extended Master Secret enforced by the client? What happens if server respond without this option, would client drop the connection as being potential man-in-the-middle attack?

Hmm, that's a good question. I did some searching around and I'm not sure. I hope it drops it, otherwise it's not a very good protection, but I can't confirm.

The reason I ask is that I probably (90% sure) was about to enable this feature in the past, haven't done it because it was not enforced anyway, i.e. not improving security because of man-in-the-middle attack. I think I tested it with mbedTLS or aiocoap, but as I say, I am not sure about it right now. Maybe we had something on Jira related to that...

[hasheddan]

I verified that mbedTLS does not require that the server (in this case) support the extended master secret extension. However, turning on this extension earlier rather than later starts us on the path of being able to require it at the server in the future (even if it is not required at the client). On a parallel track, we can work on seeing whether mbedTLS is amenable to adding support for requiring extended master secret.

Note that if we eventually got to the point where we could turn on required extended master secret at the server, the fact that it was optional at the client would not be as consequential (i.e. we are still guarding against the triple handshake attack). However, it would be nice if we could enforce this at the client and not require at the server in order to maintain backwards compatibility.

[mniestroj]

So far we have all the required features pointed out here with select ... statement. MBEDTLS_SSL_EXTENDED_MASTER_SECRET is not required. So we should either:

• make it explicit in commit message why it is required from now on (e.g. by wanting to change Golioth backend policy and make it a requirement at some point),
• use imply ... instead of select ... to allow customers to disable it.

[sam-golioth]

I've updated the commit message to indicate that Golioth may enforce the use of Extended Master Secret on the server side in the future.