MQTT [Decision to make.]

[Rolf Kalbermatter]

2 hours ago, ShaunR said:

Having played a bit, it doesn't look that straightforward.

The main idea, it seems, is that you create callbacks that allocate and free the CRYPTO_EX_DATA (which is required for the get and set) but if they are all set to NULL in CRYPTO_get_ex_new_index then you must use CRYPTO_EX_new which would have to be a global and there is no way to associate it with the SSL session.

This seems a lot harder than it should be so maybe I'm not seeing something.

It depends what you consider a lot harder. The basic function gets you a pointer sized slot to store whatever you want. If you manage allocation/deallocation of that data structure yourself you can get away with NULL callback parameters and only need the set and get functions to store the pointer and get it out back.

[ShaunR]

32 minutes ago, Rolf Kalbermatter said:

The basic function gets you a pointer sized slot to store whatever you want.

But you cannot reference it. You only get an index and the read and write require CRYPTO_EX_DATA

[ShaunR]

Hmm. Using the rbio or SSL_CTX isn't good enough. Repeats can occur 1 in 30-ish times.

Need to use a proper random....somehow.

[ShaunR]

I need something similar (session based variable that can be accessed by callbacks) for PSK too, it seems.

[ShaunR]

On 4/30/2023 at 2:21 PM, ShaunR said:

I need something similar (session based variable that can be accessed by callbacks) for PSK too, it seems.

I resorted to a global key->value lookup table. I feel dirty

[ShaunR]

On 5/2/2023 at 10:27 AM, ShaunR said:

I resorted to a global key->value lookup table. I feel dirty

