Configurer Squid en tant que proxy direct HTTPS?

9

Voici quelques informations sur mon problème:

J'ai un service Web fonctionnant sur Heroku, avec une adresse IP dynamique. Les adresses IP statiques sur Heroku ne sont pas une option.
Je dois me connecter à un service Web externe situé derrière un pare-feu. Les personnes qui exploitent le service Web externe n'ouvriront leur pare-feu qu'à une adresse IP statique spécifique.

Ma tentative de solution consiste à utiliser Squid sur un serveur séparé avec une adresse IP statique pour transférer les requêtes proxy d'Heroku au service externe. De cette façon, le service externe voit toujours l'IP statique du serveur proxy, au lieu de l'IP dynamique du service Heroku.

Étant donné que mon serveur proxy ne peut pas compter sur une adresse IP pour l'authentification (c'est le problème pour commencer!), Il doit s'appuyer sur un nom d'utilisateur et un mot de passe. De plus, le nom d'utilisateur et le mot de passe ne peuvent pas être transmis en texte clair, car si un attaquant interceptait ce texte clair, il pourrait se connecter à mon proxy en se faisant passer pour moi, faire des demandes sortantes en utilisant l'IP statique de mon proxy, et ainsi échapper à l'extérieur pare-feu du service Web.

Par conséquent, le proxy Squid ne doit accepter que les connexions via HTTPS, pas HTTP. (La connexion au service Web externe peut être HTTP ou HTTPS.)

J'utilise Squid 3.1.10 sur CentOS 6.5.x, et voici mon squid.confjusqu'ici. À des fins de dépannage uniquement, j'ai temporairement activé le proxy HTTP et HTTPS, mais je souhaite uniquement utiliser 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

Avec cette configuration, le proxy HTTP fonctionne correctement, mais pas le proxy HTTPS.

Voici une demande de proxy HTTP à partir d'une boîte 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

Bon, c'est ce que j'attendais. Il en résulte une ligne dans /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

Voici une autre demande, cette fois avec 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

Rien access.logaprès celui-ci, mais dans 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)

Voici ce qui précède, plus verbeusement:

$ 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

Ressemble à une erreur SSL. Cependant, je réutilise un certificat SSL de sous-domaine avec caractères génériques, indiqué dans la configuration ci-dessus comme cert.pemet key.pem, que j'ai réussi à déployer sur d'autres serveurs Web. De plus, l'accès au serveur proxy directement avec curl fonctionne, ou au moins établit une connexion après l'étape 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--]

Des idées sur ce que je fais mal? Est-ce que j'essaie même possible? Merci d'avance.

— David
source

2

Je ne pense pas que c'est ainsi que Squid est censé fonctionner. Je devrais être en mesure de faire une requête HTTP ou HTTPS par proxy via une connexion HTTPS. Je ne vois rien dans la documentation pour suggérer le contraire. Quoi qu'il en soit, j'ai quand même essayé ce que vous proposez, et cela n'a pas fonctionné (même résultat que ci-dessus).

— David

Mon commentaire précédent était en réponse à des commentaires d'un autre utilisateur qui semblent avoir été supprimés. Je voulais juste noter que j'ai posté cette question sur la liste de diffusion Squid: mail-archive.com/squid-users@squid-cache.org/msg93592.html

— David

En tant que personne qui avait un scénario similaire, nous avons essayé l'approche proxy, réussi et ensuite favorisé le déplacement de l'application loin de Heroku vers un fournisseur comme une machine virtuelle / dédiée avec une IP statique. Il existe un surcoût supplémentaire lié à la maintenance d'un serveur proxy de transfert uniquement à cette fin.

— Shyam Sundar CS

1

@David, selon votre fil dans Squid ML - je suggérerais d'aller avec la solution Stunnel. Votre authentification serait les certificats SSL aux deux extrémités du tunnel, le reste va en "texte clair" dans ce tunnel, ou vous pourriez faire un résumé comme vous le souhaitez.

J'ai utilisé une solution similaire pour «authentifier» les points de terminaison NFS avec beaucoup de succès.

Un exemple d'utilisation d'une telle authentification peut être vu dans la communication sécurisée de LinuxGazette avec stunnel

— Droopy4096
source

1

Vous pouvez voir comment cela se fait dans cette petite image Docker: yegor256 / squid-proxy . Le problème avec votre code est que la configuration va après l' aclinstruction. Échangez-les et tout commence à fonctionner.

— yegor256
source