Reverse Proxy mit Wildcard Zertifikat von trusted CA

[LSassl]

Guten Abend!
Lässt sich der Reverse Proxy für HTTPS-Verbindungen mit einem Wildcardzertifikat (*.domain.com) nutzen?
Lt. Doku muss der Zertifikatsname der URL entsprechen (logisch). Squid selbst bietet eine Unterstützung hierfür. Wie sieht es mit SANs im Zertifikat aus? Gibt es hier (bekannte) Probleme?
Vielen Dank für eure Antworten!

Gruß Lukas

[Erik]

Sowohl Wildcard-Zertifikate als auch Zertifikate mit einem Alias (SAN) können für den Reverse-Proxy verwendet werden. Ob Ihr Client die dann "grün" anzeigt oder nicht, ist dessen Sache

[LSassl]

Hallo Erik,

danke für deine Antwort. Ich habe nun soweit die Reverse Proxy Geschichte mit Wildcardzertifikat eingerichtet. Die Kommunikation ist momentan mit SSL Offloading zwischen Appliance und Exchange 2010 Server eingerichtet (WAN -(HTTPS443)-> APPLIANCE -(HTTP80)-> Exchange. Einsetzen würde ich jedoch gerne reverse SSL. Sobald ich dies jedoch entsprechend konfiguriert ist, läuft die Verbindung scheinbar ins Leere bzw. das Webinterface von OWA erscheint nicht. Stattdessen arbeitet der Browser und läuft irgendwann in einen Timeout. Folgendes habe ich schon gemacht um auszuschließen, dass es an der Vertrauensstellung scheitert: 1. Zertifikat auf interne IP-Adresse Exchange ausgestellt (hausinterne PKI)
2. Zertifikate der Zertifizierungsstellen importiert (Appliance)
3. Sperrlisten importiert

Hast du noch eine Idee oder einen Vorschlag?

[Erik]

In meinen Augen macht es relativ wenig Sinn, den Reverse-Proxy SSL ans Backend weiterreichen zu lassen. Hauptaufgabe ist nun mal, die CPU des Zielservers von den SSL-Geschichten zu befreien. Genau das hat sich wahrscheinlich auch die Entwicklung gedacht, als sie das implementiert hat, weswegen der Reverse-Proxy immer HTTP ans Backend schickt.

Das ist auch der Grund, warum "es" nicht funktioniert:
Sie tragen Port 443 ein, auf dem der Exchange SSL erwartet, aber der Proxy schickt dort HTTP hin.

Ich habe mal ein Ticket erstellt, sodass das (vielleicht) in Zukunft einstellbar sein wird.

[LSassl]

Ja, da hast du recht. I.d.R. sollte das Netz zwischen Appliance und Exchange "sicher" und somit eine HTTP-Kommunikation zwischen den beiden ausreichend sein. Danke fürs erstellen des Tickets. Mal schauen was die Zukunft bringt.

Jetzt ist mir beim Testen noch eine weitere Sache aufgefallen (ggf. neues Topic der Übersichtlichkeit halber)?
Der Zugriff auf Outlook Web App ist beispielsweise möglich. Wird jedoch ein Zugriff auf EAS (Exchange ActiveSync) oder Outlook Anywhere gestartet, erfolgt eine Credentialsabfrage. Diese wiederholt sich permanent und eine Verbindung ist nicht möglich. Eingerichtet ist auf dem System die Standardauthentifizierung.
Im Log wird ein 401 (nicht autorisierter Zugriff) protokolliert. Das war es dann aber auch:

2012-11-26 18:02:11 192.168.100.15 OPTIONS /Microsoft-Server-ActiveSync/default.eas - 80 - 192.168.100.254 Apple-iPhone4C1/1001.523 401 2 5 0

Hast du hierzu noch eine Idee?

[Erik]

Ich habe gerade keinen Zugriff auf eine 11er, daher kann ich es nicht verifizieren. Aber ich vermute, dass es damit zusammenhängt, dass da ein OPTIONS-Query verschickt wird und kein "normaler" GET oder POST.
Evtl können Sie eine ACL für den Reverse-Proxy schreiben, der auch die anderen "request_method"s erlaubt.

[LSassl]

Das klingt durchaus plausibel. Ich teste es dann mal und werde berichten. Nochmal zur ACL: Diese erstelle ich "manuell" in der squid-reverse-sites.conf ?

[Erik]

Extras -> Erweiterte Einstellungen -> Templates -> /etc/squid/squid-reverse.conf
vor der Zeile

Code: Alles auswählen

# finally include the reverse proxy site definitions

fügen Sie ein:

Code: Alles auswählen

acl OPTIONS method OPTIONS
http_access allow OPTIONS

Sollte das nicht fruchten, gilt es herauszufinden, ob nicht der Server ein 401 zurückgibt:

Code: Alles auswählen

# tcpdump -i <internes-interface> -np -s0 -A host <server-ip> and port 80

Ähm ja. Und dann hoffen Sie, dass da gerade nicht viele Zugriffe erfolgen

[LSassl]

Okay, das hab ich jetzt soweit durchgeführt. Der Aufruf scheitert jedoch weiterhin.
tcpdump wirft folgendes aus (nicht wundern, läuft momentan über Port 449):

Jx.....OPTIONS /Microsoft-Server-ActiveSync HTTP/1.1
Host: intern.domain.com:449
X-MS-PolicyKey: 0
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: de-de
Content-Length: 0
User-Agent: Apple-iPhone5C2/1001.405
Via: 1.1 BORDERGW.domain.dom (squid/3.2.1)
Surrogate-Capability: BORDERGW.domain.dom="Surrogate/1.0"
X-Forwarded-For: 12.345.67.890
Cache-Control: max-age=259200
Connection: keep-alive

Jx.HTTP/1.1 401 Unauthorized
Content-Type: text/html
Server: Microsoft-IIS/7.5
WWW-Authenticate: Basic realm="intern.domain.com"
X-Powered-By: ASP.NET
Date: Wed, 28 Nov 2012 13:39:10 GMT
Content-Length: 1344





401 - Nicht autorisiert: Zugriff aufgrund ung.ltiger Anmeldeinformationen verweigert.

<!--

Ein Aufruf über http://exchange/Microsoft-Server-ActiveSync unter Verwendung der Zugangsdaten ist erfolgreich. Irgendwas läuft da bei der Authentifizierung schief...

[LSassl]

Ich glaube ich habe die Lösung zu der Problematik gefunden. Eventuell kannst du mir einen Tipp geben wie ich das in eure Squid-Configuration implementieren kann:

Problembeschreibung:
http://www.squid-cache.org/mail-archive ... /0232.html

Lösungsansatz:
http://www.squid-cache.org/mail-archive ... /0247.html
http://www.squid-cache.org/mail-archive ... /0235.html

[Erik]

Ja das könnte gehen. Aber Achtung: Alles folgende "verschwindet" wieder, sobald der Proxy über die GUI neu gestartet wird!
Zum Finden des Problems reicht es aber

Als erstes müssen Sie den Reverse-Proxy so konfigurieren, dass er erstmal "läuft" (ich gehe davon aus, dass das bereits der Fall ist) und auch gestartet ist.

Loggen Sie sich auf der Firewall mit einem root-Account ein und öffnen Sie die Datei /etc/squid/squid-reverse-sites.conf

Code: Alles auswählen

# vi /etc/squid/squid-reverse-sites.conf

jetzt drücken Sie "i", navigieren dann mit den cursor in die cache_peer Zeile und schreiben zwischen "originserver" und "name=..." das Folgende:

Code: Alles auswählen

login=PASS connection-auth=on

Die Zeile sollte also ähnlich dieser aussehen:

Code: Alles auswählen

cache_peer 192.168.179.20 parent 80 0 no-query originserver  login=PASS connection-auth=on name=peer_0001_0000

Jetzt drücken Sie nacheinander:
Esc
:
w
q
Enter

Jetzt geht der Editor wieder zu.
Als nächstes gilt es die PID des Squid herauszufinden:

Code: Alles auswählen

# ps aux | grep -i squid-reverse.conf | grep -v grep | awk '{print $2}'

Um die Config des Squid neu zu laden, führen Sie jetzt aus

Code: Alles auswählen

# kill -1 DIE_PID

Das hinter dem "kill" ist ein Minus gefolgt von der Ziffer Eins.

Versichern Sie sich noch mittels

Code: Alles auswählen

# spcli syslog get

dass Sie keinen Tippfehler in der Config haben und dann können Sie den Zugriff nochmal probieren.
Wenn die Anmeldung korrekt durchgereicht wird, sehen Sie im tcpdump in dem OPTIONS-Request auch einen "Authorization"-Header.

Sollte das dann funktionieren, sagen Sie bitte Bescheid, dann werde ich ein Ticket dafür erstellen

[LSassl]

Soo, ich hab das grade mal soweit durchgeführt und siehe da, es funktioniert. Outlook Anywhere (RPC over HTTP(s)) sollte damit dann ebenfalls abgefrühstückt sein (kann es leider im Moment nicht testen). Weiterhin werde ich mal prüfen in wie weit RD Gateway über den Reverse Proxy läuft. To be continued ...

[LSassl]

So, also wie bereits vermutet. Basic Authentification funktioniert wie unten beschrieben korrekt. Anders sieht es dagegen z.B. beim NTLM Authentifizierungsverfahren aus. Lässt sich dieses und auch andere (z.B. Kerberos) Authentifizierungsverfahren aktivieren?

[LSassl]

Scheinbar wird die Authentifizierung per NTLM wohl doch unterstützt:

Code: Alles auswählen

2012-12-06T16:52:53+01:00|squid |31511|Startup: Initializing Authentication Schemes ...
2012-12-06T16:52:53+01:00|squid |31511|Startup: Initialized Authentication Scheme 'basic'
2012-12-06T16:52:53+01:00|squid |31511|Startup: Initialized Authentication Scheme 'digest'
2012-12-06T16:52:53+01:00|squid |31511|Startup: Initialized Authentication Scheme 'negotiate'
2012-12-06T16:52:53+01:00|squid |31511|Startup: Initialized Authentication Scheme 'ntlm'
2012-12-06T16:52:53+01:00|squid |31511|Startup: Initialized Authentication.

Bei der Verwendung von RD-Gateway kommt NTLM zum Einsatz. Ich vermute, dass der Client das UTM Gateway als Endpunkt sieht bzw. dieses die erzeugten Authentifizierungs-Hashs nicht korrekt an den eigentlichen Endpunkt weiterreicht.

[Erik]

Man liest auf diversen Mailinglisten, dass es da einen Bug im Squid in Bezug auf NEGOTIATE/NTLM gibt:
http://bugs.squid-cache.org/show_bug.cgi?id=3655

Wir verwenden Squid 3.2.1, also ist es gut möglich, dass das Problem besteht. Ich werde die Entwicklung mal bitten, über den Code zu schauen.

[LSassl]

Das bringt die Sache auf den Punkt. Ich warte dann mal und hoffe, dass es einen Fix von eurer Seite oder ein Update auf Version 3.2.2 gibt

[LSassl]

Schön wären auch noch nachfolgende Funktionen (wenn wir schon dabei sind):

Auswahl ob HTTPS-to-HTTP oder HTTPS-to-HTTPS eingesetzt werden soll. Bei HTTPS-to-HTTPS muss dann nachfolgendes verwendet werden:

Code: Alles auswählen

cache_peer ip_of_owa_server parent 443 0 no-query originserver login=PASS ssl sslcert=/path/to/client-certificate name=owaServer

Quelle: http://wiki.squid-cache.org/ConfigExamp ... kWebAccess

[Erik]

Kommt mit der 11.2

[LSassl]

Kommt mit der 11.2

Sehr gut

[LSassl]

Wie versprochen sind die Änderungen in der Version 11.2 berücksichtigt worden. Ich werde es in den kommenden Tagen testen und dann berichten.

[LGsys]

Zu früh gefreut! HTTPs to HTTPs kommt wohl erst mit der Version 11.3. :-(
Man kann nun zwar einen Zielport angeben, aber anscheinend wird auch beim Zielport 443 nur http und kein https gesprochen.

[Erik]

In der Tat wurde das Ticket in zwei Hälften geteilt und die SSL-Umsetzungs-Geschichte hat es im Gegensatz zur NTLM-Auth nicht mehr in 11.2 geschafft.

[LSassl]

In der Tat wurde das Ticket in zwei Hälften geteilt und die SSL-Umsetzungs-Geschichte hat es im Gegensatz zur NTLM-Auth nicht mehr in 11.2 geschafft.

Ich kann auf jeden Fall schon mal sagen, dass HTTPS-to-HTTP (ssl-offloading) stabil funktioniert und dass die NTLM Authentifizierung korrekt durchgereicht wird.

[LSassl]

Wer den Reverse Proxy in Verbindung mit RD Gateway nutzt und dabei den Windows 8 Clients bzw. Windows 7 + KB2592687 RDP-Client nutzt, wird nur über Smartcard eine Authentifizierung hinbekommen. Abhilfe schafft hier nur die Deinstallation des genannten Patches bzw. bei Windows 8 die Verwendung einer Smartcard. Weitere Informationen hierzu finden sich hier: http://bugs.squid-cache.org/show_bug.cgi?id=3776