Angus Robertson

Clouldfare supports QUIC/HTTP/3 now, so it's not just Google and has published speed comparisons. https://blog.cloudflare.com/http-3-vs-http-2/

We don;t expect any problem updating ICS to support OpenSSL 3.0, but won't do it until the API is stable with the first beta release in a month or two.  OpenSSL plans QUIC/HTTP/3 for the release after 3.0, six to 12 months away.   Hard to know how hard it will be to implement in ICS, but we'll certainly have a go. 

Supporting LibreSSL in ICS is possible, the API interface library is designed to support different OpenSSL versions dynamically, the main issue is LibreSSL has 'improved' some of the OpenSSL APIs, many macros are now function calls instead (good thing),  So quite a lot of effort required to support LibreSSL with no obvious improvements to end user applications, 

OpenSSL plans to add QUIC but not until stardardisation is closer, Google has been pushing this for 10 years or so and no standard yet.  

https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/

Angus

Sorry about that, must have forgotten to upload the 1.0.2u files to the wiki server, done now.  However both 1.0.2t files come up as downloadable, not tried doing so. 

Angus

Windows Server 2008 R2 (aka Windows 7) support ceased earlier this year.  Windows Servers usually install very basic display drivers which is probably your problem.

Angus

Those old files have gone from my local SVN and the zip list, easy to find errors when building project groups, but not things never in the group.  But not in/out of the public SVN yet, lot of interconnected units still being tested.

Angus

Thanks, I did see an exception recently rebuilding stacks of root certificates to check chains, the quick solution was to avoid rebuilding stacks (which was also more efficient), but this is probably the root cause, will fix it. 

Angus

Thanks, will fix.

Angus

That is an obsolete sample never updated for modern compilers and not in the project group, but the files are still there for some reason, but not for much longer.

The current sample is OverbyteIcsSslWebServ,dpr.

Angus

Technically it's wrong, but the actual callback does not attempt to return anything, it's really just for logging. 

Angus

Thanks, will fix but that function is never used by ICS.

Angus

Thanks, that was added recently to SVN and is not yet used due to the warning 'not working yet ' will fix it. 

Angus

Which specific FTP command causes the floating point error?  Are you using a version of ICS from the last year?  

There have been issues in the distant past calculating the speed of downloads when they take zero seconds, but that is the only calculation that takes place.

Angus

As well as protecting the files from Google, it is good to see who is interested in my various components, mostly old since many are now incorporated into ICS.

Always nice for open source authors to know people are interested in our components, usually people only email when something does not work, far fewer thank us for our work. 

People say Delphi is dying, but the number of people looking for (free) components suggests otherwise. 

Angus

There are various protection alternatives, with varying annoyance levels, important issue is that Google can not scan the files. 

I support the concept of scanning, but not the blundering way Google does it without any human intervention possible for false positives, although it may have got better since I was targetted. 

Angus

18 months ago Google decided a zip on my web site contained a nasty and placed the page on it's blacklist used by other browsers as well to stop the page being displayed, not quite the same blocking as you, but probably the same false detection.  That page had about 30 zips, OpenSSL binaries, lots of Delphi source and a couple of EXE samples, Google never told me which file. 

The answer is to stop Google scanning your files so they can not find false nasties.  robots.txt might work, but they can ignore that, my solution was to move all the files onto a password protected web page that Google can not access, and that has worked.  It's a pain for users to request the password, but over 1,000 Delphi developers have done so already, hopefully not including anyone from Google. 

Angus

Both those screen shots are raw headers from the server, with no processing by ICS, so you have to believe what the server says.  The difference might be caused by the two minute gap between the two requests or responses from different caching servers.

Angus

Updated OpenSSL Windows binaries to 1.1.1g, this fixes a severe security vulnerability (denial of service) checking certificates with TLS/1.3, however the API that does this is not used by ICS so our applications are not effected.  https://www.openssl.org/news/secadv/20200421.txt
 

Angus

Your would simply add an extra line and condition in InitializeCtx after Meth := f_TLS_method; with Meth := f_DTLS_method; and set the versions later where TLS versions are set.  But there are probably other changes needed, our code was never tested with DTLS, it is also asyc (no blocking) in operation whereas most other SSL implementations are blocking. 

Angus

I integrated SuperObject into the ICS library two years ago since we support D7 to 10.3 with mostly the same code, I used v1.2 from https://github.com/hgourvest/superobject

 which is not the latest, later versions added time zone stuff which made it harder to stabilise and duplicated stuff we had already.  With a few tweaks and new compiler version checks, it works fine on all those versions of Delphi.  https://svn.overbyte.be/svn/ics/trunk/Source/OverbyteIcsSuperObject.pas

Angus

The point I was making is ICS already has functions to correctly initialise an SSL context which work, but you chose to do it yourself probably based on old OpenSSL code and not reflecting changes made in recent years.  When OpenSSL functions fail, there is excellent error tracing available, which might help you narrow down what is failing.  I would not worry about ciphers or callbacks until the basics of your application are working, you'll get OpenSSL errors telling you what is wrong.

Angus

If you are trying to add support for DTLS and PSK to ICS using existing code, I might be able to help, but not to write a totally new SSL implementation using APIs, ignoring all our tested high level code.  I have no experience of DTLS or PSK.

Angus

libeay32.dll and ssleay.dll were used by obsolete versions of OpenSSL, support ceased for those versions at the end of last year, so they have been removed from the ICS distribution.  But we;'ll leave support for the old version in ICS itself for nine more months, until OpenSSL 3.0 is released and supported by ICS, which will be libss1-3_0.dll, etc.

None of this relates to the PORT problem you reported.

Angus

The only web page kept up to date with downloads is: http://wiki.overbyte.eu/wiki/index.php/ICS_Download

Can not diagnose anything from a one line error, but this mostly happens when you are NAT routers with public and local IP addresses.  You should be using Passive mode to avoid this if you using TLS then passive mode should be forced, so not sure what you doing without more of the log.

Angus

Beware when updating OverbyteIcsSSLEAY.pas and OverbyteIcsLIBEAY.pas they change when I'm adding new features to ICS, make sure you use the latest from SVN last week, there are minor changes not in SVN yet. 

We replicates macros as functions in OverbyteIcsLIBEAY which is where you should add any more you need, look at function f_BIO_get_ssl which calls f_BIO_ctrl, you need to add f_BIO_set_conn_hostname similarly, etc.,

Use of macros is horrible for those of us not using C++, even Google has turned them all into APIs in BoringSSL.  The main problem is when OpenSSL convert macros back into APIs, this is never documented clearly so we keep using our macro function which then usually fails. 

Angus

You are probably using an old version of ICS, Samples\Delphi\SslInternet\OverbyteIcsXferTst.dpr was added about a year ago. OverbyteIcsFtpMultipartDownload is something totally different, no use to you.

Angus