Angus Robertson

Ssllabs testing is wonderful, but only works on port 443. Angus

I can not reach https://chorus-pro.gouv.fr:5443/ with any of the four browsers on my PC either, so not really surprising that ICS can not reach it, a badly configured site. Perhaps it only supports an ancient SSL version no longer supported by anyone? The certificate is issued by someone that is not a trusted CA, but that is not the main issue. Their main site is fine, but it uses a different SSL certificate to the site on port 5443. Although ICS provides what looks like detailed SSL debug logging, this is virtually useless for SSL protocol investigations since none of the protocol packets are decoded. Wireshark does such decoding, but I really would not waste your time, just ask the web company what TLS protocols they support and which browsers. Angus

Sorry, had a quick look at the code, but can not see any reason why ParseReqHdr would truncate RequestParams, it just copies the line after the ?, need to debug it with real data and busy with end of month stuff this week. Angus

Not sure if Qualys check FTP errors, the logs just show dozens of login attempts with real and anonymous credentials, the fail is when they get access. Did not actually check any RFCs to see what to do, response 533 was already used for another command not allowed without TLS. Angus

Implicit TCP/IP connections were originally easier to implement since they did not requires changes to the protocol, often done with STunnel or similar for FTP, POP3, NNTP and SMTP. Once the protocols got updated with the STARTTLS command, some people tried to make the implicit ports obsolete, but this can be dangerous since end users don't always tick the use SSL/TLS box. There is new RFC 8314 'Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access' that again recommends implicit ports as being good practice. I have penetration testing by Qualys on my public server and they kept failing FTP port 21 for allowing clear text passwords, so I've just updated the ICS FTP server component to return '533 USER requires a secure connection' if the LOGIN command is sent before STARTTLS, and Qualys is now happy again. Angus

No ICS does not support SSH. Angus

Depending on your version of Delphi and project options, you may need to copy libcrypto-1_1.dll and libssl-1_1.dll from the samples directory into whatever directory the DCUs and EXE end up in, perhaps win32\debug or win32\release. All ICS SSL applications need access to libcrypto-1_1.dll and libssl-1_1.dll which are the latest versions of OpenSSL. In theory, these can be loaded from a directory in the common path or windows directory, but because there are so many different applications using OpenSSL, you can get lots of old DLL versions on your PC, often not compatible with each other. So generally it is safest to distribute the OpenSSL DLLs in the same directory as your application, so you have a reliable known version. By default, ICS applications will try and load from the local directory first before looking elsewhere, in your case it probably found an old OpenSSL DLL elsewhere on your PC, but was missing the other. You can force ICS to load the DLLs from a specific directory, to avoid such issues. Angus

The server now uses all three protocols, svn, http and https. The old server did not have https or rather we never set it up. I agree the svn protocol on port 3690 is very old, but we always supported it and many people will have scripts expecting to use svn (like me) rather than http, so it's still running. Angus

Now trying to get the zips updated automatically, seems someone has been messing with SVN commands in the past 12 years, which is why I never updated anything! Angus

ICS has a TMimeTypesList component that will read MIME types from the Windows registry, a supplied file mime.types or an internal list, application/vnd.ms-excel is common. This component is used by TSslHttpServer for files it opens. Angus

You should build the sample OverbyteIcsXferTst.dpr which is a a full SSL FTP client GUI, and uses TIcsFtpMulti which is much easier and quicker to use than TSslFtpclient. Angus

Beware ContentType: xls/xls is not commonly supported by browsers, but if it works... Angus

Sorry, seems the CreateSelfSignedCert function in OverbyteIcsSslX509Utils.pas got broken while being modernised, you need to add a missing line: MySslCertTools.ExpireDays := Days; { V8.64 got lost } and it will work properly again. Sorry, did not test that old function properly. The modern way to create a self signed certificate is using fields and buttons on the New Certificate Properties and Create Certificates tabs. First click 'Generate Key Pair', complete the various New Certificate Request Properties, previous tab, click 'Create Self Signed Cert from Properties', then at the bottom of the tab specify the file names for the formats you want to save, tick if you want the private key in the same file, then click the buttons to save in PEM, PKCS12, DER, etc. Finally on the List Certificate tab, click View Single File to double check the certificate is created properly. Those three tabs perform most of the common certificate functions of the OpenSSL command line tool. Angus

By old files, I meant long expired SSL certificates and job files that are no longer needed since ICS samples can now do everything they did. People try to use them and wonder why they don't work. Angus

Generally, the 'filename' is that of the page accessed with the GET request and is not returned in the response header. Again generally you should use the FilenameToContentType function to get the content type, which will return 'application/octet-stream' for an XLS file, which will cause the browser to bring up a dialogue box asking what to do with the file. If you want to display the file, there are Microsoft special headers to do so. Keep it simple until it works. Angus

Created PEM files how, which applications or which functions with what parameters. Generally public certificates can no longer be issued with an expiry beyond one year and certain ICS tools do limit that. Angus

As I said before, you don't need to use OpenSSL command line tools to create certificates, ICS has functions to do that. ICS has a lot of really old examples untested for 10 years, really should be removed. You should build the OverbyteIcsPemTool.dpr sample which has numerous facilities for creating, testing, converting and viewing X509 certificates, in various formats. Then open your certificate files which will immediately tell you whether ICS can read them, and display all the content. There are several Wiki FAQs on certificates I previously suggested you read that explain this all in detail. ICS with OpenSSL applications work perfectly on Vista and Windows 2008, two of my public servers are 2008, closed down last week due to Microsoft support ending after 12 years. I believe ICS applications still work on Windows XP but that has been out of support for years so no longer tested. The latest version 1.1.1 of OpenSSL no longer supports Windows XP, you need to use 1.0.2 or 1.1.0, both of which are now out of support so no security fixes. OpenSSL and Microsoft do offer paid support for XP and 1.0.2 for large organisations that really can not upgrade, but not for home users. Angus

