yandrey321 opened a new pull request, #11389:
URL: https://github.com/apache/ozone/pull/11389
## What changes were proposed in this pull request?
HDDS-8280 upgraded Jetty from 9.4 to 12.0.38. Jetty 12's
`SecureRequestCustomizer`
defaults `sniHostCheck` to true, which rejects any HTTPS request whose Host
header or
TLS SNI name is not covered by the certificate the connector served, with a
400 "Invalid SNI". Jetty 9.4 only applied that check when the client's SNI
actually
matched a certificate in the keystore, so requests carrying no SNI or an
unmatched name
were served with the default certificate.
That is a behavior change on every Ozone HTTPS endpoint, and it breaks
setups that
worked before the upgrade: requests to an IP literal, which send no SNI at
all, and
requests to localhost, a VIP, a load balancer name or any DNS alias absent
from the
keystore certificate.
To keep HDDS-8280 free of a TLS behavior change, `HttpServer2` disabled the
check
unconditionally:
```java
httpConfig.addCustomizer(new SecureRequestCustomizer(false));
```
That was the right call for the upgrade, but it leaves no way to get the
hardening back.
This patch makes it a configuration decision instead.
### Change
New key, read in `HttpServer2.Builder.createHttpsChannelConnector` and
passed to
`SecureRequestCustomizer` in place of the hard-coded `false`:
| Property | Default | Meaning |
|---|---|---|
| `ozone.http.sni.host.check.enabled` | `false` | `false` — the Host/SNI
name need not be covered by the served certificate (Jetty 9.4 semantics).
`true` — Jetty 12's default: reject requests whose Host or SNI the certificate
does not cover. |
The key sits in the `ozone.http.*` namespace alongside `ozone.http.policy`
and
`ozone.http.basedir`, which already govern this HTTP server family including
its HTTPS
mode. One call site covers every HTTPS endpoint: `HttpServer2` is the only
`SecureRequestCustomizer` user in the repo, and the OM, SCM, Recon, S3
Gateway and
datanode web servers are all built through it via `BaseHttpServer`.
The default stays `false` deliberately. Flipping it would reintroduce the
behavior change
HDDS-8280 avoided and would break clusters reached by VIP or IP literal on
upgrade.
Changing the default is a separate decision for a later release and needs a
release note.
`ozone-default.xml` documents what enabling it requires: the server
certificate must
carry every name clients connect with as a SubjectAlternativeName, including
an
`iPAddress` entry for every address reached by IP literal, since such a
request sends no
SNI at all. This matters because the Ozone HTTPS keystore is
operator-supplied —
`HttpServer2` reads it from `ssl-server.xml` via
`hadoop.ssl.server.keystore.location`,
not from the SCM internal CA — so whether the check can be satisfied depends
on the
operator's certificate and cannot be decided for them.
### Deliberately not included
- **No `Builder` setter and no `BaseHttpServer` hook.** The existing
`allowAmbiguousUri`
flag has that shape because S3 Gateway and httpfs need per-service
overrides. No
service needs a per-service SNI policy, so a hook would have no
overriders. A
cluster-wide conf read is sufficient; the hook can be added if a need
appears.
- **Jetty's `sniRequired` option** (reject requests that send no SNI at
all). It is a
different policy with a wider blast radius and no pre-upgrade equivalent,
so it belongs
in its own Jira if anyone wants it.
- **No docs page change.** `SecuringOzoneHTTP.md` covers SPNEGO/SIMPLE
authentication
only, there is no TLS section to extend, and `ozone.http.policy` is
likewise documented
only in `ozone-default.xml`.
Generated-by: Claude Code (claude-opus)
## What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-16682
## How was this patch tested?
New test in `TestHttpServer2SSL`:
`testIpLiteralRejectedWhenSniHostCheckEnabled`. With
the key set to true, the `127.0.0.1` IP literal that the `CN=localhost` test
certificate
does not cover gets a 400, while the `localhost` name it does cover still
gets a 200.
It pairs with the existing `testIpLiteralServedWithNonMatchingCertificate`,
which asserts
the default-false behavior (both names served with 200) and is unchanged
apart from a
javadoc wording fix. The two together are a two-sided control against the
same keystore:
if the configuration read were ignored, one of them would fail.
Ran locally:
- `mvn -pl :hdds-server-framework -am clean install -DskipTests` — BUILD
SUCCESS
- `TestHttpServer2SSL` — 11 tests, all pass
- `TestOzoneConfigurationFields` — 5 tests, all pass (it validates the new
key in both
directions, constant and `ozone-default.xml` entry)
- `checkstyle.sh` — 0 violations
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
