ffmpeg: HTTPS broken on macOS — relies on deprecated SecureTransport which can't negotiate with modern CDNs

[tonimelisma]

Summary

After the ffmpeg slim-down (PR #261303, Jan 14 2026), ffmpeg on macOS uses only Apple's SecureTransport for TLS. SecureTransport is deprecated by Apple (since macOS 10.15 Catalina in 2019) and does not support TLS 1.3. This means ffmpeg installed via Homebrew cannot negotiate TLS with a growing number of modern CDNs and servers on macOS.

This is a fundamental regression: any homebrew-core formula that uses ffmpeg for HTTPS streaming is silently broken on macOS.

The problem

SecureTransport's TLS Client Hello is rejected by major CDNs including Akamai. The error manifests as:

ffmpeg -i https://example-akamai-cdn.com/stream.m3u8
...
error: -9806 (errSSLClosedAbort)

This is not a configuration issue — SecureTransport is structurally incapable of connecting to servers that require or prefer TLS 1.3. Apple's own TLS engineer Christopher Wood confirmed SecureTransport does not support TLS 1.3 (curl/curl#4524). Apple deprecated SecureTransport in favor of Network.framework, which ffmpeg does not use.

The CDN industry is actively moving toward TLS 1.3 requirements. This problem will only get worse over time.

Impact on homebrew-core

yle-dl is a formula in homebrew-core that depends on ffmpeg to download HLS streams over HTTPS. Since the slim-down, yle-dl is completely broken on macOS — it cannot download anything because ffmpeg can't establish TLS connections to Yle's Akamai CDN.

Any other homebrew-core formula (current or future) that relies on ffmpeg for HTTPS network access is affected.

I attempted to fix this by changing yle-dl's dependency to ffmpeg-full (#266431), but that correctly failed CI — homebrew-core policy prohibits depending on ffmpeg-full.

Proposed fix

Add gnutls (or openssl) back to the standard ffmpeg formula as a TLS backend.

This is not a new or unusual dependency:

• GnuTLS was in the ffmpeg formula for 7 years (Feb 2019 – Jan 2026) with no issues
• When it was added (PR ffmpeg: GNU Transport Layer Security library req. added. #36803), maintainer @fxcoudert noted it was "not a heavy dependency" (~35MB)
• ffmpeg currently has zero transitive gnutls dependencies, so adding it back adds only gnutls itself
• The ffmpeg formula's own header comment states: "Only add dependencies required for dependents in homebrew-core or INCREDIBLY widely used and light codecs" — TLS qualifies on both counts

TLS is not a niche codec or obscure feature. It is fundamental network infrastructure. Without a working TLS implementation, ffmpeg on macOS cannot fetch any HTTPS URL — which in 2026 means it effectively cannot access the network at all.

References

• ffmpeg slim-down: ffmpeg: slim down formula. #261303
• yle-dl breakage: A sudden break? aajanki/yle-dl#387
• My failed attempt (ffmpeg-full dep): yle-dl: depend on ffmpeg-full for GnuTLS support #266431
• SecureTransport doesn't support TLS 1.3: TLS 1.3 not working with Secure Transport curl/curl#4524
• SecureTransport deprecated: Apple documentation (macOS 10.15 release notes)
• GnuTLS originally added to ffmpeg: ffmpeg: GNU Transport Layer Security library req. added. #36803

[SMillerDev]

I don't see any network or crypto library removed in that PR. What exactly caused it to be limited to this deprecated framework?

[tonimelisma]

What was removed and why it matters:

PR #261303 removed gnutls as a dependency and --enable-gnutls from the configure flags. Here's the diff for the ffmpeg formula:

-  depends_on "gnutls"
...
-      --enable-gnutls

(These same lines were added to the new ffmpeg-full formula.)

What happens without GnuTLS on macOS:

ffmpeg's configure script has this behavior:

--disable-securetransport  disable Secure Transport, needed for TLS support
                           on OSX if openssl and gnutls are not used [autodetect]

And the conflict resolution:

securetransport_conflict="openssl gnutls libtls mbedtls"

So when gnutls (or openssl) is present, SecureTransport is automatically disabled in favor of the better library. When neither is present, ffmpeg auto-detects and enables SecureTransport on macOS because Security.framework is always available.

You can verify this by comparing the two formulas' build configurations:

# ffmpeg (no TLS library specified — auto-detects SecureTransport)
$ /opt/homebrew/opt/ffmpeg/bin/ffmpeg -version | grep configuration
configuration: ... --enable-gpl --enable-libsvtav1 ...
# (no --enable-gnutls, no --enable-openssl, no TLS flag at all)

# ffmpeg-full (has gnutls — SecureTransport auto-disabled)
$ /opt/homebrew/opt/ffmpeg-full/bin/ffmpeg -version | grep configuration
configuration: ... --enable-gnutls ...

Why SecureTransport is broken:

Apple deprecated SecureTransport in macOS 10.15 Catalina (2019) in favor of Network.framework, which ffmpeg does not use. Critically, SecureTransport does not support TLS 1.3 — confirmed by Apple's own TLS engineer in curl/curl#4524.

CDNs like Akamai are increasingly requiring or strongly preferring TLS 1.3. When ffmpeg tries to connect using SecureTransport's TLS 1.2 Client Hello, these servers reject the connection:

error: -9806 (errSSLClosedAbort)

This breaks any homebrew-core formula that uses ffmpeg for HTTPS streaming. For example, yle-dl (Finnish national broadcaster downloader, also in homebrew-core) is completely broken on macOS because all streams are served via Akamai's CDN.

History:

GnuTLS was in the ffmpeg formula for 7 years (PR #36803, Feb 2019 – Jan 2026) with no issues. When it was originally added, maintainer @fxcoudert noted it was "not a heavy dependency." Adding it back would restore working TLS on macOS without adding significant weight to the formula.

[fxcoudert]

OpenSSL is more common and lighter, I think we should enable that instead? Would it fix the issue encountered?

[tonimelisma]

Yes, OpenSSL would fix this — it supports TLS 1.3 and is already a common dependency in homebrew-core. ffmpeg's configure handles it the same way as GnuTLS:

securetransport_conflict="openssl gnutls libtls mbedtls"

So adding depends_on "openssl" and --enable-openssl to the formula would disable SecureTransport autodetection and give ffmpeg a working TLS backend on macOS.

I've also filed this upstream with FFmpeg as issue #21686 — SecureTransport is deprecated by Apple and lacks TLS 1.3, so relying on it as a silent fallback is a problem regardless of Homebrew.

Happy to open a PR for this if you'd like.

[MikeMcQuaid]

@tonimelisma Thanks for the detailed explanation here and apologies for the pain!

SecureTransport is deprecated by Apple and lacks TLS 1.3, so relying on it as a silent fallback is a problem regardless of Homebrew.

I agree with this so also appreciate you filing this upstream 🙇🏻