Configurare Squid come proxy forward HTTPS?

9

Ecco alcune informazioni sul mio problema:

Ho un servizio web in esecuzione su Heroku, con un indirizzo IP dinamico. Gli IP statici su Heroku non sono un'opzione.
Devo connettermi a un servizio Web esterno dietro un firewall. Le persone che gestiscono il servizio Web esterno apriranno il proprio firewall solo a un IP statico specifico.

La mia tentata soluzione è quella di utilizzare Squid su un server separato con un IP statico per inoltrare le richieste proxy da Heroku al servizio esterno. In questo modo, il servizio esterno vede sempre l'IP statico del server proxy, anziché l'IP dinamico del servizio Heroku.

Poiché il mio server proxy non può fare affidamento su un indirizzo IP per l'autenticazione (questo è il problema per cominciare!), Deve fare affidamento su un nome utente e una password. Inoltre, il nome utente e la password non possono essere trasmessi in chiaro, perché se un utente malintenzionato dovesse intercettare quel testo in chiaro, potrebbe connettersi al mio proxy fingendo di essere me, fare richieste in uscita utilizzando l'IP statico del mio proxy e quindi eludere l'esterno firewall del servizio web.

Pertanto, il proxy Squid deve accettare connessioni solo su HTTPS, non HTTP. (La connessione al servizio Web esterno potrebbe essere HTTP o HTTPS.)

Sto eseguendo Squid 3.1.10 su CentOS 6.5.x, ed ecco il mio squid.conffinora. Solo a scopo di risoluzione dei problemi, ho temporaneamente abilitato il proxy HTTP e HTTPS, ma desidero solo utilizzare HTTPS.

#
# Recommended minimum configuration:
#
acl manager proto cache_object
acl localhost src 127.0.0.1/32 ::1
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1

# Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
# should be allowed
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged) machines

acl SSL_ports port 443
acl Safe_ports port 80      # http
acl Safe_ports port 21      # ftp
acl Safe_ports port 443     # https
acl Safe_ports port 70      # gopher
acl Safe_ports port 210     # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280     # http-mgmt
acl Safe_ports port 488     # gss-http
acl Safe_ports port 591     # filemaker
acl Safe_ports port 777     # multiling http
acl CONNECT method CONNECT

# Authorization

auth_param digest program /usr/lib64/squid/digest_pw_auth -c /etc/squid/squid_passwd
auth_param digest children 20 startup=0 idle=1
auth_param digest realm squid
auth_param digest nonce_garbage_interval 5 minutes
auth_param digest nonce_max_duration 30 minutes
auth_param digest nonce_max_count 50

acl authenticated proxy_auth REQUIRED

#
# Recommended minimum Access Permission configuration:
#
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager

# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# We strongly recommend the following be uncommented to protect innocent
# web applications running on the proxy server who think the only
# one who can access services on "localhost" is a local user
#http_access deny to_localhost

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#

# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
#http_access allow localnet
#http_access allow localhost
http_access allow authenticated

# And finally deny all other access to this proxy
http_access deny all

# Squid normally listens to port 3128
http_port 3128

https_port 3129 cert=/etc/squid/ssl/cert.pem key=/etc/squid/ssl/key.pem

# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ?

# Disable all caching
cache deny all

# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/spool/squid 100 16 256

# Leave coredumps in the first cache dir
coredump_dir /var/spool/squid

# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp:       1440    20% 10080
refresh_pattern ^gopher:    1440    0%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .       0   20% 4320

Usando questa configurazione, il proxy HTTP funziona bene, ma il proxy HTTPS no.

Ecco una richiesta proxy HTTP da una casella locale:

$ curl --proxy http://my-proxy-server.example:3128 \
  --proxy-anyauth --proxy-user redacted:redacted -w '\n' \
  http://urlecho.appspot.com/echo?body=OK
OK

Bene, è quello che mi aspettavo. Ciò si traduce in una riga in /var/log/squid/access.log:

1390250715.137     41 my.IP.address.redacted TCP_MISS/200 383 GET http://urlecho.appspot.com/echo? redacted DIRECT/74.125.142.141 text/html

Ecco un'altra richiesta, questa volta con HTTPS:

$ curl --proxy https://my-proxy-server.example:3129 \
  --proxy-anyauth --proxy-user redacted:redacted -w '\n' \
  http://urlecho.appspot.com/echo?body=OK

