There is a desktop client A connecting to website W in a https connection

A --> W

Somehow between A and W, there is a proxy G.

A --> G --> W
  • In this case, will G be able to get the certificate which A previously got from W?
  • If G can get the certificate, does that mean that G will be able to decrypt the data?
  • It's not clear to me if G is a completely different domain, acting as a proxy to the W domain. Commented Oct 29, 2021 at 8:22
  • A certificate does not have the owner’s private key.
    – Maf
    Commented Jun 22, 2023 at 12:45

7 Answers 7


How does HTTPS work?

HTTPS is based on public/private-key cryptography. This basically means that there is a key pair: The public key is used for encryption and the secret private key is required for decryption.

A certificate is basically a public key with a label identifying the owner.

So when your browser connects to an HTTPS server, the server will answer with its certificate. The browser checks if the certificate is valid:

  • the owner information need to match the server name that the user requested.
  • the certificate needs to be signed by a trusted certification authority.

If one of these conditions is not met, the user is informed about the problem.

After the verification, the browser extracts the public key and uses it to encrypt some information before sending it to the server. The server can decrypt it because the server has the matching private key.

How does HTTPS prevent man in the middle attacks?

In this case, will G be able to get the certificate which A previously got from W?

Yes, the certificate is the public key with the label. The webserver will send it to anyone who connects to it.

If G can get the certificate, does that mean that G will be able to decrypt the data?

No. The certificate contains the public key of the webserver. The malicious proxy is not in the possession of the matching private key. So if the proxy forwards the real certificate to the client, it cannot decrypt information the client sends to the webserver.

The proxy server may try to forge the certificate and provide his own public key instead. This will, however, destroy the signature of the certification authorities. The browser will warn about the invalid certificate.

Is there a way a proxy server can read HTTPS?

If the administrator of your computer cooperates, it is possible for a proxy server to sniff https connections. This is used in some companies in order to scan for viruses and to enforce guidelines of acceptable use.

A local certification authority is setup and the administrator tells your browser that this CA is trustworthy. The proxy server uses this CA to sign his forged certificates.

Oh and of course, user tend to click security warnings away.

  • 11
    If the administrator and the computer cooperates, so there won't be certificate warnings. How can the user know if the proxy listens to the conversation? Afaik my company scans https, but I don't see the self signed certificate in the chain trust when I examine the certificates of https sites.
    – Calmarius
    Commented Jun 12, 2013 at 10:31
  • 9
    You can detect it. 1st your company certificate isn't a self signed one. It is a certificate duly signed by an authority wich is automagically embedded within all the Internet Explorer of the world. To detect all magic certificates allowances without your notice, there is one uniq but hard path. Remove all the magically authorized root certificates within your Internet Explorer. From this starting point, you will have to accept explictly all servers certificates . You will have to read, understand them, and accept the ones you trust.
    – dan
    Commented Jan 6, 2014 at 21:40
  • 2
    one question is: I can't see what is leaving the network, but what about the response the server sent back to browser, now I have public key, does that mean I can decode all the responses and I saw all what the browser is seeing ?
    – zinking
    Commented Sep 16, 2014 at 2:44
  • 7
    And what about the response the W sends back to A? Will G be able to read it? Commented Oct 20, 2015 at 9:43
  • 3
    @se7entyse7en no. Just like how W has a private key, A also establishes such a key at the start of communication. G has neither of these keys.
    – jiggunjer
    Commented Apr 2, 2016 at 20:31

Assuming that users do not click through cert warnings (and assuming that you are running an unmodified client), the answer is: No, the proxy cannot decrypt the data.

For a detailed explanation of how HTTPS prevents a man-in-the-middle from decrypting your traffic, see any standard resource on SSL/TLS, e.g.,

