How can I get the MITM certificate from a flow in a script hook?

[dlenski]

I'm using mitmdump 1.0.2 to intercept a TLS connection and log and modify it with TCP hooks (--tcp foo.host.com -s script.py).

I need to find and replace the hex/ASCII digest of the upstream server certificate with the digest of mitmproxy's generated certificate—because the client expects to receive and check the certificate hash at the application level.

I can easily get the real/upstream server certificate from flow.server_conn.cert. But how can I get the generated/MITM cert sent to the client in the TCP hooks?

def tcp_message(flow):
    d = flow.dumpfile
    m = flow.messages[-1]
    c = m.content

    real_server_hash = flow.server_conn.cert.digest('sha1').replace(b':',b'').lower()

    #####
    # FIXME: how can I figure out the hash of the certificate that mitmproxy is sending to the client?
    mitm_server_hash = b'hardcodedvaluehere'
    #####

    nc = m.content
    nc = nc.replace(real_server_hash, mitm_server_hash)
    if nc!=m.content:
        print("%s message: replaced real cert hash (%r) with mitmproxy cert hash (%r)" % ('outgoing' if m.from_client else 'incoming', real_server_hash, mitm_server_hash), file=stderr)
        m.content = nc

[dlenski]

From what I can tell, the ClientConnect object only exposes the clientcert sent by the client… but it does not expose the mitmcert sent to the client.

Or am I overlooking something that I can use to get the MITM cert?

[mhils]

Getting the mitmproxy certificate in tcp_message seems to be too late for what you are trying to do - we have already established a TLS connection then. Is this just about a few domains or shall this work generically? For the former case, I'd recommend to just use --cert. Otherwise you probably have to monkeypatch TlsLayer._find_cert.

[dlenski]

Thanks for the quick response!

Getting the mitmproxy certificate in tcp_message seems to be too late for what you are trying to do - we have already established a TLS connection then.

Would it be easier to get in tcp_start?

Is this just about a few domains or shall this work generically?
For the former case, I'd recommend to just use --cert.

Yes, I've used --cert for my individual use cases, but it would be great to be able to be able to make it work generically with the generated certs.

Otherwise you probably have to monkeypatch TlsLayer._find_cert.

Would you suggest something like this, setting the mitmcert as an attribute of server_conn?

@@ -259,21 +259,25 @@ def find_cert(self):
        # RFC 2818: If a subjectAltName extension of type dNSName is present, that MUST be used as the identity.
        # In other words, the Common Name is irrelevant then.
        if host:
            sans.add(host)
-       return self.config.certstore.get_cert(host, list(sans))
+
+       # Save the certificate sent to the client in the server_conn
+       self.server_conn.mitmcert = self.config.certstore.get_cert(host, list(sans))
+       return self.server_conn.mitmcert

[mhils]

If I understand you correctly, you want to modify the certificate that is shown to the client during the handshake, right? Any of the tcp_* events would be too late for this, they trigger after TLS has been negotiated. If you need to do any shenangians with the cert, do them in find_cert directly, because that directly returns the cert which is then used for the handshake. Does that make sense? :)

[dlenski]

If I understand you correctly, you want to modify the certificate that is shown to the client during the handshake, right?

Aha, I should be clearer in my goal.

I don't actually need to modify the certificate that is shown to the client; I'm quite happy having mitmproxy generate certs on-the-fly, as long as I can lie about them self-consistently within each client session :-P

I just need to be able to access the MITM certificate used for the ongoing connection, so that I can generate its digest, and feed it to the client in the application-layer response.

[mhils]

Oh ok - makes sense now. 😄
Yes, that's something you'd want to add here the way you described above.

I'm wondering if there is a general use-case here that warrants adding this to the ServerConnection properly so that it does get persisted. @cortesi, thoughts?

[dlenski]

Yes, that's something you'd want to add here the way you described above.

Great, I'll take a crack at it!

I'm wondering if there is a general use-case here that warrants adding this to the ServerConnection properly so that it does get persisted.

In my experience analyzing VPNs, peers often exchange certificates or digests at the application layer. It's often useful to know what MITM certificate we're sending to the client, so that we can inject it at the app layer as well.