Validity of certificates generated by mitmproxy depends on integration between mitmproxy and upstream server?

[jvanheesch]

While using mitmproxy, I noticed some behavior that surprised me.

Short explanation:
The validity of the certificates generated by mitmproxy, when serving as reverse proxy, depends on the integration
between mitmproxy and upstream server. I would expect the client <-> mitm integration to not depend on the
mitm <-> upstream integration.

Detailed explanation:
My setup:

• /etc/hosts mapping example.test to 127.0.0.1
• nginx container, serving https on example.test and example.dev
• mitmproxy container, with port 443 exposed, serving as reverse proxy to nginx
  • using /etc/hosts, mitm container resolves example.test and example.dev to nginx
• root CA with nameConstraints = critical, permitted;DNS:.test, permitted;DNS:.dev
  • provided to nginx to generate ssl cert on startup
  • provided to mitmproxy to generate ssl cert on the fly

Problem:

• when mitmproxy is configured
  as mitmdump -v --mode reverse:https://example.dev:443@443 --ssl-insecure --set keep_host_header, all is fine
• when mitmproxy is configured
  as mitmdump -v --mode reverse:https://example.test:443@443 --ssl-insecure --set keep_host_header, all is fine
• when mitmproxy is configured
  as mitmdump -v --mode reverse:https://nginx:443@443 --ssl-insecure --set keep_host_header, ssl certificates
  generated by mitmproxy are invalid

  Warning: Reading certificate from stdin since no -in or -new option is given
  CN=.test
  error 47 at 0 depth lookup: permitted subtree violation
  error /tmp/cert.pem: verification failed
  

  • this problem disappears when root CA is generated without nameConstraints

Reproducer can be found here, though it's a bit cumbersome to run.

Can anyone shed some light onto this? Is this expected behavior?

[mhils]

Not exactly sure what the issue is, but this is how we generate certificates:

https://github.com/mitmproxy/mitmproxy/blob/10.2.4/mitmproxy/addons/tlsconfig.py#L487
https://github.com/mitmproxy/mitmproxy/blob/10.2.4/mitmproxy/certs.py#L259

Does it happen with a mitmproxy-generated CA, or only with your own CA?

[mhils]

Ah, I see. My guess would be that we include additional SANs that then cause validation to fail.

[jvanheesch]

I think that checks out.
When we use reverse:https://example.dev:443@443 we get:

X509v3 Subject Alternative Name:
    DNS:.test, DNS:example.test, DNS:example.dev

When we use reverse:https://example.test:443@443, we get:

X509v3 Subject Alternative Name:
    DNS:.test, DNS:example.test

When we use reverse:https://nginx:443@443 we get:

X509v3 Subject Alternative Name: 
    DNS:.test, DNS:example.test, DNS:nginx

[jvanheesch]

For me this is not a blocker. I have full control over the CA, so I can easily add nginx to permitted nameConstraints. That being said, I still feel like this is incorrect behavior. What do you think?

[mhils]

I agree this is incorrect behavior. But 1) it does not happen with the default CA generated by mitmproxy, and 2) is not entirely trivial to fix. Happy to accept contributions, but it's very low on my own priority queue. :)

[jvanheesch]

That is very fair. I most likely won't find the time to look into it. Thanks for identifying the root cause!