P.S. The certificate is public data. It contains the server's public key and domain name, neither of which are secret. Observing the certificate does not help the attacker to decrypt the data. (Yes, the proxy can observe the certificate, but this is harmless.)

  • 6
    Assuming no root CA gets popped and loses control of its private key.
    – devnul3
    Commented Oct 22, 2011 at 19:14
  • 4
    It's a fair assumption that (root and delegated) CAs will supply bogus certificates to their national intelligence agencies. Apparently there have been, presumably accidental, public marketing of proxy devices that use these sorts of certificates. Commented Oct 25, 2011 at 0:23
  • 7
    Actually Blue Coat ProxySG has been doing MiTM on HTTPS for a long time now by depending on custom trusted certificates being installed on clients accessing through them, basically pretending to be CA on top of being a caching proxy. Similar are doing Nokia, Opera mobile, Amazon Kindle, e.t.c., by installing trusted root certificates on their clients, and then proxying all requests through their spoofed CA servers. In short, anyone that claims or appears to be caching, re-compressing or otherwise optimizing HTTPS contents 'in between' is doing it.
    – TildalWave
    Commented Apr 22, 2013 at 19:36
  • 2
    Of course a proxy can decrypt data - you establish an ssl conn to the proxy the proxy decrypts everything then establishes ssl conn to actual destination and vice versa on the response: zdnet.com/article/…
    – markmnl
    Commented Nov 27, 2015 at 1:13
  • 3
    @markmnl That requires that clients be set up to trust the proxy’s certificates, or that users blindly dismiss the resulting error messages (a good bet, to be honest). From the article you linked: “If your company has set up the proxy correctly you won’t know anything is off because they’ll have arranged to have the proxy’s internal SSL certificate registered on your machine as a valid certificate. If not, you’ll receive a pop-up error message, which, if you click on to continue, will accept the ‘fake’ digital certificate.” Commented Dec 25, 2015 at 18:18

From Philipp C. Heckel's tech blog with some light edits:

While attacking unencrypted HTTP traffic can be done without having to deal with X.509 certificates and certificate authorities (CA), SSL-encrypted HTTPS connections encrypt every request and response between client and server end-to-end. And because the transferred data is encrypted with a shared secret, a middle man (or a proxy) cannot decipher the exchanged data packets. When the client opens an SSL/TLS connection to the secure web server, it verifies the server’s identity by checking two conditions: First, it checks whether its certificate was signed by a CA known to the client. And second, it makes sure that the common name (CN, also: host name) of the server matches the one it connects to. If both conditions are true, the client assumes the connection is secure.

In order to be able to sniff into the connection, Proxy server can act as a certificate authority, however, not a very trustworthy one: Instead of issuing certificates to actual persons or organizations, proxy dynamically generates certificates to whatever hostname is needed for a connection. If, for instance, a client wants to connect to https://www.facebook.com, proxy generates a certificate for “www.facebook.com” and signs it with its own CA. Provided that the client trusts this CA, both of the above mentioned conditions are true (trusted CA, same CN) — meaning that the client believes that the proxy server is in fact “www.facebook.com”. The figure below shows the request/response flow for this scenario. This mechanism is called transparent HTTPS proxying.

enter image description here

For this attack to work, there are a few conditions that must be met:

  • Proxy server as standard gateway (HTTP and HTTPS): For both HTTP and HTTPS proxying, the proxy server must of course be able to intercept the IP packets — meaning that it must be somewhere along the way of the packet path. The easiest way to achieve this is to change the default gateway in the client device to the Proxy server address.
  • Trusted Proxy CA (HTTPS only): For the HTTPS proxying to work, the client must know (and trust!) the proxy CA, i.e. the CA key file must be added to the trust store of the client.

enter image description here

If you’re interested in transparently sniffing plain SSL sockets, you might want to try SSLsplit, a transparent TLS/SSL man-in-the-middle proxy. There are many ways to attack SSL, but you don't need fake SSL certificates, a rogue Certification Authority (CA), or variations on security expert Moxie Marlinspike's man-in-the-middle SSL attacks. Why go to all that trouble when you can just buy a SSL interception proxy, such as Blue Coat Systems' ProxySG or their recently acquired Netronome SSL appliance to do the job for you?

From Steven J. Vaughan-Nichols on ZDNet (excerpted):

Blue Coat, the biggest name in the SSL interception business, is far from the only one offering SSL interception and breaking in a box. Until recently, for example, Microsoft would sell you a program, Forefront Threat Management Gateway 2010, which could do the job for you as well. With an SSL interception proxy program or device in place, here's what really happens:

enter image description here

