Studienarbeit Marcel Noe

Entwurf und Implementierung
eines Systems zur proaktiven

Erkennung von
Sicherheitsverfahren
Studienarbeit am Institut für Telematik

Prof. Dr. Martina Zitterbart
Fakultät für Informatik
Universität Karlsruhe (TH)
von
cand. inform.
Marcel Noe
Betreuer:
Prof. Dr. Martina Zitterbart
Dipl.-Inform. Lars Völker
Tag der Anmeldung: 1. März 2008

Tag der Abgabe: 30. Juni 2008
Institut für Telematik

Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Karlsruhe, den 30. Juni 2008
Inhaltsverzeichnis
1 Einleitung 1
1.1 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Grundlagen 5
2.1 SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Domain Name System . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 ACCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Analyse 9
3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Einsatz von HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Aufwand von HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Organisatorischer Aufwand von HTTPS . . . . . . . . . . . . 12
3.3.2 Technischer Aufwand von HTTPS . . . . . . . . . . . . . . . . 13
3.3.3 Rechenaufwand von HTTPS . . . . . . . . . . . . . . . . . . . 13
3.4 Gefühlte Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Einschränkung von HTTPS auf Teile von Websites . . . . . . . . . . 15
3.5.1 Link auf HTTP-Seite . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.3 HTTP-Redirect . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.4 Webserver-Konfiguration . . . . . . . . . . . . . . . . . . . . . 15
3.5.5 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6 Problem der Erkennung der Ähnlichkeit von Websites . . . . . . . . . 16
3.6.1 Einfacher Stringvergleich . . . . . . . . . . . . . . . . . . . . . 16
3.6.2 Auswertung des Common-Names im Zertifikat . . . . . . . . . 17
3.6.3 Verwendung eines Mustererkennungs-Algorithmus . . . . . . . 17
3.6.3.1 Der Gestalt-Ansatz . . . . . . . . . . . . . . . . . . . 17
3.6.3.2 Der Ratcliff/Obershelp-Algorithmus . . . . . . . . . 18
3.6.3.3 Umsetzung in dieser Studienarbeit . . . . . . . . . . 20
3.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Entwurf 23
4.1 Entwurf der Software-Komponenten . . . . . . . . . . . . . . . . . . . 23
4.1.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1.1 Test-Module . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1.2 Content-Module . . . . . . . . . . . . . . . . . . . . 25
vi Inhaltsverzeichnis
4.1.2 Mögliche Ergebnisse eines Tests . . . . . . . . . . . . . . . . . 26

4.1.3 Entwurf eines Moduls: Test auf Verfügbarkeit einer Website
mittels HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . 26
4.1.3.2 Entwurf . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Entwurf der Sicherheitsdatenbank . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3 Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.4 Ipaddresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.5 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.6 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.7 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Befüllen der Sicherheitsdatenbank . . . . . . . . . . . . . . . . . . . . 33
4.3.1 Proaktiver Betrieb . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.2 On-Demand-Betrieb . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2.1 ACCS-Mode . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2.2 Discovery-Mode . . . . . . . . . . . . . . . . . . . . . 35
4.3.3 Keywords eintragen . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.4 Domains eintragen . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.5 IP-Adressen eintragen . . . . . . . . . . . . . . . . . . . . . . 35
4.3.6 Test-Resultate eintragen . . . . . . . . . . . . . . . . . . . . . 36
5 Implementierung 37
5.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 Die Test-Modul-Schnittstelle . . . . . . . . . . . . . . . . . . . 38
5.1.2 Die Content-Modul-Schnittstelle . . . . . . . . . . . . . . . . . 38
5.2 Laufzeitoptimierung des Ratcliff/Obershelp Algorithmus . . . . . . . 38
5.3 Python-spezifische Probleme . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Global Interpreter Lock . . . . . . . . . . . . . . . . . . . . . 39
5.3.2 PyDNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.3 PyOpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.4 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.4 PHP: Probleme beim Verarbeiten von Intergern . . . . . . . . . . . . 42
5.5 Aufbau des Webinterfaces . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Evaluierung 45
6.1 Bestimmung des Ähnlichkeits-Schwellwerts . . . . . . . . . . . . . . . 45
6.1.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.1.2 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.2 Laufzeitverhalten des Ähnlichkeitstests . . . . . . . . . . . . . . . . . 47
6.2.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.2.2 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.3 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Laufzeitverhalten unter realistischen Bedingungen . . . . . . . . . . . 51
6.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.2 Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Inhaltsverzeichnis vii
6.3.3Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3.3.1 Gesamtleistung . . . . . . . . . . . . . . . . . . . . . 52
6.3.3.2 Dauer des Ähnlichkeitstests . . . . . . . . . . . . . . 52
6.3.3.3 Dauer der Netzwerkübertragung . . . . . . . . . . . 53
6.3.3.4 Verhältnis der Dauer des Ähnlichkeitstest zur Dauer
der Netzwerkübertragung . . . . . . . . . . . . . . . 55
7 Zusammenfassung und Ausblick 57
Literatur 59
1. Einleitung
In den letzten Jahren hat die Kommunikation über das Internet einen starken Zu-
wachs erhalten. Immer mehr werden auch sensible Daten wie beispielsweise solche,
die personenbezogen sind, über das Internet übertragen. Zum Schutze derartiger In-
formationen wurden diverse Verschlüsselungverfahren entwickelt. Obwohl viele dieser
Verfahren bereits in Standardsoftware wie E-Mail-Clients und Webbrowsern inte-
griert sind, ist der größte Teil des Informationsaustauschs über das Internet immer
noch ungeschützt.
Viele Anwender verzichten aus Unkenntnis oder Bequemlichkeit auf den Einsatz
geschützer Kommunikation, wenn sie über IP-basierte Netze kommunizieren. Aber
auch Diensteanbieter im Internet scheuen den Einsatz dieser Technologie. Die Ursa-
chen hierfür sind oft Kostengründe: So benötigt z.B. das Beantworten einer Anfrage
über eine TLS-geschützte Verbindung ein Vielfaches der Rechnerressourcen einer
unverschlüsselten Anfrage mit dem selben Inhalt [CoDW06]. Aber auch die Pfle-
ge der notwendigen Public-Key-Infrastruktur stellt einen nicht zu unterschätzenden
finanziellen und personellen Aufwand dar.
Aus der ursprünglichen Fragestellung dieser Studienarbeit, wieviele der Dienste, die
von den Nutzern ungeschützt benutzt werden, auch geschützt verfügbar sind, ent-
wickelte sich die Fragestellung, ob es möglich ist, automatisch zu testen, welche Si-
cherheitsverfahren von einer Gegenstelle unterstützt werden. Sehr schnell stellte sich
heraus, dass dies zwar für einige Protokolle wie z.B. SMTPS sehr einfach möglich,
für HTTPS jedoch mit sehr großen Schwierigkeiten verbunden ist. Da das World-
Wide-Web mittlerweile einer der am weitesten verbreitetsten Dienste im Internet
ist, wäre daher jedoch gerade der Test auf die Unterstützung von HTTPS einer der
aufschlussreichsten Tests.
Interessant ist die Tatsache, dass ein signifikanter Anteil der Webseiten durchaus
verschlüsselt verfügbar ist, dem Benutzer dies jedoch oft nicht angeboten wird. So
kommt es z.B. oft vor, dass die Eingabe eines Passwortes über eine geschützte Verbin-
dung abgewickelt, der Nutzer danach allerdings direkt wieder auf eine ungeschützte
Verbindung umgelenkt wird. Hierdurch wird die durch die Verschlüsselung gewon-
nene Sicherheit wieder gefährdet. Kapitel 3 wird sich dieser Problematik im Detail
widmen.
2 1. Einleitung
Wäre eine Software verfügbar, die diese Umleitungen verhindert, und wo möglich,
ungesicherte Verbindungen auf gesicherte Verbindungen umschreibt, könnte das Si-
cherheitsniveau im Internet signifikant erhöht werden, ohne dass weitere Änderungen
an der Software auf Server- oder Benutzerseite notwendig wäre. Dieses Ziel verfolgt
das parallel zu dieser Studienarbeit entwickelte ACCS-System. Eine genauere Be-
schreibung dieses System findet sich in Abschnitt 2.5.
Damit dieses System sinnvoll eingesetzt werden kann, ist es notwendig, zu erkennen,
welche Sicherheitsverfahren von der Gegenseite unterstützt werden.
1.1 Zielsetzung der Arbeit

Ziel dieser Arbeit ist es, ein Verfahren zu entwickeln, mit dem es automatisch und
proaktiv möglich ist, unterstützte Sicherheitsverfahren eines Rechners im Internet
automatisch zu erkennen. Besonderes Augenmerk liegt hierbei auf der Erkennung
von HTTPS, da es sich hierbei um den Hauptanwendungsfall der meisten Benutzer
des Internets handelt. Eine wesentliche Herausforderung ist hier die Erkennung, ob
es sich um die selben Inhalte handelt, da viele Webseiten mittlerweile dynamisch
generiert werden und sich bei jedem Seitenaufruf verändern.
Weiterhin soll das entwickelte Verfahren erweiterbar sein, so dass es ohne große
Probleme möglich ist, den Test von weiteren Protokollen wie z.B. SMTPS zu imple-
mentieren.
1.2 Gliederung der Arbeit

In Kapitel 2 werden einige Grundlagen vorgestellt und Definitionen eingeführt, die
zum Verständnis dieser Studienarbeit vorausgesetzt werden.
Kapitel 3 analysiert die Problemstellung, zu erkennen, ob eine Webseite per HTT-
PS verfügbar ist und ob über HTTPS die selben Inhalte angeboten werden, wie
über HTTP. Es werden verschiedene Algorithmen auf ihre Eignung zum Vergleich
von Webseiten untersucht, und der am besten geeignete Algorithmus für die in den
folgenden Kapiteln entworfenen Lösungen ausgewählt.
Der so ausgewählte Algorithmus dient als Grundlage für den in Kapitel 4 vorge-
stellten Entwurf. Dieses Kapitel befasst sich ausführlich mit der Datenhaltung der
anfallenden Testdaten und entwirft ein relationales Datenbankschema, in dem die
Testdaten später abgelegt werden sollen. Es werden verschiedene Verfahren vorge-
stellt, mit denen zu testende Rechner in die Sicherheitsdatenbank eingefügt werden
können. Darauf hin wird ein modulares System entworfen, mit dem ohne großen
Aufwand weitere Testverfahren hinzugefügt werden können, wodurch das System
flexibel und erweiterbar bleibt.
Auf Grundlage dieses Entwurfs wird in Kapitel 5 eine konkrete Implementierung des
entworfenen Systems vorgestellt. Diese Implementierung besteht aus zwei Teilen, ei-
nem in Python geschriebenen Framework zur Durchführung der Tests und Pflege der
Testdatenbank, und einem in PHP geschriebenen Webfrontend, mit dem der Inhalt
der Testdatenbank graphisch aufbereitet wird, und eine Reihe von vorgefertigten
Statistiken betrachtet werden kann. In diesem Kapitel wird weiterhin auf program-
miersprachenspezifische Probleme eingegangen, die während der Implementierung
aufgetreten sind, und die Lösungen für diese Probleme beschrieben.
1.2. Gliederung der Arbeit 3
Die Leistungsfähigkeit des Entwurfs und der Implementierung wird in Kapitel 6

anhand der während mehrerer Testläufe gewonnenen Testdaten gezeigt.
Den Abschluss bildet Kapitel 7, in dem die wichtigsten Ergebnisse zusammengefasst
werden und zukünftig mögliche Erweiterungen dargestellt werden.
4 1. Einleitung
2. Grundlagen
In diesem Kapitel werden die für das weitere Verständnis der vorliegenden Studien-
arbeit vorausgesetzten Grundlagen erörtert. Außerdem wird die verwendete Termi-
nologie eingeführt.
2.1 SSL/TLS
Bei SSL (Secure Socket Layer) handelt es sich um ein Verfahren, bei dem zwischen
Transport- und Anwendungsschicht eine Verschlüsselungsschicht eingeführt wird.
Bis 1998 veröffentlichte Netscape die Versionen SSLv1, SSLv2 [Hick95] und SSLv3
[FrKK96, Secr08]. 1999 wurde das Verfahren von der IETF (Internet Engineering
Task Force) standardisiert und als RFC 2246 veröffentlicht [DiAl99]. Hierbei erfolg-
te die Umbenennung in TLS (Transport Layer Security). Mittlerweile existieren die
TLS Versionen TLSv1.0 [DiAl99] und TLSv1.1 [DiRe06].
Es herrscht immer noch eine große Begriffsverwirrung zwischen TLS und SSL. Dies
liegt zum einen daran, dass es sich technisch gesehen um das gleiche Protokoll in
lediglich unterschiedlichen Versionen handelt. Zum anderen hat sich der Begriff SSL
mittlerweile als eine Art Prädikat für Sicherheit durchgesetzt und wird daher von
Herstellern und Providern aus Marketinggründen öfter verwendet als der Begriff
TLS, selbst dann, wenn eigentlich TLS gemeint ist.
Wird in dieser Studienarbeit eine Aussage getroffen, die sowohl auf SSL als auch
auf TLS zutrifft, wird der Begriff SSL/TLS oder TLS/SSL verwendet. Wird hin-
gegen nur der Begriff SSL oder TLS verwendet, dann ist auch nur diese spezielle
Protokollversion gemeint.
2.2 HTTPS
HTTPS (Hyper Text Transfer Protocol Secure) ist ein Verfahren zur Sicherung der
Datenübertragung über HTTP.
Ursprünglich wurde HTTPS von der Firma Netscape entwickelt und 1994 zusammen
mit dem SSLv1.0-Standard veröffentlicht. Von der IETF wurde HTTPS später als
RFC 2818 spezifiziert [Resc00].
6 2. Grundlagen
In aktuellen Browsern wird HTTPS entweder mit SSLv3, TLSv1.0 oder TLSv1.1
eingesetzt. Versionen vor SSLv3 sollten aufgrund von Sicherheitsschwächen nicht
mehr eingesetzt werden [MBLB+ 02].
Bei HTTPS wird standardmäßig der TCP-Port 443 verwendet. Möchte ein Browser
HTTPS verwenden, so muss er zuerst eine SSL/TLS-Verbindung mit einem Webser-
ver aufbauen. Diese SSL/TLS-Verbindung wird nun als Tunnel für eine normale
HTTP-Anfrage verwendet. HTTPS ist also technisch gesehen transparent für Brow-
ser und Webserver, es sind keinerlei Änderungen an der HTTP-Komponente not-
wendig1 [Resc00]. Durch den Einsatz von SSL/TLS-Proxies wie stunnel ist es sogar
möglich, HTTPS mit Web-Browsern und Web-Servern zu realisieren, die SSL/TLS
nicht unterstützen [Hatc08].
2.3 Domain Name System

Beim Domain Name System (DNS ) handelt es sich um einen weltweit verteilten
Dienst zur Namensauflösung im Internet. Das System dient unter anderem dazu,
menschenlesbare Rechnernamen in IP-Adressen aufzulösen.
Zur Auflösung werden sogenannte Nameserver verwendet, also Server die den DNS
Dienst anbieten.
Das DNS arbeitet hierarchisch. An oberster Stelle stehen die sogenannten Top-Level-
Domains. Hierbei handelt es sich entweder um Länderkennungen wie z.B. .de, .uk
oder .ch oder um generische Top-Level-Domains wie .org, .com, .net.
An zweiter Stelle stehen die sogenannten Second-Level-Domains.
Eine Zone bezeichnet einen Teilhirarchie innerhalb des DNS. Dies könnte z.B. ei-
ne Second-Level-Domain sein. Nameserver können innerhalb einer Zone kann die
Zuständigkeit für eine Unterzone an andere Nameserver delegieren.
Innerhalb einer Zone können mehrere Arten von Einträgen erzeugt werden. Am
wichtigsten für die vorliegende Studienarbeit sind A-, AAAA- und MX-Records.
Bei einem A-Record handelt es sich um eine IPv4 und bei einem AAAA-Record
um eine IPv6 Adresse, die innerhalb eines Zonefiles an einen symbolischen Rechner-
namen vergeben werden kann. Der symbolische Rechnername tm innerhalb der Zone
uka.de hat z.B. den A-Record 141.3.70.4“ und den AAAA-Record 2001:638:204::42“.
” ”
Den vollständigen Rechnernamen mit Domain, im Beispiel also tm.uka.de bezeichnet
man auch als Fully-Qualified-Host-Name (FQDN ).
Mit Hilfe eines MX-Records können Mailserver benannt werden, die für die Zone
zuständich sind. Die MX-Records für tm.uka.de sind beispielsweise iramx1.ira.uni-
karlsruhe.de und iramx2.ira.uni-karlsruhe.de, welche wiederrum Rechnernamen in-
nerhalb der Zone ira.uka.de sind.
1
Natürlich behandeln Browser HTTPS nicht vollkommen transparent, da dem Benutzer durchaus
signalisiert wird, dass eine sichere Verbindung aufgebaut wurde. Ausserdem hat der Benutzer
oft die Möglichkeit, die Zertifikate der Gegenstelle zu betrachten.
2.4. Terminologie 7
2.4 Terminologie
Laut des Deutschen Universal-Wörterbuchs des Duden-Verlags [Dude07] handelt es
sich bei einer Website um die Gesamtheit der hinter einer Adresse stehenden Seiten
”
im World Wide Web“.
Der Begriff Website bezeichnet also ein zusammenhängendes Informationsangebot
im World Wide Web. Eine Website besteht aus mehreren Webseiten. Eine Webseite
ist ein einzelnes Dokument innerhalb einer Website.
Die Adresse kann hierbei als die Schnittmenge aller URLs aller Unterseiten einer
Website angesehen werden, in der Regel also um die Kombination aus dem Proto-
koll http oder https und einem Fully-Qualified-Domain-Name (FQDN) [BLFM05].
Wichtig ist, dass Adresse hier nicht synonym zu dem Begriff URL steht, da unter
einer URL immer nur eine Datei, Seite oder Dienst angeboten wird.
Zu bemerken ist hierbei, dass die Begriffe FQDN und Domain oft durcheinander
geworfen werden. Insbesondere bei Hosting-Providern scheint hier einige Verwirrung
zu herrschen. Rechnernamen innerhalb einer Domain und Subdomain werden oft
verwechselt. Dies rührt daher, dass es im DNS (Domain-Name-System) möglich ist,
innerhalb einer Domain für eine Subdomain sowohl eine Delegation als auch einen
A-Record zu definieren. So ist beispielsweise innerhalb des Zonefiles der Zone .org
der Eintrag wikipedia.org sowohl eine Delegation an die Nameserver von Wikipedia
als auch selbst wieder ein A-Record innerhalb der Domain .org, der auf eine IPv4-
Adresse auflöst.
Daher gilt für diese Studienarbeit folgende Definition:
Der vollständige Name eines Rechners inklusive Domain Name wird als FQDN und
die Domain ohne Angabe eines Rechners als Domain bezeichnet. Ist also ein A-
Record (IPv4) oder AAAA-Record (IPv6) innerhalb einer Domain gemeint, der auf
eine IP-Adresse gemeint, wird von einem FQDN gesprochen. Ist hingegen die Dele-
gation an einen Nameserver gemeint, wird von einer (Sub-)Domain gesprochen2 .
Weiterhin ist zu beachten, dass bei der Voranstellung von http:// ein anderer Na-
mensraum verwendet wird als bei der Voranstellung von https://. Details siehe Ab-
schnitt 3.6.
Der Vollständigkeit halber sei hier noch auf den Sonderfall einer, auf mehrere FQDNs
verteilten Website hingewiesen. Anscheinend wurde diese Vorgehensweise als eine
Art der Suchmaschinenoptimierung propagiert3 [Brad07, Bake08]. Die Schnittmenge
wäre hier natürlich leer, die Website hätte nach obider Definition also keine Adres-
se. In diesem Falle sei die Adresse einer solchen Website als die Kombination aus
Protokoll und FQDN der Einstiegsseite definiert.
Beispielsweise könnte sich der Betreiber des Wintersportportals http://www.winter.
invalid dazu entschließen, für jede Region einen eigenen FQDN innerhalb der Domain
2
Streng genommen ist auch diese Definition nicht vollkommen korrekt, da Subdomains auch ohne
Delegation realisiert werden können, bzw. auch die Subdomain wieder auf dem selben Name-
server liegen kann. Zur Vereinfachung soll hier jedoch von dem einfachen Fall, bei dem eine
(Sub-)Domain an einen anderen Nameserver delegiert wird, ausgegangen werden.
3
Hierbei gibt es seit einiger Zeit einen neuen Wirtschaftszweig so genannter SEOs (Search Engine
Optimizer), die versprechen, das Rating bei den großen Suchmaschinen wie Google und Yahoo
zu verbessern. Ironischerweise wird mit solchen Maßnahmen oftmals eher der gegenteilige Effekt
erreicht.
8 2. Grundlagen
winter.invalid anzulegen. Informationen zu den Alpen würden sich so unter http:

