* Update Hugo installed in CI from `v0.92.1` to `v0.139.3`
The version in CI is close to 3 years old, which means it does not
encounter the same problems that newer installations of Hugo do.
* Fix Hugo deprecation error
I got the following error when building the documentation with Hugo
`v0.139.3`:
```
ERROR deprecated: data.GetJSON was deprecated in Hugo v0.123.0 and will be removed in Hugo 0.140.0. use resources.Get or resources.GetRemote with transform.Unmarshal.
```
I fixed the error by implementing the change the error recommended.
* options: add request_client_cert to enable mutual TLS
This capability was already built-in but hard-coded to be disabled. Making it configurable as option (defaulting to off) enables mTLS connections between clients and mitmproxy. If true, mitmproxy will send a TLS `CertificateRequest` message to the client during the TLS handshake, upon which a client needs to present a client certificate to mitmproxy to successfully establish an mTLS connection.
This option can be used together with the `client_certs` option to also establish an mTLS connection between mitmproxy and the upstream server. In this case, mitmproxy needs to have a full client cert, including matching private key, that is trusted and accepted by the upstream server. This is a common scenario with MQTT or IoT connections.
Example usage:
$ mitmproxy --set request_client_cert=True --set client_certs=some_directory/
With `some_directory/` containing a `mqtt.example.com.pem` x509 certificate file (including private key).
This allows a client connecting using mTLS, to be intercepted by mitmproxy, which is itself establishing an mTLS connection to the `mqtt.example.com` upstream server. Restricting the client_certs using a directory and PEM files named after the upstream domain, narrows down the mTLS requirement to this single domain, while leaving all other traffic through mitmproxy untouched (normal TLS without client certs).
* add CHANGELOG entry
* docs++
* swap section order, re-add example
---------
Co-authored-by: Maximilian Hils <git@maximilianhils.com>
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
* Add example, according to issue #3752
* Add list options
* Replace generic IPs
* Remove chars < and >
* Update docs/src/content/concepts-options.md
Perfect
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
---------
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
* Add a section on using Magisk and Magisk modules in the Android howto
This allows you to use Google Play builds with mitmproxy.
* [autofix.ci] apply automated fixes
* Explain how to get the Magisk module from mitmweb
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* Added docs for transparent mode on Windows
* Added changes to CHANGELOG.md
* Update CHANGELOG.md
* Update howto-transparent.md
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
mitmproxy previously used a homegrown logging mechanism based around
`mitmproxy.ctx.log` and the `add_log` hook. This worked well for everything
we control, but does not work outside the mitmproxy universe.
For now we have simply ignored logging in e.g. tornado or h2, but with the
upcoming introduction of mitmproxy_wireguard we now have a dependency
on some Rust/PyO3 code for which we definitely want logs, but which also
cannot easily be changed to use our homegrown logging (PyO3 does the heavy
lifting to add interoperability with stdlib logging). Long story short,
we want to introduce a log handler for stdlib logging.
Now there are two ways how such a handler could operate:
1. We could build a handler that forwards all stdlib log events
into our homegrown mechanism.
2. We embrace stdlib's logging as the correct way to do things,
and get rid of our homegrown stuff.
This PR follows the second approach by removing the `add_log` hook and
rewriting the `TermLog` and `EventStore` addons to listen for stdlib log records.
This means that all `mitmproxy.ctx.log.info` events are now simply `logging.info` etc.
One upside of this approach is that many parts of the codebase now don't depend
on the existence of `mitmproxy.ctx` and we can use off-the-shelf things like pytest's
`caplog`. We can also now better colorize log output and/or add timestamps.
Maximilian Hils