[noduerme]

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 through them 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.

So someone outside your network and the destination server cannot read your HTTPS calls at all. Someone inside your network could 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.

But in broad terms, if you are connecting directly to an external site without use of a proxy, HTTPS is secure end to end.

[LinuxBender]

For completeness sake I would only add that a nation-state actor or an organized crime org with access to an unethical CA can generate certs for any site and perform the MITM. CA's sometimes get caught operating this way. One method to mitigate this is to periodically check the fingerprint of the cert for the site you are talking to.

Here is one way using openssl:

   for i in $(echo -e "news.ycombinator.com ycombinator.com www.ycombinator.com"); do echo -en "${i}: "; openssl s_client -servername "${i}" -connect "${i}":443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin; done|sort -k2 -t"=" | awk '{print $NF "\t" $1}' | column -t

  Fingerprint=22:05:8D:96:A0:F7:9B:8F:B8:1D:0F:74:EC:4B:76:8F:84:B0:42:49  www.ycombinator.com:
  Fingerprint=5D:70:F0:DC:E0:AF:67:A0:8F:BC:2F:B8:49:F0:79:5D:8B:FF:49:93  news.ycombinator.com:
  Fingerprint=C4:A6:FF:38:83:13:31:DC:14:01:3D:05:E8:3B:29:95:FD:AE:9B:0E  ycombinator.com:

One could diff the output in a script then send an alert if there is a diff from one test to the other. If doing this factor in expiration and test from multiple locations. Meaning you can expect the cert to change some time before it expires, hopefully.

   openssl s_client -servername news.ycombinator.com -connect news.ycombinator.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -dates

  notBefore=Sep  7 00:00:00 2021 GMT
  notAfter=Oct  8 23:59:59 2022 GMT

Another mitigating control is public key pinning but very few organizations do this any more. It is just too risky operationally. Another method is to limit what CA's you trust but this is not practical for most organizations. e.g. You have a specific purpose system that only talks to Specified_Bank and that Specified_Bank only uses Specified_CA, you can strip out all other CA's from your trust store and/or manually pin their public key in your system accepting the risk connections will break when they update their cert without coordinating with you.

[tomklein]

That’s what Certificate Transparency is for. If CT is required by the client, then the wrongfully issued certificate could be detected and the CA be reported for that.

[LinuxBender]

True, though CT has positive and negative checks. [1] If a malicious CA chooses to silently issue certs without creating logs, all you get is a lack of logs. AFAIK no browsers will balk at this. You may eventually detect it if the certificate is widely used, but if the certificate is being targeted to one victim or a small set of victims, it is highly unlikely anyone would detect this. If you can MITM someone, you can prevent them from checking the logs and instead give them a server error 500.

[1] - https://certificate.transparency.dev/howctworks/