Jump to content

MQTT [Decision to make.]


ShaunR

Recommended Posts

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.

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

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

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 by ShaunR
Link to comment
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.:P

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 by ShaunR
Link to comment
  • 2 weeks later...
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 by Rolf Kalbermatter
Link to comment
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... 

 

Link to comment
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 :D

  • Haha 1
Link to comment
  • 3 weeks later...
  • 3 weeks later...
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. :P

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.

Link to comment
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.

Link to comment
  • 9 months later...

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.

  • Like 1
Link to comment
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.