HTTPS decryption

When an app opens an HTTPS connection through HTTPGlass’s proxy, it asks the proxy to connect it to a host. If that connection is one HTTPGlass should decrypt, HTTPGlass sits in the middle:

1. It completes the TLS handshake with the app itself, using a certificate for that host that it generates on the spot, signed by the root certificate you trusted during setup.
2. It opens its own, separate TLS connection to the real server.
3. It relays the decrypted data between the two, reading and recording it as it passes through.

This is the standard technique every HTTPS debugging proxy uses (Charles, Proxyman, mitmproxy included). All of it happens inside the app on your Mac.

If a connection isn’t one to decrypt, HTTPGlass passes it through untouched. The app talks to the real server directly and HTTPGlass records only the host name — the row reads Encrypted.

What gets decrypted

A connection is decrypted when any of these match:

• The app that opened it is one you picked — see Pick the app you’re debugging.
• The host is on the SSL Proxying list under Rules — see Rule syntax.
• Decrypt all HTTPS is on (Pro only, and on by default for Pro).

Changing any of these closes connections that were passing through encrypted and would now be decrypted, so the app reconnects and you see its traffic straight away.

Just after you start capturing, HTTPGlass needs a moment to get its certificate signing ready. During that moment HTTPS passes through unread rather than stalling; hovering over the toolbar status says so.

HTTP/2 and HTTP/1.1

When the app and the server both speak HTTP/2, a decrypted connection stays HTTP/2 end to end, so what you see is what the app really sent. The Protocol column shows h2 or h1.1.

Hosts with a Map Local, Map Remote, Rewrite, script, breakpoint, or Network Condition rule are negotiated down to HTTP/1.1 so the rule can apply. Blocking and No-Cache work on both.

To force HTTP/1.1 everywhere, turn off HTTP/2 in Settings → Proxy.

When the app refuses the certificate

If the app rejects the certificate HTTPGlass presents, the row reads Untrusted or Pinned, and HTTPGlass passes that host through untouched from then on so the app keeps working:

• Untrusted — your Mac doesn’t trust the HTTPGlass root yet. Trust it, and the host decrypts like any other. See Certificate not trusted.
• Pinned — the root is trusted, but the app still refused. Either it pins its certificate, or it keeps its own list of trusted certificates and doesn’t read the macOS one. The inspector tells you which when it can recognise the client — see Command-line tools and other trust stores and What HTTPGlass can’t see.

Try Again in the inspector, or Try Decrypting host Again from the row’s menu, makes HTTPGlass attempt the host again on its next connection.