If your company has set up the proxy correctly you won't know anything is off because they'll have arranged to have the proxy's internal SSL certificate registered on your machine as a valid certificate. If not, you'll receive a pop-up error message, which, if you click on to continue, will accept the "fake" digital certificate. In either case, you get a secure connection to the proxy, it gets a secure connection to the outside site -- and everything sent over the proxy can be read in plain text. Whoops.

  • 3
    Is it possible to tell original facebook certificate from generated by man-in-the-middle?
    – stiv
    Commented Jul 1, 2016 at 18:21
  • @manav are you sure by telling facebbok.com and showing anywhere certificate will work ?? Commented Feb 6, 2017 at 22:30
  • @SudhanshuGaur do you really believe that above information is sufficient to hack facebbok.com !! The information provided is very basic plus old and todays organisational security systems are miles ahead in both HW and SW en/decryption
    – manav m-n
    Commented Mar 19, 2017 at 20:53
  • @stiv Yes, you need to inspect the certificate and make sure that the root certificate it traces back to is well-known. You can copy its SHA-256 Fingerprint and paste it into any database such as Google or crt.sh — if it is widely reported as being in the trust stores of many reputable vendors, you can assume it's not a run-of-the-mill fake-ca "attack" such as corporate TLS proxies use (though, obviously, it could still be a compelled-certificate-creation attack) Commented Apr 27, 2022 at 1:04

Depending on the configuration of the network that you're on, it may be possible for administrators to view the contents of HTTPS connections (and possibly VPNs).

It is obviously possible to intercept traffic on the network, but the usual problem is that they can't issue valid certificates for all the sites that you visit, so you would see a lot of certificate warnings every time you access an HTTPS site, if they try to decrypt the traffic to look at it.

However, if you're using a machine provided by the company they could install a new Certificate Authority and then use that to create SSL certificates for sites that you visit, so it would not show up as a problem.

With the VPN side of things it could be more complex if the VPN doesn't use SSL, but the same theory applies. If you access the Internet from a machine owned by someone else on a network they control, they can likely access any content you enter.

If you're looking to avoid this kind of problem, I'd use a device that you own/control to access the Internet, that way you should get warned if any SSL interception occurs.


Right, the corporate network admins implement a man-in-the-middle attack against the TLS client with their own CA so that they can see what's leaving their network. They will probably have a device that will create a certificate on the fly that is valid for gmail.com when you visit gmail.com. The reason they do this isn't to play Dr. Evil, it's so they can guard against trade secrets being shuttled out of their building over their Internet connection. Seriously, don't do your private banking on a work computer.

If you use a software product that does not use the system certificate store (say, an OpenVPN instance), then, no, they cannot intercept and decode your traffic because you're not trusting their CA. You might achieve the same result using a Firefox portable app, for instance. And in most browsers you can check the details of your secure connection and see who the CA is, to be sure who is listening or not.


The proxy can block https and only allow http from the browser. Then it can initiate its own https connection to pass the requests to the server.

Most users will not notice.

HSTS is supposed to stop this but it is not widely used.

  • If I'm not mistaken, (a) this relies on the "attacker" having administrator access, or at least being able to reconfigure the browser, on the "victim" machine to mark its HTTPS server as valid; so (b) HSTS wouldn't stop this anyway—did you mean HPKP? Commented Apr 27, 2022 at 1:09

SSL termination or SSL proxy products like Bluecoat need to be on your network and considering the cost, the installation procedures involved and the normal security policy any organization would have who installs these products - the threats of a malicious attacker using a commercial SSL termination product is almost zero. OTOH - a trusted insider with access to the NOC (network operations center) could in fact monitor SSL-terminated traffic and disclose sensitive information.

This is a common concern (justified or not) for companies implementing DLP systems.

HOWEVER HAVING SAID ALL THAT - there is another attack vector which is common in the home banking space which doesn't require a network proxy and is piggback/shim attacks in the browser - since the DOM has access to clear text traffic before it hits the SSL pipe - this is a convenient attack vector and is often installed via a browser extension. There is an excellent Stackexchange article on shims - Can a shim (a.k.a. polyfill) be installed in IE, FF, or Chrome without user knowledge, and can it read passwords entered by user on a login page?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .