IndySecOpenSSL is now available on OPM

[TheMouseAUS]

Thanks for your reply, I might revisit this later. I only had a couple of days to get this working (the modem update changed the api to https) and i really didn't have the time to figure it out.
That coupled with the fact it was working perfectly up to a reboot of my PC was extremely frustrating. I was using your test example for other sites and it was working fine so I know the SSL part was working and more than likely something I was doing wrong.

[TheMouseAUS]

I have been using this as the IOHandler in IdTCPServer and IdTCPClient. When the client initially connects , the server logs "error:0A0001BB:SSL routines::bad record type" but after that everything works fine and checking with wireshark shows the traffic is correctly encryped with TLS 1.3. I have had a search but can find no definitive cause other than the server is possibly receiving a clear text packet to start with. Any ideas how to debug this as I dont want the log filling up with these messages. Otherwise its working perfectly.

FPC 3.2.2
x86_64-linux-qt6

these are my server settings :-
      IdTCPSSL := TIdSecServerIOHandlerSSLOpenSSL.Create(nil);
      IdTCPSSL.SSLOptions.CertFile:= configDir + 'server_cert.crt';
      IdTCPSSL.SSLOptions.KeyFile:= configDir + 'server_key.key';
      IdTCPSSL.SSLOptions.Method:= sslvTLSv1_3;
      IdTCPSSL.SSLOptions.SSLVersions:= [sslvTLSv1_2, sslvTLSv1_3];
      IdTCPSSL.SSLOptions.VerifyMode:= [];
      IdTCPSSL.SSLOptions.Mode:= sslmServer;
      IdTCPServer1.IOHandler := IdTCPSSL;

IdTCPServer.OnConnect
TIdSSLIOHandlerSocketBase(AContext.Connection.IOHandler).PassThrough := False;

[Thaddy]

I don't use Indy, but can it be just a Linefeed issue in the certificate(s)? It looks OK to me. (CRLF vs LF or CR)
I think you use self-signed certificates. If they are generated on a Linux machine this may cause this. A long shot, but check it. Otherwise contact Remy. He will probably read this at some point.

[LeP]

What  version of OpenSSL are you using ?
I saw that MWA Software  is using different "trunk" for every OpenSSL version.

Hope that they will unifiy all.

This release (2.0) updates the IndySecOpenSSL package to use the OpenSSL 3.0.20 with legacy support headers from the MWASoftware/PascalAPI4OpenSSL repository. Other branches of IndySecOpenSSL are also available using different OpenSSL release headers provided by the PascalAPI4OpenSSL. Support for the Windows Trusted Certificate store is now provided by the PascalAPI4OpenSSL instead of a unit within IndySecOpenSSL.

[tonyw]

What  version of OpenSSL are you using ?
I saw that MWA Software  is using different "trunk" for every OpenSSL version.

Hope that they will unifiy all.

This release (2.0) updates the IndySecOpenSSL package to use the OpenSSL 3.0.20 with legacy support headers from the MWASoftware/PascalAPI4OpenSSL repository. Other branches of IndySecOpenSSL are also available using different OpenSSL release headers provided by the PascalAPI4OpenSSL. Support for the Windows Trusted Certificate store is now provided by the PascalAPI4OpenSSL instead of a unit within IndySecOpenSSL.

Be careful. OpenSSL has undergone a fast evolution in recent years, tidying up the API and adding functionality. This is reflected in a rapid release of different versions. However, the core functionality appears to have stabilised after Release 3.0 with increasing version numbers largely reflecting increased functionality.

IndySecOpenSSL is intended to provide an add on package for Indy supporting later versions of OpenSSL (Indy itself stops at OpenSSL 1.0.2). The main branch of IndySecOpenSSL supports OpenSSL Releases 1.0.2, 1.1.1 and 3.0 onwards. It uses only OpenSSL core functionality and still appears to work with OpenSSL 4.0.

Separately, the PascalAPI4OpenSSL repository provides Pascal units transliterated from OpenSSL API headers and hence provides an API compatible with that version - but usually also with later versions depending on how seriously OpenSSL itself manages backwards compatibility.

IndySecOpenSSL provides a useful confidence test for the various versions of the PascalAPI4OpenSSL headers and separate branches of IndySecOpenSSL are provided with headers copied from the corresponding PascalAPI4OpenSSL versions. You may use them but there should be no value in using them unless you are paranoid about avoiding earlier versions of OpenSSL.

[tonyw]

