Assessment: Met
Justification
The project makes network connections via exactly two remote protocols: HTTPS and SFTP. Both are secure by enforcement, not by convention. Insecure protocols (plain HTTP, FTP, telnet, SSLv3, SSHv1) are categorically blocked — they cannot be enabled by configuration.

Evidence by protocol

1. HTTPS — enforced at the scheme-validation layer
   URLSecurityValidator._parse_and_validate_url() hard-rejects any scheme that is not https or sftp:

if parsed.scheme not in ['https', 'sftp']:
raise TrestleError(f'Only HTTPS or SFTP schemes are allowed for remote URLs, got: {parsed.scheme}')

This is called both at HTTPSFetcher.init() (cache.py:269) and again immediately before every fetch (cache.py:337) to close the DNS-rebinding TOCTOU window. There is no code path that makes an HTTP request — requests.get() (cache.py:355) is only reachable after scheme validation has already confirmed https://.

TLS version is delegated to the requests library's default, which uses the system OpenSSL/TLS stack. No downgrade to SSLv3/TLSv1.0/TLSv1.1 is configured; the verify parameter is set to True by default and overridden only by a user-supplied CA bundle path (cache.py:342–350), not disabled.

2. SFTP — SSH transport, insecure FTP explicitly rejected
   SFTPFetcher uses paramiko over SSH, inheriting SSHv2 (paramiko's only supported version). The client.load_system_host_keys() call (cache.py:482) enforces known-host verification.

Plain ftp: is explicitly caught and rejected by FetcherFactory.get_uri_type() (cache.py:578–579):

if uri_clean.startswith('ftp:'):
raise TrestleError(f'Invalid uri {uri} ftp is not supported. Use sftp instead.')

This error is unconditional — there is no configuration flag to re-enable FTP.

3. No plain HTTP, no telnet, no SSLv3, no SSHv1
   There is no http:// fetcher class, no telnet support, and no SSL version downgrade option anywhere in the codebase. The only two UriType enum values for remote access are SFTP and HTTPS (cache.py:554–556).

4. Documented as HTTPS/SFTP only
   The user-facing documentation explicitly lists only the two secure schemes:

"The provided href can be of form trestle://, https://, sftp://, or file:///."
— docs/tutorials/cli.md:547

Key source locations
File Relevance
trestle/core/remote/security.py:159–160 Hard scheme allowlist: only https and sftp permitted
trestle/core/remote/cache.py:578–579 Explicit ftp: rejection with error message directing to sftp
trestle/core/remote/cache.py:249–380 HTTPSFetcher — HTTPS-only, TLS cert verification on by default
trestle/core/remote/cache.py:405–539 SFTPFetcher — paramiko SSHv2, known-hosts enforced
trestle/core/remote/cache.py:334–337 Pre-fetch re-validation to prevent DNS-rebinding downgrade
docs/tutorials/cli.md:547–552 User documentation listing only https:// and sftp:// as remote schemes

Assessment: Met
Justification
The project uses TLS exclusively through the requests library for HTTPS fetching. TLS 1.2+ compliance is guaranteed by the combination of the requests version floor, its dependency chain, and the absence of any downgrade configuration in the project code.

How TLS is used
The sole TLS code path is HTTPSFetcher._do_fetch(), which calls requests.get() (cache.py:355–362):

response = requests.get(
self._url,
auth=auth,
verify=verify, # defaults to True (cert validation on)
timeout=30,
allow_redirects=False,
stream=...,
)

There is no ssl_context, ssl_version, or PROTOCOL_* override anywhere in the codebase — TLS negotiation is fully delegated to the requests/urllib3/OpenSSL stack.

Why that stack enforces TLS 1.2+

1. requests >= 2.32.2 (pyproject.toml:53)

requests 2.32.x depends on urllib3 >= 2.0. urllib3 2.0 dropped support for TLS 1.0 and TLS 1.1 entirely, setting SSLContext.minimum_version = TLSVersion.TLSv1_2 by default. This means TLS 1.2 is the minimum regardless of the system OpenSSL default.

2. cryptography >= 46.0.7 (pyproject.toml:38)

The cryptography 46.x series requires OpenSSL 1.1.1 or later and PyCA cryptography itself enforces TLS 1.2+ in all contexts it manages. This underpins the paramiko SSH transport as well.

3. paramiko == 5.0.0 (pyproject.toml:39)

Paramiko 5.x requires cryptography >= 3.3 and exclusively uses SSHv2 — there is no SSHv1 support in any supported paramiko release. The SFTP transport carries no TLS but does carry SSHv2, which is a listed approved protocol in the requirement.

4. Certificate verification on by default

verify=None in the requests.get() call means True (verify against the system CA bundle) unless the user has set REQUESTS_CA_BUNDLE or CURL_CA_BUNDLE to a valid path (cache.py:342–350). Setting those env vars to an invalid path raises a TrestleError — it is impossible to silently disable certificate verification.

Key source locations
File Relevance
pyproject.toml:53 requests>=2.32.2 — floor that pulls in urllib3>=2.0, which enforces TLS 1.2 minimum
pyproject.toml:38 cryptography>=46.0.7 — modern TLS stack, OpenSSL 1.1.1+ required
pyproject.toml:39 paramiko==5.0.0 — SSHv2 only, no SSHv1
trestle/core/remote/cache.py:334–380 Only TLS call site — no version override, cert verify on by default
trestle/core/remote/cache.py:340–350 CA bundle handling — invalid path raises error, cannot be used to disable TLS verification
trestle/core/remote/security.py:159–160 Scheme allowlist enforces https or sftp only — plain HTTP cannot reach the TLS layer at all
Key external references
urllib3 2.0 changelog (drops TLS <1.2): https://urllib3.readthedocs.io/en/stable/changelog.html
requests 2.32 release (urllib3 2.x dependency): https://github.com/psf/requests/releases/tag/v2.32.0
paramiko 5.x (SSHv2 only): https://www.paramiko.org/changelog.html