MB_JETTY_SKIP_SNI evaluating env variable as string instead of bool, always evaluating to truthy if set

[likeshumidity]

Describe the bug

Setting MB_JETTY_SKIP_SNI always evaluates to false if unset and always evaluates to true if set because config/config-str being used instead of config/config-bool for :mb-jetty-skip-sni.

• https://github.com/metabase/metabase/blob/master/src/metabase/server.clj#L21-L34

To Reproduce

1. Generate a self-signed cert replacing YOUR.HOSTNAME with your hostname (can't be localhost and requires at least one . in the hostname. (May need to add a line to your /etc/hosts when using 127.0.0.1.)

# leave all prompted values for CN, CO, ST, etc. blank
$ keytool -keystore selfsigned-ip-cn-and-san-nohost.jks -storepass storepass -genkeypair -keyalg RSA -validity 365

2. Set Jetty to run with SSL like below:

MB_SITE_URL=https://YOUR.HOSTNAME:8443
MB_JETTY_SSL=true
MB_JETTY_SSL_PORT=8443
MB_JETTY_SSL_KEYSTORE=/app/selfsigned.jks
MB_JETTY_SSL_KEYSTORE_PASSWORD=storepass
MB_JETTY_SKIP_SNI=false

3. Set MB_JETTY_SKIP_SNI to any value (e.g. false, "false", true, "true", abc123)
4. Run Metabase
5. Metabase runs JETTY with SNI disabled
6. To verify behavior with SNI enabled, comment out MB_JETTY_SKIP_SNI=false in the .env file which defaults to false and should see an SNI error since the hostname won't match the certificate

Expected behavior

• Expect these to set :mb-jetty-skip-sni to false and enable SNI:
  • MB_JETTY_SKIP_SNI=false
  • MB_JETTY_SKIP_SNI="false"
  • not setting MB_JETTY_SKIP_SNI in the .env
• Expect these to set :mb-jetty-skip-sni to true and disable SNI:
  • MB_JETTY_SKIP_SNI=true
  • MB_JETTY_SKIP_SNI="true"

Logs

If SNI enabled and hostname doesn't match certificate, then expect to see below in logs:

If SNI disabled, expect to see nothing unusual in the logs

Information about your Metabase installation

- `master` as of `0468c9a7f5946c9a9d3b91ced5cee9a68d81533e`
- v1.49.8

Severity

P1: Users unable to explicitly set MB_JETTY_SKIP_SNI to false

• Metabase could be deployed with MB_JETTY_SKIP_SNI=false explicitly requiring SNI to address a risk and SNI would be disabled, and there may be no indication to administrator that it was not working unless they tried to verify it which would be unusual.

Additional context

https://metaboat.slack.com/archives/C052ZBWRG3W/p1715096284142429

[likeshumidity]

On the fence re: P1 vs P2, so can downgrade if needed. It seems most modern browsers warn users if SNI not enabled with a "your connection is not private" message or similar. But seems like an easy fix as well re: one line change.