Where do login credentials show up when HTTPS traffic is intercepted with mitmproxy?

In plain text in the body of the HTTP POST request sent by the login form, for example the username and password form fields of the Wikipedia login request.

TLS protects data on the wire, between two TLS endpoints. With interception, the browser's TLS session ends at mitmproxy, which decrypts the stream, displays the plain HTTP messages, re-encrypts them and forwards them to the real server over a second TLS session.

So in the mitmproxy flow list, the login appears as a POST request to the site's login URL. Opening it shows the request headers (cookies, user agent) and the form body, URL-encoded field by field, including the password exactly as typed. The response, with the new session cookie, is equally readable, so the interceptor could also hijack the session.

Nothing in this needs a vulnerability in the website: whoever terminates TLS sees all application data. Mitigations that survive a trusted-CA interceptor are those that do not rely on the trust store alone: certificate pinning in apps, phishing-resistant authentication (FIDO2/passkeys bind the login to the real origin and never send a reusable secret), and using sensitive services only on networks and devices you control, or through a VPN you trust.

Go deeper:

• mitmproxy docs: How mitmproxy works — why the proxy sees the full decrypted request.
• Wikipedia: Man-in-the-middle attack — defences, including certificate pinning and mutual authentication.