//alpen.winter.invalid, Informationen zum Schwarzwald unter http://schwarzwald.
winter.invalid und Informationen zum Berner Oberland unter http://bern.example.
invalid finden. In diesem Fall wäre die Adresse der Website http://www.winter.
invalid, da es sich hierbei um die Einstiegsseite des Portals handelt.
In der vorliegenden Studienarbeit gilt die vereinfachende Annahme, dass unter einer
Domain nur eine Website zu finden ist.
2.5 ACCS
ACCS steht für Auto-Configuration of Communication Security. Es handelt sich
hierbei um ein am Institut für Telematik der Universität Karlsruhe (TH) entwickel-
tes System zur Erhöhung der Sicherheit von IP-basierter Kommunikation. Hierzu
klinkt sich das ACCS -System in das Betriebssystems ein und erkennt automatisch
alle Versuche, eine unsichere Verbindung aufzubauen. Das System versucht nun, mit
Hilfe verschiedener Tests festzustellen, ob die angesprochene Gegenstelle die Mög-
lichkeit besitzt, die Kommunikation über eine geschützte Verbindung abzuwickeln.
Hierzu unterstützt das ACCS System nicht nur TLS/SSL-basierte Verbindungen,
sondern auch die Möglichkeit eine mittels IPSec geschützte Verbindung aufzubauen
und hierüber die angeforderte Kommunikation abzuwickeln.
Die vorliegende Studienarbeit ist Teil des ACCS -Forschungsprojekts und soll proto-
typisch einige der Testverfahren entwickeln und testen, die später in diesem System
zum Einsatz kommen werden.
3. Analyse
In diesem Kapitel wird die Problemstellung, zu erkennen, ob eine Website auch per
HTTPS verfügbar ist, analysiert. Es wird sich zeigen, dass es zwar relativ einfach
ist, festzustellen, ob ein bestimmter Webserver HTTPS anbietet; allerdings ist es
notwendig, die über HTTPS abgerufenen Inhalte mit der ursprünglichen Site zu
vergleichen, um festzustellen, ob es sich um die selbe Website handelt.
Zum besseren Verständnis der Problemstellung werden zunächst Gründe untersucht,
die Website-Betreiber dazu bewegen, HTTPS-Verbindungen nicht zuzulassen. Es
folgt ein kurzer Abschnitt, in dem verschiedene Techniken vorgestellt werden, mit
denen Website-Betreiber versuchen, HTTPS-Verbindungen zu verhindern.
Im zweiten Teil dieses Kapitels wird ausführlich auf verschiedene Verfahren und Al-
gorithmen eingegangen, mit denen Websites miteinander verglichen werden können.
Die Algorithmen werden auf Vor- und Nachteile untersucht. Besonderes Augenmerk
wird hierbei auf die Tauglichkeit zum Vergleich von sich dynamisch ändernden Web-
sites gelegt. Einer der vorgestellten Algorithmen stellt sich als besonders geeignet
heraus und wird in den folgenden Kapiteln in einer verbesserten Form zur Lösung
der Aufgabenstellung verwendet.
3.1 Anforderungen
Eines der Ziele dieser Studienarbeit ist es, ein Verfahren zu entwickeln, mit dem
festgestellt werden kann, ob eine Website per HTTPS verfügbar ist. Die Anwendung
dieses Verfahrens wird im folgenden Test genannt.
Hierbei gilt in dieser Studienarbeit folgende Definition:
Eine Website ist per HTTPS verfügbar, genau dann wenn:
• Eine HTTPS-Verbindung auf dem HTTPS-Standard-Port (443)1 erfolgreich

aufgebaut werden kann, und
1
Auch bei anderen Protokollen werden nur die Standard-Ports untersucht, wie sie unter [IANA08]
aufgelistet werden.
10 3. Analyse
• über die HTTPS-Verbindung die gleiche Website angeboten wird wie über eine
HTTP-Verbindung.
Der zu entwickelnde Test soll genau dann ein positives Ergebnis zu einer Website
liefern, wenn diese per HTTPS verfügbar ist, sonst ein negatives.
Der erste Punkt obiger Definition ist relativ leicht zu überprüfen, indem man ver-
sucht, eine HTTPS-Verbindung mit den Webservern, auf denen die Ziel-Website ge-
hostet wird, aufzubauen. Kommt diese Verbindung zustande, und wird ein SSL/TLS-
Zertifikat zurückgeliefert, so ist die erste Forderung an den Test erfüllt.
Die Umsetzung des zweiten Punkt erweist sich jedoch als ungleich schwieriger (vgl.
Abschnitt 3.6). Das Problem ist, dass sich viele Websites aufgrund der Verwendung
von dynamischen Inhalten bei jedem Abruf verändern.
Bei einer statischen Website ist durch einfachen Stringvergleich der über HTTPS
angeforderten mit der unverschlüsselt angeforderten Website noch relativ einfach
möglich, herauszufinden, ob es sich um die gleiche Website handelt. Im Gegensatz
hierzu verändern sich viele dynamische Websites jedoch mit jedem Abruf. Dies kann
von simplen Änderungen wie der Anzeige des aktuellen Datums, bis zu einer voll-
ständigen Änderung oder Umsortierung der Inhalte reichen. Ein extremes Beispiel
hierfür ist die Website des Online-Buchhändlers Amazon. Hier werden bei jeder An-
frage sogar Teile des Layouts ausgetauscht, um verschiedene Produktempfehlungen
zu präsentieren. Ein einfacher Stringvergleich würde in diesem Falle fälschlicherweise
davon ausgehen, dass es sich um unterschiedliche Websites handelt.
Der zu entwickelnde Test muss in der Lage sein, auch mit diesen sich ändernden In-
halten umgehen zu können, und auch solche Websites möglichst akkurat vergleichen
können.
Verschiedene Möglichkeiten, einen solchen Test zu implementieren werden in den
Abschnitten 3.6ff vorgestellt.
3.2 Einsatz von HTTPS

Wie bereits in der Einleitung angedeutet, unterstützen zwar viele Websites HTTPS,
bieten dies jedoch dem User nicht direkt an. Ruft der User die HTTPS-Seite di-
rekt auf, so wird er oft durch spezielle Techniken zur Unterbindung von HTTPS-
Verbindungen (vgl. Abschnitt 3.5) wieder auf die unverschlüsselte HTTP-Seite um-
gelenkt.
Verschlüsselte Verbindungen werden oft nur für wenige Unterseiten einer Website,
wie z.B. zur Eingabe von Zahlungsdaten wie Kreditkartennummern oder zur Ein-
gabe von Passwörtern verwendet. Hierbei soll dem Benutzer durch den Einsatz von
HTTPS und die damit verbundene, besondere Darstellung im Browser (z.B. ein
kleines Schloss in der URL-Leiste) das Gefühl von Sicherheit vermittelt werden. Ins-
gesamt führt dies jedoch zu einem deutlich niedrigeren Sicherheitsniveau, als wenn
der gesamte Datenverkehr verschlüsselt ablaufen würde.
Es sind viele Angriffe denkbar, die sich die nur teilweise vorhandene Verschlüsselung
zunutze machen. Der einfachste Angriff ist das Mitschneiden des unverschlüsselten
3.2. Einsatz von HTTPS 11
Datentransfers. Es ist zwar nicht möglich, an das Passwort des Benutzers zu gelan-
gen, es kann allerdings nachvollzogen werden, welche Daten sich der Benutzer nach
seinem Login anschaut. So kann es möglich sein, dass ein mitlauschender Angreifer
in den Besitz von sensiblen Informationen gelangt, auf die er sonst keinen Zugriff
hätte. Denkbar wäre hier z.B., dass der Angreifer nach einem Login des Nutzers zu
einem Webmailer die E-Mails mitlesen kann, die der User sich gerade mit seinem
Rechner betrachtet. Im Falle eines Online-Shops könnte der Angreifer nachvollzie-
hen, für welche Produkte sich der User interessiert oder welche er kauft. Handelt es
sich hier beispielsweise um eine Online-Apotheke, kann dies für den User eine erhebli-
che Beeinträchtigung seiner Privatsphäre bedeuten, da aus gekauften Medikamenten
Rückschlüsse auf vorhandene Krankheiten gezogen werden könnte.
Unter Umständen kann es dem Angreifer sogar gelingen, die Identität des Benut-
zers zumindest zeitweise zu übernehmen. Da das HTTP-Protokoll ist zustandslos
ist, müssen mit jeder Anfrage vom Benutzer genügend Informationen mitgesendet
werden, um diesen zu identifizieren. Die einfachste Methode ist, jedes mal den Be-
nutzernamen und das Passwort mit der Anfrage zu übermitteln2 [FHBHL+ 99].
Viele Anbieter versuchen jedoch, zumindest das Passwort des Benutzers zu schüt-
zen, und beschreiten einen anderen Weg: Alle Daten einer Sitzung werden auf dem
Webserver in einer so genannten Session gespeichert. Der Benutzer bekommt nun
eine so genannte Session-Id übergeben, die ihn für die Benutzung dieser Session
legitimiert. Die Session-Id kann als eine Art Token gesehen werden, den der Benut-
zer mit jeder Anfrage mitschickt. Die eigentlichen Authentifizierungsdaten bleiben
so auf dem Webserver und sind vor einem mithörenden Angreifer geschützt. Aller-
dings handelt es sich hier nur um eine Problemverschiebung: Ist der Benutzer einmal
authentifiziert, ist die Session-Id äquivalent zu einem Passwort. Gelingt es dem An-
greifer, diese Session-Id zu extrahieren, kann er – zumindest für die Dauer einer
Sitzung – die Identität des Benutzers annehmen. Das Passwort des Benutzers bleibt
so zwar geschützt, nicht jedoch die vertraulichen Daten, für die er sich durch die
Verwendung seines Passwortes legitimiert hat. Auch eine zusätzliche Überprüfung
der IP-Adresse kann hier nur wenig Schutz bieten, da ein Angreifer, der in der Lage
ist, Pakete zwischen Sender und Empfänger abzufangen, die Überprüfung der IP-
Adresse durch IP-Spoofing, also dem Vortäuschen einer falschen Absenderadresse,
umgehen kann.
Ist der Angreifer neben dem reinen Mitlesen dazu noch in der Lage, den Daten-
transfer zwischen Webserver und Benutzer zu manipulieren, dann ist es ihm sogar
möglich, in den Besitz des Passwortes des Benutzers zu gelangen. Hierzu muss er
lediglich den Hyper-Link, der den Benutzer zur Passworteingabe ( Login“) führt, um-
”
lenken, so dass dieser auf eine vom Angreifer kontrollierte Website führt. Dort kann
der Angreifer das Passwort des Benutzers abfangen und diesen danach zur richtigen
Website zurücklenken. Da der Link zur Passworteingabe meistens nicht per HTTPS
geschützt wird, bleibt eine solche Manipulation in den meisten Fällen unbemerkt.
Beispiele für solche Angriffe finden sich in [deVi06], [Lawr05] und [Mill05].
Insgesamt muss also festgestellt werden, dass ein wirkungsvoller Schutz i.a. nicht
gegeben ist, wenn lediglich ein Teil einer Website mittels HTTPS geschützt wird.
2
Auf diese Weise funktioniert z.B. die in RFC-2617 spezifizierte Basic Authentifizierung.
12 3. Analyse
Daraus ergibt sich direkt die Frage, warum die meisten Website-Anbieter immer
noch auf den Einsatz von HTTPS verzichten bzw. diesen nur für einen geringen Teil
ihrer Inhalte anbieten. Die Ursachen hierfür werden im folgenden Abschnitt genauer
diskutiert.
3.3 Aufwand von HTTPS

Das Betreiben einer Website, die über eine HTTPS-geschützte Verbindung abgerufen
werden kann, bedeutet für den Anbieter einen deutlich gesteigerten Aufwand und
höhere Kosten.
Dieser Aufwand kann in drei Kategorien eingeteilt werden:
• Organisatorischer Aufwand
• Technischer Aufwand
• Rechnerischer Aufwand
Diese Kategorien werden im folgenden genauer untersucht.
3.3.1 Organisatorischer Aufwand von HTTPS

Möchte eine Website HTTPS einsetzen, so wird zunächst wird ein Zertifikat benötigt.
Dies kann entweder von einer externen Zertifizierungsstelle (CA) oder im Falle von
größeren Organisationen, die ihre eigene Public-Key-Infrastruktur (PKI) betreiben,
von einer internen Zertifizierungsstelle ausgestellt werden.
Ist die ausstellende Zertifizierungsstelle eines Zertifikats dem Browser nicht bekannt,
wird eine Fehlermeldung angezeigt. Da die meisten Betreiber diese Fehlermeldung
vermeiden möchten, müssen sie ihre Zertifikate von einer bekannten Zertifizierungs-
stelle, deren Zertifikat in den meisten Browsern vorinstalliert ist, unterschreiben
lassen. Die Alternative des Nachinstallierens eines Stammzertifikats überfordert die
meisten Benutzer einer Website. Zertifikate dieser bekannten Zertifizierungsstellen
sind mitunter recht teuer.
Damit ihm ein Zertifikat ausgestellt wird, muss der Antragsteller seine Identität
nachweisen. Im Falle einer juristischen Person, wie beispielsweise einem Verein oder
einer Kapitalgesellschaft, muss dies von einem gesetzlichen Vertreter – also z.B. dem
Vorstand eines Vereins oder einem Geschäftsführer einer GmbH – vorgenommen
werden. Dies stellt meist schon die erste organisatorische Hürde dar: Oft handelt es
sich hier um nicht technisch versierte Personen, denen entweder schwer zu vermitteln
ist, wofür ein Zertifikat benötigt wird, oder die mit der Prozedur des Nachweises
der Identität überfordert sind. Hier kann es hilfreich sein, wenn man alle nötigen
Formulare für diese Personen bereits soweit vorbereitet, dass sie diese nur noch
unterschreiben müssen.
Darüber hinaus sind die Zertifikate nur eine begrenzte Zeit gültig, so dass meist
nach spätestens 3 Jahren ein neues Zertifikat angefordert und bezahlt werden muss.
Wichtig ist hierbei, dass man rechtzeitig daran denkt, das neue Zertifikat zu bean-
tragen, bevor das alte ausläuft. Dass dies nicht immer reibungslos funktioniert, sieht
man an der hohen Zahl von Websites, die abgelaufene Zertifikate verwenden[Veri].
3.3. Aufwand von HTTPS 13
3.3.2 Technischer Aufwand von HTTPS

Wurde das Zertifikat erfolgreich beantragt, müssen die Webserver, die die Website
anbieten, für HTTPS konfiguriert und das Zertifikat auf diesen installiert werden.
Hier stellt sich das nächste Problem: Viele Webserver bieten mit der selben IP-
Adressen viele verschiedene Websites an, wobei die Websites anhand ihrer Namen
unterschieden werden (Name Based Virtual Hosting). Mit aktueller Browser- und
Webserversoftware jedoch pro IP-Adresse nur eine Website mit HTTPS verwendet
werden3 . Dies ist eine direkte Folge aus der HTTPS-Spezifikation, die fordert, dass
die Verbindung bereits beim Übertragen des Host-Headers verschlüsselt sein muss.
D.h. der gesamte TLS-Handshake inklusive Zertifikatsaustausch muss bereits statt-
gefunden haben, bevor der Browser dem Webserver mitteilt, welche Site er überhaupt
sehen möchte – Die Übertragung des Names der Website findet allerdings erst da-
nach statt. Daher ist es nicht möglich, HTTPS in Kombination mit Name Based
Virtual Hosting zu betreiben.4 Für jede per HTTPS-abrufbare Website auf einem
Webserver muss also eine eigene IP-Adresse verwendet werden [Foun]. Dies bedeu-
tet neben zusätzlichem Administrationsaufwand evtl. auch weitere Kosten, falls der
Provider, bei dem der Webserver gehostet wird, für zusätzliche IP-Adressen Geld
verlangt.
Außerdem unterstützten viele Hardware-Loadbalancer kein HTTPS. Da viele Web-
sites Sessions verwenden, bei denen Daten eines Benutzers auf dem Server gespei-
chert werden, ist es notwendig, dass alle Anfragen eines bestimmten Benutzers von
dem Webserver beantwortet werden, auf dem seine Session vorgehalten wird. Hier-
zu inspizieren viele Loadbalancer den Inhalt einer Anfrage, und speichern (ähnlich
zu einer Stateful Firewall ) in einer Zustandstabelle, welcher Benutzer auf welchen
Webserver weitergeleitet wird. Bei der Verwendung von HTTPS ist dies nur dann
möglich, wenn der Loadbalancer in der Lage ist, die Anfrage zu entschlüsseln, da
er diese sonst nicht inspizieren kann. Hierzu ist teure Spezial-Hardware notwendig
[Visw01].
3.3.3 Rechenaufwand von HTTPS

SSL/TLS und damit HTTPS verwendet zur Verschlüsselung sowohl symmetrische als
auch asymmetrische Kryptographie. Dies führt zu einem deutlich erhöhten Aufwand
an Rechenleistung im Vergleich zu einer unverschlüsselten Übertragung.
Laut [He02] beträgt der CPU-Overhead von HTTPS im Vergleich zu unverschlüssel-
tem HTTP ca. 33% auf Server-Seite. Realistischer erscheinen jedoch die Ergebnisse
von [CoDW06]. Dieser Artikel spricht von einem Overhead von Faktor 3,4 bis 9 von
HTTPS im Vergleich zu ungeschütztem HTTP.
Zur Beschleunigung von HTTPS können SSL/TLS-Beschleuniger einsetzt werden.
Hierbei handelt es sich meist um PCI-Karten, auf denen sich spezielle Prozesso-
ren befinden, die je nach Typ entweder nur den SSL/TLS-Handshake oder sogar
den ganzen SSL/TLS-Vorgang abwickeln. Laut [CoDW06] bringt das Hinzufügen
3
Abhilfe verspricht hier RFC-3546 Server Name Indication“, das bereits von einigen Herstellern
”
wie Mozilla implementiert wurde.
4
Mithilfe von SubjAlt-Name Einträgen ist es möglich, innerhalb eines Zertifikates mehrere un-
terschiedliche FQDN aufzuführen, womit ein Name-Based-Virtual-Hosting möglich wäre. Aller-
dings unterstützte zum Zeitpunkt dieser Studienarbeit keine bekannte CA diese Vorgehensweise
14 3. Analyse
eines solchen Beschleunigers etwa eine Verdoppelung des Durchsatzes an HTTPS-

