I'm not a security expert but I always thought that HTTPS was secure and that if my code was calling an API (for example) with HTTPS/SSL Cert that it was encrypted end to end. Rephrase, I know it's encrypted but I'm aware that MITM or SSL Proxy methods can be used to expose that traffic by spoofing client/server keys.<p>So I assume that someone has to be on your network to use a tool like Charles Proxy. Is the combination of securing your network plus HTTPS
"enough" security to keep web and app traffic safe? What are other aspects I'm missing? Would love to learn more if anyone is willing to share some good resources. TIA.
HTTPS is secure point to point. It's easy to make an HTTPS endpoint that displays your request via skywriter or whatever. There should be no guarantee or suggestion that having https along one part of the journey means the whole thing is secure (but you do/did get a lock icon in the browser).<p>Protection from MITM with HTTPS and TLS in general relies on certificate validation (or exotic key setup). Commonly used browsers do a good job (baring whatever security issues are found from time to time), but apps are mixed.<p>Sometimes they accept any certificate, from any issuer, including self-signed certificates. Sometimes, the certificate needs to match the domain, but any issuer is fine, including self-signed. Sometimes, the certificate needs to match the domain and be issued by a widely accepted CA. Sometimes, the certificate needs to be issued by one of a small list of issuers, but any domain is fine. Sometimes, the certificate needs a matching domain and be from a small list of issuers.<p>Also, not all apps check certificate expiration. There are a lot of ways to do it wrong here, so the app says https or uses port 443 or even wireshark shows TLS doesn't tell you much.
This would be better asked on StackOverflow, or something; HN isn't really the place for this kind of question. But okay, in a nutshell, Charles and other proxies can only work to decode SSL traffic if the whole session goes <i>through them</i> which is why they are called a proxy -- they read the certificate from the external site, decode that site and send it to the browser, and then re-encode the browser response. So your browser, when running Charles, is talking to Charles in clear text, unencrypted. Charles is talking to the HTTPS site.<p>So someone outside your network and the destination server cannot read your HTTPS calls at all. Someone inside your network <i>could</i> read your traffic if they tricked your browser into talking through a proxy instead of talking directly out across the internet. This is why you should never use captive portals / hotel WiFi that replaces SSL certificates with their own, because they're acting as a proxy for your traffic.<p>But in broad terms, if you are connecting directly to an external site without use of a proxy, HTTPS is secure end to end.
end-to-end encryption means that the underlying data is visible only on both ends, hence safe to transport via any medium. if for instance someone performs MITM, anywhere along the line, won't allow them to decrypt the data.<p>replacing certificates requires control of either machine, in which case you'd have bigger problems.<p>then there's the question of how secure is the encryption, which is a rabbit hole of it's own: key size, random generator effectiveness, correct padding, correct implementation or even which layer eg. HTTPS still has exposed SNI, and it goes on and on...