Re: FreeBSD-basierter Firewall

Bernhard(at)gtkx.de wrote:
> ich bin entsetzt wie hier argumentiert wird
>
> von was reden wir?
>
> wir reden wie eine sichere verbidung, aus was für gründen auch immer,
> beschnüffelt werden soll.

Nun komm mal wieder runter ... Du hast noch nie bei einer
Firma eine Firewall oder einen Virenscanner aufgesetzt, nicht
wahr? Das "Aufbrechen" von SSL-Verbindungen ist da Standard,
fast jede größere Firma macht das. Und stell Dir mal vor:
Das ist sogar vollkommen legal. Sonst würde das spätestens
beim nächsten ISO9k-TÜV-Audit auffliegen.

Der Begriff "Aufbrechen" ist eigentlich auch übertrieben (und
vielleicht flößt es Dir deswegen etwas Angst ein). Ich versuch
mal, es Dir zu erklärenm, da Du Dich offenbar mit so Internet-
Protokollen nicht so gut auskennst ... Also, die SSL-Verbindung
zum Web-Server terminiert ganz normal auf dem Proxy (Firewall,
Virenscanner, was auch immer), der aus Server-Sicht den Client
darstellt. Der Proxy verwendet dann eine neue SSL-Verbindung
zum internen Client, für die er ein neues Zertifikat mit einer
eigenen CA erzeugt (die vom Admin ggf. auf den internen Clients
hinterlegt wurde).

Der entscheidende Punkt dabei ist, dass das Zertifikat zwar auf
den Namen des ursprünglichen Webservers ausgestellt ist, aber
nicht zu dessen CA zurückverfolgt werden kann. Das Original-
Zertifikat kann der Proxy nicht "faken". Daher ist dieser
Vorgang _nicht_ transparent, denn der Client sieht nicht mehr
das Zertifikat der Web-Server-CA, sondern das, das von der
internen CA erzeugt wurde. Insofern kann man auch _nicht_ von
"Man-in-the-middle" reden. Ein erfolgreicher MITM-Angriff wäre
nicht feststellbar, d.h. transparent.

Man sollte sich auch vor Augen halten, dass SSL verschiedene
Aufgaben hat. Zum einen soll der Übertragungsweg verschlüsselt
und somit "sicher" vor fremden Zuhörern sein. Dies ist auch
bei dem beschriebenen Proxy der Fall, da keine Klartext-Daten
im Netz auftauchen, weder intern noch extern. Zweitens dient
SSL der Sicherstellung der Identität der beteiligten Partner
anhand eines gültigen Zertifikats. Diese Prüfung wird in dem
Szenario vom Proxy durchgeführt, ist somit auch kein Problem.

Natürlich könnte der Admin des Proxies theoretisch die Daten
mitlesen, die auf dem Proxy ja zum Scannen vorübergehend
entschlüsselt werden (das ist ja der Sinn der Übung). Aber
das ist vollkommen irrelevant, denn der Admin könnte sie ja
auch ebensogut auf dem Client mitlesen, der sie ja ohnehin
entschlüsseln muss. Letzteres wäre technisch sogar einfacher
durchzuführen.

Man kann es nicht oft genug betonen: SSL hat, ebenso wie ssh,
die Grundvoraussetzung, dass man beiden Endpunkten traut. (Das
ist auch der Grund, warum man z.B. in einem Internet-Cafe auf
gar keinen Fall Online-Banking machen oder sich per ssh irgendwo
einloggen sollte.)

In einer Firma gehört der SSL-Endpunkt (Client) der Firma, d.h.
Du musst zwangsläufig der Firma und deren Admins trauen, ob
Du willst oder nicht, und zwar ganz egal, ob Deine SSL-Sachen
irgendwo "aufgebrochen" werden oder nicht.

Langer Rede kurzer Sinn: Es ist sowohl juristisch als auch
technisch völlig irrelevant, ob SSL-Verbindungen "aufgebrochen"
werden oder nicht.

Noch eine Anmerkung:

> in einem gut verwaltetem netzwerk verwendet man switch und keine hub
> und dann geht da vom client aus nix mit ausspionieren

Darauf solltest Du Dich nicht verlassen. Unter bestimmten
Bedingungen kann man auch in einem geswitchten Netz Daten
mitlesen, oder zumindest einen Teil. Da gibt es verschiedene
Angriffsmöglichkeiten, siehe z.B. Arp-Cache-Poisoning. Dem
kann man administrativ entgegenwirken, aber auch nicht immer
(kommt auf die Umstände an). Und in einem WLAN ist nichts
geswitcht, da kannst Du immer mitlauschen. Da hilft Dir auch
WPA o.ä. nicht, denn alle internen (Firmen-)Clients haben ja
den Schlüssel. (Auch hier kann man mit hinreichend Aufwand
entgegenwirken, aber das wird in der Praxis kaum gemacht.)

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"And believe me, as a C++ programmer, I don't hesitate to question
the decisions of language designers.  After a decent amount of C++
exposure, Python's flaws seem ridiculously small." -- Ville Vainio
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message