Verbindungen.
Darüber hinaus werden auch so genannte SSL/TLS-Offloader angeboten. Hierbei
handelt es sich um Hardware-Appliances, welche den gesamten SSL/TLS-Vorgang
abwickeln. Diese Appliances werden über ein Ethernet mit dem Webserver verbun-
den. Der gesamte Datenverkehr zwischen Appliance und Webserver läuft unver-
schlüsselt, der Verkehr zwischen Appliance und Browser des Benutzers verschlüsselt.
Alle Ver- und Entschlüsselungen werden hierbei von der Appliance durchgeführt.
Zu beachten ist, dass das Netzwerk zwischen Webserver und Appliance hierbei be-
sonders geschützt werden muss, da ein Angreifer sonst an dieser Stelle alle Daten
unverschlüsselt abgreifen könnte [Shin04].
Insgesamt muss der Server-Betreiber für eine SSL/TLS-geschützte Übertragung also
mehr Hardware-Ressourcen vorhalten als für eine unverschlüsselte Übertragung. Ins
Gewicht fallen hier nicht nur die höheren Kosten für Hardware, sondern auch höhere
Energiekosten, erhöhter Platzbedarf und höhere Kosten für die Klimatisierung von
Serverräumen.
3.4 Gefühlte Sicherheit

In Diskussionen wird als Argument für HTTPS angeführt, kein Anbieter von kom-
merziellen Websites könne sich erlauben, die Daten seiner Benutzer nicht angemessen
zu schützen, da viele Benutzer den Dienst sonst mieden.
Da jedoch die meisten erfolgreichen kommerziellen Websites HTTPS lediglich für
einen Teil ihrer Unterseiten einsetzen, muss die Gültigkeit dieses Argumentes be-
zweifelt werden. Es bleibt die Frage, wieso die meisten Benutzer dennoch bereit
sind, ihre vertraulichen Daten solchen Websites anzuvertrauen.
Zunächst einmal ist festzustellen, dass die wenigsten Anwender technisch versiert
genug sind, um wirklich zu beurteilen, welche Teile der Übertragung schützenswert
sind und welche nicht.
Dazu kommt, dass von Seiten der Website-Anbieter eine Fehlinformation der Benut-
zer stattgefunden hat, indem behauptet wurde, dass die Nutzerdaten sicher sind, so
lange während der Eingabe ihres Passwortes und ihrer Zahlungsdaten (wie beispiels-
weise Kreditkartennummern oder Bankverbindungen) ein Schloss in der URL-Leiste
des Browsers angezeigt wird [Bank08] [deVi06] .
Da in der Vergangenheit die meisten Internetzugänge über Punkt-zu-Punkt-Verbindungen
wie Modem, ISDN oder DSL realisiert wurden, bestand für die meisten Benutzer tat-
sächlich nur ein relativ geringes Risiko, dass ihre Daten während der Übertragung
ausgespäht wurden. Dementsprechend selten waren die Fälle, in denen es wirklich
zu Schäden durch ausgespähte Daten kam. Dies bewegte die Anbieter dazu, den
Behauptungen der Websites-Anbieter Glauben zu schenken.
Hierdurch hat sich bei den Benutzern ein Gefühl der Sicherheit etabliert, das nicht
viel mit der tatsächlichen Sicherheit ihrer Übertragung zu tun hat. Im wesentlichen
hat sich die Überzeugung durchgesetzt, dass man als Anwender sicher ist, solange an
einer bestimmten Stelle der Übertragung das Schloßsymbol in der URL-Leiste ange-
zeigt wird. Dies soll im weiteren Text als Gefühlte Sicherheit“ bezeichnet werden.
”
3.5. Einschränkung von HTTPS auf Teile von Websites 15
3.5 Einschränkung von HTTPS auf Teile von Web-

sites
In diesem Abschnitt werden gängige Techniken vorgestellt, mit denen Betreiber von
Websites versuchen, den Einsatz von HTTPS auf einen Teilbereich ihrer Website
einzuschränken.
3.5.1 Link auf HTTP-Seite
Eine häufig verwendete Methode ist die absolute Verlinkung auf die HTTP-Adresse
einer Seite. Hierbei kann eine Seite zwar per HTTPS abgerufen werden, alle internen
Links zeigen jedoch wieder auf unverschlüsselte Seiten, so dass der Besucher selbst
beim händischen Abruf über HTTPS spätestens nach dem ersten Klick auf einen
Link wieder auf einer unverschlüsselten Seite landet.
Diese Technik lässt sich recht einfach durch eine aktive Softwarekomponente wie
beispielsweise ein Proxy-Server oder Browser-Plugin aushebeln, die die Links wieder
auf HTTPS umschreibt. Ähnliche Methoden werden bereits seit geraumer Zeit von
Popup-Blockern in Browsern verwendet, es ist daher zu erwarten, dass eine solche
Technik relativ einfach implementiert werden kann5 .
3.5.2 JavaScript
Bei dieser Methode wird in jede Seite wird JavaScript-Code eingebunden, das über-
prüft, ob der Seitenabruf über HTTPS erfolgt. Ist dies der Fall, erfolgt eine Weiter-
leitung auf die ungeschützte HTTP-Verbindung.
Die einfachste Methode, diese Technik zu umgehen, ist das Abschalten der Java-
script-Unterstützung im verwendeten Browser. Jedoch lassen sich dann viele Web-
seiten gar nicht oder nur noch teilweise anzeigen. Insbesondere durch die zunehmende
Verbreitung von Webseiten auf AJAX6 -Basis wird diese Methode immer unprakti-
kabler. Eine bessere Methode ist der Einsatz einer aktiven Komponente, wie bereits
in Abschnitt 3.5.1 vorgeschlagen wurde.
3.5.3 HTTP-Redirect
Mittels eines Skripts wird auf der Serverseite überprüft, ob der Abruf über HTTP
oder HTTPS erfolgt. Handelt es sich um einen Abruf über HTTP, wird die gewünsch-
te Webseite angezeigt. Andernfalls wird der Browser mittels eines HTTP-Redirects
auf die unverschlüsselte Seite umgeleitet [Foru].
Da ein solches Skript die Inhalte gar nicht an den Browser ausliefert, wenn der Zugriff
über HTTPS erfolgt, ist es auch nicht möglich, diese Methode zu umgehen.
3.5.4 Webserver-Konfiguration
Der Webserver ist so konfiguriert, dass nur bestimmte Teile einer Website über
HTTPS zugänglich sind. Für alle andere Teile kann eine Umleitung mittels HTTP-
Redirect auf eine unverschlüsselte HTTP-Seite erfolgen.
Da der Webserver hier die Inhalte gar nicht über HTTPS anbietet, gibt es auch keine
Möglichkeit, diese Methode zu umgehen.
5
Eine parallele Studienarbeit am Institut für Telematik der Universität Karlsruhe beschäftigt sich
bereits mit der Entwicklung eines entsprechenden Browser-Plugins
6
Bei AJAX(Asynchronous JavaScript and XML) handelt es sich um ein Konzept zur asynchronen
Datenübertragung zwischen Browser und Webserver auf Basis von Javascript und XML.
16 3. Analyse
3.5.5 Bewertung
Auch wenn mit dem in den Abschnitten 3.5.3 und 3.5.4 beschriebenen Techniken
der Einsatz von HTTPS effektiv verhindert werden kann, zeigt die Praxis, dass
viele prominente Websites bevorzugt auf die die den Abschnitten 3.5.1 und 3.5.2
beschriebenen Techniken zurückgreifen oder sogar ganz auf den Einsatz dieser Tech-
niken verzichten. HTTPS kann also durchaus verfügbar sein, obwohl es nicht aktiv
angeboten wird.
Daher ist die, in der vorliegenden Studienarbeit vorgeschlagene, automatische Erken-
nung der HTTPS-Unterstützung durchaus erfolgversprechend, und in Kombination
mit dem aktiven Eingreifen durch das ACCS -System ist eine deutliche Verbesserung
der Übertragungssicherheit zu erwarten.
3.6 Problem der Erkennung der Ähnlichkeit von

Websites
Unter https://FQDN findet sich oft eine andere Website als unter http://FQDN. Der
Hauptgrund hierfür ist das oben schon angesprochene Problem mit HTTPS und
Name-Based-Virtual-Hosting. Oft teilen sich viele Websites die selbe IP-Adresse,
wobei jedoch nur für eine Website HTTPS konfiguriert werden kann.
Gegeben sei beispielsweise ein Webserver mit der IP-Adresse IP-1, und den Websi-
tes A, B und C. Für die Website A sei HTTPS konfiguriert, für B und C nicht.
Unter HTTP://FQDN-B erreicht man nun korrekterweise die Website B. Unter
HTTPS://FQDN-B erreicht man hingegen Website A, obwohl man Website B er-
warten würde.
Soll nun festgestellt werden, ob eine bestimmte Website per HTTPS verfügbar ist,
wäre der triviale Ansatz, sich zu dem für HTTPS vorgesehenen Port (in der Regel
ist dies der TCP-Port 443) zu verbinden, und zu schauen, ob sich hier eine Webseite
abrufen lässt. Wie bereits erwähnt, handelt es sich hier jedoch nicht immer um die
gleiche Website, die man durch den Abruf über HTTP erhalten würde. Es ist also
notwendig, zu überprüfen, ob bei beiden Anfragen die selbe Website zurückgeliefert
wurde.
Hierzu gibt es eine Reihe von Algorithmen, die im folgenden vorgestellt und vergli-
chen werden.
Der Algorithmus wird als eine Funktion f(string1, string2) implementiert, die einen
Gleitkommawert zwischen 0 und 1 zurückliefert. Dieser Wert ist die so genannte
Ähnlichkeit. Die Ähnlichkeit hat den Wert 1, wenn string1 mit string2 identisch ist.
3.6.1 Einfacher Stringvergleich

Eine einfache Methode zur Bestimmung der Gleichheit zweier Websites wäre ein
Stringvergleich der einzelnen HTML-Seiten der Websites. Der Stringvergleich kann
so durchgeführt werden, dass er einen Gleitkommawert mit der Anzahl der Zeichen
bis zum ersten unterschiedlichen Zeichen (Präfix-Gleichheit) zurückliefert. Teilt man
diesen Wert durch die Gesamtzahl der Buchstaben, erhält man einen Prozentwert,
der die Ähnlichkeit der beiden Seiten repräsentiert.
3.6. Problem der Erkennung der Ähnlichkeit von Websites 17
Problematisch ist jedoch, dass mittlerweile viele Webseiten zur Abrufzeit dynamisch
von Skripten generiert werden. Hierbei unterscheiden sich die Seiten von Abruf zu
Abruf teils erheblich, weil sich z.B. die angezeigte Werbung oder Produktvorschläge
bei jedem Aufruf ändern oder an einer anderen Stelle in der Seite angezeigt werden.
Benutzt man diesen Stringvergleich, um mehrere Versionen einer solchen Seite zu
vergleichen, indem man sie zweimal hintereinander abruft, würde dieser nur eine
geringe Übereinstimmung zurückliefern, was offensichtlich ein falsches Ergebnis ist.
Der Stringvergleich ist also nur für einfache, statisch generierten Seiten geeignet und
kommt daher als Lösung für diese Studienarbeit nicht in Frage.
3.6.2 Auswertung des Common-Names im Zertifikat

Prinzipiell wäre es möglich, den Common-Name und die SubjectAlt-Names der Zer-
tifikate die für HTTPS verwendet werden, zu betrachten. Stimmen diese mit dem
Namen der angeforderten Website überein, so ist dies ein starkes Indiz dafür, dass
es sich um die gleiche Site handelt. Der Vorteil dieser Lösung ist, dass sie sich ohne
großen Aufwand umsetzen lässt.
Problematisch ist jedoch, dass lediglich die Konfiguration des Webservers, nicht je-
doch die Inhalte der dahinter liegenden Seiten verglichen werden. So wäre es denkbar,
dass der Webserver zwar für HTTPS konfiguriert ist, über HTTPS jedoch nur eine
Fehlermeldung ausgeliefert wird, und der erwartete Inhalt gar nicht verfügbar ist.
Diese Methode eignet sich daher höchstens als Schnelltest, eine Überprüfung des
Inhaltes ist unerlässlich.
3.6.3 Verwendung eines Mustererkennungs-Algorithmus

Eine fortgeschrittene Methode ist die Verwendung eines Mustererkennungs-Algorithmuse.
Ein solcher Algorithmus erkennt nicht nur Übereinstimmungen des ersten Präfixes,
wie es bei einem Stringvergleich der Fall ist, sondern ist auch in der Lage, Muster
innerhalb eines Strings zu erkennen.
Der Vorteil dieser Methode im Gegensatz zum einfachen Stringvergleich ist, dass ein
solcher Algorithmus auch bei geringfügigen Unterschieden zweier verglichener Seiten
einen recht hohen Ähnlichkeitswert zurückliefert.
Der Nachteil ist vor allem der recht hohe Aufwand. Der im folgende vorgestellte
Algorithmus von Ratcliff/Obershelp hat einen Worst-Case-Aufwand von O(n3 ), die
optimierte Variante immerhin noch von O(n2 ), wobei n die Länge der Eingabe be-
zeichnet.
3.6.3.1 Der Gestalt-Ansatz

In [RaMe88] stellen die Autoren einen Ansatz zur Mustererkennung vor, den sie The
”
Gestalt Approach“ nennen. Das aus dem Deutschen ins Englische übernommene
Fremdwort gestalt“ bedeutet im Englischen soviel wie äußere Erscheinungsform
” ”
einer Entität, die über die Summe ihrer Einzelteile hinaus geht“.
Ziel des Ansatzes ist es, eine intuitive, an die Vorgehensweise des menschlichen Ge-
hirns angelehnte Methode der Mustererkennung zu entwickeln. Die Autoren beschrei-
ben, dass Menschen in der Lage sind, die Ähnlichkeit zweier Entitäten aufgrund
18 3. Analyse
von Eigenschaften zu erkennen, die diese gar nicht besitzen. Als Beispiel wird ein
Verbinde-die-Punkte Rätsel genannt, bei dem Punkte in der richtigen Reihenfolge
verbunden werden müssen, um ein Bild zu erhalten. Manche Personen sind in der
Lage, bereits das Bild oder Teile desselbigen zu erkennen, obwohl die Punkte noch
nicht (vollständig) verbunden wurden. Ein weiteres Beispiel wäre der unterbewußte
Vergleich einer neu kennengelernten Person mit einer, die man bereits kennt ( Person
”
A erinnert mich an Person B“).
Die algorithmische Umsetzung dieser Vorgehensweise wird im Artikel Ratcliff/
”
Obershelp-Mustererkennungs-Algorithmus“ genannt. Dieser Algorithmus nimmt zwei
eindimensionale Objekte als Eingabe und gibt den Prozentwert der Ähnlichkeit der
beiden Objekte zueinander aus. Da Strings eindimensionale Objekte sind, eignet sich
dieser Algorithmus insbesondere zum Stringvergleich.
In dem Artikel werden mehrere Beispielanwendungen für den Algorithmus genannt.
Die erste Anwendung ist ein Compiler, der in der Lage ist, Programme trotz Tipp-
fehlern korrekt zu übersetzen. Hierzu wird aus den Namen aller im Namensraum der
Stelle des Fehlers befindlichen Entitäten wie Variablen, Funktionen und Schlüssel-
wörter ein Wörterbuch erstellt. Das fehlerhafte Wort wird nun mit Hilfe des Ratcliff/-
Obershelp-Algorithmus mit allen Wörtern des Wörterbuchs verglichen und durch den
besten Treffer ersetzt. Dem Benutzer wird nun eine Warnung ausgegeben.
Als weiteres Beispiel wird Lernsoftware genannt. Bei damaliger Software wird von
den Autoren kritisiert, dass diese sich auf Multiple-Choice beschränke, da es kei-
ne zuverlässige Methode gebe, die Richtigkeit einer vom Benutzer als Freitext ein-
gegebenen Antwort zu erkennen – denn bereits ein einziger Tippfehler führte zur
Bewertung als Fehler. Mit dem Ratcliff/Obershelp-Algorithmus sei es möglich, die
eingegebene Lösung mit einem Katalog von richtigen Lösungen zu vergleichen und ab
einem bestimmten Schwellenwert der Ählichkeit das Ergebnis als richtig zu werten.
Darüber hinaus denkbar wäre die Anwendung in der Rechtschreibprüfung von Text-
verarbeitungssystemen oder zur Suche von Namen in Datenbanken, wenn die Schreib-
weise nicht eindeutig ist (z.B. Mayer, Maier, Meyer).
3.6.3.2 Der Ratcliff/Obershelp-Algorithmus
Der Algorithmus von Ratcliff/Obershelp wird in [RaMe88] lediglich als Assembler

Quelltext vorgestellt. Zum leichteren Verständnis erfolgte für die vorliegende Studi-
enarbeit eine Übersetzung in Java-Code.
Ein Programm, dass den Algorithmus einbinden möchte, ruft die Funktion simil()
auf und übergibt ihr die beiden zu Vergleichenden Strings. simil() verpackt beide
Strings in ein Array und legt dieses Array auf einen neu erzeugten Stack.
Nun wird die Funktion calculateSimilarity aufgerufen und ihr wird der Stack als
Parameter übergeben.
Innerhalb der Funktion calculateSimilarity wird nun eine While-Schleife aufgerufen.
Die Bedingung der While-Schleife ist so lange Wahr, so lange Elemente vom Stack
geholt werden können. In jedem Schleifenaufruf wird ein solches Element vom Stack
geholt. Zu beachten ist jedoch, dass innerhalb der Schleife auch wieder neue Objekte
auf den Stack gelegt werden können.
3.6. Problem der Erkennung der Ähnlichkeit von Websites 19
Jedes Element auf dem Stack ist ein Array, in dem zwei Strings gespeichert werden.
Als erste Operation in der While-Schleife werden diese Strings in den Variablen a
und b gepeichert. Nun wird der größte gemeinsame Substring von a und b bestimmt
und in der Variable match gespeichert. Zur Variablen match, die initial den Wert 0
hat, wird nun die Länge von match addiert.
Als nächster Schritt werden die beiden Substrings von a und b bestimmt, die Links
von match liegen. Diese Substrings werden wieder in einem Array mit dem Namen
left gespeichert. Auf die selbe Weise werden die beiden Substrings von a und b, die
sich Rechts von match befinden, bestimmt und in der Variable right gespeichert.
Es folgt eine Überprüfung, ob es rechte oder linke Substrings gibt. Falls dies der Fall
ist, wird die entsprechende Variable (also left oder right) auf den Stack gelegt.
Sobald die While-Schleife verlassen wird, wird der Wert score zurückgegeben und
das Programm kehrt zur Funktion simil() zurück.
Zu Letzt wird der von calculateSimilarity() errechnete Wert verdoppelt (da es zwei
Eingabestrings gab) und durch die Gesamtlänge der beiden Strings geteilt.
1 f l o a t c a l c u l a t e S i m i l a r i t y ( s t a c k ){
2 Array e l e m e n t s ; // Auf dem S t a c k wird j e w e i l s
3 // e i n Array aus z w e i zu v e r g l e i c h e n d e n
4 // S t r i n g s g e s p e i c h e r t .
5
6 String a ; // Der e r s t e S t r i n g
7 String b ; // Der z w e i t e S t r i n g
8 S t r i n g match ; // Die l a e n g s t e Uebereinstimmung der
9 // beiden Strings
10 f l o a t s c o r e = 0 ; // Der a k t u e l l e Score
11
12 while ( e l e m e n t s = s t a c k . pop ( ) ) { // Ein Array vom S t a c k h o l e n

13
14 // Array a u f t e i l e n
15 a = elements [ 0 ] ;
16 b = elements [ 1 ] ;
17
18 // Bestimmen d e s l a e n g s t e n s Matchs
19 // der b e i d e n S t r i n g s ;
20 match = getLongestMatch ( a , b ) ;
21
22 // Score um d i e Laenge d e s
23 // Matches erhoehen
24 s c o r e += match . l e n g t h ;
25
26 // Die S u b s t r i n g s von a und b , d i e

27 // r e c h t s von dem l a e n g s t e n Match l i e g e n
28 // bestimmen .
29 l e f t = g e t L e f t S u b s t r i n g ( a , b , match ) ;
30
31 // Die S u b s t r i n g s von a und b ,

32 // d i e l i n k s von dem l a e n g s t e n Match l i e g e n
20 3. Analyse
33 // bestimmen
34 r i g h t = g e t R i g h t S u b s t r i n g ( a , b , match ) ;
35
36 // Wir schauen , ob e s u e b e r h a u p t
37 // l i n k e S u b s t r i n g s g i b t . Das i s t nur
38 // dann der F a l l , wenn b e i d e S t r i n g s
39 // m i n d e s t e n s e i n Z e i c h e n haben .
40 // Wenn ja , dann l e g e n wir b e i d e
41 // a l s Array a u f den S t a c k .
42 if ( left )
43 s t a c k . push ( l e f t ) ;
44
45 // Das s e l b e machen wir nun f u e r d i e

46 // r e c h t e n S u b s t r i n g s .
47 if ( right )
48 s t a c k . push ( r i g h t ) ;
49 }
50
51 // Summe z u r u e c k g e b e n
52 return s c o r e ;
53 }
54
55 f l o a t s i m i l ( S t r i n g inputA , S t r i n g inputB ){
56
57 // Laenge b e i d e r S t r i n g s bestimmen
58 float length = ( f l o a t ) inputA . l e n g t h + ( f l o a t ) inputB . l e n g t h ;
59
60 // Stack , a u f dem wir d i e zu v e r g l e i c h e n d e n

61 // S u b s t r i n g s a b l e g e n
62 Stack s t a c k = new Stack ;
63
64 // I n i t i a l l e g e n wir d i e E i n g a b e s t r i n g s
65 // a u f den S t a c k .
66 s t a c k . push ( new Array ( inputA , inputB ) ) ;
67
68 // Nun b e r e c h n e n wir d i e Anzahl der

69 // uebereinstimmenden Z e i c h e n
70 float s i m i l a r i t y = c a l c u l a t e S i m i l a r i t y ( stack ) ;
71
72 // Der A e h n l i c h k e i t s w e r t i s t zweimal d i e
73 // Anzahl der u e b e re i n s t i m m e n d e Z e i c h e n
74 // g e t e i l t durch d i e Summe der Laenge
75 // der b e i d e n S t r i n g s .
76 return 2 ∗ s i m i l a r i t y / l e n g t h ;
77 }
3.6.3.3 Umsetzung in dieser Studienarbeit

