TLS 1.3 support

[David Powell]

Hi,

I was looking at the source code for the file downloading, as I was curious if it was using WinINet, WinHttp, or something else for file downloading, as I know that WinINet based  downloading can be affected by a user's Internet Options settings for SSL/TLS (which has caused support cases for me in the past).

I found that it was using THttpClient, but in doing so I noticed that  Setup.DownloadFileFunc.pas (line 121) didn't include TLS 1.3 in the list of secure protocols, but it did include the insecure TLS 1.0 protocol. Perhaps this line should be updated to the following?

AHTTPClient.SecureProtocols := [THTTPSecureProtocol.TLS11, THTTPSecureProtocol.TLS12, THTTPSecureProtocol.TLS13];

Note that dropping TLS 1.0 would have an effect on Windows version support, as Windows Server 2012, Windows 7 Service Pack 1 (SP1), and Windows Server 2008 R2 SP1 didn't ship with TLS 1.1 and 1.2 support. However, perhaps it is time to drop support for these versions of Windows, given that they are all EOL?

Cheers,

David Powell

[Ethin Probst]

Honestly, it would probably be best if we dropped TLS 1.0 and 1.1 support. There is little reason to support either version of the protocol anymore, in my opinion. I would be all for only TLS 1.3 support but I am fine with having 1.2, but I don’t know anything that supports the 1.1 or 1.0 anymore, or rather, nothing which actively uses those versions.

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/df814a2e-fbd3-4a3f-a305-4906006ff1ban%40googlegroups.com.

[Martijn Laan]

Hi David,

Thanks for the suggestion, I will test the TLS 1.3 option. It wasn't available (in Delphi 10.3 Rio) when the download functionality was (in 6.1.0), but it is now, which I didn't realize before.

As for TLS 1.0: If you don't like TLS 1.0 you shouldn't host your files on a server which allows it? Excluding it on the client has no benefit?

Re old versions: Downloading from a old version of Windows which hasn't been updated with TLS1.1/1.2 doesnt work anyway, because it won't understand the SSL certificates.

Greetings,

Martijn

Op dinsdag 19 augustus 2025 om 10:55 schreef David Powell <david.i...@gmail.com>:

--

[David Powell]

Hi Martjin,

If the web server is properly configured, then it shouldn't permit any version of SSL, or TLS versions below 1.2 (which are insecure or deprecated). However, excluding support for old versions in the client prevents SSL/TLS downgrade attacks should the server not be configured correctly.

Cheers,

David

[Martijn Laan]

Hey,

Op dinsdag 19 augustus 2025 om 11:28 schreef David Powell <david.i...@gmail.com>:

If the web server is properly configured, then it shouldn't permit any version of SSL, or TLS versions below 1.2 (which are insecure or deprecated). However, excluding support for old versions in the client prevents SSL/TLS downgrade attacks should the server not be configured correctly.

Thanks for your explanation. I see where you’re coming from, but I’m still not convinced that enforcing minimum TLS versions on the client provides much real security. As I see it, verifying what’s downloaded (using [ISSigKeys] and issigverify ideally or else using SHA-256 hashes) is fundamentally more important and should always be required, regardless of the transport layer.  The new DownloadFiles.iss example script shows how to do this, and the CodeDownloadFiles.iss example has been updated for this as well. Client-side protocol restrictions seem more like a fallback for when proper verification is neglected, which ideally shouldn’t happen.

That said, I do understand the value of defense-in-depth and avoiding unnecessary risks, so I’ll give it some more thought and discuss with Jordan as well.

Greetings,

Martijn

[David Powell]

Hi Martijn,

Thanks for the extra info about the new example script, and to you both for all your work on Inno Setup over many years.

Cheers,

David

[Martijn Laan]

Hi,

Op 19-8-2025 om 19:10 schreef David Powell:

Thanks for the extra info about the new example script, and to you both for all your work on Inno Setup over many years.

You're welcome!

FYI, I added this for the next version:

• All download functionality now supports TLS 1.3 when available. On Windows 8 and later, support for TLS 1.0 and 1.1 has been disabled.

Successfully tested it with this 1.3-only URL: https://tls13.1d.pw/

I don't know when it will be released and it's also subject any comments Jordan might have.

Greetings,
Martijn

[David Powell]

Thanks Martijn,

Good call on setting the available TLS versions based on the Windows version.

Looking at the webpage below, TLS 1.3 should only be enabled for Windows 11 or higher or Windows Server 2022:

https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-

I guess it's because older versions of Windows may have experimental support for TLS 1.3.

Cheers,

David

[Martijn Laan]

Hi,

Op 20-8-2025 om 12:17 schreef David Powell:

Looking at the webpage below, TLS 1.3 should only be enabled for Windows 11 or higher or Windows Server 2022:

https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-

You mean because of the "Enabling TLS 1.3 on earlier versions of Windows is not a safe system configuration." note right?

Because of this note I initially implemented it to only activate on Windows Server 2022 or newer. But then I realized they mean that enabling TLS 1.3 for the system is unsafe on Windows 10. That's why it talks about 'system configuration'.

I'm just enabling for inside Inno Setup, and for in the entire system.

Delphi also has a built-in fallback mechanism when TLS 1.3 can't be enabled: it retries with TLS 1.3 disabled.

Greetings,
Martijn

[David Powell]

Hi,

On Wednesday, 20 August 2025 at 11:40:11 UTC+1 Martijn Laan wrote:

You mean because of the "Enabling TLS 1.3 on earlier versions of Windows is not a safe system configuration." note right?

Yes, I read this as suggesting that it's only safe on Windows 11 or newer and Windows Server 2022 or newer.

I know for WinHTTP (which I think THttpClient uses) that setting the secure protocol versions overrides the Windows' default ones for that connection, as I use this to enable TLS 1.2 support on Windows 7 machines in my own applications, as it is disabled by default even when the Windows update that adds support for TLS 1.1/1.2 has been installed.

As it happens, I think I recall seeing TLS 1.3 (experimental) listed in Internet Options on the Advanced tab, which applies to WinINet based applications like Internet Explorer, on my old Windows 10 machine (you can get to this Control Panel app by opening windows settings and searching for 'Internet Options').

Cheers,

David

[Martijn Laan]

Op 19-8-2025 om 19:52 schreef 'Martijn Laan' via innosetup:

• All download functionality now supports TLS 1.3 when available. On Windows 8 and later, support for TLS 1.0 and 1.1 has been disabled.

Update, we changed it: TLS 1.0 and 1.1 will be disabled on all versions of Windows.

Greetings,
Martijn

[David Powell]

Thanks Martijn (and Jordan),

That's probably the best option, as Windows 7 and Windows Server 2008 R2, Windows Server 2012 installs will have KB3140245 TLS 1.2 update installed (released 14/06/2016), if they are up to date with their Windows updates.

Cheers,

David