I set up a Squid proxy on the server system, and configured it as a
transparent proxy, but it only works with http requests.
Isso é esperado, pois o HTTP e o HTTPS funcionam de maneira diferente e não podem ser tratados da mesma maneira por um proxy. Quando uma solicitação HTTPS é redirecionada para uma porta proxy de forma transparente, o proxy não pode examinar o tráfego criptografado e, portanto, não pode manipulá-lo. Um proxy transparent na verdade funciona mais como um "Man in the Middle" que intercepta o tráfego HTTP sem que os usuários saibam, o que é possível devido à falta de segurança no protocolo http.
link
HTTPS (also called HTTP over TLS,[1][2] HTTP over SSL,[3] and HTTP
Secure[4][5]) is a protocol for secure communication over a computer
network which is widely used on the Internet. HTTPS consists of
communication over Hypertext Transfer Protocol (HTTP) within a
connection encrypted by Transport Layer Security or its predecessor,
Secure Sockets Layer. The main motivation for HTTPS is authentication
of the visited website and protection of the privacy and integrity of
the exchanged data.
In its popular deployment on the internet, HTTPS provides
authentication of the website and associated web server with which one
is communicating, which protects against man-in-the-middle attacks.
Additionally, it provides bidirectional encryption of communications
between a client and server, which protects against eavesdropping and
tampering with and/or forging the contents of the communication.[6] In
practice, this provides a reasonable guarantee that one is
communicating with precisely the website that one intended to
communicate with (as opposed to an impostor), as well as ensuring that
the contents of communications between the user and site cannot be
read or forged by any third party.
Como você pode ver, o HTTPS deve proteger contra o homem no ataque do meio e não permitir isso. A seguinte página do Squid explica todas as suas dúvidas e confusões em detalhes.
link
When a browser comes across an https:// URL, it does one of two
things:
Squid interaction with these two traffic types is discussed below.
CONNECT tunnel
The CONNECT method is a way to tunnel any kind of connection through
an HTTP proxy. By default, the proxy establishes a TCP connection to
the specified server, responds with an HTTP 200 (Connection
Established) response, and then shovels packets back and forth between
the client and the server, without understanding or interpreting the
tunnelled traffic. For the gory details on tunnelling and the CONNECT
method, please see RFC 2817 and the expired Tunneling TCP based
protocols through Web proxy servers draft.
CONNECT tunnel through Squid
When a browser establishes a CONNECT tunnel through Squid, Access
Controls are able to control CONNECT requests, but only limited
information is available. For example, many common parts of the
request URL do not exist in a CONNECT request:
the URL scheme or protocol (e.g., http://, https://, ftp://, voip://, itunes://, or telnet://),
the URL path (e.g., /index.html or /secure/images/),
and query string (e.g. ?a=b&c=d)
With HTTPS, the above parts are present in encapsulated HTTP requests
that flow through the tunnel, but Squid does not have access to those
encrypted messages. Other tunnelled protocols may not even use HTTP
messages and URLs (e.g., telnet).
Quando um navegador é configurado para usar um proxy manualmente, ele usa o método CONNECT mencionado acima e funciona.
Dito isto, existem maneiras de configurar o proxy transparente para interceptar o tráfego https (ssl-bump), que não é recomendado e deve ser usado com cuidado.
Bumping CONNECT tunnels
{X} WARNING: {X} HTTPS was designed to give users an expectation of privacy and security. Decrypting HTTPS tunnels without user consent
or knowledge may violate ethical norms and may be illegal in your
jurisdiction. Squid decryption features described here and elsewhere
are designed for deployment with user consent or, at the very least,
in environments where decryption without consent is legal. These
features also illustrate why users should be careful with trusting
HTTPS connections and why the weakest link in the chain of HTTPS
protections is rather fragile. Decrypting HTTPS tunnels constitutes a
man-in-the-middle attack from the overall network security point of
view. Attack tools are an equivalent of an atomic bomb in real world:
Make sure you understand what you are doing and that your decision
makers have enough information to make wise choices.
Squid SslBump and associated features can be used to decrypt HTTPS
CONNECT tunnels while they pass through a Squid proxy. This allows
dealing with tunnelled HTTP messages as if they were regular HTTP
messages, including applying detailed access controls and performing
content adaptation (e.g., check request bodies for information leaks
and check responses for viruses). Configuration mistakes, Squid bugs,
and malicious attacks may lead to unencrypted messages escaping Squid
boundaries.
From the browser point of view, encapsulated messages are not sent to
a proxy. Thus, general interception limitations, such as inability to
authenticate individual embedded requests, apply here as well.