In dieser Studienarbeit wird eine modifizierte Version des Ratcliff/Obershelp Algo-
rithmuses gewählt, der die Worst-Case-Laufzeit O(n2 ) und eine Best-Case-Laufzeit
3.7. Zusammenfassung 21
von O(n) besitzt. Der ursprüngliche Algorithmus hat eine Worst-Case-Laufzeit von
O(n3 ) und eine Best-Case-Laufzeit von O(n2 ). Hierbei bezeichnet n die Anzahl der
angegebenen Zeichen.
Die Bestimmung der Ähnlichkeit zweier Webseiten A und B geschieht in mehreren
Schritten:
1. Abrufen von 3 Versionen von Webseite A, Speicherung in A1 bis A3 .
2. Abrufen von 3 Versionen von Webseite B, Speicherung in B1 bis B3 .
3. Bestimmen der durchschnittlichen Ähnlichkeit der Versionen von A zueinan-

der:
s(A1 , A2 ) + s(A2 , A3 ) + s(A1 , A3 )
standardDiff(A) = (3.1)
3
4. Bestimmen der durchschnittlichen Ähnlichkeit der Versionen von A zu den
Versionen von B: P3 P3
(Ai , Bj )
sDiff(A, B) = i=1 j=1 (3.2)
9
5. Bestimmen der normierten, prozentualen Ähnlichkeit der Webseite A zur Web-
seite B:
sdiff(A, B) ∗ 100
diff(A, B) = (3.3)
standardDiff(A)
Ab einem gewissen Schwellenwert7 von diff(A, B) werden zwei verglichene Websites

A und B als identisch bezeichnet.
3.7 Zusammenfassung
Es wurden verschiedene Algorithmen analysiert, mit denen einzelne Webseiten auf
Ähnlichkeit untersucht werden können. Während sich herausstellte, dass ein ein-
facher Stringvergleich für die Lösung dieses Problems ungeeignet ist, erwies sich
Patternmatching auf Basis einer modifizierte Form des Algorithmus von Ratcliff/-
Obershelp als effektive Lösung.
Darüber hinaus wurden verschiedenen Methoden, mit denen Website-Betreiber ver-
suchen, eine HTTPS-Verbindung auf einen Teil ihrer Website einzuschränken, aufge-
zählt, und es wurde gezeigt, dass sich zumindest ein Teil dieser Verfahren umgehen
lässt.
Insgesamt erwies sich das Konzept dieser Studienarbeit als realisierbar, so dass nun
in den folgenden Kapiteln eine konkrete Lösung entwickelt werden kann. Die Ent-
wicklung einer Methode, um HTTP-Verbindungen durch HTTPS-Verbindungen zu
ersetzen, stellte sich als realisierbar heraus.
7
In einigen Testläufen der Beispiel-Implementierung wurden mit einem Schwellenwert von 95%
die besten Ergebnisse erzielt
22 3. Analyse
4. Entwurf
In diesem Kapitel wird der Entwurf eines Systems vorgestellt, das die in der Analyse
in Kapitel 3 gewonnenen Erkenntnisse umsetzt.
Hierbei wird ein modularer Ansatz gewählt, wobei eine Rahmenarchitektur, zur
Durchführung von Tests auf unterstützte Sicherheitsverfahren, entworfen wird, die
später mit Hilfe von Modulen einfach erweitert werden kann. Der eigentliche Test
auf die Verfügbarkeit einer Website mittels HTTPS wird als Modul entworfen. Hier-
durch wird zum einen die Vorgehensweise beim Entwerfen eines Moduls gezeigt, zum
anderen wird damit die eigentliche Aufgabenstellung dieser Studienarbeit gelöst.
Die Speicherung der Testergebnisse erfolgt innerhalb einer relationalen Datenbank,
deren Schema in diesem Kapitel erörtert wird.
Das zu entwerfende System wird als NSC (Network Security Checks) bezeichnet. Das
Präfix NSC wird zur Kennzeichnung allen zu NSC gehörigen Klassen vorangestellt.
4.1 Entwurf der Software-Komponenten

In diesem Abschnitt wird der Entwurf der Softwarekomponenten des NSC -Systems
beschrieben.
Wie in Abbildung 4.1 zu sehen besteht das System im wesentlichen aus einem Haupt-
programm (NSCMain), den Schnittstellen für die Test- und (NSCTest) Content-
Module (NSCContent) sowie einer Helfer Klasse für DNS -Anfragen (Lookup).
Für die vorliegende Studienarbeit sind vor allem die Modul Klassen von interesse.
Auf Module wird in den folgenden Abschnitten genauer eingegangen. Bei den Klassen
NSCMain und Lookup handelt es sich um implementierungstechnische Details, die
ausserhalb des Fokus dieser Studienarbeit liegen. Wichtig ist an dieser Stelle ledig-
lich, dass eine Implementierung das durch das UML-Klassendiagramm vorgegebene
Interface verwendet.
4.1.1 Module
Funktionen werden im NSC-Framework mit Hilfe von Modulen implementiert. Es
wird zwischen zwei Arten von Modulen unterschieden:
24 4. Entwurf
Abbildung 4.1: NSC Klassendiagramm
• Test-Module, die die Tests auf unterstützte Sicherheitsprotokolle implementie-

ren. Test-Module arbeiten rein auf Protokollebene, Inhalte von Übertragungen
werden nicht betrachtet.
4.1. Entwurf der Software-Komponenten 25
• Contentr-Module, die dazu dienen, Inhalte von Übertragungen zu analysieren.

Hierbei wird vorausgesetzt, dass die eine (gesicherte) Verbindung erfolgreich
aufgebaut werden kann; es werden keine Vorgänge auf Protokollebene betrach-
tet.
4.1.1.1 Test-Module
Das Testen der unterstützten Sicherheitsverfahren wird mit Hilfe von Modulen rea-
lisiert. Ein Modul kann einen oder mehrere Tests implementieren. Implementiert ein
Modul mehrere Tests, so sollen diese in einem logischen Zusammenhang stehen. So
könnte z.B. die Überprüfung von SMTPS auf TCP-Port 465, SMTP mit STARTTLS
auf Port 25 sowie SUBMISSION auf TCP-Port 587 in einem Modul mit Namen mail ’
sinnvoll zusammengefasst werden1 .
Eine Zusammenfassung von unterschiedlichen Protokollen wie z.B. IMAPS und HTT-
PS in einem Modul wäre hingegen weniger sinnvoll, da diese Protokolle ganz unter-
schliche Anwendungsgebiete haben, und sollte daher nicht vorgenommen werden.
Einem Modul wird beim Initialisieren eine Liste der zu testenden Rechner (entweder
als DNS-Namen oder als IP-Adressen) übergeben. Alle weiteren Informationen wie
z.B. TCP-Ports, auf denen die zu testenden Dienste laufen, sind entweder fest im
Modul konfiguriert oder werden von diesem zur Laufzeit bestimmt.
Test-Module müssen eine Methode test() anbieten. Mit dieser Methode wird das Mo-
dul dazu veranlasst, alle in ihm implementierten Tests für die bei der Initialisierung
übergebenen Ziel-Rechner zu starten. Diese Methode ist synchron. Von der Methode
wird entweder eine Liste mit allen Testresultaten oder im Falle eines Fehlers eine
Exception geworfen.
Ein Ergebnisdatensatz besteht jeweils mindestens aus IP-Adresse des getesteten
Rechners, die Ports der getesteten Protokolle, sowie dem Resultat des Tests (sie-
he Abschnitt 4.1.2).
4.1.1.2 Content-Module
Content-Module dienen dazu, Inhalte einer Übertragung zu analysieren.
Einem Content-Modul werden bei der Initialisierung alle Informationen übergeben,
die das Modul benötigt, um die angeforderten Inhalte zu finden. Hierbei kann es
sich z.B. um die URL einer Webseite handeln. Es gibt allerdings auch Module, wie
beispielsweise Suchmaschinen-Crawler, bei denen die Zielseite bereits feststehen und
lediglich noch Anfrageparameter übergeben werden.
Content-Module bieten eine Methode crawl() an, die Analyse startet. Analog zur
test()-Methode arbeitet diese Methode synchron. Als Rückgabewerte liefert diese
Methode entweder die extrahierten Informationen oder, im Falle eines Fehlers, eine
Exception.
Insbesondere das Modul SIMILARITYContent, das die Unterstützung von HTTPS
überprüft, ist als Content-Modul implementiert. Zwar handelt es sich eigentlich um
den Test auf die Unterstützung eines Sicherheitsprotokolls – ein typischer Anwen-
dungsfall von Test-Modulen –, allerdings müssen für diesen Test die Inhalte der zu
testenden Webseiten, wie in Abschnitt 3.6.3.3 beschrieben, untersucht werden.
1
Diese Zusammenfassung ist auch aus technischer Sicht sinnvoll, da diese Protokolle praktisch
identisch sind.
26 4. Entwurf
4.1.2 Mögliche Ergebnisse eines Tests

Ein Testmodul kann folgende Ergebnisse zurückliefern:
• Not Connected : Eine Verbindung zum zu testenden Rechner war nicht möglich.
Entweder wurde der Verbindungsaufbau abgelehnt ( Connection refused“) oder
”
eine Verbindung kam innerhalb des zulässigen Zeitrahmens nicht zu stande und
es ist ein Timeout aufgetreten.
• Connected : Eine Verbindung zu dem Port war möglich, es wurde allerdings

kein SSL/TLS (z.B. in der EHLO Antwort eines SMTP-Servers) angeboten.
• TLS failed : SSL/TLS wurde angeboten, beim Handshake ist allerdings ein
Fehler aufgetreten, so dass keine SSL/TLS Verbindung zustande kam.
• TLS worked : SSL/TLS wurde angeboten, der Aufbau einer SSL/TLS Verbin-
dung war möglich und es wurde ein Zertifikat von der Gegenstelle empfangen.
In diesem Falle wird das Zertifikat dem Testergebnis für die Gegenstelle hin-
zugefügt.
4.1.3 Entwurf eines Moduls: Test auf Verfügbarkeit einer Web-

site mittels HTTPS
In diesem Abschnitt wird beispielhaft der Entwurf eines Moduls vorgestellt. Hier-
bei bietet es sich an, den Test auf Verfügbarkeit einer Website mittels HTTPS als
Modul zu entwerfen, da es sich hierbei um das wichtigste Modul zur Erfüllung der
Aufgabenstellung der vorliegenden Studienarbeit handelt. Ausserdem kann anhand
eines praktischen Beispiels der Entwurf eines Moduls demonstriert werden.
4.1.3.1 Vorgehensweise
In Abschnitt 3.6.3.3 wurde eine modifizierte Form des Algorithmus von Ratcliff/-
Obershelp zur Bestimmung der Ähnlichkeit von Webseiten ausgewählt.
Diese Ähnlichkeitsberechnung wird in der Methode crawl() implementiert. Hierbei
wird die von SIMILARITYContent angebotene Methode download(url) zum Her-
unterladen verwendet. Drei Versionen der unter url angegebenen Webseite werden
in den Variablen A1 bis A3 , drei Versionen der unter httpsurl angegebenen Seite in
den Variablen B1 bis B3 gespeichert und dann der in Abschnitt 3.6.3.3 dargestellte
Algorithmus angewendet.
4.1.3.2 Entwurf
Das Modul wird als Klasse mit dem Namen SIMILARITYContent implementiert.
Diese Klasse ist von der Klasse Content abgeleitet.
Im Konstruktor wird der Klasse der notwendige Parameter url und der optionale
Parameter httpsurl übergeben. Wird httpsurl nicht übergeben, so wird hierin die
HTTPS-Entsprechung der in url übergebenen URL gespeichert.
Die Klasse enthält die privaten Methoden compare(a, b) und download(url), und
bietet die öffentliche Methode crawl() an.
4.2. Entwurf der Sicherheitsdatenbank 27
Bei compare(a, b) handelt es sich um eine Einschubmethode (Template-Method), in

der der eigentliche Test auf Ähnlichkeit vorgenommen wird. Hiermit wird es möglich,
den zum Vergleich der Inhalte verwendeten Algorithmus leicht gegen einen anderen
auszutauschen, indem die Klasse SIMILARITYContent abgeleitet und die Methode
compare(a, b) überschrieben wird.
Standardmäßig soll compare(a, b) den modifizierten Algorithmus von Ratcliff/Obers-
help verwenden.
4.2 Entwurf der Sicherheitsdatenbank

Die Sicherheitsdatenbank ist die zentrale Komponente des zu entwerfenden Systems.
In ihr werden alle Testergebnisse gespeichert, und im ACCS-System soll sie später
als Entscheidungsgrundlage für das zu wählenden Sicherheitsverfahren dienen. Daten
können auf drei verschiedenen Wegen in die Sicherheitsdatenbank gelangen:
Durch
• proaktives Testen.
• Anfrage eines Clients nach einer Gegenstelle, die sich noch nicht in der Daten-
bank befindet, wodurch das durchführen von Tests veranlast wird.
• Rückmeldung eines Clients darüber, ob ein Verbindungsversuch mit dem aus-
gewählten Sicherheitsverfahren erfolgreich war oder fehlgeschlagen ist. ( Rück-
”
kopplung“).
Die Sicherheitsdatenbank dient hier vor allem dazu, den Verbindungsaufbau im

ACCS-System zu beschleunigen. Dazu sollen in der Sicherheitsdatenbank die In-
formationen über die häufigsten Zielrechner bereits vorliegen, so dass ein zeitauf-
wendiges Testen entfallen kann. Die Sicherheitsdatenbank agiert hier also als eine
Art Cache.
4.2.1 Überblick
Um die spätere Auswertung der Testergebnisse zu vereinfachen, wurde die Entschei-
dung getroffen, alle Daten in einer relationalen Datenbank zu speichern. Das ER-
Diagramm der Datenbank ist in Abbildung 4.2 dargestellt.
Zentrales Element der Datenbank ist die Relation Domains. In dieser Relation wer-
den die Domainnamen der zu testenden Websites gespeichert.
In der Relation Ipaddresses werden die IP-Adressen aller zu testenden Rechner ge-
speichert.
Über die Relation domains has ipaddresses werden die IP-Adressen zu Domains und
der Funktion der IP-Adresse innerhalb einer Domain (z.B. Webserver, MX-Server,
DNS-Server) zugeordnet. Hat eine IP-Adresse mehrere Funktionen innerhalb einer
Domain, erfolgen auch mehrere Einträge in die Relation domains has ipaddresses.
Für jeden durchgeführten Test wird in der Relation Tests ein Eintrag erzeugt. In die-
sem Eintrag ist unter anderem die IP-Adresse des getesteten Rechners, das getestete
Protokoll sowie das Ergebnis des Tests vermerkt.
Die wichtigsten Relationen werden in den folgenden Abschnitten im Detail beschrie-
ben.
28 4. Entwurf
HI

G

HI
23 4 53

G
,K <!@

J
HI

G
23 4 53 BCC
!" #$%& #& !" #$%& % ,- .
'( ' ' )*+
H 7 483 9

;
! " #$%&
!" #$%& #& !" #$%& % ,- /
'( ' ' )*+

HI

G

HI

G

! " #$%& #& ,K <!@ & % ,- .
'( 'J ' )*+

01 ! " #$%& #& ,K <!@ & % ,- /
'( 'J ' )*+

7 483 9: HI

01 ; G
< ,=&$>,& #& $? # @,&&,& % ,- .
'( ' ' )*+

23 4 53 6

<,=&$>,& #& $? # @,&&,& % ,- A
'( ' ' )*+
01

<,=&$>,& #& $? # @,&&,& % ,- A
'( ' ' )*+

7 483 9:
;
U
V 8 W6 W W W
;

23 4 53

? @! >! D !M

? @! >! D !M& $% ,- .SA T
'

7 483 9:
;

1
8 N 3 8 O

0 P

1
Q 10 1
73 8

>,& >& % ,- /
' )*+

1 23 4 53

1
@,& LM>
>,& >& % ,- A

1 ' )*+

>,& >& % ,- R
' )*+

>,& >& % ,- R
' )*+

23 4 53 BCC
23 4 53 C

D # $% ,- / E/ F
'

Abbildung 4.2: Datenbank-Diagramm

Abbildung 4.3: Die Keywords Relation
4.2.2 Keywords
In der Relation Keywords werden von Hand Schlüsselwörter eingetragen, die als Ein-
gabe für die Content-Module dienen. Die Content-Module (vgl. Abschnitt 4.1.1.2)
liefern eine Liste mit Domains zurück2 , welche in die Relation Domains eingefügt
und danach mit den entsprechenden Schlüsselwörtern verknüpft werden.
4.2.3 Domains
Abbildung 4.4: Die Domains Relation
Die Relation Domains stellt im NSC-Datenbankdesign die zentrale Entität, sozu-

