Drill 15 — TLS transport

[sylvioCampos]

The lab runs everything in clear text. internal/session/logon.go sets 98=0 with a comment saying "FIX-level encryption is not used; transport security, when a venue requires it, is TLS underneath the session" — and then never shows that layer.

For a lab that goes to some trouble to keep the session password out of the logs, shipping only a plaintext transport is an odd place to stop. The password is masked in internal/fixlog and then sent over an unencrypted socket.

What the drill should teach

• EncryptMethod (98) being about FIX-level encryption, which nobody uses, and having nothing to do with whether your connection is secure — a genuinely common confusion
• TLS underneath the session: SocketUseSSL, certificate and key paths, CA verification
• Client certificate authentication, which some venues require in addition to the password in RawData
• What a certificate failure looks like from the client: a connection that closes with no FIX-level explanation at all, since the failure happens below the protocol. This is worth showing, because it is indistinguishable from a network problem unless you know to look.

Implementation sketch

• Generate a throwaway CA plus server and client certs at test setup — never commit key material, not even test keys
• A compose profile with TLS enabled, so the reader can diff it against the plaintext one
• Trace showing a successful handshake, and one showing a rejected certificate

quickfixgo supports this already: loadTLSConfig reads the settings, and Acceptor.SetTLSConfig exists for programmatic use.

Acceptance

• docs/drills/15-tls.md
• Certificates generated at runtime, never committed
• A test covering both a successful TLS session and a rejected certificate
• The 98=0 comment in internal/session/logon.go updated to point here