I don't use Indy, but can it be just a Linefeed issue in the certificate(s)? It looks OK to me. (CRLF vs LF or CR)
I think you use self-signed certificates. If they are generated on a Linux machine this may cause this. A long shot, but check it. Otherwise contact Remy. He will probably read this at some point.

It is probably not worth bothering Remy. He is responsible for IndySockets but this issue is one for IndySecOpenSSL.

[LeP]

IndySecOpenSSL is intended to provide an add on package for Indy supporting later versions of OpenSSL (Indy itself stops at OpenSSL 1.0.2). The main branch of IndySecOpenSSL supports OpenSSL Releases 1.0.2, 1.1.1 and 3.0 onwards. It uses only OpenSSL core functionality and still appears to work with OpenSSL 4.0.
Separately, the PascalAPI4OpenSSL repository provides Pascal units transliterated from OpenSSL API headers and hence provides an API compatible with that version - but usually also with later versions depending on how seriously OpenSSL itself manages backwards compatibility.
IndySecOpenSSL provides a useful confidence test for the various versions of the PascalAPI4OpenSSL headers and separate branches of IndySecOpenSSL are provided with headers copied from the corresponding PascalAPI4OpenSSL versions. You may use them but there should be no value in using them unless you are paranoid about avoiding earlier versions of OpenSSL.

All this means that is better to use OpenSSL 3.0.20 (like suggested in your release comment) and the standard IndySecOpenSSL release ?

If yes, it's bettere that OP let a try in this way.

[tonyw]