sagen das Wurzelelement, dar. Wie in Abschnitt 4.2.2 bereits angedeutet, wird die
Relation Domains durch die Rückgabe eines Content-Moduls zur Eingabe bestimm-
ter Keywörter befüllt.
4.2.4 Ipaddresses
Die Rechnernamen innerhalb einer Domain werden bereits zur Testzeit in IP-Adres-
sen aufgelöst, und die Testresultate werden mit den entsprechenden IP-Adressen
verknüpft. Hierdurch ergibt sich zwar der Nachteil, dass spätere Änderungen im
DNS zur Zeitpunkt des Tests nicht mehr berücksichtigt werden. Würde hingegen der
symbolische Hostname gespeichert, ergäben sich allerdings große Probleme bei der
2
Zu beachten ist hier, dass es sich nicht zwangsläufig um Second-Level-Domains handeln muss,
sondern durchaus auch Domains tieferer Ebene zurückgeliefert werden können.
30 4. Entwurf
Abbildung 4.5: Die Ipaddresses Relation
Zusammenarbeit mit dem ACCS-System. Die Ursache hierfür liegt darin, dass das
ACCS-System sich an der Socketschnittstelle des Kernels in den Verbindungsaufbau
einklingt. An dieser Schnittstelle ist die Angabe des Zielhosts bereits in eine IP-
Adresse aufgelöst worden. Da die Zuordnung von symbolischem Hostnamen auf IP-
Adressen nicht injektiv ist, gäbe es keine einfache Möglichkeit, die Testergebnisse in
der Datenbank zu lokalisieren.
IPv4-Adressen werden üblicherweise durch einen String repräsentiert. Dieser String
besteht aus vier dezimalen Zahlengruppen, die jeweils durch einen Punkt getrennt
sind, also z.B. 192.168.255.1“. Jede dieser Zahlengruppen kann einen Wert zwischen
”
0 und 255 annehmen.
Analog dazu werden IPv6-Adressen durch einen String mit 8 hexadezimalen Zah-
lengruppen repräsentiert, die jeweils durch einen Doppelpunkt getrennt sind. Jede
dieser Zahlengruppen kann einen Wert zwischen 0x0000 und 0xFFFF, also zwischen
0 und 65535, annehmen.
Für die Speicherung in einer Datenbank ist die Darstellung als String jedoch ungeeig-
net. Zwar bieten einige Datenbank-Management-Systeme (DBMS) wie z.B. Oracle
und PostgreSQL eigene Datentypen für IPv4-Adressen an, IPv6 wird allerdings bis-
her von keinem dieser Produkte unterstützt. Der Entwurf dieser Studienarbeit soll
sich nicht auf die Eigenschaften eines bestimmten Datenbanksystems stützen. Um
den Entwurf weitestgehend produktneutral zu gestalten, ist der Entwurf eines ande-
ren Formats zur Speicherung von IP-Adressen erforderlich.
Würde eine IPv4-Adresse als String gespeichert, wäre hierzu ein Feld notwendig, das
15 Byte lang ist. Da eine IPv4-Adresse allerdings nur 2564 unterschiedliche Werte
darstellen kann, was einer Länge von 32 Bit – oder 4 Byte – entspricht, würden bei
der Speicherung als String 11 Bytes verschenkt werden.
Darüber hinaus wären Datenbankanfragen, die sich nicht auf eine bestimmte IP-
Adresse, sondern z.B. auf ein bestimmtes Subnetz3 beziehen, nur mit Hilfe von Strin-
goperationen möglich. Dies würde eine sehr große Last für die Datenbank bedeuten.
Die Ursache hierfür ist, dass die verwendete Stringoperation für jeden Datensatz in-
nerhalb der Relation durchgeführt werden muss. Üblicherweise werden zum schnel-
leren Auffinden von Datensätzen innerhalb einer Relation spezielle Indexstrukturen
verwendet. Beim Verwenden von Stringoperationen können diese Indexstrukturen
allerdings nicht, oder nur teilweise benutzt werden, was einen deutlich höheren Auf-
wand für das BDMS bedeutet.
3
Im vorliegenden Entwurf werden solche Suchoperationen nicht durchgeführt. Im Rahmen zu-
künftiger Erweiterungen sind jedoch durchaus Anwendungen solcher Anfragen denkbar (z.B.
zur Suche aller Webserver, die von einem Provider betrieben werden).
Aufgrund dieser Nachteile wurde für diese Studienarbeit eine andere Darstellung ver-
wendet. Für die Speicherung in der Datenbank wird eine Umwandlung des Strings
in eine Ganzzahl vorgenommen. Eine IPv4-Adresse wird hierzu an den Punkten in
4 Teile zerlegt. Jeder dieser Teile repräsentiert eine Zahl zwischen 0 und 255, kann
also mit Hilfe von 8 Bit dargestellt werden. Nun wird der erste der so erhaltenen
4 Teile mit 224 , der zweite mit 216 und der dritte mit 28 multipliziert. Nun wird
die Summe dieser drei so erhaltenen Produkte gebildet, und der vierte, unverän-
derte Teil dazuaddiert. Insgesamt entsteht so eine 32 Bit lange Ganzzahl, der die
ursprüngliche IPv4-Adresse repräsentiert. Die IPv4-Adresse 192.168.255.1“ würde
”
mit diesem Verfahren in 3232300801“ umgewandelt werden.
”
Die Umwandlung einer IPv6-Adresse in eine 128 Bit lange Ganzzahl geschieht analog,
wobei hier jedoch nicht 8 Bit, sondern gleich 16 Bit auf einmal kodiert werden: Die
IPv6-Adresse wird an den Doppelpunkten in 8 Teile zerlegt, von denen jeder 16 Bit
lang ist. Der erste Teil wird nun mit 2112 , der zweite mit 296 (da 112 - 16 = 96) usw.
multipliziert. Auch hier werden nun wieder die Summen der so erhaltenen 7 Produk-
te und des letzten, unmodifizierten Teil der IPv6-Adresse gebildet, wodurch eine 128
Bit lange Ganzzahl entsteht. Die IPv6-Adresse 2001:638:204:10:214:85ff:fe31:19a1“
”
würde mit diesem Verfahren in 42540614293834371487594751202908248481“ umge-
”
wandelt werden.
Ein Problem bei der Speicherung von IPv6-Adressen als Ganzzahl stellt jedoch die
Tatsache dar, dass die meisten Datenbank-Systeme keine 128 Bit langen Ganzzahlty-
pen anbieten. Da jedoch die Verbreitung von IPv6 immer mehr fortschreitet, besteht
die Hoffnung, dass viele Datenbanksysteme in absehbarer Zukunft einen eigenen Da-
tentyp zur Speicherung von IPv6 anbieten werden. Dies hätte außerdem den Vorteil,
dass die IP-Adressen nichtmehr im Programmcode umgerechnet werden müssen.
Hierdurch wäre der Entwurf allerdings nichtmehr produktneutral.
Bis diese Datentypen verfügbar sind, wurde für diese Studienarbeit eine andere Zwi-
schenlösung gewählt: Der SQL-99-Standard definiert den Datentyp DECIMAL. Mit-
hilfe dieses Datentyps können Gleitkommazahlen präzise gespeichert werden: Üb-
licherweise werden Gleitkommazahlen mit Hilfe der IEEE-754-Darstellung gespei-
chert. Diese Darstellung hat jedoch den Nachteil, dass Operationen mit IEEE-754-
Zahlen nicht immer genau sind, was zum Auftreten von Rundungsfehlern führen
kann. Im Gegensatz dazu kann bei der Darstellung einer Zahl als DECIMAL die
Genauigkeit mit Hilfe der Angaben der Gesamtlänge der Zahl sowie der Nachkom-
mastellen genau festgelegt werden. Die maximale Länge einer DECIMAL-kodierten
Zahl beträgt 65 Stellen. Da die größte mögliche IPv6-Adresse den Wert 2128 und
damit 39 Stellen hat, ist eine Spalte vom Typ DECIMAL(39,0) hinreichend lang,
um alle möglichen IPv4- sowie IPv6-Adressen zu speichern.
Zur Unterscheidung zwischen einer IPv4- und eine IPv6-Adresse wurde in der Rela-
tion ipaddresses zusätzlich noch ein ENUM-Feld mit den beiden möglichen Werten
4“ und 6“ hinzugefügt, dass angibt, um welche Art von Adresse es sich handelt.
” ”
4.2.5 Protocols
In der Relation Protocols ist für jedes Protokoll, das getestet werden kann (d.h.
für das ein Testmodul vorhanden ist) ein Eintrag vorhanden. Dieser wird mit dem
Testergebnis verknüpft.
32 4. Entwurf
Abbildung 4.6: Die Protocols Relation
Da in dieser Studienarbeit die Annahme gilt, dass jedem Protokoll fest eine TCP-
Port-Nummer zugeordnet ist, wird in dieser Relation diese Nummer als Primär-
schlüssel verwendet.
4.2.6 Results
Abbildung 4.7: Die Results Relation
In der Relation Results sind alle möglichen Testergebnisse gespeichert. Dies dient
zum einen dazu, festzustellen, ob ein Test erfolgreich war, oder fehlgeschlagen ist,
zum anderen wird bereits die Art des Fehlers (z.B. Verbindungsaufbau fehlgeschla-
”
gen“ oder TLS-Handshake nicht möglich“) gespeichert. Diese Ergebnissen werden
”
bereits beim Erstellen der Datenbank in die Relationen eingetragen und werden zur
Laufzeit des Programms nichtmehr verändert.
Die Bedeutungen der einzelnen Resultate werden in Abschnitt 4.1.2 erläutert.
4.2.7 Tests
In der Relation Tests werden die Resultate der einzelnen Testläufe gespeichert. Hier-
zu gibt es zu jedem Testlauf jeder IP-Adresse für jeden Eintrag in der Relation
Protocols genau einen Eintrag in der Relation Tests. Durch die Verknüpfung mit
4.3. Befüllen der Sicherheitsdatenbank 33
Abbildung 4.8: Die Tests Relation
Ipaddresses wird die Zieladresse und mit der Verknüpfung mit Protocols das getes-
tete Protokoll gespeichert. Mit der Verknüpfung zu Results wird das Resultat des
Tests, also im wesentlichen ob der Test erfolgreich war oder welche Art von Fehler
aufgeteten ist, gespeichert.
Jeder Test ist mit einem Datum versehen und beinhaltet außerdem ein Text-Feld,
in dem das Zertifikat gespeichert werden kann, das beim Test von der Gegenstelle
zurückgegeben wurde. Hierdurch sollen später detailiertere Analysen ermöglicht wer-
den, z.B. wäre die Bestimmung der häufigsten CAs (Certificate Authorities) denkbar.
4.3 Befüllen der Sicherheitsdatenbank

Das Befüllen der Sicherheitsdatenbank kann proaktiv oder nach Bedarf (On-Demand-
Betrieb) geschehen werden. Auch eine Kombination aus beiden Vorgehensweisen ist
möglich.
In diesem Abschnitt werden zunächst die zwei Betriebsmodi (proaktiver- und On-
demand-Betrieb) des Einfügens von Testdaten in die Datenbank dargestellt. Beide
Modi greifen auf Teilfunktionalitäten zurück, die in den nachfolgenden Abschnitten
detailiert diskutiert werden.
4.3.1 Proaktiver Betrieb

Im proaktiven Betrieb trägt der Administrator der Sicherheitsdatenbank initial von
Hand eine Menge von Keywords in die Datenbank ein. Für jedes dieser Keywords
34 4. Entwurf
wird eine Reihe von Suchmaschinen (z.B. Google, Yahoo, MSN Search) nach den n
besten Suchergebnissen befragt4 .
Diese Suchergebnisse bestehen aus einer Menge von URLs. Aus jeder dieser URLs
wird der FQDN extrahiert. Dieser FQDN wird nochmal in Rechnername und Domain
zerlegt. Diese Domain wird nun in die Datenbank eingetragen (vgl. Abschnitt 4.3.4).
Nun wird der FQDN in eine oder mehrere IP-Adressen aufgelöst5 . Außerdem werden
für die Domain noch alle MX-Records6 angefragt und in IP-Adressen aufgelöst. Die
so erhaltenen IP-Adressen werden mit ihren jeweiligen Funktionen (MX- und/oder
Webserver) in die Testdatenbank eingetragen (vgl. Abschnitt 4.3.5).
Sind alle Keywords abgearbeitet, kann der Administrator den Start der Tests ansto-
ßen. Hierbei wird für jede IP-Adresse jedes installierte Testmodul einmal abgearbei-
tet und die Ergebnisse in die Testdatenbank eingetragen (Vgl. Abschnitt 4.3.5).
Der proaktive Betrieb ist vor allem dafür vorgesehen, eine initiale Testdatenbank
aufzubauen. Hierbei wählt der Administrator die Keywords so, dass er glaubt, damit
die Themen abzudecken, die seine Benutzers besonders häufig abrufen werden.
Außerdem wurde der proaktive Betrieb dazu verwendet, die Effektivität der hier vor-
gestellten Lösung zu testen. Dieses Thema wird ausführlich in Kapitel 6 behandelt.
4.3.2 On-Demand-Betrieb
Im Gegensatz zum proaktiven Betrieb wird der On-Demand-Betrieb erst dann gest-
artet, wenn der Verbindungsaufbau entweder bereits im Gange (ACCS-Mode) oder
in Kürze zu erwarten ist (Discovery-Mode).
4.3.2.1 ACCS-Mode
Beim ACCS-Mode wird der Test direkt vom ACCS-System angestoßen. Entdeckt
das ACCS-System einen Verbindungsaufbau, dann stellt es eine Verbindung mit der
Testdatenbank her und überprüft zunächst, ob es für die Ziel-IP-Adresse bereits
einen Eintrag gibt. Wenn ja, dann werden die aktuellsten Testresultate als Grundla-
ge für eine Entscheidung verwendet. Falls keine Testresultate vorhanden sind, (oder
sich die Ziel-IP-Adresse noch nicht in der Datenbank befindet) wird in der Testda-
tenbank ein neuer Eintrag für die Ziel-IP-Adresse erzeugt und ein neuer Test wird
durchgeführt. Sobald die Ergebnisse dieses Tests vorliegen, setzt das ACCS-System
seine Arbeit fort. Sollte es hierbei zu einem Fehler kommen (z.B. weil ein Sicherheits-
verfahren trotz positiven Testergebnisses nicht verfügbar war oder das Zielsystem in
nicht mehr erreichbar ist), dann wird dieser als neues Test-Resultat in die Testda-
tenbank eingetragen (Rückkopplung). Dies vereinfacht eine spätere Fehlersuche im
Test-System.
4
Der Parameter n ist vom Administrator konfigurierbar
5
Aufgrund eines Bugs in der Python-DNS-Library wird im Moment nur IPv4 unterstützt (Siehe
Abschnitt 5.3.2). Das Framework ist allerdings für den Umgang mit IPv6 vorbereitet und die
Datenfelder in der Datenbank entsprechend dimensioniert.
6
Ein MX-Record spezifiziert einen Mailserver, der E-Mails für diese Domain annimmt.
4.3. Befüllen der Sicherheitsdatenbank 35
4.3.2.2 Discovery-Mode
Beim Discovery-Mode kommt eine DNS-Proxy-Komponente ins Spiel. Diese Kom-
ponente wird zwischen Client und DNS-Server positioniert. Alle DNS-Abfragen ge-
hen nun über diese Proxy-Komponente. Für jede DNS-Abfrage wird in der Test-
Datenbank nachgeschaut, ob sich die Domain des angefragten FQDN bereits in der
Test-Datenbank befindet. Falls nichtm wird diese eingetragen und ein neuer Test
angestoßen. Um die DNS-Abfrage nicht zu verzögern, läuft die gesamte Operation
asynchron ab.
4.3.3 Keywords eintragen
Die Keywords werden, wie oben bereits angedeutet, vom Administrator mittels eines
Pflegetools von Hand eingetragen. Das Datenbank-Management-System (DBMS)
stellt hierbei sicher, dass ein Keyword nicht mehrfach eingetragen werden kann. In
diesem Fall wird ein Fehler ausgegeben.
4.3.4 Domains eintragen
Wird die Datenbank proaktiv befüllt, dann werden die Domains von der Administra-
tionsanwendung in die Datenbank eingetragen und mit allen Keywords verknüpft,
für die eine zurückgelieferte URL diese Domain beinhaltet. Außerdem ist es mit
Hilfe der Administrationsanwendung möglich, eine Domain ohne die Angabe von
Keywords in die Datenbank einzufügen.
Im ACCS- bzw. Discovery-Mode geschieht die Eintragung mittels RPC-Aufruf.
Das DBMS stellt sicher, dass eine Domain nicht mehrfach in die Datenbank ein-
getragen werden kann. In diese Fall wird die Ausführung ohne die Ausgabe eines
Fehlers fortgesetzt.
4.3.5 IP-Adressen eintragen
Im proaktiven Betrieb werden die zu einer Domain gehörigen IP-Adressen (z.B. für
MX- und Webserver) bereits während der Ausführung des Content-Moduls mittels
DNS-Anfrage bestimmt.
Wird eine Domain mittels Administrationsanwendung eingetragen, wird zum Zeit-
punkt der Eintragung die DNS-Anfrage durchgeführt.
In beiden Fällen wird eine eingetragene IP-Adresse mit der Domain verknüpft. Es
ist möglich, dass eine IP-Adresse mehreren Domains zugeordnet ist (z.B. bei Name-
Based-Virtual-Hosting). Innerhalb dieser Verknüpfung wird vermerkt, welche Rollen
die IP-Adresse in dieser Domain übernimmt. Werden mehrere Rollen übernommen,
so werden auch mehrere Verknüpfungen angelegt. Mögliche Rollen sind z.B. Webser-
ver, MX-Server oder DNS-Server.
Beim ACCS-Mode ist die IP-Adresse bereits bekannt und kann direkt in die Test-
datenbank eingetragen werden.
Beim DNS-Proxy-Mode wird bereits eine DNS-Anfrage durchgeführt. Das Ergebnis
dieser Anfrage wird, sobald es vorliegt, für die angefragte Domain in die Datenbank
eingetragen. Wird anstelle der IP-Adresse ein Fehler zurückgegeben, so wird die
eingetragene Domain wieder aus der Datenbank entfernt.
In jedem Fall wird bei der IP-Adresse spezifiziert, ob es sich um eine IPv4- oder eine
IPv6-Adresse handelt.
36 4. Entwurf
4.3.6 Test-Resultate eintragen

Im proaktiven Betrieb wird das Kreuzprodukt aller IP-Adressen und aller Rollen der
jeweiligen IP-Adressen angefragt. Das Ergebnis dieser Anfrage sind Kombinationen
aus zu testenden IP-Adressen und Ports. Für jede dieser Kombinationen wird das
entsprechende Test-Modul ausgeführt. Das Ergebnis dieses Tests wird in die Relation
Tests eingefügt. Ältere Test-Resultate werden hierbei nicht überschrieben, sondern
das neue Ergebnis wird an das Ende der Relation angehängt.
Im Betrieb als DNS-Proxy ist das zu testende Protokoll nicht bekannt. In diesem
Falle werden alle installierten Test-Module ausgeführt.
Im ACCS-Mode ist das gewünschte Protokoll bereits bekannt, und das entsprechende
Test-Modul kann direkt ausgewählt werden.
In allen Fällen wird zum Test ein Resultat (vgl. Abschnitt 4.1.2), ein Datum so-
wie im Falle einer erfolgreichen SSL/TLS-Verbindung das Zertifikat der Gegenstelle,
gespeichert.
4.4 Zusammenfassung
Im zweiten Teil des Kapitels wurde eine modulare Architektur entworfen, die als
Grundlage für das zu entwickelnde System dient. Hierbei wurde zwischen Test- und
Content-Modulen unterschieden, mit denen jeweils verschiedene Aspekte des Sys-
tems implementiert werden.
Weiterhin wurde die Vorgehensweise zum Bestimmen der Ähnlichkeit zwischen zwei-
er Webseiten A und B erläutert und der Test hierauf als Modul entworfen.
Im zweiten Teil dieses Kapitels wurde relationales Datenbankschema entworfen, in
dem die Informationen über die getesteten Rechner sowie die Resultate der durch-
geführten Tests gespeichert werden.
Es wurden verschiedene Methoden vorgestellt, mit denen diese Datenbank befüllt
werden kann, von denen der proaktive Modus der für diese Studienarbeit wichtigste
ist.
5. Implementierung
In diesem Kapitel wird die Implementierung der für die Zwecke dieser Studienarbeit
geschriebenen Software erörtert. Darüber hinaus wird auf die Probleme, die es bei
der praktischen Umsetzung gab, eingegangen, und die gefundenen Lösungen werden
beschrieben.
Die für die Zwecke dieser Studienarbeit geschriebene Software besteht im wesentli-
chen aus zwei Teilen:
• NSC Framework: Framework zur Implementierung von Test- und Content-

Modulen.
• NSC Web: Web-Frontend zur Abfrage der Sicherheitsdatenbank und Anforde-
rung von Statistiken.
Das NSC Framework wurde in der Programmiersprache Python entwickelt. Py-

