Mit dem Erscheinen des ersten Bandes im Dezember werden hier die Slides, Fragen und Antworten sowie Korrekturen angeboten.

In engem Zusammenhang mit dem Buch steht eine Vorlesung im Computer-Science and Media Bachelor mit dem Titel "Advanced Internet Security". Dort finden Sie weitere Materialien zum Thema Firewall Architektur, Security Policies und Frameworks zum Aufbau einer Sicherheitsstrategie in Firmen, XML-Security, Web-Services, Firewallproblematik einzelner Services sowie stateless und stateful filtering mit Beispielen. Ebenso finden Sie dort einen Fragenkatalog zum Thema Security. Advanced Internet Security.

Neben Vorlesungen und Seminaren zu Crypthographie, Protokollen und Sicherer Software bietet die Fakultät CS&M weiter Trainings zum Thema Security, u.a. mit unserem Partner Jochen Bauer und dem Steinbeiss Zentrum für Mobile communication and embedded systems" an. Sie finden weitere Information zu den Aktivitäen hier . Gerne stellen wir für Firmen und Organisationen ein auf diese zugeschnittenes Programm zusammen.

Sie können sich für unseren Newsletter registrieren und erhalten dann Nachricht wenn besondere Security Days anstehen. Wir haben uns in der Vergangenheit auf diesen Tagen mit den verschiedensten Themen wie Underground Economy, live hacking, web application firewalls, mainframe security etc. auseinandergesetzt und dabei Top Spezialisten der Industrie zu Gast gehabt. Auch eigene Arbeiten von Diplomanden und Staff z.B. zu Vista Security wurden erfolgreich vorgestellt.

Der nächste Security Day findet im Mail 2008 statt und wird als Themen Risikowahrnehmung und Einschätzung, Forensik und Industriespionage haben.

Ziel eines SCIP Proxies ist es, einen Zugriff auf den Datenstrom für Content- und Malware Scanning zu ermöglichen, und damit dem Proxy die Schutzfunktion für die interne Infrastruktur zurück zu geben, die bei den unverschlüsseltem Datenprotokollen z.B. als HTTP Proxy bereits einen festen Platz in den meisten Sicherheitskonzepten hat.

Ein Beispiel für eine kommerzielle Implementierung liefert Microdasys jedoch gibt es auch open source Projekte und auch im Software-Technik Praktikum im Studiengang Medieninformatik der HDM wurde im Wintersemester 05/06 vor ein SCIP Proxy von Alexander Koch, Florian Graßl, Sven Höckel und Elke Kniesel entwickelt.

Hinter den sog. SCIP Proxies steckt jedoch manchmal ein Problem der Authentisierung von Clients auf das uns Matthias Schmidt und Thomas Huber aufmerksam gemacht haben. Es geht dabei um die Frage wie ein Server sicher sein kann dass NACH einer erfolgten Authentisierung der folgende Request tatsächlich vom selben Client kommt. Und letztlich um die Frage wie weit Server und Client letztendlich doch aufeinander angewiesen sind um eine Interaktion sicher und zuverlässig durchführen zu können.

Die Frage nach der Identität des Clients beim zweiten Request scheint zunächst unsinnig: Es gibt doch Mechanismen die eine Session garantieren, d.h. die gleichbleibende Identität zweier kommunizierender Partner. Z.b. kann der Server ein Cookie setzen das im folgenden Request wieder zurückgeschickt wird und anhand dessen der Server den Request dem entsprechenden Client zuordnen kann. Alternativen sind URL-rewriting oder - wie wir im Buch empfehlen - die Verwendung der SSL-SessionID. Diese ID hat den Vorteil dass sie nicht im Cookie Verzeichnis des Browsers auftaucht und daher auch nicht so leicht durch eine Attacke auf den Browser des Clients entwendet und für die übernahme der Session durch einen Angreifer verwendet werden kann.

Diese Empfehlung berücksichtigt jedoch nicht die sog. SCIP Proxies. Bei diesen Proxies handelt es sich um Clientseitige Proxies die meist von grossen Firmen eingesetzt werden um den sicheren Punkt-zu-Punkt Kanal der SSL Verbindung eines Clientbrowsers innerhalb des Firmennetzes mit einem Server ausserhalb aufzubrechen.

