When you set a proxy in a browser and it connects to https://www.facebook.com/abc/def
, you see this in the proxy:
So you can match on the domainname and portnumber.
However, the proxy then connects that hostname and port and splices that connection to the incoming connection
to the client. The client itself will do the SSL handshake and when that is finished, it sends:
GET /abc/def HTTP/1.1
over the encrypted connection. What the proxy sees is just the SSL negotiation and binary gibberish.
Of course, there are proxy servers who will not do the transparent splice, but they will insert a man-in-the-middle
that makes an encrypted connection to http://www.facebook.com
, and make the client believe they are talking to that
server by presenting a locally generated SSL certificate. To make this work without the client immediately noticing
it, the fake certificate is signed by a root certificate that has been added to the client certificate store. That only
works in e.g. a company, where the IT staff can add that certificate while installing the machines. You cannot do
that in a normal customer WiFi network unless you are a state government or intelligence organisation, who have
trusted root certificates in the commonly used browsers.
Even then it is being detected in newer browsers like Google Chrome, who can detect that a presented certificate
is signed by an unusual root certificate.