thon bietet alle Vorzüge einer modernen, objektorientierten Programmiersprache
und bringt bereits alle wesentlichen Funktionalitäten wie OpenSSL-, HTTP- und
MySQL-Unterstützung bereits als Modul implementiert sind. Da es sich bei Python
um eine Skriptsprache handelt, war es sehr schnell möglich, einen funktionsfähigen
Prototyp für das Framework zu schreiben, um die weiteren Anforderungen bereits
in einer sehr frühen Phase der Entwicklung evaluieren zu können.
Als Backend für die Speicherung der anfallenden Testdaten wurde MySQL ausge-
wählt.
Das Webinterface wurde der Einfachheit halber in der Programmiersprache PHP
geschrieben. Die Hauptaufgabe des Webinterfaces ist die Visualisierung der ange-
fallenen Testergebnise. Im wesentlichen handelt es sich hierbei um Anfragen an die
Testdatenbank, so dass ein Großteil der Logik in Form von SQL-Anfragen realisiert
wurde.
5.1 Module
Wie in Abschnitt 4.1.1 bereits erwähnt, wird die Test- und Inhalts-Analyse-Funktionalität
mit Hilfe von Modulen realisiert. Hierzu bietet das NSC-Framework zwei verschie-
dene Modulschnittstellen, jeweils eine für Test-Module und Content-Module.
38 5. Implementierung
5.1.1 Die Test-Modul-Schnittstelle

Test-Module werden im Unterverzeichnis tests“ des Quellcodeverzeichnises abge-
”
legt. In diesem Verzeichnis befindet sich bereits die Datei test.py“, in der der Quell-
”
code der Klasse NSCTest liegt.
Neue Test-Module werden in einer neuen Datei als neue Klassen implementiert. Sie
erben von der Klasse NSCTest. Zur Implementierung wird das Entwufsmuster Scha-
blonenmethode (Template-Method ) verwendet [GHJV95], wobei die Klasse NSCTest
bereits alle Standard-Aufgaben – wie das Aufbauen der Netzwerkverbindung und die
Rückgabe der Test-Ergebnisse – realisiert, so dass ein neues Test-Modul nur noch
den eigentlichen Test implementieren muss.
In der init -Methode – also dem Konstruktor – der Test-Klasse werden hierzu die
beiden Variablen self.ports und self.tests definiert.
Die Variable self.ports enthält hierbei eine Liste aller TCP-Ports, zu der es Verbin-
dungen aufbauen möchte. Für jeden dieser Ports wird in der Variable self.tests mit
Hilfe eines Dictionaries 1 , das Funktionspointer auf die entsprechenden Methoden als
Werte enthält, jedem Port eine Test-Methode zugeordnet. Mit dieser Technik ist es
möglich, dass ein Modul auch mehrere Tests für verschiedene Protokolle durchführen
kann. Nach welchem Schema die Tests auf Module verteilt werden sollen, wird in
Abschnitt 4.1.1.1 festgelegt.
5.1.2 Die Content-Modul-Schnittstelle
Content-Module werden im Unterverzeichnis content“ des Quellcodeverzeichnises
”
abgelegt. In diesem Verzeichnis befindet sich bereits die Datei content.py“, in der
”
die Klasse NSCContent implementiert ist.
Neue Content-Module werden in einer neuen Datei im selben Verzeichnis als neue
Klassen implementiert. Sie erben von der Klasse NSCContent. Ein neuer Conten-
Module muss die Methode crawl()“ implementieren, die in NSCContent lediglich
”
als abstrakte Methode vorliegt. Die Klasse NSCContent implementiert bereits den
größten Teil der Funktionalität, die von einem Content-Modul benötigt wird. Sie
ist Mithilfe der Methode download(url)“ in der Lage, eine Datei über HTTP oder
”
HTTPS abzurufen, und den Inhalt dieser Datei als String zurückzugeben. Hierbei
wird auch der Abruf von gzip-komprimierten Inhalten unterstützt.
Darüber hinaus stehen noch die beiden Methoden extractLinks(dokument)“ und
”
extractHost(link)“ zur Verfügung. Die Methode extractLinks(dokument)“ extra-
” ”
hiert alle Links auf unverschlüsselte Webseiten2 . Auf so extrahierte Links kann die
Methode extractHost(link)“ angewendet werden, um den FQDN des Ziel-Hostes
”
aus dem Link zu extrahieren.
5.2 Laufzeitoptimierung des Ratcliff/Obershelp Al-

gorithmus
Der in Abschnitt 3.6.3.3 vorgestellte optimierte Algorithmus von Ratcliff/Obershelp
liegt im Modul difflib bereits als Python-Implementierung vor. Diese Implementie-
rung übernimmt bereits die Entfernung aller nicht alpha-numerischen Zeichen.
1
Hierbei handelt es sich um das Pythonäquivalent einer Hashtabelle
2
Allerdings nur, wenn der Link keine Angabe eines Ports enthält, da dies der Annahme dieser
Studienarbeit, dass sich alle HTTP-Seiten auf Port 80 befinden, wiedersprechen würde.
5.3. Python-spezifische Probleme 39
Obwohl mit dieser optimierten Veriante bereits eine deutliche Laufzeitverbesserung

gegenüber der ursprünglichen Variante des Algorithmus von Ratcliff/Obershelp er-
zielt wird, beträgt die Wartezeigt bei aktuellen Webseiten, die oft eine Größe von
über 100 kB haben, mehrere Minuten3 . Abhilfe schafft hier die Verwendung der Me-
thode quick ratio() des der Python difflib. Im Gegensatz zu ratio() wird hier kein
genauer Wert zurückgeliefert, sondern es wird in einem Durchlauf eine obere Schran-
ke für die Übereinstimmung berechnet und diese zurückgeliefert. Dieser Wert kann
deutlich über dem Wert liegen, den ratio() zurückliefern würde. Allerdings hat die
Methode quick ratio() einen Worst-Case Aufwand von O(n) (n bezeichnet die Länge
der Eingabe), was eine deutliche Beschleunigung bedeutet4 .
Insgeamt handelt es sich also um einen Kompromiss zwischen Genauigkeit und Lauf-
zeit. In einem Versuch hat sich jedoch gezeigt, dass sich bei einem entsprechend ho-
hen Schwellenwert mit quick ratio() durchaus sehr brauchbare Ergebnisse erzielen
lassen, und eine zuverlässige Erkennung von per HTTPS verfügbaren Webseiten im-
mer noch möglich ist. Eine genauere Analyse der Erkennungsrate bei verschiedene
Schwellenwerte wird in Kapitel 6 durchgeführt.
5.3 Python-spezifische Probleme

In diesem Abschnitt wird auf Probleme eingegangen, die durch die Verwendung von
Python bzw. Python-spezifischen Modulen entstanden sind.
5.3.1 Global Interpreter Lock

Python wurde mit dem Ziel entworfen, höchste Portierbarkeit ohne Notwendigkeit
der Veränderung des Quelltextes, zu gewährleisten. Hierzu werden alle Operationen,
die mit dem Betriebssystem interagieren, in sogennante Module gekapselt, und für
jedes Ziel-Betriebssystem wird eine eigene Implementierung dieser Module ausgelie-
fert.
Nun ist es so, dass manche Betriebssysteme Kernel-Level-Threads (KLTs) anbie-
ten, andere hingegen nicht. KLTs sind Threads, die dem Betriebssystem bekannt
sind. Dies bedeutet, dass das Betriebssystem alle Threads einer Applikation kennt,
und im Falle eines blockierens eines solchen Threads einfach einen anderen Thread
der selben Applikation starten kann. Wird ein Betriebssystem verwendet, das kei-
ne KLTs anbietet, können lediglich sogenannte Pure-User-Level-Threads (PULTs)
verwendet werden. Hierbei sind die einzelnen Threads nur der Applikation bekannt,
das Betriebssystem hingegen weiß nichts von den Threads einer Applikation. Blo-
ckiert nun einer dieser PULTs, steht die ganze Applikation so lange, bis die Blockade
aufgehoben ist. Insbesondere kann die Applikation keine anderen Operationen wäh-
rend dieser Zeit durchführen. Darüber hinaus ist es nicht möglich, eine Applikation
gleichzeitig auf mehreren Prozessoren eines Mehrprozessorsystems laufen zu lassen.
In dieser Studienarbeit werden Threads vor allem dazu verwendet, die Wartezeit
bei blockierenden Netzwerk-Operationen zu verringern: Sobald ein KLT eine blo-
ckierende Netzwerk-Operation aufruft, wird dies vom Betriebssystem erkannt, der
3
Für die Webseite http://www.amazon.com dauerte ein kompletter Testdurchlauf 25 Minuten, 43
Sekunden. Die Seite umfasste zum Zeitpunkt des Testes 104 kB.
4
Ein vollständiger Testdurchlauf unter der Verwendung von quick ratio() der Webseite
http://www.amazon.com brauchte noch 8,849 Sekunde, was eine Beschleunigung um Faktor
174 im Vergleich zur Verwendung von ratio() bedeutet.
KLT unterbrochen und ein anderer KLT wird gestartet. Sobald die Ergebnisse der
blockierenden Eingabe-/Ausgabe-Operation vorliegen, wird die Ausführung des un-
terbrochenen KLTs fortgesetzt. Auf einem Betriebssystem, auf dem lediglich PULTs
verfügbar sind, würde der blockierte Thread so lange weiterlaufen – und somit wert-
volle Ausführungszeit mit Nichtstun verschwenden – bis die Zeitscheibe der Appli-
kation, zu dem der Thread gehört, abgelaufen ist, und eine neue Applikation vom
Betriebssystem aufgerufen wird.
Bei der Verwendung der Threading-Unterstützung von Python ist die Verwendung
von KLTs und PULTs für den Benutzer transparent. Sobald ein Betriebssystem
KLTs anbietet, und Python die Implementierung des jeweiligen Betriebssystems un-
terstützt, werden KLTs verwendet. Ist dies nicht der Fall, bildet Python die Funk-
tionalität von KLTs mit Hilfe von PULTs nach. Der Programmierer muss hierzu
nichts an seinem Programm ändern.
Hiebei stellt sich nun allerdings ein Problem: PULTs können prinzipbedingt nicht
parallel ausgeführt werden, bei KLTs ist dies jedoch durchaus möglich. Bei der
parallelen Ausführung von Threads stellen sich jedoch ganz neue Anforderungen an
den Programmierer, der verhindern muss, dass durch das parallele Ausführen von
Threads sogenannte Race Conditions, also Fehler, die durch ungüngstiges Timing
ausgelöst werden, auftreten. Hierzu werden Sperren, auch Locks genannt, verwendet,
die verhindern, dass mehrere parallel laufende Threads zur selben Zeit in kritische
Codestellen eintreten.
Entwickelt nun ein Programmierer ein Programm, das auf Threads basiert, und
verwendet zum Testen eine Plattform, die keine KLTs unterstützt, dann ist die
Wahrscheinlichkeit recht hoch, dass auf einer KLT -fähigen Plattform die korrekte
Ausführung dieses Programms nicht möglich ist. Dieses Verhalten stünde also im
Wiederspruch zur Forderung der Portierbarkeit.
Zur Lösung dieses Problems gibt es in Python das sogenannte Global-Interpreter-
Lock (GIL). Hierbei handelt es sich um eine globale Sperre, die alle Datenstukturen
in Python schützt [Pyth08]. Das GIL wird zu einer bestimmten Zeit jeweils nur von
einem einzigen Thread gehalten. Nur der Thread, der das GIL hält, darf auf Python-
Objekten operieren oder Betriebssystemaufrufe ausführen. Effektiv führt dies dazu,
dass zu einer bestimmten Zeit immer nur ein bestimmter KLT laufen kann; alle
anderen Threads sind blockiert, da sie auf das GIL warten. Ein Thread, der das GIL
hält, gibt dieses nach einer bestimmten Anzahl von Instruktionen wieder frei, so dass
ein anderer KLT die Möglichkeit bekommt, das GIL zu erwerben. Außerdem wird das
GIL freigegeben, sobald eine blockierende Eingabe-/Ausgabeoperation aufgerufen
wird.
Die Verwendung des GIL ist unter Python-Programmierern heftig umstritten, da es
das simultane Ausführen mehrerer Threads verhindert, was bei Prozessor-lastigen
Anwendungen ein Nachteil sein kann. Das GIL bietet jedoch einige Vorteile, die
diese Nachteile wieder aufwiegen. Zunächst einmal ist der schon angesprochene Vor-
teil der Portierbarkeit, da Anwendungen, die Threads verwenden ohne Änderungen
als Quellcode auf vielen verschiedenen Plattformen laufen. Der wichtigste Vorteil
dürfte jedoch die Arbeitserleichterung für den Entwickler sein: Der Entwickler kann,
ohne sich große Gedanken über die Verwendung von komplexen Datenstrukturen
wie sogenannte SpinlocksHierbei handelt es sich um eine spezielle Sperre, die dazu
5.3. Python-spezifische Probleme 41
verwendet wird, mehrere paralell laufende Threads zu synchronisieren. machen zu

müssen, Threads in seinem Programm verwenden. Außerdem wird das Auftreten von
schwer zu identifizierenden Fehlern, wie sie bei der Verwendung von Threading auf
anderen Plattformen häufig auftreten, vermieden.
Da Threads in den meisten Fällen dazu benutzt werden, die Wartezeit bei blockieren-
den Eingabe/Ausgabe-Operationen effektiv zu nutzen, ist echte Parallelisierbarkeit
oft gar nicht notwendig oder sogar garnicht gewünscht5 . Ist echte Parallelisierung
gewünscht, so ist es immer noch möglich, mit Hilfe von fork() einen neuen Task zu
starten. Hierbei muss jedoch beachtet werden, dass dies auf einigen Plattformen wie
Windows eine sehr teure Operationen sein kann. Auf Linux, der für die vorliegende
Studienarbeit verwendeten Plattform, hingegen ist die Verwendung von fork() 6 nicht
viel teurer als die Verwendung von Threads.
In der vorliegenden Studienarbeit werden alle Netzwerk-lastigen Operationen, wie
z.B. die Durchführung der Tests durch die Verwendung von Threads und alle Prozessor-
lastigen Operationen wie z.B. die Ähnlichkeitsanalysen von Webseiten durch die
Verwendung von fork() beschleunigt, da hierbei alle Prozessoren eines Systems ver-
wendet werden können.
5.3.2 PyDNS
PyDNS ist ein Python-Modul, das es ermöglicht, aus einem Python Programm her-
aus DNS-Abfragen zu stellen. Normalerweise ist dies nicht notwendig, da beim Öff-
nen eines Sockets der DNS-Resolver des Betriebssystems diese Aufgabe übernimmt.
Für die Zwecke dieser Studienarbeit ist dies jedoch nicht immer ausreichend, da hier-
mit kompliziertere DNS-Anfragen – wie z.B. die Bestimmung eines MX-Eintrages –
nicht möglich sind. An diser Stelle kommt PyDNS ins Spiel. PyDNS implementiert
selbst einen Resolver, mit dem jede beliebige DNS-Anfrage gestellt werden kann.
Leider wurde IPv6 bei der Entwicklung von PyDNS nicht berücksichtigt, so dass
Antworten auf Anfragen von AAAA-Records von PyDNS falsch interpretiert wer-
den. Aus diesem Grund wurde in dieser Studienarbeit die Unterstützung von IPv6
vorübergehend deaktiviert. Sobald eine neue Version von PyDNS verfügbar ist, die
IPv6 unterstützt, kann diese wieder aktiviert werden.
5.3.3 PyOpenSSL
PyOpenSSList die Python-Schnittstelle zur OpenSSL-Bibliothek. Es handelt sich
hierbei um eine Abbildung der OpenSSL-C-API auf Python-Funktionen. Dement-
sprechend ähnlich ist auch die Vorgehensweise beim Schreiben von Programmen auf
Basis von PyOpenSSL. Leider ist die Dokumentation von PyOpenSSL sehr spärlich,
so dass die Funktionsweise von vielen Methoden oft nur aus der Dokumentation der
OpenSSL C-API erschlossen werden kann.
Eine häufige Fehlerquelle war das Verwenden von Timeouts bei Sockets, die mit
PyOpenSSL nicht gut zusammenarbeiten. Diese Problematik wird im folgenden Ab-
schnitt genauer erläutert.
5
Die Ausführung eines Programms auf mehreren Prozessoren gleichzeitig bietet nicht immer nur
Vorteile und kann in Extremfällen sogar zu einer deutlichen Verlangsamung führen. Dies ist
vor allem dann der Fall, wenn entwender eine Nutzung von Caches durch die Parallelisierung
nicht möglich ist, oder aber auf Non-Uniform-Memory-Access-Systemen, in denen die Kosten
des Speicherzugriffs von der Entfernung zwischen Prozessor und Speicher abhängt.
6
Unter Unix startet fork() einen neuen Prozess (Task).
5.3.4 Timeouts
Die Socket-Schnittstelle in Python hat standardmäßig keinen Timeout-Wert gesetzt.
Das bedeutet, dass bei einer Socket Operation, auf die keine Antwort erfolgt, un-
endlich lange versucht wird, die Operation zu wiederholen, bis eine Antwort der
Gegenstelle erfolgt. Da bei einem Test von vielen tausend Gegenstellen – wie es
bei dieser Studienarbeit der Fall ist – die Wahrscheinlichkeit sehr hoch ist, dass ei-
ne oder mehrere Gegenstellen nicht antworten, ist dieses Verhalten natürlich nicht
wünschenswert.
Um Abhilfe zu schaffen bietet die Socket-Schnittstelle in Python die Methode setti-
meout() an, mit der die maximale Zeit spezifiziert werden kann, die auf eine Gegen-
stelle gewartet werden soll.
Die Methode settimeout() hat jedoch leider einen unerwünschten Seiteneffekt: Beim
Setzen eines Timeouts wird der Socket vom blockierenden in den nicht blockierenden
Zustand versetzt. Dies fällt zunächst nicht auf, da die Methoden des Socket-Moduls
in Python das blockierende Verhalten simulieren, so dass alle Python-Programme,
die auf das Socket-Modul aufsetzen, von der Veränderung nichts mitbekommen.
PyOpenSSL operiert jedoch nicht auf dem Socket-Modul von Python, sondern eine
Ebene tiefer, nämlich direkt auf dem Socket der C -Standardbibliothek. Da auf dieser
Ebene die durch das Python-Socket-Modul implementierte Abstraktion nicht zur
Verfügung steht, führt dies dazu, dass PyOpenSSL mit der Meldung abbricht, dass
die empfangenen Daten falsch formatiert seien.
Die Lösung für dieses Problem fand sich in dem Modul timeoutsocket von Timo-
thy O’Malley. Dieses Modul arbeitet als Dekorierer (Decorator ) [GHJV95] für das
Socket-Modul von Python und fügt diesem die Unterstützung von Timeouts hin-
zu. timeoutsocket arbeitet hierbei so, dass es alle Methoden, bei denen ein Timeout
auftreten kann, wie z.B. accept(), recv(), connect() etc. kapselt. Wird die gekapselte
Methode aufgerufen, wird der socket zunächst von blockierend auf nicht blockierend
umgestellt. Dann wird in einer Schleife mit Hilfe von select() so lange versucht, von
dem Socket zu lesen, bis entweder ein Timeout auftritt oder aber die angeforderte
Operation erfolgreich durchgeführt wurde. Dannach wird der Socket zurück in den
blockierenden Modus geschaltet und das Ergebniss der Operation wird zurückgege-
ben.
Hierdurch ist zum einen gewährleistet, dass Socket-Operationen nicht unendlich lan-
ge dauern können; zum anderen funktioniert aber auch die Zusammenarbeit mit
PyOpenSSL, da sich der Socket im blockierenden Modus befindet, sobald er an Py-
OpenSSL übergeben wird.
5.4 PHP: Probleme beim Verarbeiten von Inter-

