TLS handshake failure when downloading Far30b6666.x64.20260324.7z

[nylli]

Checklist

• I have searched for existing issues and found nothing relevant

Far Manager version

3

Is this the latest available version?

• I confirm that this is the latest available version (including nightly builds)

OS version

Windows

Other software

I am experiencing a TLS handshake failure when trying to download the file
https://farmanager.com/files/Far30b6666.x64.20260324.7z
from Windows 7 SP1 using Scoop (aria2 and its .NET fallback downloader).

My environment:

OS: Windows 7 SP1 x64, fully patched

TLS: SHA-2 support installed (KB4474419, KB4490628), TLS 1.2 enabled system-wide

.NET: 4.8 with SchUseStrongCrypto = 1 and SystemDefaultTlsVersions = 1 for CLR 2.0 and 4.x

WinHTTP DefaultSecureProtocols configured for TLS 1.1/1.2

Scoop command:

powershell
scoop install far

Output (excerpt):

text
Installing 'far' (3.0.6666) [64bit] from 'main' bucket
Starting download with aria2 ...
[SocketCore.cc:1019] errorCode=1 SSL/TLS handshake failure: Error: Received unexpected message
...
WARN Download failed! (Error 1) An unknown error occurred
WARN https://farmanager.com/files/Far30b6666.x64.20260324.7z
...
Fallback to default downloader ...
Запрос был прерван: Не удалось создать защищенный канал SSL/TLS.
URL https://farmanager.com/files/Far30b6666.x64.20260324.7z is not valid

Notes:

The same system successfully downloads many other Scoop packages over HTTPS (GitHub, various vendor sites, etc.), so the WinHTTP/Schannel/.NET TLS configuration appears to be correct.

The issue seems specific to the farmanager.com TLS configuration for this file/path and affects both aria2 (OpenSSL-based) and the .NET/WinHTTP fallback.

Could you please:

check the TLS configuration for https://farmanager.com/files/Far30b6666.x64.20260324.7z (and related vhost/frontend), especially for older Windows 7 TLS clients, and

confirm whether this is an intended change (e.g. dropping compatibility with Win7 TLS client hello/cipher suites) or a misconfiguration?

Any guidance or workaround from the server side would be appreciated. If you publish an alternative download endpoint or mirror, I can also relay that to Scoop maintainers so they can update their manifest.

Steps to reproduce

Steps to reproduce

Use a Windows 7 SP1 x64 system with the following TLS configuration:

All SHA‑2 and TLS 1.2 updates installed (e.g. KB4474419, KB4490628).

Schannel TLS 1.2 enabled, DefaultSecureProtocols configured for TLS 1.1/1.2 for WinHTTP.

.NET Framework 4.8 installed with SchUseStrongCrypto = 1 and SystemDefaultTlsVersions = 1 for both CLR 2.0 and 4.x.

Install Scoop and its default main bucket.

In PowerShell 5.1, run:

scoop install far

Observe the download attempt for:
https://farmanager.com/files/Far30b6666.x64.20260324.7z
first via aria2c, then via Scoop’s default .NET/WinHTTP downloader.

Both download paths fail during the TLS handshake:

aria2c reports:
SSL/TLS handshake failure: Error: Received unexpected message

the .NET/WinHTTP fallback reports:
The request was aborted: Could not create SSL/TLS secure channel.

On the same machine, other Scoop packages from different HTTPS hosts download successfully, indicating that the WinHTTP/Schannel/.NET TLS configuration is working in general.

Expected behavior

No response

Actual behavior

Actual behavior
When running scoop install far on this Windows 7 SP1 system, Scoop attempts to download
https://farmanager.com/files/Far30b6666.x64.20260324.7z
and the download consistently fails during the TLS handshake.

The aria2c downloader reports:
SSL/TLS handshake failure: Error: Received unexpected message

Scoop then falls back to its default .NET/WinHTTP downloader, which reports:
The request was aborted: Could not create SSL/TLS secure channel.
and prints:
URL https://farmanager.com/files/Far30b6666.x64.20260324.7z is not valid

Other Scoop packages from different HTTPS hosts download and install successfully on the same system, so the issue appears specific to the TLS handshake with farmanager.com for this file/path rather than a general TLS misconfiguration on the client side.
github
+1

[yegor-mialyk]

Could you please try on your PC:
aria2c --check-certificate=false https://farmanager.com/files/Far30b6666.x64.20260324.7z

Also you can try:
aria2c --min-tls-version=TLSv1.2 https://farmanager.com/files/Far30b6666.x64.20260324.7z

[nylli]

For additional context I ran some direct aria2c tests on the same Windows 7 SP1 system.

1. Far Manager URL (fails):

powershell
aria2c --min-tls-version=TLSv1.2 "https://farmanager.com/files/Far30b6666.x64.20260324.7z"

Result:

text
SSL/TLS handshake failure: Error: Получено непредвиденное сообщение или оно имеет неправильный формат. (80090326)

The same error occurs when using:

powershell
aria2c --check-certificate=false "https://farmanager.com/files/Far30b6666.x64.20260324.7z"

