The issuer's certificate in turn will have its own issuer & signature, creating a chain of certificates, up until a final self-signed root certificate. TLS certificates include a reference to the issuer of the certificate, and a signature proving that the issuer verified the certificate.It expects the server's response to include a valid certificate for that hostname. When any modern TLS client first connects to a server, its initial message includes a Server Name Indication (SNI), telling the server which hostname it's looking for (e.g.

Every TLS client keeps track of some set of root certificate authorities (root CAs) that it trusts completely.If you are interested in the fine details of TLS, The Illustrated TLS Connection is well worth a look, for a byte-by-byte breakdown of the whole process. I'm not going to go into the lowest level details, but it is important to understand the basics of how TLS works. Everything we're going to talk about here is really about TLS - the HTTP within is just normal GET / requests and 200 OK responses. How HTTPS trust worksĪn HTTPS request is an HTTP request, made over a TLS connection. Let's talk though how HTTPS clients in general manage this kind of trust, see how that works on Android specifically, and then look at how it's possible to get around this and intercept real HTTPS traffic. To do so, it has to automatically ensure that it's trusted by HTTPS clients on Android devices, without breaking security on those devices completely (it would be a very bad idea to simply turn off certificate validation, for example). This isn't theoretical - HTTP Toolkit does exactly this, automatically intercepting HTTPS from real Android devices, for inspection, testing & mocking. If you want to intercept your own HTTPS on Android, perhaps to capture & rewrite traffic from your Android device for debugging or testing, how do you do that? To intercept, inspect or manipulate HTTPS traffic, you need the HTTPS client to trust you.

Wireshark intercept https