gern
In diesem Abschnitt werden Probleme beschrieben, die durch die Verwendung der
Programmiersprache PHP entstehen.
Die Länge des PHP -Datentyps PHP-Integer ist plattformabhängig, d.h. auf einer
64-Bit-Plattform ist ein PHP -Integer länger als auf einer 32-Bit Plattform. Darüber
5.5. Aufbau des Webinterfaces 43
hinaus sind PHP -Integer immer vorzeichenbehaftet, d.h. der größtmögliche Wert
eines Integers auf einer 32-Bit Plattform beträgt 231 − 1 [Grou08].
In Abschnitt 4.2.4 wurde beschrieben, dass in dieser Studienarbeit IP-Adressen
als Integerwerte in der Sicherheitsdatenbank gespeichert sind. Eine IPv4-Adresse
wird hierbei durch einen 32-Bit langen Integer repräsentiert. PHP interpretiert das
höchstwertige Bit eines solchen Integers immer als Vorzeichen. Da es in PHP keine
Möglichkeit gibt, Integer in einen vorzeichenlosen Typ zu konvertieren, sind Rechen-
operationen und insbesondere das Umwandeln einer IP-Adresse in Integerdarstellung
in die Stringdarstellung in PHP praktisch unmöglich.
Glücklicherweise bietet MySQL bereits eine Reihe von Funktionen an, mit denen IP-
Adressen bereits auf Datenbankebene manipuliert und umgewandelt werden können.
Im Webinterface dieser Studienarbeit wird die MySQL-Funktion inet ntoa() verwen-
det, um eine IP-Adresse beim Auslesen in die Stringdarstellung zu konvertieren. Da
das Statistikinterface lediglich zur Darstellung der Ergebnisse verwendet wird, alle
Suchoperationen bereits von dem DBMS vorgenommen werden können und das Ein-
fügen und Ändern der Daten von Python vorgenommen wird, das im Gegensatz zu
PHP keinen solchen Beschränkungen bei der Länge von Integern aufweist, konnten
diese PHP -spezifischen Probleme jedoch umgangen werden.
5.5 Aufbau des Webinterfaces

Das Webinterface ist – wie bereits angedeutet – in der Programmiersprache PHP
implementiert. Das Design folgt dem MVC -Muster [GHJV95], wobei jedoch der Ein-
fachheit wegen Controller und Model in der selben Klasse definiert wurden. Bei jeder
Anfrage an das Web-Interface wird die Datei index.php aufgerufen, welche als Dis-
patcher agiert und die Anfrage an den jeweils passenden Controller weiterleitet. Die
Controller befinden sich im Verzeichnis Controllers. Das zu dem Controller passende
Modell wurde in der Form von Funktionen im Kopf der entsprechenden Control-
lerdatei definiert – es ist jedoch ohne weiteres möglich, diese in separate Dateien
auszulagern, um den MVC -Entwurf noch deutlicher zu unterstreichen.
Im Rumpf der Controllerdatei werden zunächst alle vom Browser übergebenen Va-
riablen ausgelesen, anhand derer entschieden wird, welche Anfrage an das Modell
zu stellen ist. Dannach wird diese Anfrage an das Modell gestellt, und die Ausga-
be wird an das zum Controller passende Template – in MVC -Terminologie auch
View genannt – übergeben. Dieses Template verarbeitet die Ausgabe des Models zu
HTML-Code, welcher wiederum vom Browser dargestellt wird.
5.6 Zusammenfassung
In diesem Kapitel wurden die implementierungsspezifischen Details dieser Studien-
arbeit beschrieben.
Zunächst wurde beschrieben, wie sich die in Abschnitt 4.1.1 entworfene Modul-
schnittstelle auf die Implementierung in Python abbilden lässt.
Dannach wurde eine Optimierung der Laufzeit des verbesserten Ratcliff/Obershelp
Algorithmus vorgeschlagen, da der Algorithmus sehr langsam wird, wenn sehr große
Webseiten verglichen werden sollen. Hierbei wird anstelle eines genauen Ähnlichkeits-
wertes lediglich eine obere Schranke für die Ähnlichkeit berechnet und der Schwel-
lenwert, ab dem das System davon ausgeht, dass es sich um die selbe Seite handelt
auf einen höheren Wert gesetzt. Diese Lösung erwies sich als signifikant schneller
und lieferte nur unwesentlich schlechtere Ergebnisse.
Im folgenden Abschnitt wurden Python-spezifische Probleme erläutert, die zum einen
das Multi-Threading-Modell von Python betrafen, das auf Grund des sogenannten
Global Interpreter Locks“ keine simultane Ausführung mehrere Threads auf mehre-
”
ren Prozessoren eines Mehrprozessor-Systems erlaubt. Es wurde jedoch gezeigt, dass
sich hieraus für Eingabe-/Ausgabe-lastige Threads keine Nachteile ergeben, und dass
für Prozessor-lastige Threads auf die Verwendung von mehreren Prozessen ausgewi-
chen werden kann. Zum anderen wurden einige Probleme beschrieben, die nicht
auf Python direkt, sondern auf die Schnittstellenmodule zum Domain-Name-System
(DNS) und OpenSSL zurückgehen. Die OpenSSL betreffenden Probleme konnten
zwar gelöst werden, für die DNS-spezifischen Probleme muss jedoch auf eine IPv6-
fähige Version von PyDNS gewartet werden, so dass die IPv6-Unterstützung in dieser
Studienarbeit nicht getestet werden konnte.
Es folgt ein Abschnitt, der PHP spezifische Probleme bei Operationen mit Integern
mit Werten größer 231 betrafen. Hierfür konnte eine Lösung gefunden werden, indem
diese Operationen in die Datenbank verlagert wurden.
Zuletzt wurde kurz die Implementierung des Webinterfaces vorgestellt, mit Hilfe
dessen sich der Inhalt der Sicherheitsdatenbank in einem Webbrowser darstellen
lässt.
6. Evaluierung
In diesem Kapitel wird das entwickelte System evaluiert.

Zunächst wird hierzu in Abschnitt 6.1 der Schwellwert bestimmt, ab dem zwei Web-
seiten als ähnlich anzusehend sind.
In den darauf folgenden Abschnitten werden umfangreiche Tests der Leistungsfähig-
keit des entwickelten System durchgeführt.
Hierzu wird zunächst in Abschnitt 6.2 das Laufzeitverhalten des Ähnlichkeitstest
unter idealen Bedingungen genauer untersucht.
In Abschnitt 6.2 wird schliesslich das Laufzeitverhalten des Gesamtsystem unter
realistischen Bedinungen getestet und die Ergebnisse werden vorgestellt. Es wird im
Detail auf die Laufzeit einzelner Teilaspekte der Test eingegangen und insbesondere
wird das Verhältnis zwischen Laufzeit der Tests und Dauer der Netzwerkübertragung
untersucht.
Für alle Testläufe wurde ein Linux-System mit Kernel 2.6.24-19-generic, Python Ver-
sion 2.5.2, 32 GB Hauptspeicher sowie 2 QuadCore Intel XEON X3533 Prozessoren
verwendet. Insgesammt standen also 8 CPU-Kerne zur Verfügung.
6.1 Bestimmung des Ähnlichkeits-Schwellwerts

In diesem Abschnitt soll der Schwellwert für die Ausgabe des in 3.6.3.3 definierten
Algorithmus bestimmt, ab dem die zwei verglichenen Webseiten A und B als gleich
anzusehen sind.
6.1.1 Vorgehensweise
Zur Bestimmung des Schwellwerts wird eine möglichst große Eingabemenge an zu
testenden Websites aufgebaut. Hierzu werden genau 100 Keywords aus verschiedenen
Lebensbereichen von Hand in die Datenbank eingegeben.
Nun wird der GOOGLECrawler ausgeführt, der für jedes dieser Keywords eine An-
frage an die Suchmaschine Google startet, und die besten 100 Suchergebnisse, wie
in Abschnitt 4.3.4 beschrieben, in die Relation Domains einfügt.
46 6. Evaluierung
Auf diese Weise kommt eine Datenmenge von 8507 Einträge in der Relation Domains
zu Stande. Für jeden dieser Einträge wird nun ein Schnelltest durchgeführt, bei dem
versucht wird, eine SSL/TLS Verbindung mit dem HTTPS-Port (443) des jeweiligen
Zielrechners aufzubauen. Hirbei wird das Testresultat wie gewohnt in die Relation
Tests eingefügt.
Im nächsten Schritt werden mit Hilfe der Relation Tests alle Websites bestimmt,
bei denen der Test für das Protokoll HTTPS das Ergebnis TLS-Worked lieferte.
Hierdurch kommt es zu einer Liste von 3991 Websites. Für jede der so bestimm-
ten Websites wird ein das Test-Modul SIMILARITYContent ausgeführt und der so
erhaltene Ähnlichkeitswert in den Datensatz der Website in Domains eingefügt.
Sobald die Daten des Testdurchlaufs vorliegen, wird händisch, vom höchsten Ähn-
lichkeitswert beginnnen, überprüft, ab welchem Wert keine Gleichheit der Seiten
mehr vorliegt.
Beim Testdurchlauf stellten sich zwei Probleme, nämlich die Behandlung von HTTP-
Redirect-Anweisungen, also Umleitungen auf eine andere Webseite und das Vorhan-
densein einer Übergangszone bei den Ähnlichkeitswerten.
Tritt beim Abruf einer Webseite eine HTTP -Redirect-Anweisungen auf, so liefert das
SIMILARITYContent-Modul sofort der Ähnlichkeitswert -1 zurück, da es davon
ausgeht, dass es sich um einen Redirect von HTTPS auf HTTP handelt. Hierbei
kann es jedoch vorkommen, dass fälschlicherweise eine Umleitung von HTTP auf
HTTPS auch mit dem Ähnlichkeitswert -1 bewertet wird, was zu falsch-negativen
Ergebnissen führen kann.
Darüber hinaus stellt sich das Problem, dass der Zusammenhang zwischen Ähnlich-
keitswert und der Verfügbarkeit von HTTPS nicht stetig ist. Dies bedeutet, dass
sich keine eindeutige Grenzen finden lässt, die die abgerufenen Webseiten eindeutig
in solche, die HTTPS anbieten und solche die es nicht tun, trennt. Viel mehr ist
es so, dass es immer einen Übergangsbereich finden lässt, indem sich sowohl solche
Seiten befinden, die HTTPS anbieten als auch solche, die es nicht tun. Dies liegt
daran, dass es Seiten gibt, die sich zwischen zwei Abrufen stärker unterscheiden als
zwei unterschiedliche Seiten mit ähnlichem Inhalt. Die Wahl eines Schwellenwerts
ist daher garnicht eindeutig möglich.
6.1.2 Ergebnisse
Unter der Annahme, dass ein falsch-negatives Ergebnis weniger schädlich ist, als
ein falsch-positives, wurde in der vorliegenden Studienarbeit daher die Entscheidung
getroffen, den Schwellwert so zu wählen, dass der Anteil der falsch-positiven Ergeb-
nisse unter eine Schwelle von 3% sinkt. Zur Bestimmung dieses Schwellwertes wurde
Stichprobenartig von Hand überprüft, ab welchem Schwellwert der Anteil der kor-
rekt eingeordneten Seiten größer ist als der der falsch eingeordneten Seiten. Dies ist
ab einem Wert von ca. 85 der Fall.
Im nächsten Schritt wurden alle Seite über 85 betrachtet und alle Seiten, bei denen
die Übereinstimmung der über HTTP mit den über HTTPS abgerufenen Versionen
gegeben war. Diese Seiten wurden als korrekt eingestuft markiert. Nun wurde iterativ
der Schwellwert so lange erhöht, bis der Anteil der korrekt markierten Seiten mit
einem Ähnlickeitswert über dem Schwellwert, 97% erreichte.
6.2. Laufzeitverhalten des Ähnlichkeitstests 47
Dies war ab einem Schwellwert 94,36 der Fall. Insgesamt wird hieraus gefolgert,
dass eine Seite mit einem Ähnlichkeitswert von mindestens 95% als über HTTPS
verfügbar zu werten ist.
6.2 Laufzeitverhalten des Ähnlichkeitstests

In diesem Abschnitt soll das Laufzeitverhalten des Ähnlichkeitstestes für Webseiten
in Abhängigkeit der Länge der eingegebenen Webseiten A und B untersucht werden.
Zur Vereinfachung des Testens des Laufzeitverhaltens wird davon ausgegangen, dass
sich die beiden Webseiten A und B bei mehreren aufeinanderfolgenden Abrufen nicht
verändern.
Hierbei sind drei Fälle zu unterscheiden:
• 1. Fall: Webseite A ist deutlich größer als Webseite B.
• 2. Fall: Webseite A ist deutlich kleiner als Webseite B
• 3. Fall: Webseite A und Webseite B sind ungefährt gleich groß.
Zum Testen wurde eine Test-Datei mit einer 300 MB langen zufälligen Zeichenfolge
generiert. Mit Hilfe einer Python-Funktion wird für jeden Durchlauf des Tests von
einer zufälligen Position eine Zeichenfolge bestimmter Länge gelesen. Die Länge des
so gewonnen Auszug wird als Parameter an die Python-Funktion gegeben.
Diese Funktion wird in ein Skript eingebettet, in dem sich auch der in Abschnitt 3.6.3.3
beschriebene Algorithmus befindet, so wie er auch vom SIMILARITYContent-Modul
implementiert wird.
Dieses Skript arbeitet nun die drei beschriebenen Fälle ab. Für den ersten Fall wird
mit der oben beschriebenen Python-Funktion ein Auszug der Größe 20 kB als Stell-
vertreter für Webseite B ausgelesen. Der Stellvertreter für Webseite A wird initial
mit einem Auszug von 40 kB Größe belegt und ein Vergleichstest zwischen A und
B wird durchgeführt; die Laufzeit dieses Tests wird gespeichert. Nun werden itera-
tiv weitere Auszüge für A erstellt – wobei dieses jeweils 5 kB größer sind, als der
vorhergebende Auszug – und der Test wird wiederholt. Wieder wird das Laufzeit-
verhalten aufgezeichnet. Dies wird so lange wiederholt, bis A eine Größe von 280 kB
überschreitet.
Der zweite Fall wird analog dazu ausgeführt, allerdings wird nun A festgehalten und
B wächst. Dieser Fall muss deshalb untersucht werden, da der in Abschnitt 3.6.3.3
beschriebene Algorithmus nicht symmetrisch ist.
Im dritten Fall werden A und B mit zwei unterschiedlichen, gleich großen Auszügen
aus der Zufallsdatei befüllt, wobei die initiale Größe auf jeweils 20 kB gestgelegt
wird. Analog zum ersten und zweiten Fall wird nun iterativ in einer Schleife die
Dateigröße beider Dateien um jeweils 5 kB erhöht, ein Test durchgeführt und das
Zeitverhalten des Tests aufgezeichnet. Dieser Test wird so lange wiederholt, bis A
und B insgesamt eine Größe von 300 kB erreicht haben.
48 6. Evaluierung
6.2.2 Probleme
Bei der oben beschriebenen Vorgehensweise könnten zwei Probleme auftreten:
• Der Algorithmus verhält sich bei Zufallszeichen anders als bei Fließtext oder
HTML-Text.
• Das Laufzeitverhalten des Algorithmus hängt vom Grad der Übereinstimmung

der verglcihenen Texte ab.
Zur Untersuchung des ersten Falls wurden mehrere Versionen von diversen Webseiten
aus dem World Wide Web heruntergeladen. Der Test wurde nun zunächst mit diesen
Webseiten durchgeführt. Danach wurde der Test mit Zufallsdateien mit den selben
größen der Webseiten durchgeführt. Eine Laufzeitanalyse zeigte, dass die Dauer des
Algorithmus nicht von der Art der eingegebenen Datei abhängt. Daraus kann gefol-
gert werden, dass das Laufzeitverhalten einer Webseite dem Laufzeitverhalten auf
einer Zufallsdatei mit der selben Größe entspricht, der Test also realistische Werte
misst.
Zur Untersuchung des zweiten Falls wurden zwei identische Dateien, zwei komplett
unterschiedliche und zwei zufällige Dateien miteinenander verglichen. Jeder dieser
Dateien hatte die selbe Größe. Bei jedem Durchlauf wurde die selbe Laufzeit ge-
messen, woraus gefolgert werden kann, dass die Laufzeit des Algorithmus nicht vom
Grad der Übereinstimmung abhängt.
6.2.3 Ergebnisse
In Abbildung 6.1, 6.2 und 6.3 sind die Ergebnisse des in Abschnitt 6.2.1 beschriebe-
nen Tests dargestellt. Zunächst ist festzustellen, dass die Laufzeit in allen drei Fällen
linear ist. Dies deckt sich mit der in Abschnitt 5.2 geäußerten Feststellung, dass die
Methode quick ratio() einen linearen Aufwand hat, also sich in der Effizienzklasse
O(n) befindet (n bezeichnet die Anzahl der Eingegebenen Zeichen). Hieraus kann
gefolgert werden, dass das entwickelte Verfahren sehr gut mit der Länge er Eingabe
skaliert.
Beim Vergleich der Abbildung 6.2 mit den Abbildungen 6.1 und 6.3 kommt die Frage
auf, weshalb der Vergleich bei gleicher Laufzeit deutlich schneller abgeschlossen ist.
Dies liegt daran, dass die Methode quick ratio() in einer Schleife über den ersten
Parameter iteriert. Da im 2. Fall der erste Parameter immer eine feste Länge hat
und zudem noch deutlich kürzer ist, als der zweite Parameter, eine obere Schranke ist
also schneller gefunden. Bei einem genauen Test würde die Reihenfolge der Parameter
keine Rolle spielen. In einer zukünftigen Version wäre eine Optimierung denkbar, bei
der zuerst die Länge der beiden Webseiten betrachtet wird, und jeweils immer die
kleinere als ersten Parameter an quick ratio() übergeben wird.
Unter der Annahme, dass viele große Websites auf eine bestimmte Maximalgröße
optimiert muss allerdings davon ausgegangen werden, dass der 3. Fall der Fall ist,
der am häufigsten anzutreffende ist.
Zum Vergleich ist in Abbildung 6.4 das Zeitverhalten des Testes für den 3. Fall aufge-
zeigt, wenn anstelle von quick ratio() die Methode ratio() verwendet wird. Aufgrund
6.2. Laufzeitverhalten des Ähnlichkeitstests 49
Fall 1: B konstant, A waechst

10
'fall1.txt'
f(x)
6
Laufzeit in s
0
50 100 150 200 250 300
Gesamtgroesse in kB
Abbildung 6.1: 1. Fall
Fall 2: A konstant, B waechst

10
'fall2.txt'
f(x)
6
Laufzeit in s
0
50 100 150 200 250 300
Gesamtgroesse in kB
der hohen Laufzeitverhaltens wurde hier jedoch ein Startwert von 2 kB für die Größe
50 6. Evaluierung
Fall 3: A waechst, B waechst

10
'fall3.txt'
f(x)
6
Laufzeit in s
0
50 100 150 200 250 300
Gesamtgroesse in kB
Fall 3 mit ratio(): A waechst, B waechst

10
'fall4.txt'
f(x)
6
Laufzeit in s
0
0 10 20 30 40 50 60
Gesamtgroesse in kB
Abbildung 6.4: 3. Fall mit der Verwendung von ratio(). Sehr deutlich zu sehen ist
das quadratische Laufzeitverhalten.
6.3. Laufzeitverhalten unter realistischen Bedingungen 51
von A und B gewählt; die Erhöhung von Schritt zu Schritt betrug jeweils 1 kB pro
Auszug; die Ausführung wurde beim Überschreiten von 40 kB abgebrochen.
Sehr deutlich zu Erkennen ist die quadratische Laufzeit von ratio(). Vergleicht man
Abbildung 6.3 mit Abbildung 6.4, wird sehr schnell klar, weshalb die Verwendung
von quick ratio() eine deutliche Beschleunigung bedeutet.
6.3 Laufzeitverhalten unter realistischen Bedingun-