The latest versions of TSslFtpServer and TSslWSocketServer do not require to use an SslContext, which was never well documented and is complicated to use. You should instead use IcsHosts to specify listeners, SSL properties and certificates, The IcsHosts SslCert property can be a file name or an string containing a PEM certificate and the component loads either automatically. This is all done in TSslWSocketServer.LoadOneCert if you really want to do it the old way. Angus

OverbyteIcsWebAppServerUploads,pas is a handler that accepts POSTed files. Angus

No TSimpleWebSrv does not currently support POST or PUT, if you look at the diagnostic log output you'll see 'Server Request Ignored'. It was designed as a light weight server for OAUTH2 and responding to well-known requests by certificate authorities. Adding complexity increases the size of any ICS REST applications that use those features. Angus

This list is possible additions to ICS, new protocols and functionality, none of which is guaranteed... Open to suggestions for other possible protocol additions or improvements. Personally, I'm unlikely to look at any of this stuff for several months, unless my company has an urgent need for something new. But if several other users are all looking for the same thing, I can help co-ordinating improvements. Protocol: STUN client and server Why: Session Traversal Utilities for NAT allows finding a public IP address while behind a NAT router, by contacting a STUN server. Used by public servers and clients that need to tell other applications how to contact them. Also some client protocols like a host name, like SMTP. Difficulty: low, simple protocol, easy to implement. Benefits: medium, saves configuring the IP manually. Protocol: RDAP Client Why: Registration Data Access Protocol is the replacement for the Whois protocol, using HTTPS REST and Json protocols. Both domains and IP addresses. Difficulty: low, simple protocol, easy to implement. Benefits: low, Whois is heavily censored now. Protocol: Roughtime client and server Why: replacement for NTP and SNTP network time protocols (from Google), with security. Difficulty: low, simple protocol. Benefits: low, usually get time from Windows. Protocol: HTTP/2 for HTTP client and server Why: More efficient version of HTTP/1.1, particularly for web pages with dozens of elements, compresses headers. Difficult: moderate, extra DLL, messy, lots to change. Benefits: low, ICS is rarely used to download complex web pages, perhaps more important for the HTTP server. Protocol: SASL for SMPT and POP3 clients Why: Simple Authorisation and Security Layer adds OAuth2 for SMTP and POP3, safer than clear authentication. Difficulty: low, OAuth2 already done. Benefits: high, where the email provider requires it. Protocol: OAuth1 for Twitter Why: Twitter uses OAuth1 rather than the easier and more recent OAuth2 almost everyone else uses. Difficulty: low, uses HMAC which is done already. Benefits: high, if you want to send tweets. Protocol: DNS over HTTPS (DOH) Why: secure DNS can not be intercepted and modified. Difficulty: ICS already has a TDnsQueryHttps component and sample, but causing it to be used by TWSocket and other components at low level could get messy and link in all the REST and Json units. Benefits: low, Microsoft is threatening to support DOH, probably only Windows 10/2019. Protocol: MQTT Why: MQ Telemetry Transport is used to send messages between devices, including IoT. Difficulty: ICS MQTT project n GutHub, needs integration. Benefits: high, if you need the protocol. Protocol: Websockets server Why: A full duplex version of HTTP often used for server push to dynamically update web pages. Difficulty: ICS websockets project in GutHub, needs update and integration. Benefits: high, if you need the protocol. Protocol: SChannel SSL/TLS Support Why: avoid distributing OpenSSL DLLs by using SSL/TLS protocol APIs built into Windows. Downside is Microsoft often takes years to support new protocols and often only in the latest operating systems Difficulty: high, needs to be done at the lowest levels, risks adding bugs for OpenSSL if both supported, need to replace a lot of OpenSSL encryption APIs with Windows APIs, and certificate APIs. Benefits: low, unless you really hate DLLs. Protocol: POP3 Server, IMAP Client and Server Why: because these are missing and we all use email. Difficulty: moderate, lot of new new code. Benefits: high, if you need them. Platform: Better C++ and MacOS Support Why: we don't do much testing on C++ and MacOS due to lack of volunteers to do this regularly. We lack samples for C++ and MacOS. Difficulty: high, users want someone else to do the work. Benefits: high, for C++ and MacOS users. Platform: Support for mobile apps and Linux Why: more platforms. Difficulty: very high, probably at least one man year effort, maybe more. Benefits: high, for mobile apps and Linux. Angus

Better use of multiple CPUs needs threads, which we generally try to avoid in ICS, but bring the ICS threaded socket server up to date is on my list, and perhaps allowing the web server to use it. I'm aware there are Windows APIs that offer performance improvements over our existing use of sockets, by sending and receiving entire files, but you then lose control over what is happening and SSL becomes problematic. But it's something we can look at. Angus

I've explained the limitations of the TCP implementation on Windows and how to get around it. If you don't want to listen to my experience, feel free to Google for better solutions then let us know when you have a proven working solution. Many of us have done all this before, often several times. Angus

I have already given my suggestions on how to solve very common issue. If you need new features you have the ICS source and you can update it yourself. Or listen to those of us that have been using it for 20 years. Angus

If you want to write your own internet library for your own requiremets, please feel free. Angus