abhinav-phi opened a new pull request, #2126:
URL: https://github.com/apache/stormcrawler/pull/2126
Fixes #2079.
`http.trust.everything` shipped enabled with a static `SSLContext("SSL")`, a
no-op trust manager and a hostname verifier that accepted any name: anybody
able to answer for a host name received the `Authorization` header built from
`http.basicauth.*`, credential headers from `http.custom.headers` and the
replayed cookies — on a connection where the server was never authenticated.
The always-true verifier was a second, independent loss of server identity.
- `http.trust.everything` now defaults to **false**: certificate chains are
validated, as a normal TLS client would do. Hosts with self-signed certificates
need an explicit opt-in
- the trust-all context is built from `TLS` instead of `SSL`
- hostname verification is a separate decision (`http.verify.hostnames`,
default true) and is no longer disabled as a side effect of trusting any
certificate
- credentials are withheld over connections whose server certificate was not
validated, unless `http.credentials.allow.insecure` is set: basic auth,
credential headers (`authorization`, `proxy-authorization`, `cookie`,
`x-api-key`) in `http.custom.headers`, headers set by request and cookies are
all covered
- every insecure state logs a WARN naming the keys; the keys are surfaced in
`crawler-default.yaml`, the archetype `crawler-conf.yaml` files and the docs
The new `OkHttpTrustEverythingTest` runs a local HTTPS server with
self-signed keystores (one issued for `localhost`, one for another name) and
covers all eleven paths: rejection by default, trust-all opt-in, hostname
verification under trust-all, separate hostname disabling, and
withholding/sending of basic auth, credential headers and cookies.
**Release note needed (major change):** the default flip changes behaviour
for intranet crawls relying on self-signed certificates — they need
`http.trust.everything: true` plus, if they authenticate,
`http.credentials.allow.insecure: true`.
--
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]
