Angus Robertson

The server does have a certificate on that address, for pc21-tele.magenta, signed by the ICS intermediate and ICS root, but the Echo would not accept that. The server redirects from 70 to 443, but that would have been logged. Client certificates are not requested. Strange that six Echo devices all decided to go web server hunting within two hours, just once in a week, although I rarely look at the server logs unless debugging ICS. A pity SSL failed, would be very interesting to know what URL it was looking for. That server has another address on the public internet that currently has 615 hackers blocked, mostly accessing the server by IP address. Just added an ASN database to ICS, so the logs will shortly list ISP names as well as countries, I expect to be blocking some connected with China but running in the USA and other western countries. Angus

I just searched the six C++ project files, no -k. They were updated in May, in SVN and the overnight zip, not released yet. Angus

ARP does not involve opening an SSL connection to port 443, which fails due to a certificate error. 03:35:20 Client Hello: 192.168.1.101:443[id=365] from 192.168.1.34 (192.168.1.34) Server Name: , ALPN: http/1.1, Versions: TLSv1.2 Extensions, renegotiate, ext master secret, signature algos, next proto neg, app layer prot neg, EC point formats, elliptic curves 03:35:20 SSL Handshake Error: 192.168.1.34 - error:0A000418:SSL routines::tlsv1 alert unknown ca, State: error But it was just one night, no repeats since, very strange. Angus

I'll test PemTools to make sure RSA encryption is not broken in V9,5, the source code clearly states it needs a rewrite to work properly with OpenSSL 3, unless {$DEFINE OpenSSL_Deprecated} is used. Angus

Those ICS encryption functions were written 15 years ago by another developer, I've never used them not aware anyone else has either, so untested. But you may have hit a change in latest version, make sure OverbyteDefs.inc has {$DEFINE OpenSSL_Deprecated} Angus

I would do option 3, fork and translate for the non-Chinese market, and hope the developer realizes it's to his benefit to update both Chinese and English repositories. Angus

Adding the three functions to convert the ASN.1 signature to the simpler IEEE version would be good, but I need Delphi code for ICS. Angus

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