Confusion About Https Proxies

The comment 'There are no HTTPS forward proxies' is not true. They are very common. Any company of decent size will incorporate explicit forward proxies for SSL so that they can decrypt the https traffic for monitoring, logging and filtering purposes - a common euphemism being 'Compliance Reporting'.

Some background, which you may already know, for context:

The initial handshake of an HTTPS session contains three parts:

1. Greeting: ClientHello message containing what TLS versions and ciphers it supports, and a ServerHello message with similar info. This step and the following one are not encrypted.

2. Cert Exchange: Server provides it's TLS cert, which the client needs to decided if it trusts - typically implemented with implicit trust on those signed by certificate authorities and requiring user intervention for self-signed.

3. Key Exchange - The method decided on in step 1 is used; the simplest method is a RSA key exchange type transaction: Client generates a key using a random number and encrypts it using the server's public key. This is decrypted using the server's private key (it can only be encrypted with the public key, it cannot be decrypted without the private key, which is subtle but confusing to many).

From here on, entirely encrypted communications take place, with nearly all of the TCP/IP packet encrypted (except for headers/fields required for routing).

The answer to your questions is that a forward proxy requires that the proxy entirely decrypts the HTTPS communications. The client never handshakes directly with the intended server (sometimes without knowing that it isn't, which I touch on below).

Here is an explanation from Palo Alto Networks on how a Forward HTTPS Proxy works (PAN-OS refers to their network SW):

1. Client is trying to reach out with HTTPS. Traffic is matching the decryption policy.
2. This traffic is handled by our SSL proxy engine, and a certificate for is generated by our internal PKI (signed by the CA certificate).
3. PAN-OS is proxying the ssl traffic and setting up a new ssl connection with the Web Server.
4. Web Server is starting handshake with PAN-OS device.
5. PAN-OS device is completing its SSL handshake with client presenting generated certificate in Server Hello message.

This (if malicious) is an explicit man in the middle attack - it turns a 2 party transaction: PC ⟺ Google - into 2 separate transactions: PC ⟺ Proxy and Proxy ⟺ Google.

Side Note

As forward proxies are primarily used to monitor ssl traffic, it is interesting that the non-proxy method also discussed in that PAN link - inbound 'inspection / decryption' which requires that the firewall have the servers cert and keys, and is therefore able to entirely decrypt the communication with simple packet monitoring. As an aside, it's a bit unnerving that they advertise this as a key feature when one would hope it would have very few use cases - it requires that the operator of the firewall have the public and private keys of the 3rd party site - e.g. Google's private keys. One would think that wouldn't be common.

There are many different ways forward proxies can be implemented and I barely touch on them - many if not most forward proxies are implemented as 'transparent' forward proxies, meaning the clients are not configured to connect to a proxy at all, and the firewall / proxy interposes itself into the transaction. The forward proxy described above is a 'transparent' proxy. Once the client has accepted the cert from the proxy, which if it is a CA signed cert is usually automatic, the client machines will receive packets that the proxy modified to appear to be from the original server (e.g. google).