Angus Robertson

The FTP server sample does all the logging properly,SslFtpServer1AnswerToClient. If you use IcsHosts in the latest server, you don't need an SslContext, all that is handled by the component. You set the certificates and an SSL security level and everything else is done automatically, including installing Let's Encrypt SSL certificates on a public server. This all works now, just no new sample yet. Angus

Improving your logging will help, you did not report the response or errors to commands received which is essential to error tracing with bad clients. The latest ICS in SVN has FTP server improvements to simplify SSL configuration in the same way as the web and proxy servers two years ago using IcsHosts, but there is no sample to copy yet, you need to look at the multi-web server sample and see how that configures listeners and at http://wiki.overbyte.eu/wiki/index.php/FAQ_Using_IcsHosts. Angus.

The ICS TFtpClient component has no directory handling, there are no formal standards for directory formats with the LIST command, you should use the MLSD command which is supported by all proper FTP servers and is standardised. Otherwise your application is responsible for the different directory listing formats when using TFtpClient. The ICS FTP server has even more efficient directory listing commands that handle sub-directories. But you are probably using the wrong component, 15 years ago I wrote a higher level ICS FTP client component which is now part of the main ICS distribution as TIcsFtpMulti which is described briefly at http://wiki.overbyte.eu/wiki/index.php/ICS_V8.60 with a new sample application OverbyteIcsXferTst.dpr. This handles all the directory listing stuff for you, at least for most known common FTP servers, there are always developers with strange implementations. and automates uploading and downloading whole directories and sub-directories of files. Angus

I have no idea how the openssl client tool works or why you are using it to test FTP, but 'AUTH C:\TEMP\TLS' is not a valid command, it should be AUTH TLS'. You have not shown what smartftp sent. Since the ICS sample works, you have missed something in your implementation but I can not debug your code. Angus

You don't log the IP address and port your server is using, although your client says port 5420 which is not an SSL FTP port, so the server does not attempt to negotiate SSL Using non standard ports for SSL requires extra code. V8.64 has a new Option ftpsAuthForceSsl that might do it simply. Not sure why you are testing an FTP servers with a non-FTP client that does not send the correct protocol. Angus

Not sure what you are trying to achieve, but I suggest you get the original ICS sample working first, then work out what is different with your project. The IcsLogger is for our development purposes, not debugging applications. Your code has lots of Logit commands, it's what those report that helps with debugging. Angus

So how do you suggest the password is entered for a background service application on a hosted server? Using a token from an authentication server is fine, but how do you get it? Angus

The code itself is probably OK if you copied it correctly. the issue is more likely all the settings and SSL/TLS certificates that are needed to make a secure server work, of which you show none. You could also have shown the protocol that you logged with all the errors. What SSL certificate are you using, and what intermediate, since you are setting SslCaFile. But servers don't use SslCAPath. Angus

Updated OpenSSL to 1.1.1f, this reverts a change in 1.1.1e that caused problems in some applications, but I don't believe ICS was effected. Angus

Encrypting a string or password is easy, harder is how you protect the key used for the encryption. Angus

The Internet Communications Suite (ICS) has a REST client component using Json and an application web server that sends whatever you give it. There is an ICS topic here. But no SOAP protocol as such, Json seems to have overtaken SOAP as much easier to use. ICS uses SuperObject for Json and reading XML, all Delphi 2007 compatible. Adding a SOAP wrapper to your XML objects should not be too hard. Angus

Servers use SSL/TLS certificates, not usually clients. Some errors on a certificate will prevent a server accepting an SSL/TLS connection, like an invalid private key. or cause the client problems like an expired certificate, but using self signed certificates is optional in the client, you decide whether to accept them or not. Angus

There is nothing wrong with Delphi 7 for applications today, if anything they are less bloated than later compilers where EXEs just get bigger with no extra functionality, All my ICS development and commercial applications are Delphi 2007, but then tested and made compatible with the latest and greatest of the day. Obviously cross platform development is another matter, but I don't do that. And lots of new language features and library functions, which ICS seems to manage without, or has implemented it's own versions to be compatible across all compilers D7 up. For client/server, also look at the new ICS component TIcsIpStrmLog and sample OverbyteIcsIpStmLogTst, the component can be configured as TCP/UDP/Client/Server with SSL/TLS, and mainly just sends lines of text back and forward, with two methods to connect/listen and send and one event to receive, you can build client/server apps very quickly. Angus

Websockets are designed for use in browsers, as a more efficient duplex mechanism than Ajax, for interactive content like spell check and auto completion as you type. Don't see any purpose outside the browser environment where simple TCP client/server has been used for 30 years. ICS has several sockets demos illustrating various client/server concepts. Angus

When I get feedback from people actually testing this initial implementation, I'll look at it again. Angus

I've updated the ICS distribution with the Websocket server implementation (HIXIE and HYBIE protocols) ported from phpws project, written by Stan Korotky <stasson@orc.ru> (eight years ago). This demo may be tested against the web page websocketclient.html which should be accessed from a server using the same IP address as this application, such as the ICS demo web server. The web page uses the WebSocket API with Javascript to send data to the server which is echoed back to the page. Ideally, websockets should be integrated into the ICS web server so they can be used on the same ports, the request that starts them up is HTTP, and I'll do that is anyone needs it. Please note this is an experimental server websocket implementation, that needs a lot more testing in case the protocol has changed in the last eight years. But it works with the latest version of Firefox as a client. A websockets client component is more work, but using most of the same code as the server since it's a duplex protocol. Angus

Websockets is a client server protocol, like HTTP, except once the connection is open duplex packets can be sent back and forward. So that packet stuff is common to client and server, and exists in the old code using ICS. The sample application is just a server and a JavaScript client web page. But creating an ICS client should not be hard, uses HTTP and the same functions as the server. Angus

I will do a quick evaluation of building that old code with the latest ICS over the next few days, but I won't do anything further unless someone else sets up a websockets test environment to test it all, that often takes as long as the coding, a server and client that the ICS components can be separately tested against. Angus

I added your change to my copy, not in SVN yet. Angus

Thanks, now fixed. Angus

Has anyone have a requirement to support IDNs in ICS, or have any punycode conversion functions to share with ICS? Someone just filled in a form on my web site with email domain with an accented character, first time I've seen that. My ICS email client can handle the MIME encoded email header for display, but is unable to reply to the email due to no IDN handling. I guess punycode conversion would fix that, but not sure which email header fields need which encoding. Or indeed whether we should try and handle IDN at a lower level in ICS. Guess I should register an accented domain name for testing. Angus

SVN and the overnight zip have been updated with a lot of changes so ICS supports International Domain Names for Applications (IDNA), i.e. using accents and Unicode characters in domain names. Domain names can only contain lowercase ASCII letters and numbers and a couple of symbols, so Unicode U-Labels (nodes in a domain) must be converted to A-Labels (Punycode ASCII) with an ACE (ASCII Compatible Encoding) prefix. So www.mâgsÿstést.eu becomes www.xn--mgsstst-pwa1e4l.eu and мособлеирц.рф becomes xn--90aijkdmaud0d.xn--p1ai. ICS mostly does the Unicode to A-Label conversion just before looking up an IP address for a domain name (in DnsLookup) and converts back from A-Label to Unicode when doing a reverse lookup (in ReverseDnsLookup). HTTP headers also contain A-Labels for the Host: header and the host part of URLs for proxy or relocation, but Unicode paths should be UrlEncoded by the application as now. Not looked at SMTP yet. The HTTP client and server, Ping, ICMP and DNS Query components all now support Unicode domain names, generally without application changes unless you want to display the A-Label name looked-up (PunycodeHost property). DNS Query does require application changes due to all methods and properties previously being AnsiString, now String. SSL/TLS now fully supports Unicode domain names, including displaying the Unicode version of the domain name (except for Subject and Issuer lines), and X509 automatic certificate ordering from Let's Encrypt fully supports Unicode domain names. Certificate files are saved with Unicode names, not A-Labels. For server testing I registered an eu domain which is live on one of my web sites at https://www.mâgsÿstést.eu/ and https://scrúdú.mâgsÿstést.eu/ which have ICS ordered SSL certificates. I do have DNS for Cyrillic and Far East domains, but this web server is built with Delphi 2007 so no full Unicode. Angus

That works OK, but redirects to an Alibaba site using western domains. I did try and register an accented test domain earlier with 123-Reg. My attempt for co.uk was declined but they registered a com OK except it is missing all the accented characters, won't accept xn-- names only Unicode. I'll try an eu instead, they must support accents. Angus

It seems those using non-English domains hedge their bets on their sites: Handshake done, error #0 - SSL Connected OK with TLSv1.2, cipher ECDHE-RSA-AES128-GCM-SHA256, key auth RSA, key exchange ECDH, encryption AESGCM(128), message auth AEAD ! VerifyResult: ok, Peer domain: мособлеирц.рф 3 Certificate(s) in the verify chain. #3 Issued to (CN): mosobleirc.ru Alt Domains (SAN): mosobleirc.ru, www.mosobleirc.ru, www.мособлеирц.рф, www.новый.мособлеирц.рф, мособлеирц.рф, новый.мособлеирц.рф Issued by (CN): Let's Encrypt Authority X3, (O): Let's Encrypt Expires: 11/05/2020 18:43:06, Signature: sha256WithRSAEncryption Does anyone have any working Far East web sites with IDNs, Chinese, Japanese, etc, those I've tried are all dead. Angus

Testing IDN with Windows 2019 DNS Server is proving problematic. I've been able to set-up A records for scrúdú and xn--scrd-srab, I would have expected DNS Manager to convert an accented domain to puncode ASCII but it actually stores scr\303\272d\303\272 in the file. It also stores 16-bit characters. I had to convert the punycode version manually. Old versions of ICS are actually able to lookup scrúdú.ftptest.co.uk without any punycode, so it seems windows usea the full 8-bits for DNS queries, Internally, we convert Unicode to ANSI before the query, so this will only work for code pages that match the DNS server. The real question is whether this DNS behaviour is by design or ignorance, perhaps internal networks are allow full 8-bit local names? I've Googled a lot, but can not find any design recommendations for IDN and Windows DNS Server, indeed no mentions atall. I was planning on changing ICS to automatically convert IDNs in Unicode to punycode ASCII, but this would break existing internal applications using 8-bit ANSI, so perhaps it needs to be optional, I'd prefer ASCII to become the default. Also, think the HTTP client and server need changing, because the Host: header needs to be punycode ASCII, probably Location: as well, but sure about sub directories, arguments are always character converted but does that apply to directories as well? Angus