* Update and rename strip_ech addon to use new DNS HTTPS records API
* Update CHANGELOG.md
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* Do not mutate data when splitting into chunks (#6873)
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* Update PyInstaller spec to set the u (unbuffered) flag
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* Setting SIG_IGN for SIGPIPE errors
The issue was reported in https://github.com/mitmproxy/mitmproxy/issues/6744
Problem description:
When there is a sudden surge of requests, mitmproxy will hit SIGPIPE (broken pipe) errors because it was trying to write to a closed socket. The stacktrace is:
File "asyncio/runners.py", line 44, in run
File "asyncio/base_events.py", line 636, in run_until_complete
File "asyncio/base_events.py", line 603, in run_forever
File "asyncio/base_events.py", line 1909, in _run_once
File "asyncio/events.py", line 80, in _run
File "mitmproxy/proxy/server.py", line 294, in handle_connection
File "mitmproxy/proxy/server.py", line 407, in server_event
File "asyncio/streams.py", line 325, in write
File "asyncio/selector_events.py", line 924, in write
When this happens, the process terminates unless handled
The fix will allow the process to continue to run.
* add changelog entry
* [autofix.ci] apply automated fixes
* Handling SIGPIPE only in non-Windows platforms
* [autofix.ci] apply automated fixes
* nit: make check platform-agnostic
---------
Co-authored-by: changsin <changsin@strac.io>
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* button to close flow details section + test
* [autofix.ci] apply automated fixes
* update changelog
* remove useless imports
* change span to button
* update snapshots
* move the close button to the left
* change color to gray
* add icon instead of text
* update tests
* review changes
* remove useless stuff
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
* ensure that `Start` is always the first event
fix#6745
* simplify proxy handler
this commit should not do any functional changes
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
#### Description
This fixes some specification compliance issues as well as a potential
DoS vulnerability.
Start with version 1.0.0, aioquic follows semantic versioning, so no
breaking changes will occur before version 2.0.0.
#### Checklist
- [x] I have updated tests where applicable.
- [x] I have added an entry to the CHANGELOG.
#### Description
On get_message_content_view, the content type wasn't including the
boundary, and was only setting the MIME type. This made the multipart
content view unusable, as the boundary was required on parsing. To fix
the issue, we assign the full content type instead.
This wasn't triggered by any previous tests because they would test
against the multipart parser directly, and not the generic parser.
#### Checklist
- [X] I have updated tests where applicable.
- [x] I have added an entry to the CHANGELOG.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
#### Description
This PR fixes bug described here : #4448
I set a max-height property and a scroll in case of overflow on the
y-axis.
#### Checklist
- [x] I have updated tests where applicable.
- [x] I have added an entry to the CHANGELOG.
---------
Co-authored-by: Maximilian Hils <git@maximilianhils.com>
#### Description
The mutual exclusivity of the allow-hosts and ignore-hosts parameters
looks like an unnecessary obstacle and does not make much sense.
It is very convenient to use a proxy only for the domain of your
service, but at the same time ignore some subdomains, especially when
they serve some kind of CDNs with a large amount of data.
Although this filtering could be implemented using regexp with negative
lookahead, but it complicates configuration and is not as clear as
conjuction of allow and deny filters.
#### Checklist
- [x] I have updated tests where applicable.
- [x] I have added an entry to the CHANGELOG.
---------
Co-authored-by: Denis Stanishevskiy <>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
#### Description
Fixes#4506
`mitmproxy` during server-replay mode, calculates the hashes of flows
from input files based on user defined filters and uses them to compare
against hashes of incoming requests to serve the corresponding stored
response by matching the hash. However, during runtime, if the user
changes any of the filters, `mitmproxy` fails to recalculate the hashes
of input flows and hence doesn't return the intended response. This PR
fixes this issue by recomputing the hashes for every flow whenever a
filter(option) used for computing hashes is changed.
#### Checklist
- [x] I have updated tests where applicable.
- [x] I have added an entry to the CHANGELOG.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: Maximilian Hils <git@maximilianhils.com>
#### Description
Unfortunately 0b5e310881 broke mitmproxy's
ability to issue leaf certificates if `ca_file` contains multiple CAs.
This PR restores that capability.
The issue lies in `mitmproxy/certs.py` - specifically, in the
`from_files` method of the `CertStore` class. Before
0b5e310881, the issuing CA was identified
like this:
``` python
raw = ca_file.read_bytes()
key = load_pem_private_key(raw, passphrase)
…
certs = re.split(rb"(?=-----BEGIN CERTIFICATE-----)", raw)
ca = Cert.from_pem(certs[1])
```
This worked even when `ca_file` contained multiple CAs. For example,
consider this example:
```
-----BEGIN PRIVATE KEY-----
REDACTED
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIICmTCCAfqgAwIBAgIRAIqaBJ6aU5wXT+5JAn8Uj1IwCgYIKoZIzj0EAwQwMDEu
MCwGA1UEAxMlbWFuc2VsbWkgSW50ZXJtZWRpYXRlIENBICgyMDIzLTA0LTExKTAe
Fw0yNDAyMTQxNzEzMDBaFw0yNDAyMTUxNzE0MDBaMB8xHTAbBgNVBAMTFG1pdG1w
cm94eSBJc3N1aW5nIENBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEeKTLpy6KeiWN
89S9UJoTM9w6HyrEiVByf/ie2wUX3vR/3nHVMTi5XZQD6/8h3A9yUWwtRtVDj55D
STbPKjN6G8t/Qh1dGz2vanNjmWNlceM3DOIlT30vmR5+GrUOwj+7o4HoMIHlMA4G
A1UdDwEB/wQEAwIBhjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwEgYD
VR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUkf9kgx5DbP0B66Ir6oLUDV/CIU4w
HwYDVR0jBBgwFoAUqBYQLb8rkIidwq5dYuiDFdKhY48wYAYMKwYBBAGCpGTGKEAB
BFAwTgIBAQQcbWlrZUBtYW5zZWxtaS5jb206aXNzdWluZy1jYQQrYmZhODBJaGMz
VXNUcU0yQlp6ZG1rYW1OLW1XNGtpWTJrM1g5X19kd3Q0bzAKBggqhkjOPQQDBAOB
jAAwgYgCQgF/QLZ0cThJKeoeIk4dY4+Z2MdIey7kvvy1jwlWrsOqOY+UXUWHXRlj
oXZN92imAKqgLU5T859MMqWrjA1LjN7w6QJCAY+2xN7ovry3WSMqwnu86NuPL8vh
fjftZeIW5GWuLzOsEFt7SfWMhkmFc/jcFpZ/qlolPhvr6E170zNhHUSMKvjb
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIICcjCCAdSgAwIBAgIQeK+VyMjx85py1kqGdjn5nTAKBggqhkjOPQQDBDAoMSYw
JAYDVQQDEx1tYW5zZWxtaSBSb290IENBICgyMDIzLTA0LTExKTAeFw0yMzA0MTEw
MjIzMzdaFw0yODA0MDkwMjIzMzdaMDAxLjAsBgNVBAMTJW1hbnNlbG1pIEludGVy
bWVkaWF0ZSBDQSAoMjAyMy0wNC0xMSkwgZswEAYHKoZIzj0CAQYFK4EEACMDgYYA
BADhbjtnME8IDpBab8MogM0HchH0V9B8Qx7nRXK+tbGyyHlgLjIBYF/erJGBP0md
RMAxU5x/nPlHPODRBkJhB0wbcwGC9zjQQyxfhG75806QzkaZSsC0kFZ9d3JG4fjn
uenY1S2VZ5qE0gDc8Qmfyjcx7KqxQKwS9RwtG1ymAmWgvmGIJ6OBlDCBkTAOBgNV
HQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBATAdBgNVHQ4EFgQUqBYQLb8r
kIidwq5dYuiDFdKhY48wHwYDVR0jBBgwFoAU6+JptrrPiOuWZyKvwg0EJz5TkW8w
KwYDVR0fBCQwIjAgoB6gHIYaaHR0cDovL2NhLm1hbnNlbG1pLmNvbS9jcmwwCgYI
KoZIzj0EAwQDgYsAMIGHAkEw/A2kiL4Kt9/8PND89vlXEehqeymFgats62a3UMU2
g3zATES/WI2E1IgqIsmB6ILRgWMslzpH+NGP+JJkFCz9cwJCAJaRlnOc3xafHZta
0Xwr5YUVAAfmVOj9a2XAsNlNuMy2t8cmeeGmQjrZwCuivlzLOp19Ge3Mi0dnzeV+
5L2rBOCL
-----END CERTIFICATE-----
```
`certs` would have three elements: the private key, the issuing CA and
the intermediate CA. As a result, `ca = Cert.from_pem(certs[1])` would
select the first CA (the issuing CA).
From 0b5e310881 onward, we instead have
``` python
raw = ca_file.read_bytes()
key = load_pem_private_key(raw, passphrase)
…
certs = x509.load_pem_x509_certificates(raw)
ca = Cert(certs[-1])
```
Now, `certs` would have only two elements: the issuing CA and the
intermediate CA. (`x509.load_pem_x509_certificates` discards the private
key.) As a result, `ca = Cert(certs[-1])` must instead be `ca =
Cert(certs[0])`, otherwise the `ca` and `key` won't correspond to each
other and we'll eventually see an error like this when mitmproxy tries
to generate a leaf certificate:
```
Addon error: [('x509 certificate routines', '', 'key values mismatch')]
Traceback (most recent call last):
File "/Users/manselmi/repos/mitmproxy/mitmproxy/addons/tlsconfig.py", line 208, in tls_start_client
tls_start.ssl_conn.use_privatekey(
File "/Users/manselmi/virtualenv/mitmproxy-py312/lib/python3.12/site-packages/OpenSSL/SSL.py", line 1949, in use_privatekey
self._context._raise_passphrase_exception()
File "/Users/manselmi/virtualenv/mitmproxy-py312/lib/python3.12/site-packages/OpenSSL/SSL.py", line 1123, in _raise_passphrase_exception
_raise_current_error()
File "/Users/manselmi/virtualenv/mitmproxy-py312/lib/python3.12/site-packages/OpenSSL/_util.py", line 57, in exception_from_error_queue
raise exception_type(errors)
OpenSSL.SSL.Error: [('x509 certificate routines', '', 'key values mismatch')]
```
#### Description
Fix issue #6656
This generates a wireguard config with the correct endpoint when using
two or more active NICs.
#### Checklist
- [x] I have updated tests where applicable.
- [x] I have added an entry to the CHANGELOG.
---------
Co-authored-by: Maximilian Hils <github@maximilianhils.com>
#### Description
Fixes#6647 by assuming all DNS queries are made over UDP, will need to
be reworked when TCP support is added.
#### Checklist
- [x] I have updated tests where applicable.
- [x] I have added an entry to the CHANGELOG.
Maximilian Hils