This is an OpenSSL Error Message and it could be a bug in the OpenSSL library and has been reported by another user of OpenSSL (https://stackoverflow.com/questions/79153028/what-does-the-openssl-error-ssl-routinesbad-record-type-indicate). The TLS 1.3 handshake protocol is specific as to the order in which messages are sent and this error message can (e.g.) be caused by an error in the sequence or an application data record sent before handshake is complete. That is it could be either an OpenSSL bug or caused by incorrect use of the API.

The first thing to do when debugging is to add a status information callback and write your own log of what OpenSSL is telling you. This could shed light on the problem. For an example, look at the examples that come with IndySecOpenSSL. Both server and client examples include use of status call backs i.e. HandleServerStatusInfo and HandleClientStatusInfo and how to enable them.

I have been using this as the IOHandler in IdTCPServer and IdTCPClient. When the client initially connects , the server logs "error:0A0001BB:SSL routines::bad record type" but after that everything works fine and checking with wireshark shows the traffic is correctly encryped with TLS 1.3. I have had a search but can find no definitive cause other than the server is possibly receiving a clear text packet to start with. Any ideas how to debug this as I dont want the log filling up with these messages. Otherwise its working perfectly.

FPC 3.2.2
x86_64-linux-qt6

these are my server settings :-
      IdTCPSSL := TIdSecServerIOHandlerSSLOpenSSL.Create(nil);
      IdTCPSSL.SSLOptions.CertFile:= configDir + 'server_cert.crt';
      IdTCPSSL.SSLOptions.KeyFile:= configDir + 'server_key.key';
      IdTCPSSL.SSLOptions.Method:= sslvTLSv1_3;
      IdTCPSSL.SSLOptions.SSLVersions:= [sslvTLSv1_2, sslvTLSv1_3];
      IdTCPSSL.SSLOptions.VerifyMode:= [];
      IdTCPSSL.SSLOptions.Mode:= sslmServer;
      IdTCPServer1.IOHandler := IdTCPSSL;

IdTCPServer.OnConnect
TIdSSLIOHandlerSocketBase(AContext.Connection.IOHandler).PassThrough := False;

[tonyw]

All this means that is better to use OpenSSL 3.0.20 (like suggested in your release comment) and the standard IndySecOpenSSL release ?

If yes, it's bettere that OP let a try in this way.

At present, I would normally recommend using the main branch of IndySecOpenSSL and the most recent version of OpenSLL 3.0 available (3.0.21 has just been released but this does not require an IndySecOpenSSL upgrade). OpenSSL 3.0.x is a long term support release and only if you need the functionality provided by a later version is it currently worth upgrading to that later version.

If you look on the OpenSSL Downloads page (https://openssl-library.org/source/). EOL for 3.0.x is Sept 2026 which is getting quite close. Hence you should be thinking about deployment using the next LTS release (OpenSSL 3.5) which has an EOL of  April 2030. However, the OpenSSL functionality used by IndySecOpenSSL seems to behave identically for both OpenSSL 3.0 and 3.5. Hence, the main branch of IndySecOpenSSL should also work with OpenSSL 3.5.

Currently, your only reason to switch to the 3.5 branch of IndySecOpenSSL is that you want to enforce the use of OpenSSL 3.5 or later.

[LeP]

Currently, your only reason to switch to the 3.5 branch of IndySecOpenSSL is that you want to enforce the use of OpenSSL 3.5 or later.

Let's say that using 3.5 is practically mandatory given the "expiration" of the older versions in just over three months.
If you're providing a commercial product, obviously the application vision is long-term, so using a "long-term" LTS is essential.

I use TaurusTLS, but I also keep the sources updated with IndySecOpenSSL releases. It's been a while since I tested IndySecOpenSSL, however.

I was currently using OpenSSL version 4, but with this in mind, I rightly think I'll go back to 3.5.

[TheMouseAUS]

Hi Everyone, thanks for your input,

The Indy TCP Server with TLS is running on a Debian 13 box which when queried says the OpenSSL version is 3.5.6.

I will log the status call backs and see what light they may shed.

One thing I have just tested is my dev box has openssl v 3.6.2 and I havent seen that issue maybe it is a OpenSSL bug? In which case I am going to either have to upgrade Debians version or ignore the error?

[tonyw]

Currently, your only reason to switch to the 3.5 branch of IndySecOpenSSL is that you want to enforce the use of OpenSSL 3.5 or later.

Let's say that using 3.5 is practically mandatory given the "expiration" of the older versions in just over three months.
If you're providing a commercial product, obviously the application vision is long-term, so using a "long-term" LTS is essential.

I use TaurusTLS, but I also keep the sources updated with IndySecOpenSSL releases. It's been a while since I tested IndySecOpenSSL, however.

I was currently using OpenSSL version 4, but with this in mind, I rightly think I'll go back to 3.5.

It's not simply enough to use a LTS but you must also keep up-to-date with the most recent version of the OpenSSL library. When you check the release notes you will often find that each version fixes a number of security vulnerabilities.

Both IndySecOpenSSL and TaurusTLS share a common code base and are forks of my initial attempt to add OpenSSL 3 support to IndySockets. My intent is for IndySecOpenSSL to be a stable package adding https support for Indy, but limiting it to that. TaurusTLS seems to be aiming to additionally provide new functionality with, for example, OpenSSL 4. The PascalAPI4OpenSSL is available for the TaurusTLS team to help exploit the new functionality.

If you are going to go back to 3.5 then you should use 3.5.7 - released yesterday.

[tonyw]

Hi Everyone, thanks for your input,

The Indy TCP Server with TLS is running on a Debian 13 box which when queried says the OpenSSL version is 3.5.6.

I will log the status call backs and see what light they may shed.

One thing I have just tested is my dev box has openssl v 3.6.2 and I havent seen that issue maybe it is a OpenSSL bug? In which case I am going to either have to upgrade Debians version or ignore the error?

It could easily be an issue for OpenSSL given the error message has been reported elsewhere and IndySecOpenSSL relies on OpenSSL to establish communication and should not send any application data before ssl_connect has completed.

It will be interesting to see if the issue exists in the new OpenSSL 3.5.7.

The fun bit is always going to be keeping up-to-date with OpenSSL releases when you are tied into Debian versions. Hopefully, LTS versions of Debian rely on LTS versions of OpenSSL and issue updates to ensure they are up-to-date with their version of OpenSSL. If you are using an old stable version of Debian then you may need to upgrade to the latest stable version of Debian in order to ensure that your security patches are up-to-date. As always, it is a good idea to read release notes.

[LeP]

It's not simply enough to use a LTS but you must also keep up-to-date with the most recent version of the OpenSSL library. When you check the release notes you will often find that each version fixes a number of security vulnerabilities.
If you are going to go back to 3.5 then you should use 3.5.7 - released yesterday.

Of course, I always stay up-to-date with 3.5, 3.6 and 4. All old versions were dropped. Now I'll tested all new version with Taurus and after I'll try with IndySec.

[LeP]

I tried with OpenSSL 4.0.1, and 3.5.7 with TaurusTLS and IndySec (all updated).

All work good.

Only issue (not blocking) is that with IndySec tha SSLTEST reports this issse (while TaurusTLS is good), see images. The orange text ('Chain issues    Contains anchor') indicate the issue.

The code is exactly the same, except for use of "Context" derived for proper SSLContext and other assigned path.

P.S.: in the code there is (in the SSLOptions)

Code: Pascal  [Select][+][-]

1. UseSystemRootCertificateStore := false;