Squid als HTTPS-Forward-Proxy konfigurieren?

9

Hier einige Hintergrundinformationen zu meinem Problem:

Ich habe einen Webdienst auf Heroku mit einer dynamischen IP-Adresse. Statische IPs auf Heroku sind keine Option.
Ich muss eine Verbindung zu einem externen Webdienst herstellen, der sich hinter einer Firewall befindet. Die Personen, die den externen Webdienst betreiben, öffnen ihre Firewall nur für eine bestimmte statische IP.

Meine versuchte Lösung besteht darin, Squid auf einem separaten Server mit einer statischen IP-Adresse zu verwenden, um Proxy-Anforderungen von Heroku an den externen Dienst weiterzuleiten. Auf diese Weise sieht der externe Dienst immer die statische IP des Proxyservers anstelle der dynamischen IP des Heroku-Dienstes.

Da sich mein Proxyserver für die Authentifizierung nicht auf eine IP-Adresse verlassen kann (das ist zunächst das Problem!), Muss er sich auf einen Benutzernamen und ein Kennwort stützen. Außerdem können der Benutzername und das Kennwort nicht im Klartext übertragen werden. Wenn ein Angreifer diesen Klartext abfängt, kann er eine Verbindung zu meinem Proxy herstellen, der vorgibt, ich zu sein, ausgehende Anforderungen mithilfe der statischen IP-Adresse meines Proxys stellen und so der externen IP ausweichen Firewall des Webdienstes.

Daher darf der Squid-Proxy nur Verbindungen über HTTPS akzeptieren, nicht über HTTP. (Die Verbindung zum externen Webdienst kann HTTP oder HTTPS sein.)

Ich verwende Squid 3.1.10 unter CentOS 6.5.x und hier ist meine squid.confbisherige. Nur zur Fehlerbehebung habe ich vorübergehend sowohl HTTP- als auch HTTPS-Proxy aktiviert, möchte jedoch nur HTTPS verwenden.

#
# 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

Mit diesem Setup funktioniert das HTTP-Proxying einwandfrei, das HTTPS-Proxying jedoch nicht.

Hier ist eine HTTP-Proxy-Anfrage von einer lokalen Box:

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

Gut, das habe ich erwartet. Dies führt zu einer Zeile 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

Hier ist eine weitere Anfrage, diesmal mit 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

Nichts access.lognach diesem, aber 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)

Hier noch einmal ausführlicher:

$ 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

Sieht aus wie ein SSL-Fehler. Ich verwende jedoch ein Subdomain-Wildcard-SSL-Zertifikat, das in der obigen Konfiguration als cert.pemund angezeigt wird und key.pemdas ich erfolgreich auf anderen Webservern bereitgestellt habe. Darüber hinaus funktioniert der direkte Zugriff auf den Proxyserver mit Curl oder stellt zumindest eine Verbindung nach der SSL-Phase her:

$ 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="/server//">/</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--]

Irgendwelche Ideen, was ich falsch mache? Ist das, was ich versuche, überhaupt möglich? Danke im Voraus.

— David
quelle

2

Ich glaube nicht, dass Squid so funktionieren soll. Ich sollte in der Lage sein, entweder eine HTTP- oder eine HTTPS-Anfrage über eine HTTPS-Verbindung zu stellen. Ich sehe in der Dokumentation nichts, was etwas anderes vorschlagen könnte. Unabhängig davon habe ich versucht, was Sie sowieso vorschlagen, und es hat nicht funktioniert (gleiches Ergebnis wie oben).

— David

Mein vorheriger Kommentar war eine Antwort auf Kommentare eines anderen Benutzers, die scheinbar gelöscht wurden. Ich wollte nur beachten, dass ich diese Frage in die Squid-Mailingliste gepostet habe: mail-archive.com/squid-users@squid-cache.org/msg93592.html

— David

Als jemand, der ein ähnliches Szenario hatte, haben wir den Proxy-Ansatz ausprobiert, waren erfolgreich und haben es dann vorgezogen, die Anwendung von Heroku zu einem Anbieter wie Virtual / Dedicated Machine mit einer statischen IP zu verschieben. Die Wartung eines Forward-Proxy-Servers ist nur für diesen Zweck mit einem zusätzlichen Aufwand verbunden.

— Shyam Sundar CS

1

@ David, gemäß Ihrem Thread in Squid ML - ich würde vorschlagen, mit Stunnel-Lösung zu gehen. Ihre Authentifizierung wären die SSL-Zertifikate an beiden Enden des Tunnels, der Rest wird in diesem Tunnel als "Klartext" angezeigt, oder Sie können Digest nach Ihren Wünschen ausführen.

Ich habe eine ähnliche Lösung verwendet, um NFS-Endpunkte mit großem Erfolg zu "authentifizieren".

Ein Beispiel für die Verwendung einer solchen Authentifizierung ist die sichere Kommunikation von LinuxGazette mit stunnel

— Droopy4096
quelle

1

Sie können sehen, wie es in diesem kleinen Docker-Bild gemacht wird: yegor256 / squid-proxy . Das Problem mit Ihrem Code ist, dass die Konfiguration nach der aclAnweisung erfolgt. Tauschen Sie sie einfach aus und alles beginnt zu funktionieren.

— yegor256
quelle