Angus Robertson

Have a read at https://blog.yaakov.online/ecdsa-signatures-openssl-vs-net/ might give you a few clues. I'm not planning any signing changes in ICS at the moment, the next release is weeks overdue. Angus

Sha256 and Sha512 give different length digests, and HMAC is not using a private key. Private keys are not strings. Digests are binary, there are lots of ways of converting binary to text, variations of bas64, hex, etc. You need to work which version gives you the length you need. ASN is the binary format of X509 certificates, never heard of p1363. Signing gives a digest, nothing more. Angus

When you run the OverbyteIcsJoseTst sample I suggested, you are presented with a screen with two buttons, 'New Private Key', and 'Sign/Verify Data', with selections for key type and Signing Hash Algorithm. Selecting sensible values and clicking Sign, gives Private Key: ECDSA Key Encryption prime256v1 256 bits, 256 security bits Digest Type: SHA256 Digest Length (binary): 72 bytes IcsAsymSignDigestTB IcsBase64UrlEncodeTB: MEYCIQDkLYe2S1wPJGWqTWEy7S5fJRQuPFGN-0jypS1tBWlYoQIhANWHbVfbXUqeH7lzJfOUo0662ECYzrFLvwtu-xmy2hpV IcsAsymVerifyDigest: Passed Verify The screen even tells you what ICS function to use to sign the code, IcsAsymSignDigestTB which is in unit OverbyteIcsLIBEAY.pas. SigTB := IcsAsymSignDigestTB(DataTB, fPrivateKey.PrivateKey, SignDigest); Did you run this sample? Angus

As I said before, run the Jose sample. It allows you to create key pairs in several formats, then sign and check data in several ways, using various Jose formats. It does not do any encryption, which is rare for REST requests since they are encrypted with SSL/TLS. Angus

You encode with a private key, decode with a public key. StrEncRsa is not an ICS function I'm aware of, Signing does not encode data, it generates a signature digest of that data to check it's not corrupted. The ICS Jose unit contains many signing related functions, ditto the Jose sample. Angus

OpenSSL has issued a new release 3.5.2. In OpenSSL 3.5.2, the FIPS provider now performs a PCT on key import for RSA, EC and ECX. Windows binaries are available in SVN and the overnight zip file and separately from https://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp In addition to the three DLL files, the zips include compiled RES resource files that contain the same DLLs, text files and version information, see the RC file. The RES file may be linked into application EXE files and code then used to extract the DLLs from the resource to a temporary directory to avoid distributing them separately. ICS V9.1 and later optionally support loading the resource file. These OpenSSL versions are included with ICS V9.5 beta available from SVN and the overnight zip. ICS V9.5 beta now defaults to using OpenSSL 3.5.2, provided the new OverbyteIcsDefs.inc files is installed, or you undefine OpenSSL_35 and suppress an earlier version. Angus

I don't believe the logging code built into ICS will help you, I hardly use it myself and I do all ICS development. It looks pretty to have lots of information logged, but it was originally written for SSL development, but that has been stable for years. No idea how the CPP files are created, certainly not by me, but I know some ICS units contain {$HPPEMIT 'Symbol'} hints for those files added 10 years ago and not touched since. So perhaps there are hints missing, but not being a C++ developer, someone else will need to fix them. It's likely other C++ users have fixed units in the past, but rarely do they get shared. Since TIcsIpStrmLog seems to work OK, you could try adapting your application to use that, it mostly uses simple non-object parameters. The OverbyteIcsAppMonSrv unit is the best example of using it as a server to handle multiple clients at a time. Angus

SVN has new versions of the Websocket components and three samples, will be zipped overnight. IcsAppMonMan which contacts multiple Websocket servers is much better on startup with async connections. Angus

If the sample used to work on old versions of C++ and fails now, that would suggest something has changed in C++. Perhaps the way classes are declared has changed in C++, or the C++ header files are not created correctly. But not being a C++ developer, I'm afraid there is nothing more I can do. Diagnosing this needs help from someone that actually understands C++. If changes are needed to make ICS compatible with C++, I'll do them when someone tells me what to change. There seem to be a lot of C++ developers using ICS, maybe old versions, but it's at least two years since someone supplied a C++ fix to me. Angus

And yet the debugger shows some of the TWSocketClient properties, albeit not some I'd expect to be set. We know the SocketServer component is working correctly when used in other components. In your original code, I don't see any public client class declaration, our sample has: TTcpSrvClient = class(TWSocketClient) public RcvdLine : String; ConnectTime : TDateTime; end; This should be assigned to the server as WSocketServer1.ClientClass := TTcpSrvClient;, but your code has Server->ClientClass = __classid(TTestClient); where TTestClient is not defined publicly, only within another procedure. If you remove the line setting the ClientClasss, the Client parameter should then contain the correct values. Angus

