Skonfigurować Squid jako proxy przekazywania HTTPS?

9

Oto kilka informacji na temat mojego problemu:

Mam usługę internetową uruchomioną na Heroku, z dynamicznym adresem IP. Statyczne adresy IP na Heroku nie są opcją.
Muszę połączyć się z zewnętrzną usługą internetową za zaporą ogniową. Osoby, które obsługują zewnętrzną usługę internetową, otworzą zaporę tylko dla określonego statycznego adresu IP.

Moim próbowanym rozwiązaniem jest użycie Squid na oddzielnym serwerze ze statycznym adresem IP do przekazywania żądań proxy z Heroku do usługi zewnętrznej. W ten sposób usługa zewnętrzna zawsze widzi statyczny adres IP serwera proxy zamiast dynamicznego adresu IP usługi Heroku.

Ponieważ mój serwer proxy nie może polegać na adresie IP do uwierzytelniania (to jest problem na początek!), Musi on polegać na nazwie użytkownika i haśle. Ponadto nazwa użytkownika i hasło nie mogą być przesyłane jawnym tekstem, ponieważ jeśli osoba atakująca miałaby przechwycić ten czysty tekst, wówczas mogłaby połączyć się z moim serwerem proxy, udając, że jestem mną, wysyłać żądania wychodzące przy użyciu statycznego adresu IP mojego serwera proxy, a tym samym unikać zewnętrznego zapora sieciowa.

Dlatego proxy Squid musi akceptować połączenia tylko przez HTTPS, a nie HTTP. (Połączenie z zewnętrzną usługą internetową może być HTTP lub HTTPS.)

Używam Squid 3.1.10 na CentOS 6.5.x, a oto mój squid.confjak dotąd. Wyłącznie do celów rozwiązywania problemów tymczasowo włączyłem proxy HTTP i HTTPS, ale chcę używać tylko 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

Dzięki tej konfiguracji proxy HTTP działa dobrze, ale proxy HTTPS nie działa.

Oto żądanie proxy HTTP z lokalnego pola:

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

Dobrze, tego się spodziewałem. Wynikiem tego jest wiersz w /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

Oto kolejna prośba, tym razem z 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

Nic access.logpo tym, ale w 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)

Oto powyższe pytanie, bardziej szczegółowo:

$ 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

Wygląda na błąd SSL. Jednak ponownie używam certyfikatu SSL z subdomeną, pokazanego w powyższej konfiguracji jako cert.pemi key.pem, który pomyślnie wdrożyłem na innych serwerach WWW. Ponadto bezpośredni dostęp do serwera proxy za pomocą curl działa lub przynajmniej ustanawia połączenie poza etapem 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--]

Jakieś pomysły, co robię źle? Czy to, co próbuję, jest w ogóle możliwe? Z góry dziękuję.

— David
źródło

2

Nie sądzę, że tak właśnie powinien działać Squid. Powinienem być w stanie wykonać żądanie HTTP lub HTTPS proxy za pośrednictwem połączenia HTTPS. Nie widzę nic w dokumentacji, co sugerowałoby inaczej. Niezależnie od tego próbowałem i tak, co sugerujesz, i to nie zadziałało (taki sam wynik jak powyżej).

— David

Mój poprzedni komentarz był odpowiedzią na komentarze innego użytkownika, które prawdopodobnie zostały usunięte. Chciałem tylko zauważyć, że wysłałem

— David

Jako ktoś, kto miał podobny scenariusz, wypróbowaliśmy podejście proxy, udało się, a następnie opowiedzieliśmy się za przeniesieniem aplikacji z Heroku do dostawcy takiego jak maszyna wirtualna / dedykowana ze statycznym adresem IP. Dodatkowy narzut związany z utrzymywaniem przekierowującego serwera proxy tylko w tym celu.

— Shyam Sundar CS

1

@David, według twojego wątku w Squid ML - sugerowałbym skorzystanie z rozwiązania Stunnel. Twoje uwierzytelnienie to certyfikaty SSL na obu końcach tunelu, reszta przechodzi w „czysty tekst” w tym tunelu, lub możesz przeprowadzić Digest, jak chcesz.

Z wielkim sukcesem zastosowałem podobne rozwiązanie do „uwierzytelnienia” punktów końcowych NFS.

Przykładowe użycie takiego uwierzytelnienia można zobaczyć w Bezpiecznej komunikacji LinuxGazette z stunnelem

— Droopy4096
źródło

1

Możesz zobaczyć, jak to się robi na tym małym obrazku Docker: yegor256 / squid-proxy . Problem z twoim kodem polega na tym, że konfiguracja idzie za aclinstrukcją. Po prostu zamień je i wszystko zacznie działać.

— yegor256
źródło