Das Vorgehen beruht dabei auf dem Einsatz eines eigenen Root-Zertifikates das die Firma selber ausstellt und auf ihren Browsern im Trust-Store installiert. Mit Hilfe dieses Root-Zertifikates wird dann ein Server Zertifikat erstellt und auf dem SCIP-Proxy im Key-Store installiert. In der Folge wird der Clientbrowser den SCIP Proxy jederzeit als bekannten Server akzeptieren. Baut der Clientbrowser nun eine SSL Verbindung zu einem externen Server auf, wird er per Browserkonfiguration der Firma auf einen Weg über den SCIP Proxy gezwungen. Der SCIP Proxy seinerseits beendet den SSL Tunnel des Browserclients bereits auf seiner Maschine. Gleichzeitig baut er eine neue Verbindung zum echten externen Server per SSL auf und beginnt die Requests des Clients an diesen zu schicken sowie dessen Antworten an den Client weiterzugeben.

Der Clientbrowser innerhalb der Firma bemerkt davon nichts. Der SCIP Proxy hingegen kann nun alle Kommunikation zwischen Browser und externem Server mühelos mitschneiden. Diese überwachungsfunktion des Client kommt jedoch auch zu einem hohen Preis: Es gibt keinen sicheren Tunnel mehr zwischen Client und Server und wenn der SCIP Proxy kompromittiert würde käme das einem Security-GAU für die Firma gleich. Der externe Server geht ausserdem fälschlicherweise von einer sicheren Verbindung zum Client aus die es in Wirklichkeit nicht gibt da der SCIP Proxy dazwischen steht.

Dmait sind einige grundsätzliche Sicherheitsproblem bereits genannt. Wirklich kritisch wird es jedoch wenn es auf der Seite des SCIP Proxies zu Fehlverhalten kommt. So scheinen einige dieser Proxies so konfiguriert zu sein, dass sie ALLE Sessions der Clients im Falle des gleichen externen Zielservers auf EIN UND DIESELBE SSL SessionID mappen. Der Effekt ist dass der Server die Möglichkeit verliert die verschiedenen Clients hinter eines solchen Proxies zu unterscheiden. Im Fall von kritischen Services wie E-shopping oder E-banking sind die Folgen katastrophal. Clients sehen Daten anderer Clients und können Transaktionen durchführen.

Ein damit verwandtes Problem stellt der Internet Explorer 6 und kleiner dar: dort wird all alle zwei Minuten eine neue SSL SessionID erzeugt und die Aufgabe des Servers ist nun über diese SSL Sessions hinweg eine logische Session zwischen Client und Server aufrecht zu erhalten..

Welche Möglichkeiten hat ein Server sich gegen SCIP Proxies zu wehren? Letztlich kann er nur auf gegenseitiger starker Authentisierung bestehen (auf Basis einer gemeinsamen Certificate Authority). Dies nimmt dem SCIP Proxy die Chance sich als Client auszugeben. Da ein Client-Zertifikat in den wenigsten Fällen vorhanden sein wird bleibt dem Server nur die Aufgabe wenigstens zu entdecken wann ein SCIP Proxy vorliegt bzw. sicherzustellen dass die Clientidentität dort nicht versehentlich vermischt wird. In der Praxis werden beide Probleme: Entdecken sowie die Clientidentität sichern auf die gleichen Massnahmen hinauslaufen: Auswerten aller verfügbaren Information die vom Client kommen: Cookies, IP-Adressen, User-Agent Informationen, Verhalten im Protokoll, spezielle Flags etc. Kommen mehrere Anfragen von der gleichen IP Adresse aber mit verschiedenen, inkompatiblen Inhalten (verschiedene Account Nummern etc.) dann kann der Server bereits die Verwendung eines Proxies erkennen. Wird dabei jedemal die gleiche SSL SessionID verwendet so liegt ein gravierender Fehler auf der Clientseite vor (oder evtl. eine bestimmte Absicht?). Im Grunde genommen läuft das auf eine hochkomplexe Heuristik zur Entdeckung von falsch konfigurierten SCIP Proxies hinaus bei der Fehler immer möglich sind. Die Identität des Clients ist nun das Ergebnis einer Vielzahl von Parameter und lässt sich nicht mehr durch eine einfache SessionID bestimmen.

Insgesammt zeigt sich auch im Fall der SCIP Proxies die Problematik der Client-Server Kommunikation für die Sicherheit. Letztlich ist es Aufgabe des Servers alle zu tun um das Verhalten der Clientseite zu prüfen. Die blosse Annahme dass die Clientseite sich vernünftig verhält ist leider nicht genug. Selbstverständlich ist der Aufwand auf der Serverseite eine Funktion des Businessmodells und wird je nach Geschäftsfall unterschiedlich ausfallen.