gen
In diesem Abschnitt soll das Laufzeitverhalten des Gesamtsystems bewertet werden.
Ziel hierbei ist es, das System unter realistischen Bedingungen zu testen. Interessant
ist hierbei vor allem das Zeitverhalten des Zugriffs über das Internet, der durch die
Verwendung von TLS/SSL verursachte Overhead sowie das Verhältnis zwischen der
für die Abrufe benötigte Zeit zur Laufzeit des eigentlichen Tests.
Grundsätzlich wird auf die in Abschnitt 6.1.1 beschriebene Art und Weise getestet.
Jedoch wurde das Modul CONTENTSimilarity dahingehend ergänzt, dass es an
bestimmten Stellen im Programmcode Zeitstempels setzt, um das Zeitverhalten der
einzelnen Operationen erfassen zu können.
Es werden hierbei – abhängig von der durchschnittlichen Seitengröße – folgende
Werte aufgezeichnet:
• Dauer der HTTP-Übertragung
• Dauer der HTTPS-Übertragung
• Verhältnis Dauer der HTTPS-Übertragung zur HTTP-Übertragung
• Dauer des Ähnlichkeitstests
• Verhältnis Dauer des Ähnlichkeitstest zur Gesamtzeit der Übertragung (HTTP

und HTTPS)
6.3.2 Probleme
Das größte Problem bei der Auswertung der Testergebnisse war das große Rauschen
innerhalb der Statistiken zur Dauer der Netzwerkübertragung, wie es in der Abbil-
dungen 6.5, sowie in den Abbildungen ?? bis ?? zu sehen ist.
Dies liegt vor allem daran, dass neben der Dateigröße unter anderem die Entfer-
nung zum Ziel und die Qualität der Netzanbindung des Ziels sowie die Auslastung
des Zielsystems eine Rolle spielen. Es gestaltet sich daher nicht immer einfach, die
richtigen Rückschlüße aus den Ergebnissen zu ziehen. Dieser Fehler relativiert sich
jedoch, sobald die übertragenen Daten eine gewisse Größe erreichen und der Transfer
daher hinreichend lange dauert.
Darüber hinaus ist der Vergleich der Ergebnisse aus Abschnitt 6.3.3 mit den aus
Abschnitt 6.2.3 mit Vorsicht zu genießen, da sich bei den Tests in Abschnitt 6.2.3
52 6. Evaluierung
die Größe einer Datei während mehreren Abrufen innerhalb eines Schleifendurchlaufs
nicht verändert haben. Bei den Ergebnissen in Abschnitt 6.3.3 ist dies hingegen
durchaus möglich, daher wurde bei der Auswertung jeweils die mittlere Dateigröße
verwendet.
6.3.3 Ergebnisse
In diesem Abschnitt werden die Ergebnisse des Gesamtleistungstest vorgestellt und
bewertet.
6.3.3.1 Gesamtleistung
TOTAL-Profile
60
'total_profile.txt'
f(x)
g(x)
50
40
Laufzeit in s
30
20
10
0
0 100 200 300 400 500
Durchschnittliche Seitengroesse HTTP + HTTPS in kB
Abbildung 6.5: Laufzeitverhalten des Gesamtsystems abhängig von der Größe der
Eingabe.
In Abbildung 6.5 ist das Laufzeitverhalten des Gesamtsystems zu sehen. Bei der
gesammtgröße handelt es sich um die mittlere Größe der Summe der über HTTP-
und HTTPS übertragenen Daten. Deutlich zu sehen ist das in 6.3.2 angesprochene
Rauschen, dass durch die Zeit der Übertragung über das Internet verursacht wird.
Bei genauerem hinesehen lassen sich die beiden Geraden f und g identifizieren,
die das Laufzeitverhalten annähern. Betrachtet man die Daten genauer lassen sich
sogar noch mehr Geraden identifizieren. Bei den Geraden handelt es sich um die
Laufzeitverhalten der einzelnen Prozessoren des Testsystems. Dieser Effekt wird im
folgenden Abschnitt genauer untersucht.
6.3.3.2 Dauer des Ähnlichkeitstests
In Abbildung 6.6 wird die Laufzeit des Ähnlichkeitsvergleiches abhängig von der
Größe der Eingabe dargestellt. Bei der auf der X-Achse aufgetragenen Gesamtgröße
handelt es sich um die selbe Größe wie im vorhergehenden Abschnitt.
6.3. Laufzeitverhalten unter realistischen Bedingungen 53
CPU-Profile
7
'cpu_profile.txt'
a(x)
b(x)
6 c(x)
d(x)
e(x)
5 f(x)
Laufzeit in s
0
0 100 200 300 400 500
Abbildung 6.6: Rechenzeit abhängig von der Größe der Eingabe.
Deutlich zu sehen ist, dass sich das Diagramm in 6 verschiedene Gerade aufteilen
lässt. Hierbei handelt es sich um die einzelnen Prozessorkernel des Systems, de-
ren Bearbeitungsgeschwindigkeit sich aufgrund von Cache-Lokalitäts-Effekten leicht
voneinander unterscheiden. Bei den Punkten auf der Geraden a handelt es sich um
die Laufzeit der Prozesse, die vom selben Prozessor-Kern bearbeitet wurden, auf dem
auch das Hauptprogramm gestartet wurde. Bei den Geraden b, c und d handelt es
sich um Prozesse, die im physikalischen Prozessor, jedoch auf ander Prozessorkernen
als der Hauptprozess ausgeführt wurden. Auf der Geraden e und f befindet sich die
Laufzeit der Prozesse, die von den vier Prozessor-Kernen bearbeitet wurden, die sich
nicht im selben Prozessor befanden wie der Prozessor-Kern, der den Hauptprozess
bearbeitet hat.
6.3.3.3 Dauer der Netzwerkübertragung
In Abbildung 6.7 ist die Dauer des HTTP-Abrufs abhängig von der Dateigröße dar-
gestellt. In Abbildung 6.7 ist der selbe Sachverhalt für HTTPS-Abrufe dargestellt.
In diesen Abbildungen ist wieder sehr deutlich das bereits angesprochene Rauschen
zu sehen.
In Abbildung 6.9 ist das Verhältnis der Dauer des Abrufs einer Datei über HTTPS-
zur Dauer des Abrufs über HTTP aufgetragen. Zu Erkennen ist, dass bei kleinen
Dateien der Abruf über HTTPS um ca. Faktor 5 länger dauert als der Abruf über
HTTP. Bei größeren Dateien Dateien relativiert sich dieser Effekt jedoch, ab einer
Größe von ca. 400 kB dauert der Abruf einer Datei über HTTP fast genau so lange
wie der Abruf über HTTPS. Die Ursache hierfür ist, dass bei HTTPS vor allem
der initiale Aufbau einer Verbindung ins Gewicht fällt. Bei größeren Datentransfers
54 6. Evaluierung
HTTP-Profile
60
'http_profile.txt'
f(x)
50
40
Laufzeit in s
30
20
10
0
0 100 200 300 400 500
Durchschnittliche Seitengroesse in kB
Abbildung 6.7: Übertragungszeit für HTTP-Verbindungen.
HTTPS-Profile
40
'https_profile.txt'
f(x)
35
30
25
Laufzeit in s
20
15
10
0
0 100 200 300 400 500
Durchschnittliche Seitengroesse in kB
Abbildung 6.8: Übertragungszeit für HTTPS-Verbindungen.
spielt – wie aus der Abbildung 6.9 zu entnehmen – die Dauer des Aufbaus einer
Verbindung kaum noch eine Rolle.
6.4. Zusammenfassung 55
HTTPSvsHTTP-Profile
40
'https2http_profile.txt'
f(x)
35
30
25
Laufzeit in s
20
15
10
0
0 100 200 300 400 500
Abbildung 6.9: Verhältnis der Übertragungszeit von HTTPS-Verbindungen zu

HTTP-Verbindungen.
6.3.3.4 Verhältnis der Dauer des Ähnlichkeitstest zur Dauer der Netz-
werkübertragung
In Abbildung 6.10 ist die Dauer des Ähnlichkeitstest im Verhältnis zur Dauer der
Netzwerkübertragung. Sehr deutlich zu sehen ist, dass sich dieses Verhältnis in den
meisten Fällen kleiner als 1 ist. Dies bedeutet, dass die Übertragung der Daten über
das Netzwerk fast immer länger dauert als der eigentliche Test auf Ähnlichkeit.
Zunächst überraschend ist, dass dieses Verhältnis sogar noch kleiner wird, je größer
die getestete Seite ist. Konkret bedeutet dies, dass die Übertragungszeit der Websei-
ten stärker zunimmt, als der Zeit, die benötigt wird, den Vergleich durchzuführen.
6.4 Zusammenfassung
In diesem Kapitel wurde zunächst untersucht, ab welchem Schwellwert zwei Websei-
ten als ähnlich anzusehen sind. Hierbei liessen sich mit einem Schwellwert von 95%
die besten Ergebnisse erzielen.
Daraufhin wurde die Laufzeit des Ähnlichkeitstests unter idealen Bedingungen un-
tersucht und es zeigte sich, dass das entwickelte System linear mit der Größe der
Eingabe skaliert.
Schliesslich fand ein Test unter realistischen Bedingungen statt. Dieser Test be-
stätigte das idealisierte Ergebnis, und es zeigte sich, dass das Gesamtsystem auch
unter realistischen Bedingungen linear skaliert. Darüber hinaus konnte gezeigt wer-
den, dass die Dauer der Datenübertragung stärker ins Gewicht fällt, als die Dauer
56 6. Evaluierung
CPUvsIO-Profile
4
'cpu2io_profile.txt'
f(x)
3.5
3
Rechenzeit / Uebertragungszeit
2.5
1.5
0.5
0
0 100 200 300 400 500 600
Gesamtgroesse in kB
Abbildung 6.10: Verhältnis zwischen Dauer der Übertragung und benötigten Zeit
zum Ähnlichkeitsvergleich.
des eigentlichen Ähnlichkeitstests. Hieraus kann geschlossen werden, dass sich das
entwickelte Verfahren für den praktischen Einsatz eignet.
7. Zusammenfassung und Ausblick
Bla fasel. . .
(Keine Untergliederung mehr!)
58 7. Zusammenfassung und Ausblick
Literatur
[Bake08] Loren Baker. Subdomains or Subfolders: Which are Bet-

ter for SEO?, Mai 2008. http://www.searchenginejournal.
com/subdomains-or-subfolders-which-are-better-for-seo/6849/, ab-
gerufen am 30. Mai 2008.
[Bank08] JPMorgan Chase Bank. How We Protect You - Online Securi-

ty, 2008. http://www.chase.com/ccp/index.jsp?pg name=ccpmapp/
privacy security/protection/page/online security, abgerufen am 30.
Mai 2008.
[BLFM05] T. Berners-Lee, R. Fielding und L. Masinter. Uniform Resource Iden-

tifier (URI): Generic Syntax. RFC 3986 (Standard), Januar 2005.
[Brad07] Mike Bradbury. Subdomains or Subfolders: The Age Old Search En-
gine Optimization Question., März 2007. http://www.objectwareinc.
com/subdomains-subfolders.aspx, abgerufen am 30. Mai 2008.
[BWNHM+ 03] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen und

T. Wright. Transport Layer Security (TLS) Extensions. RFC 3546
(Proposed Standard), Juni 2003. Obsoleted by RFC 4366.
[BWNHM+ 06] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen und

T. Wright. Transport Layer Security (TLS) Extensions. RFC 4366
(Proposed Standard), April 2006.
[CoDW06] Cristian Coarfa, Peter Druschel und Dan S. Wallach. Performan-

ce analysis of TLS Web servers. ACM Transactions on Computer
Systems, 24(1), 2006, S. 39–69.
[deVi06] David deVitry. Cross Site Scripting Vulnerabilities, Oktober 2006.

http://www.devitry.com/security.html, abgerufen am 30. Mai 2008.
[DiAl99] T. Dierks und C. Allen. The TLS Protocol Version 1.0. RFC 2246
(Proposed Standard), Januar 1999. Obsoleted by RFC 4346, updated
by RFC 3546.
[DiRe06] T. Dierks und E. Rescorla. The Transport Layer Security (TLS)

Protocol Version 1.1. RFC 4346 (Proposed Standard), April 2006.
Updated by RFCs 4366, 4680, 4681.
[Dude07] Dudenverlag. Duden – Deutsches Universalwörterbuch. 6. Auflage,

2007.
60 Literatur
[FHBHL+ 99] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,

A. Luotonen und L. Stewart. HTTP Authentication: Basic and Di-
gest Access Authentication. RFC 2617 (Draft Standard), Juni 1999.
[Foru] High Ranking Forum. How to redirect HTTPS to HTTP? http:

//www.highrankings.com/forum/index.php?showtopic=35833, ab-
gerufen am 30. Mai 2008.
[Foun] The Apache Software Foundation. SSL/TLS Strong Encryption:

FAQ. http://httpd.apache.org/docs/2.0/ssl/ssl faq.html#vhosts,
abgerufen am 30. Mai 2008.
[FrKK96] Alan O. Freier, Philip Karlton und Paul C. Kocher. The SSL Pro-
tocol Version 3.0. Memo, November 1996. http://wp.netscape.com/
eng/ssl3/draft302.txt.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides.
Design Patterns, Band 1. Addison-Wesley. ISBN-978-0-201-63361-0,
1995.
[Grou08] The PHP Group. PHP: Integers, Mai 2008. http://www.php.net/

manual/en/language.types.integer.php, abgerufen am 30. Mai 2008.
[Hatc08] Brian Hatch. Stunnel.org. Website, 2008. http://www.stunnel.org/,

abgerufen am 30. Mai 2008.
[He02] Xubin He. A Performance Analysis of Secure HTTP Protocol. Tech-

nischer Bericht, Department of Electrical and Computer Enginee-
ring, Tennessee Technological University, 2002. http://iweb.tntech.
edu/hexb/publications/https-STAR-03122003.pdf.
[Hick95] Kipp E.B. Hickman. The SSL Protocol. Memo, Februar 1995. http:
//wp.netscape.com/eng/security/SSL 2.html.
[IANA08] Internet Assigned Numbers Authority IANA. Port Numbers. Web-

page, Juni 2008. http://www.iana.org/assignments/port-numbers.
[Lawr05] Eric Lawrence. TLS and SSL in the Real World, April 2005. http://
blogs.msdn.com/ie/archive/2005/04/20/410240.aspx, abgerufen am
30. Mai 2008.
[MBLB+ 02] Anne de Micheli, Sylvie Brunessaux, Shreekanth Lakshemshwar, An-

toon Bosselaers und David Parkinson. CYBERVOTE. Website, Ja-
nuar 2002.
[Mill05] Rich Miller. Banks Shifting Logins to Non-SSL Pages, Au-

gust 2005. http://news.netcraft.com/archives/2005/08/23/banks
shifting logins to nonssl pages.html, abgerufen am 30. Mai 2008.
[Prob] Problem Websites. http://problemwebsites.com/, abgerufen am 30.

Mai 2008.
Literatur 61
[Pyth08] Python.org. Thread State and the Global Interpreter Lock, Mai
2008. http://docs.python.org/api/threads.html, abgerufen am 30.
Mai 2008.
[RaMe88] John W. Ratcliff und David E. Metzener. Pattern Matching: The

Gestalt Approach. Dr. Dobb’s Journal, 13(7), Juli 1988. http://
www.ddj.com/184407970?pgno=5.
[Resc00] E. Rescorla. HTTP Over TLS. RFC 2818 (Informational), Mai 2000.
[Secr08] IETF Secretariat. Transport Layer Security Charter. Website, Mai

2008. http://www.ietf.org/html.charters/tls-charter.html, abgerufen
am 30. Mai 2008.
[Shin04] Debra Littlejohn Shinder, Juni 2004. http://www.windowsecurity.

com/articles/SSL-Acceleration-Offloading-Security-Implications.
html, abgerufen am 30. Mai 2008.
[Veri] Verisign. https://securitycenter.verisign.com/contents VRSN US/

HTML/pop validityPeriod.htm, abgerufen am 30. Mai 2008.
[Visw01] Vivek Viswanathan. Load Balancing Web Applications, Septem-

ber 2001. http://www.onjava.com/pub/a/onjava/2001/09/26/load.
html, abgerufen am 30. Mai 2008.
62 Literatur

Studienarbeit Marcel Noe

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Studienarbeit Marcel Noe

Hochgeladen von

Copyright:

Verfügbare Formate

Entwurf und Implementierung

eines Systems zur proaktiven

Studienarbeit am Institut für Telematik

Tag der Anmeldung: 1. März 2008

Institut für Telematik

4.1.2 Mögliche Ergebnisse eines Tests . . . . . . . . . . . . . . . . . 26

7 Zusammenfassung und Ausblick 57

1.1 Zielsetzung der Arbeit

1.2 Gliederung der Arbeit

Die Leistungsfähigkeit des Entwurfs und der Implementierung wird in Kapitel 6

2.3 Domain Name System

An zweiter Stelle stehen die sogenannten Second-Level-Domains.

winter.invalid anzulegen. Informationen zu den Alpen würden sich so unter http:

• Eine HTTPS-Verbindung auf dem HTTPS-Standard-Port (443)1 erfolgreich

3.2 Einsatz von HTTPS

3.3 Aufwand von HTTPS

Diese Kategorien werden im folgenden genauer untersucht.

3.3.1 Organisatorischer Aufwand von HTTPS

3.3.2 Technischer Aufwand von HTTPS

3.3.3 Rechenaufwand von HTTPS

eines solchen Beschleunigers etwa eine Verdoppelung des Durchsatzes an HTTPS-

3.4 Gefühlte Sicherheit

3.5 Einschränkung von HTTPS auf Teile von Web-

3.6 Problem der Erkennung der Ähnlichkeit von

3.6.1 Einfacher Stringvergleich

3.6.2 Auswertung des Common-Names im Zertifikat

3.6.3 Verwendung eines Mustererkennungs-Algorithmus

3.6.3.1 Der Gestalt-Ansatz

3.6.3.2 Der Ratcliff/Obershelp-Algorithmus

Der Algorithmus von Ratcliff/Obershelp wird in [RaMe88] lediglich als Assembler

12 while ( e l e m e n t s = s t a c k . pop ( ) ) { // Ein Array vom S t a c k h o l e n

26 // Die S u b s t r i n g s von a und b , d i e

31 // Die S u b s t r i n g s von a und b ,

45 // Das s e l b e machen wir nun f u e r d i e

60 // Stack , a u f dem wir d i e zu v e r g l e i c h e n d e n

68 // Nun b e r e c h n e n wir d i e Anzahl der

3.6.3.3 Umsetzung in dieser Studienarbeit

1. Abrufen von 3 Versionen von Webseite A, Speicherung in A1 bis A3 .

2. Abrufen von 3 Versionen von Webseite B, Speicherung in B1 bis B3 .

3. Bestimmen der durchschnittlichen Ähnlichkeit der Versionen von A zueinan-

Ab einem gewissen Schwellenwert7 von diff(A, B) werden zwei verglichene Websites

4.1 Entwurf der Software-Komponenten

Abbildung 4.1: NSC Klassendiagramm

• Test-Module, die die Tests auf unterstützte Sicherheitsprotokolle implementie-

• Contentr-Module, die dazu dienen, Inhalte von Übertragungen zu analysieren.

4.1.2 Mögliche Ergebnisse eines Tests

• Connected : Eine Verbindung zu dem Port war möglich, es wurde allerdings

4.1.3 Entwurf eines Moduls: Test auf Verfügbarkeit einer Web-

Bei compare(a, b) handelt es sich um eine Einschubmethode (Template-Method), in

4.2 Entwurf der Sicherheitsdatenbank

Die Sicherheitsdatenbank dient hier vor allem dazu, den Verbindungsaufbau im

Abbildung 4.2: Datenbank-Diagramm

Abbildung 4.3: Die Keywords Relation

Abbildung 4.4: Die Domains Relation

Die Relation Domains stellt im NSC-Datenbankdesign die zentrale Entität, sozu-

Abbildung 4.5: Die Ipaddresses Relation

Abbildung 4.6: Die Protocols Relation

Abbildung 4.7: Die Results Relation

Abbildung 4.8: Die Tests Relation

4.3 Befüllen der Sicherheitsdatenbank

4.3.1 Proaktiver Betrieb

4.3.6 Test-Resultate eintragen

• NSC Framework: Framework zur Implementierung von Test- und Content-

Das NSC Framework wurde in der Programmiersprache Python entwickelt. Py-