[restapi] Disable TLS session tickets to fix FIPS AES-128-CTR panic

[ganglyu]

Why I did it

When restapi is built with the FIPS-patched Go toolchain (Trixie / Go 1.24+fips) and the SymCrypt OpenSSL provider is the active FIPS provider, the first HTTPS request panics during the TLS 1.3 handshake:

http: panic serving X.X.X.X: crypto/cipher: unsupported cipher: AES-128
vendor/github.com/golang-fips/openssl/v2.newCipherCtx
vendor/github.com/golang-fips/openssl/v2.(*aesCipher).NewCTR
crypto/cipher.NewCTR
crypto/tls.(*serverHandshakeStateTLS13).sendSessionTickets

Go's TLS 1.3 server uses AES-128-CTR to encrypt NewSessionTicket payloads. golang-fips/openssl/v2 routes the cipher allocation to OpenSSL's EVP_CIPHER_fetch, and the SymCrypt FIPS provider does not implement AES-128-CTR, so the fetch returns NULL and the binding panics.

How I did it

Set SessionTicketsDisabled: true on the HTTPS server's tls.Config. Session resumption via tickets is not a load-bearing feature for the management REST API, and TLS handshakes still complete normally — they just go through a full handshake every time rather than resuming.

How to verify it

On a SONiC image built with INCLUDE_FIPS=y + Trixie restapi container:

1. Configure restapi cert files in CONFIG_DB so restapi starts HTTPS on :8081.
2. Run from any client:

   openssl s_client -connect <DUT-IP>:8081 -cert client.crt -key client.key -CAfile ca.crt
   

3. Before this patch: tail /var/log/syslog shows http: panic serving ... crypto/cipher: unsupported cipher: AES-128 and the connection is reset.
4. After this patch: TLS handshake completes (SSL handshake has read X bytes and written Y bytes, Protocol: TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256); syslog has no panic.

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).