so this is not caused by certificate validation, but by a TLS protocol error during the handshake.

2. Ghostscript URL used by Scoop (works):
   From the ghostscript manifest in the Scoop main bucket:

json
"url": "https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs10071/gs10071w64.exe#/dl.7z"

I tested the same aria2c binary with:

powershell
aria2c --min-tls-version=TLSv1.2 "https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs10071/gs10071w64.exe"

and:

powershell
aria2c --check-certificate=false "https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs10071/gs10071w64.exe"

Both commands complete successfully, downloading the file via a redirect to https://release-assets.githubusercontent.com/..., with status:

text
(OK): download completed.

There are no TLS handshake errors in this case.

This shows that on this Windows 7 SP1 system the same aria2c client, with the same TLS options, can successfully establish HTTPS connections to other modern hosts (GitHub and its blob endpoint) and download Scoop packages. The TLS handshake failure (80090326) appears to be specific to the https://farmanager.com/files/Far30b6666.x64.20260324.7z endpoint, not to my aria2/WinHTTP/TLS configuration in general.

[yegor-mialyk]

It looks like farmanager.com does not support the older cipher suites required by Windows 7/8:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

These may have been disabled because they are not considered secure enough.

[nylli]

I also tested installing far with an HTTP proxy configured for Scoop:

scoop config proxy 127.0.0.1:9088
scoop install far

With this proxy enabled, other apps (e.g. totalcommander 11.57) download and install fine via aria2 and the fallback downloader. However, far still fails with the same TLS handshake error:

[SocketCore.cc:1019] errorCode=1 SSL/TLS handshake failure: Error: Получено непредвиденное сообщение ...
...
Запрос был прерван: Не удалось создать защищенный канал SSL/TLS.
URL https://farmanager.com/files/Far30b6666.x64.20260324.7z is not valid

This suggests the problem is not related to my ISP or route, but to TLS compatibility between farmanager.com and Win7 TLS clients (aria2 / .NET) for this specific endpoint.
(

[drweb86]

Может это и не связано с проблемой. Еще часто TLS соединения не установлены, когда отстают системные часы от общего времени более чем на 45 секунд. Такое можно проверить, загуглив время текущее. Я столкнулся с тем, что уже на двух ПК пришлось устанавливать сторонние утилиты синхронизации времени, поскольку встроенная в Windows не могла подключиться ни к одному из серверов времени.

[nylli]

Способ, что помог мне — автоматом не выглядит, но работает! Чтобы «заставить» установку far работать в консоли PowerShell — нужно применить при скачивании сторонний криптостек (OpenSSL), ему безразличны ограничения Windows 7.

В случае с сайтом Far Manager проблема кроется не в протоколе TLS 1.2, а в эллиптических кривых (ECDH Curves), они используются при обмене ключами. Некоторые хостинги (включая тот, что у farmanager.com) перешли на кривую X25519. Встроенный в Windows 7 Schannel её не поддерживает.

Решение следующее:

1. скачать установочный файл в кэш Scoop, но не средством самой Windows
2. и установить!

Вот подходящая команда Python, в неё нужно заложить путь до архива (виден, кстати, в неудачных попытках качать прямо через Scoop, например при использовании Aria2)

python -c "import urllib.request; urllib.request.urlretrieve('https://farmanager.com/files/Far30b6699.x64.20260614.7z', r'$env:USERPROFILE\scoop\cache\far#3.0.6699#875492e.7z')"

Как убедиться, что скачался именно архив, а не страница?

[System.BitConverter]::ToString((Get-Content "$env:USERPROFILE\scoop\cache\far#3.0.6699#875492e.7z" -Encoding Byte -TotalCount 4))

37-7A-BC-AF — это заголовок настоящего архива .7z

ВСЁ.

Можно смело запускать scoop install far

Важно. Автоматически через scoop update far софтина обновляться не будет. Но полуавтоматом можно (код ниже на новой-новой версии не проверял, ждём обновления far!)

Вы как обычно пишете scoop update (чтобы обновились сами базы/манифесты Scoop).
Запускаете этот скрипт.

1. Читаем локальный JSON-файл манифеста из локальной папки Scoop

$manifestPath = "$env:USERPROFILE\scoop\buckets\main\bucket\far.json"
$mod = Get-Content $manifestPath -Raw | ConvertFrom-Json

2. Вытаскиваем версию, URL и хэш (совместимо с PS 5.1)

$version = $mod.version
$url = $mod.architecture.'64bit'.url
$hashRaw = $mod.architecture.'64bit'.hash
$hashShort = ($hashRaw -split ':')[0].Substring(0,7)

3. Формируем правильное имя кэша и путь

$cache_name = "far#$version#$hashShort.7z"
$cache_path = "$env:USERPROFILE\scoop\cache$cache_name"

4. Качаем через Python и обновляем

Write-Host "Скачиваю Far Manager v$version..." -ForegroundColor Cyan
python -c "import urllib.request; urllib.request.urlretrieve('$url', r'$cache_path')"

Write-Host "Запускаю scoop update..." -ForegroundColor Green
scoop update far

Всё.