STARTTLS
STARTTLS upgrades an in-flight RESP2 connection from plaintext to TLS 1.3
without a reconnect. It is available only when the RESP listener runs in
STARTTLS mode (--resp-starttls); under implicit TLS the command is not
registered and replies -ERR unknown command.
./bin/tellstone \ --tls-cert /path/to/server.crt \ --tls-key /path/to/server.key \ --resp-starttls--resp-starttls requires --tls-cert and --tls-key — the server refuses
to start without them. The flag affects only the RESP listener; the binary
protocol is always implicit TLS. See
Security for the full TLS
picture.
Syntax
Section titled “Syntax”STARTTLSNo arguments. Issuing the command does not encrypt anything by itself — the
server replies +OK and the client then performs a standard TLS 1.3
handshake on the same connection:
> STARTTLS+OK[Client → Server: TLS 1.3 ClientHello]When to upgrade
Section titled “When to upgrade”STARTTLS precedes the authentication gate, so AUTH credentials are sent
only after the connection is encrypted — never in plaintext. The upgrade also
honours certificate rotation: the handshake uses the latest rotated
certificate at upgrade time.
Pipelining is rejected
Section titled “Pipelining is rejected”For safety, STARTTLS must arrive alone in its buffer. A plaintext command
sharing a buffer with STARTTLS causes the connection to close without a
reply, so no command is ever executed before the upgrade completes.
Error cases
Section titled “Error cases”| Situation | Reply |
|---|---|
Too many arguments (STARTTLS now) | -ERR wrong number of arguments for 'starttls' command |
Connection already encrypted (repeat STARTTLS) | -ERR connection is already encrypted |
Implicit-TLS mode (no --resp-starttls) | -ERR unknown command 'STARTTLS' |