curl: (56) Recv failure: Connection reset by peer

Niente access.logdopo questo, ma in cache.log:

2014/01/20 20:46:15| clientNegotiateSSL: Error negotiating SSL connection on FD 10: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request (1/-1)

Ecco di nuovo quanto sopra, in modo più dettagliato:

$ curl -v --proxy https://my-proxy-server.example:3129 \
  --proxy-anyauth --proxy-user redacted:redacted -w '\n' \
  http://urlecho.appspot.com/echo?body=OK
* Adding handle: conn: 0x7f9a30804000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7f9a30804000) send_pipe: 1, recv_pipe: 0
* About to connect() to proxy my-proxy-server.example port 3129 (#0)
*   Trying proxy.server.IP.redacted...
* Connected to my-proxy-server.example (proxy.server.IP.redacted) port 3129 (#0)
> GET http://urlecho.appspot.com/echo?body=OK HTTP/1.1
> User-Agent: curl/7.30.0
> Host: urlecho.appspot.com
> Accept: */*
> Proxy-Connection: Keep-Alive
> 
* Recv failure: Connection reset by peer
* Closing connection 0

curl: (56) Recv failure: Connection reset by peer

Sembra un errore SSL. Tuttavia, sto riutilizzando un certificato SSL con caratteri jolly del sottodominio, mostrato nella configurazione precedente come cert.peme key.pem, che ho distribuito correttamente su altri server Web. Inoltre, l'accesso al server proxy direttamente con curl funziona o almeno stabilisce una connessione oltre la fase SSL:

$ curl https://my-proxy-server.example:3129
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>ERROR: The requested URL could not be retrieved</title>

[--SNIP--]

<div id="content">
<p>The following error was encountered while trying to retrieve the URL: <a href="https://serverfault.com/">/</a></p>

<blockquote id="error">
<p><b>Invalid URL</b></p>
</blockquote>

<p>Some aspect of the requested URL is incorrect.</p>

<p>Some possible problems are:</p>
<ul>
<li><p>Missing or incorrect access protocol (should be <q>http://</q> or similar)</p></li>
<li><p>Missing hostname</p></li>
<li><p>Illegal double-escape in the URL-Path</p></li>
<li><p>Illegal character in hostname; underscores are not allowed.</p></li>
</ul>

[--SNIP--]

Qualche idea su cosa sto facendo di sbagliato? Ciò che sto tentando è anche possibile? Grazie in anticipo.

— David
fonte

2

Non penso sia così che dovrebbe funzionare Squid. Dovrei essere in grado di effettuare una richiesta HTTP o HTTPS inoltrata tramite una connessione HTTPS. Non vedo nulla nella documentazione per suggerire diversamente. Indipendentemente da ciò, ho provato quello che mi suggerisci comunque, e non ha funzionato (stesso risultato di cui sopra).

— David,

Il mio commento precedente era in risposta ai commenti di un altro utente che sembrano essere stati eliminati. Volevo solo notare che ho inviato questa domanda alla mailing list di Squid: mail-archive.com/squid-users@squid-cache.org/msg93592.html

— David

Come qualcuno che aveva uno scenario simile, abbiamo provato l'approccio proxy, ci siamo riusciti e quindi abbiamo preferito spostare l'applicazione da Heroku a un provider come una macchina virtuale / dedicata con un IP statico. Vi è un ulteriore sovraccarico nel mantenere un server proxy forward solo per questo scopo.

— Shyam Sundar CS,

1

@David, secondo il tuo thread in Squid ML - Suggerirei di andare con la soluzione Stunnel. La tua autenticazione sarebbe il certificato SSL su entrambe le estremità del tunnel, il resto diventa "testo in chiaro" all'interno di quel tunnel o potresti fare Digest come desideri.

Ho usato una soluzione simile per "autenticare" gli endpoint NFS con grande successo.

Un esempio di utilizzo di tale autenticazione potrebbe essere visto nella comunicazione sicura di LinuxGazette con stunnel

— Droopy4096
fonte

1

Puoi vedere come è fatto in questa piccola immagine Docker: yegor256 / squid-proxy . Il problema con il tuo codice è che la configurazione segue le aclistruzioni. Basta scambiarli e tutto inizia a funzionare.

— yegor256
fonte