So, given the above, if we want to intercept HTTPS we need to be able to present a certificate issued by a trusted certificate authority. If you'd like to get into the nitty gritty of how the certificate validation really works, Scott Helme has written up a great guide. This is a bit simplified and I'm ignoring all sorts of edge cases, but it's enough for our purposes. In short: every TLS client has a list of root CAs that it trusts, and to successfully receive an HTTPS request, you must be able to present a certificate for the target hostname that includes a trusted root CA somewhere in its chain. it never sends any part of its HTTPS request.
If it doesn't trust the certificate, it closes the connection before sending any content, i.e. If the client trusts the certificate, it continues creating the encrypted connection, and then sends and receives data over that connection.It does so by checking the details of the certificate (notably checking the hostname is what was expected), and then examining the issuer of the certificate, and then issuer of the issuer's certificate, and so on and so on until it reaches a certificate that it already trusts (a trusted certificate authority) or running out of issuers and deciding that it doesn't trust the certificate at all. The client must decide if it trusts the server's certificate.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.
#Intacept desktop android#
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.
0 kommentar(er)
