Angus Robertson

ICS does not put random files into that directory, it extracts the OpenSSL DLL files there, as explained in the readme9.txt file. Using a common directory, means all ICS applications share the same DLLs, unlike a couple of years ago where ICS applications typically had DLLs in multiple directories that were a pain to update for new versions. If you are not using OpenSSL, don't include that unit. If you are using OpenSSL and don't want that directory or prefer to specify your own directory, the readme explains ways to change it, but these are not extensively tested or used. You will then become responsible for distributing the OpenSSL DLLs, somewhere. Angus

None of the functions relate to the ICS library, never heard of WP Tools. Angus

I don't see any references in the Delphi WinApi. Windows unit to winsock2.h, except as a single comment. But there are lots of $HPPEMIT defines bringing in other files like wintrust.h, so I guess that is how winsock2 comes in. At least the problem is fixed, for now. Angus

Why did your project include winsock2.h? ICS applications should not need any winsock literals or types, others than those defined in OverbyteIcsTypes or other ICS units. Angus

Perhaps the July change forced C++ to rebuild header files for the ICS components? So your C++ TCP servers are now behaving correctly? As I've said before, my understanding of how all this works is zero. Perhaps old headers should be deleted when packages are built, maybe that is what experienced C++ developers do, but that information needs to be fed back to me, so I can fix the root cause. Angus

CF_ACCEPT and CF_REJECT were only added to ICS this July, I'll rename them to avoid any conflicts with C++ header files. But it probably brings us closer to the problem. If you include C header files that diverge from the Pascal conversions we use, a mix of Delphi RTL and ICS own versions, conflicts might arise, ideally flagged by the compiler as in this case. The RTL conversions are rarely updated for new APIs, the Win services unit is missing stuff added 20 years ago. And since ICS has to be compatible with Delphi 7, we need our own anyway. Angus

doSocketLocalClick has both a client and server, you only need the server code. But it's very similar to OverbyteIcsIpStrmLogTst so may not help you get closer to the real C++ problem. Angus

The Snippets sample has two simple examples of using logprotTcpServer mode. Did you the compiled sample work OK as a sample? No idea why it fail would from C++. Angus

Sorry, it's a reference not everyone can access. Angus

Every version I upload to SVN is stable, mostly anyway. I believe C++ is happy with Win32, Win64 maybe although the paths need a minor fix before the next release, Win64x is dead until RSB-503 is fixed, since C++ can not build packages that import other C++ packages. Angus

Found the problem with encryption and decryption, the RSA key is blank, possible because of an internal change in OpenSSL at some point and OpenSSL dies rather than giving a sensible error message. In function EncryptPublicRSA (and the other), change Ics_Ssl_EVP_PKEY_GetKey to EVP_PKEY_get1_RSA and it should work again. I'll fix it properly shortly with new tests in the JOSE sample, the E stands for encryption, but currently it does no encryption. I'll also update it for new APIs, but that won't be this week. Angus

If you read my message properly, you'll see I specifically mentioned RSA_public_encrypt as the functions ICS has used for 15 years. But it is deprecated and no longer loaded by the latest ICS. If you are going to make comments about the ICS library, which I understand you do not actually use, please do some minimal research first. Some of your comments are useful, many just confuse real ICS users. Angus

Have you added the define as requested and rebuilt all the packages so the old RSA functions are loaded? Check the pointer to RSA_public_encrypt is not nil. I am adding a better sample for the encryption stuff, but this is a busy week, end of the month stuff. Angus

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 did a lot of web server testing, looking at lots of logs, expect hacking of my public IPs from around the world, usually a few hundred different IPs weekly to my various servers. But a web server log today had some more interesting entries in the log: 192.168.1.31 > alexa-bath.magenta 192.168.1.34 > alexa-hall.magenta 192.168.1.36 > alexa-livingrm.magenta 192.168.1.37 > alexa-garden.magenta 192.168.1.39 > alexa-clock.magenta It seems some of my Amazon Echo units are also attempting SSL connections to my local web server, All the connections failed with an SSL handshake error, so not sure what URL the Echoes are looking at. Why would Echoes be looking for web servers? 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