Have you tried avoiding the cast for (Client : TWSocketClient) but accessing it directly, ie Client->GetPeerAddr())? That should get you past onClientConnect, but you still need a cast for onDataAvailable. Angus

I guess I don't understand your real problem. In which specific server event, which passed parameter is empty? In your TForm1::ClientDataAvailable, I don't see a client declared, but C++ is meaningless to me. In Delphi we'd declare Client, set it, then use it. Our sample has a clear 'Client = (TTcpSrvClient *)Sender;' which I understand. Angus

I didn't mean convert the TIcsIpStrmLogs sample, but put more events and logging into your own application. Or compare yourold C++ OverbyteIcsTcpSrv sample with the current Delphi version, which I updated and tested last week for a new TWSocketServer event. Until then, the only changes in the sample in 15 years were to add a new unit, Types. Angus

I can only suggest logging in the various server events, as the TIcsIpStrmLog component does so you can track the problem. It is unlikely to be with the ICS code. Angus

I'll look at your changes, but I rewrote the WSConnect function yesterday, adding an async option so it is no longer blocking, which was a serious anomaly for ICS. I've also changed the ICS server component not to send welcome or other data immediately, before the client has a chance to process the 101 command and switch to Websocket mode. Still testing all this. Angus

I meant test your original code or the ICS OverbyteIcsTcpSrv sample against the ComGen data stream. Angus

So now you just need to disconnect and reconnect a few times to make sure close session is working. Then test again with your original data source. I often find testing with alternate clients or servers shows up missed issues ComGen on mahpub5 is configured to just send a line every 10 seconds, but it could be 100 lines per second, or lots of short repeated sessions. It uses an array of TIcsIpStrmLog components, so does everything that component does. Angus

Good, so at least the ICS socket server component is behaving correctly, but does not explain why it fails when you use it at a lower level. Try connecting to non-SSL port :21502 on my server and see if your own code receives the same information? If not, you need more diagnostics to see what is happening. You are connecting to a free tool I wrote called ComGen which I've used extensively for testing ICS over 15 years. Angus

Should be done in SVN in a couple of days. Angus

I'm afraid the C++ samples have not been tested for 13 years. Please try running the sample OverbyteIcsSnippets, click Remote Socket Traffic, and data should start appearing from one of my servers. All the code is in a single function, doSocketRemoteClick that should be easy to convert to C++ If that fails, we do have a serious C++ problem. Angus

You can download prebuilt samples from https://wiki.overbyte.eu/wiki/index.php/ICS_Samples to avoid building them yourself. Sorry, no idea why your sample no longer works, but I don't write C++ so can not test it. I am very careful when updating ICS to make it remain compatible with older versions of Delphi, events and such like rarely change. Logging events is the only to debug your problem. Angus

Are you saying the same code runs OK in the older version of ICS, but not the new version? You don't say what your project is for, but you would be better starting with the TIcsIpStrmLog component that hides all the low level stuff from you, try running the pre-built OverbyteIcsIpStmLogTst sample, configuring it as a TCP Server, and start it. All the logging for diagnostics is built in. Angus

When opening a new connection to a remote host, ICS does a DNS lookup that may return several IP addresses, but is only able to connect to one of those addresses, usually the first in the list, unless changed in the onDnsLookup event. An application that wants to try to connect to another IP after failure needs to retry the connect, selecting another IP from DnsResultList. Handling this automatically has never been implemented in ICS. Windows has a Winsock2 API WSAConnectByList that takes a list of IP addresses and attempts to connect to each in turn until one succeeds, or a timeout is reached. Only catch is this is a blocking request, so the application will not process messages until it completes, which is rare in ICS. This could be added without much effort as an option in TWSocket to avoid applications needing to handle the failures and next IP attempts using code (how many of us bother?). Ideally, ICS would handle multiple attempts using events and timeouts, but this is rather more complex to write and test. Would connect to list of IPs be a feature you'd use? Angus

While opening multiple connections would be good, it is not trivial, which is the benefit of WSAConnectByList. ICS does support IPv6, the IP selected depends on the TSocketFamily specified, so may be the first IPv6 address if both are available. But it does not try others if the first fails, and my office IPv6 connection is currently down due to misconfiguration at my ISP (not their opinion). Currently, IPv6 testing is done on my two hosted servers, I really should setup a VPN to one of them. So it's important for applications to be able to select TSocketFamily, to prefer or disable IPv6 depending on circumstance. Angus

In general, ICS does use FreeAndNil for new code, if not nilled in code, the nil being the important part, since double Free without nil does cause an exception. Double free is common, due to the complex inheritance of many ICS components. But I simply don't have the time to clean up code written up to 25 years ago, unless I'm updating that code for other reasons. It all needs testing afterwards, and often correction when it then fails to compile on older versions of Delphi... Angus