ShaunR

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

HTML Help files (manuals). Documentation is by far the greatest resource hog and we should be able to get away from programmer created VI descriptions. But I don't just mean documenting VI's though. I also mean generating API references, menu layouts, including external references and collating examples with descriptive comments about their function and what they demonstrate (from the code in the diagrams). A far better DLL importer. The one we have currently is next to useless for 80% of DLL's. I'd like an AI that can do what Rolf does . It should be able to import the DLL and create the VI's containing CLFN's for complex structures (e.g strings nested in structures), callbacks (he, he), events and error handling.

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

I was mesmerised by the cheesy forced grin of the guy demonstrating. Why does AI type so slowly? I agree it's looking promising. It's at the level if an intern but actually listens to you. Linear coding is never the final solution. I expect it was tuned for very specific requirements but I was more impressed with it reading the emails and specs and interpreting them in context. Would suffice for Unit Test cases and feasibility prototypes. Looking forward to getting my hands on it.

I was thinking more of not having to support (or make new releases) of my software anymore.

So I can retire in October?

It's all gone a bit quiet on the acquisition front. Was supposed to be concluded in early April but we're nearly in June. Trouble at t' mill?

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

It might be interesting to see what it comes up with for DLL interfacing to LabVIEW (PostLVUserEvent, passing structures to CLFN's etc). On second thoughts. Maybe we don't want to give it any ideas!

SNDCSDLM.dll depends on cvirte.dll. You can check it's deployed on the target machine with Dependency Walker. It's always deployed on development machines so maybe that's the issue. Something easy to check and eliminate.

Are any of the DLL's dependencies (if any) missing on the troublesome PC?

Me neither so I'm stealing that snippet.

What are you queueing? The image array or the U64 reference? (then reading the image in the consumer). You'll need to post your code so we can see what you are doing.

What do you mean "fails"? You are not consuming fast enough?

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?

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). Generate an array of 264 cryptographically random bytes (global). Lets call it RNDARR. Create an index (global UINT8). Lets call it IDX. For the Generate callback: if IDX = 0 initialise RNDARR with 264 new bytes. (Should get new bytes whenever we roll over as it's a UINT8) Take 8 bytes of RNDARR at IDX in the array. Concatenate the 8 bytes with 8 bytes of the SSL session reference (Uint64 as bytes). SHA1 Hash the 16 byte concatenated array (one of the fastest and only 20 bytes). Append IDX to the SHA1 hash and present the 21 bytes as the cookie. Increment IDX. For the verify callback: Take the last byte and use it as an index (lets call it IDX_V); Take 8 bytes of RNDARR at IDX_V in the array. Concatenate the 8 bytes with 8 bytes of the SSL session reference (Uint64 as bytes). SHA1 Hash the 16 byte array. 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).

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

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

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.

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

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.

Ooooh. I shall have a play.

It's not so much safety but I can have multiple connections (on say 127.0.0.1) and I don't want a global for all the connections. A random per callback would be OK but there is no way to tell the verifying callback what the generator chose (hence they have a global). It would have been preferably to be able to define the cookie to be compared so that the cookie generation could be done in the application rather than inside the callback. I'm not sure HMAC is all that useful here either (they use SHA1-HMAC by the way). Effectively we are just saying "is it mine? rather than "is it from who it says it is"? They are really relying on the port number from the same address (127.0.0.1, say) and that definitely isn't random and could be repeated. What I've done is just SHA1 the result of SSL_get_rbio(ssl) It's not "cryptographically" random but is probably random enough for this purpose (this is for DDOS rather than hiding secrets-similar reasoning that we use broken hashes for file integrity) and, unlike their global, it changes on each connect. I could do the whole HMAC thing using the SSL_get_rbio(ssl) as the random but I'm not sure it's really worth the overhead. Can you give an argument in favour?

OK. So seems it's to do with the security level. They are compiled in but disabled at run-time. SSL_CTX_set_security_level states: That last sentence isn't in 1.1.1. The default security level is 1. You have to set it to 0 to get the rest. Now we're cooking!

3.1.0. They weren't disabled in 1.1.1. That post seems to be specifically for Debian since it says "OpenSSL on Debian 10 is built with TLS 1.0 disabled.". You used "no-{tls1|tls1_1} to disable them at compile time. Using that compile option also removes the TLS1 methods from the binary as well. The TLS1 methods are available in the 3.1.0 binary.