That was a crap idea (was awfully complicated and memory bloaty) so I thought of something else....bear with me (it's easier done than said).

1. Generate an array of 264 cryptographically random bytes (global). Lets call it RNDARR.
2. Create an index (global UINT8). Lets call it IDX.

For the Generate callback:

1. if IDX = 0 initialise RNDARR with 264 new bytes. (Should get new bytes whenever we roll over as it's a UINT8)
2. Take 8 bytes of RNDARR at IDX in the array. 
3. Concatenate the 8 bytes with 8 bytes of the SSL session reference (Uint64 as bytes).
4. SHA1 Hash the 16 byte concatenated array (one of the fastest and only 20 bytes).
5. Append IDX to the SHA1 hash and present the 21 bytes as the cookie.
6. Increment IDX.

For the verify callback:

1. Take the last byte and use it as an index (lets call it IDX_V);
2. Take 8 bytes of RNDARR at IDX_V in the array. 
3. Concatenate the 8 bytes with 8 bytes of the SSL session reference (Uint64 as bytes).
4. SHA1 Hash the 16 byte array.
5. Compare the SHA1 hash with the cookie ignoring the last byte of the cookie.

So. that should mean we have a session dependent random number hash that is shared between callbacks. We get a unique hash on every client hello and It doesn't matter if the session is reused as the hash is relying on the 8 random bytes. (still convinced we don't need an HMAC but could do that instead of just a straight SHA1). Oh. And it's fast. Very fast.

There is one corner case when IDX rolls over and a hash is in-flight (created with the IDX=255). The array is populated with new random data so the 8 random bytes used for the hash are no longer available for verification. In practice, OpenSSL retries so it's not an issue but I will think about it more for a proper solution (if you have an idea, let me know).

Edited May 5, 2023 by ShaunR

[ShaunR]

16 hours ago, ShaunR said:

I will think about it more for a proper solution

OK. So I now have a 2D array (2x264 bytes).

if the IDX==0; the bytes are copied from the first row to the second and the random bytes in the first row are regenerated.

If the verification fails with the random bytes in the first row, it looks in the second row. If that fails then they are hammering the connection and don't deserve to be let in.

It means that every 255 client hello's we might have the overhead of an extra SHA1 hash to calculate. We can easily live with that. Any other ideas?

Edited May 6, 2023 by ShaunR

[ShaunR]

While I was faffing around with callbacks. I also implemented PSK.

[Rolf Kalbermatter]

On 5/19/2023 at 9:58 AM, ShaunR said:

While I was faffing around with callbacks. I also implemented PSK.

I'm an "Urgestein". For me PSK still mean Phase Shift Keying. 

[ShaunR]

18 hours ago, Rolf Kalbermatter said:

I'm an "Urgestein". For me PSK still mean Phase Shift Keying. 

So I guess you have a Ham Radio licence? It's exactly what my Ham Radio buddy said.

[Rolf Kalbermatter]

2 hours ago, ShaunR said:

So I guess you have a Ham Radio licence? It's exactly what my Ham Radio buddy said.

No, I didn't go through the whole procedure to obtain a license. But I did in a long ago past, during my education in electronics, experiment with building the hardware for a radio transceiver to do that. And also another one to receive the satellite radio signal from weather satellites (all at that time in analogue hardware, when 137MHz was considered still really HF and its signal propagation in a circuit sometimes more magic than anything else, not one of those easy SDR dongles 😁)

At some point I decided that HF was simply too hard to really work with and concentrated on mostly digital electronics and some audio electronics for PA.

Edited May 25, 2023 by Rolf Kalbermatter

[mhenz]

On 5/25/2023 at 12:45 PM, Rolf Kalbermatter said:

No, I didn't go through the whole procedure to obtain a license.

Shame on you 🙂

I did it and I'm still active, even not on the frequencies, but making videos, mounting antennas for the contest, painting the truck, climbing on the mobile tower ...

here it goes... 

 

[ShaunR]

On 5/27/2023 at 9:55 PM, mhenz said:

Shame on you 🙂

I did it and I'm still active, even not on the frequencies, but making videos, mounting antennas for the contest, painting the truck, climbing on the mobile tower ...

here it goes... 

 

I expect you could hear Marconi's original transmission with that set-up 

[ShaunR]

On 5/19/2023 at 8:58 AM, ShaunR said:

While I was faffing around with callbacks. I also implemented PSK.

 

4.4.0 released with DTLS and Pre-shared Key support. 

You can try Phase Shift Keying with it but don't contact me for support.

Edited June 16, 2023 by ShaunR

[ShaunR]

Well.

I got a rudimentary CoAP API working (over DTLS). It's a much better protocol than MQTT, IMHO.

I'm beginning to run out of protocols to implement. 

[JKSH]

16 hours ago, ShaunR said:

Well.

I got a rudimentary CoAP API working (over DTLS). It's a much better protocol than MQTT, IMHO.

I'm beginning to run out of protocols to implement. 

Congrats!

Fancy giving CBOR a go, if you're looking for something to do? It's designed to work well with CoAP. I'd imagine that the API can be modelled closely after Dr Powell's JSONtext.

[ShaunR]

51 minutes ago, JKSH said:

Congrats!

Fancy giving CBOR a go, if you're looking for something to do? It's designed to work well with CoAP. I'd imagine that the API can be modelled closely after Dr Powell's JSONtext.

CBOR isn't a protocol so wouldn't fit with ECL. While there are a couple of encoding schemes like Base58 and Base64, they are one-shot enc/dec functions and not really an API.

I think you already know what I'm going to say next. The request would fit better Dr Powell's JSONtext (as you suggest) since it' already has the API and just needs to swap out the parser.

[ShaunR]

Anyone interested in QUIC? I have a working client (OpenSSL doesn't support server-side ATM but will later this year).

I feel I need to clarify that when I say I have a working client, that's without HTTP3 (just the QUIC transport). That means the "Example SSL Data Client" and "Example SSL HTTP Client TCP" can use QUIC but things like "Example SSL HTTP Client GET" cannot (for now).

If you are interested, then now's the time to put in your use-cases, must haves and nice-to-haves.

I'm particularly interested in the use-cases as QUIC has the concept of multiplexed streams so may benefit from a complete API (similar to how the SSH API has channels) rather than just choosing between TLS/DTLS/QUIC as it now operates.

[ShaunR]

ECL Version 4.5.0 was released with CoAP support.

Next on the hit-list will be QUIC (when it's supported by OpenSSL properly).

I'm also thinking of opening up the Socket VI's as a public API so people can create their own custom protocols.