[imanimanyara]

Closes the last open limitation of the SSH tunnel work: MySQL and MariaDB can now verify the server's real name through a tunnel.

Why it needed more than a config change

Through a TCP tunnel the client dials 127.0.0.1, and checking a certificate against that name fails. PostgreSQL avoids this with libpq's hostaddr: dial one address, verify another name (#47, proven live in #58). MySQL and SQL Server have no equivalent:

• mysqlnd builds a fresh TLS context for each connection and never sets peer_name, so PHP checks the certificate against the host string it dialled. No PDO attribute changes that.
• pdo_sqlsrv has no HostNameInCertificate key (connection options). Its TLS handshake also runs inside TDS PRELOGIN packets, which a relay can't take over with PHP streams.

The fix: a verifying TLS relay for MySQL

MySQL starts TLS inside its own protocol, so the TLS step can be done for the client. Tunnels\Relay\MysqlTlsRelay is a PHP worker process, started like the phpseclib pump, that sits in front of the tunnel:

1. It forwards the server's greeting with CLIENT_SSL cleared, so PDO never asks the relay for TLS.
2. It sends the SSLRequest itself, built from the client's handshake response, and starts TLS with peer_name set to the real host, the configured tls.ca, and tls.cert/tls.key for mutual TLS.
3. It renumbers the connection-phase packets across the extra SSLRequest. The client's packet 1 becomes the server's packet 2, and so on until OK or ERR. Both sides take turns, so caching_sha2's fast and full paths work.
4. After that it passes bytes through unchanged; commands number from 0 on both sides.

PDO talks to the relay in plaintext over a 0600 socket inside the tunnel's 0700 directory. Everything past the relay is TLS, and doctor measures the session as encrypted and required_ok. A certificate that doesn't match fails the login with a MySQL ERR naming why, e.g. TLS to db.example.com failed: … did not match.

When it applies: a MySQL-family server, tls.enabled and tls.verify on, and a target across the network from the SSH host. PostgreSQL keeps hostaddr. A socket or loopback target, unverified TLS, and TLS off need no relay.

Refactor

Tunnels\Support\WorkerProcess now holds the start-and-wait logic the phpseclib driver had: settings on stdin, a READY line, and exit on stdin EOF. It's a verbatim move, in its own commit. TlsRelayLauncher is a contract, so the registry tests open relayed tunnels without spawning a process.

Tests

• Unit: packet framing across split reads, the greeting edit, the SSLRequest, the renumbering, the end of the connection phase, the ERR packet. Plus the registry wiring: when the relay applies and when it doesn't, the client's TLS options stripped, a socket local end allowed only when relayed, and the tunnel closed if its relay can't start. Each wiring guard goes red when what it guards is removed.
• End to end over Unix sockets, in every pest job that can listen (required in CI): a fake TLS MySQL server with a certificate for mytls. One case logs in with a full-auth round trip and runs a command; the other has a certificate for another name refused, with the reason reaching the client.
• Live, live-ssh job: mytls, a MySQL 8.4 with require_secure_transport=ON and a certificate for its own name, which also answers to mytls-alias. With both drivers: the session is TLS and required_ok, a second session shares the relay, the alias is refused with the reason, and mysqldump backs up through it.

Locally: pest 854 passed (92 live or listening tests skipped), with laranail-pint --test, phpstan and rector clean. CHANGELOG [0.1.4] and older sections are byte-identical to the v0.1.4 tag.

SQL Server stays documented: tls.verify=false through a tunnel, with the reason above.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.