Anwendungsschicht





E-Mail Emoticons – Gefühle in E-Mails

Veröffentlicht am von
Kommentar

Die Kommunikation via E-Mail – ähnlich jeder Form der schriftlichen Kommunikation – ist alleine auf den Kommunikationskanal der Schrift festgelegt, d.h. der persönlichen Kommunikation fehlen zusätzliche Informationskanäle, wie z.B. Gestik und Mimik des Gegenübers, Intonation und Betonung des gesprochenen Wortes. Um diese zusätzlichen Informationen schriftlich zu fixieren, bedarf es entweder beschreibender oder erklärender Worte, bzw. man entwirft eine zusätzliche Kodierung, um die Intention einer sprachlichen Äußerung klar zu machen. Letzteren Weg nahm auch die Kommunikationsform der E-Mail, da in dieser elektronischen Form der Kommunikation ebenso wie bei SMS oder neuerdings auch Twitter möglichst viel Information auf möglichst wenig Raum untergebracht werden muss.

Daher haben sich sogenannte Emoticons etabliert, mit denen der Autor einer elektronischen (Kurz-)Nachricht über seine Stimmungslage bzw. über die Intention der getroffenen Aussage zusätzliche Informationen angegeben kann. Bereits 1964 erfand der Werbegrafiker Harvey Ball (1921–2001) das Original-Smiley, als er für die Versicherungsgesellschaft State Mutual Life Assurance Cos. of America einen Ansteckbutton zur Motivation der Mitarbeiter entwerfen sollte. Dazu zeichnete er einfach einen Kreis, malte ihn gelb aus, setzte zwei Punkte und darunter einen Halbkreis hinein: fertig war der ”Smiley“ (UTF-8 Zeichen: ☺) .

Das elektronische Gegenstück zum Smiley wurde erstmals am 19. September 1982 von Scott E. Fahlman (*1948) vorgeschlagen und kann mit Hilfe des regulären ASCII-Zeichensatze unabhängig von einer Unterstützung durch Grafikzeichensätzen geschrieben werden. Dabei steht :-) für positive Gefühle und Witz und :-( gegenteilig für negative Gefühle. Die Zeichenfolgen deuten dabei ein nach links gekipptes Gesicht an, das fröhlich bzw. traurig dreinschaut. Schnell entwickelten sich zahlreiche Varianten mit unterschiedlichster Bedeutung, mit deren Hilfe ein Autor elektronischer Texte seine Stimmungslage bzw. seine persönliche Intention mit einfachsten Mitteln (ASCII-Zeichen) ausdrücken kann.



Was ist Pretty Good Privacy (PGP)?

Veröffentlicht am von
Kommentar

Von Phil Zimmerman 1991 entwickeltes System zur sicheren Abwicklung des E-Mail-Nachrichtenverkehr. PGP ist frei verfügbar für die meisten Hardwareplattformen und Betriebssysteme und bietet E-Mail-Nachrichten-Verschlüsselung mit symmetrischen Schlüsselverfahren (Triple-DES, IDEA, CST), Sicherung des symmetrischen Schlüssels über ein asymmetrisches Verschlüsselungsverfahren (RSA-Kryptosystem), sowie Sicherung der Integrität von E-Mail-Nachrichten (MD5 Message Digest) und Wahrung der Authentizität der Kommunikationspartner (digitale Signaturen). PGP ist das am weitesten verbreitete System zum sicheren Umgang mit E-Mail-Nachrichten.



Anwendungsschicht und Internetanwendungen – Grundbegriffe

Veröffentlicht am von
Kommentar

Nachdem bisher alle notwendige Grundlagen der Kommunikation im Internet behandelt wurden, richten wir jetzt unsere Aufmerksamkeit auf die Anwendungsschicht des TCP/IP-Referenzmodells. In den Schichten unterhalb der Anwendungsschicht werden alle Aufgaben des Datentransfers gelöst und ein zuverlässiger Transportdienst zur Verfügung gestellt. Der Anwender allerdings nimmt das überhaupt nicht wahr, da ihm die Schnittstellen, mit denen er in Berührung kommt, bereits voll funktionstüchtige Anwendungen bieten, wie z.B. Datei-Transfer, E-Mail versenden und empfangen oder HTML-Seiten abrufen. Die Kommunikationsprotokol-le und Verbindungen eines Netzwerks sind zwar für die Kommunikation im Internet lebensnotwendig, doch die direkt nutzbare Funktionalität wird erst durch mitunter sehr anspruchsvolle Anwendungssoftware bereitgestellt, die auf diesen Diensten aufsetzt und sie für ihre Zwecke nutzt.

Vergleicht man das Internet mit einem Telefonnetz, so liefern die Kommunikationsprotokolle zwar die zur Kommunikation notwendige Infrastruktur, es braucht aber noch die Teilnehmer, die über das Telefonnetz kommunizieren, und die vielfältigen Dienstangebote, wie Fax u.a., um das Telefonnetz zu einem nützlichen und begehrten Telefondienstleistungsanbieter zu machen. Ebenso wie beim Telefondienst die Teilnehmer, setzt die Kommunikation im Internet Anwendungsprogramme voraus, die über das Internet kommunizieren wollen. Zu diesem Zweck kontaktiert eine Anwendung auf dem einem Computer eine Anwendung auf einem entfernten Rechner, um mit dieser die für ihre Zwecke notwendigen Daten auszutauschen. Auch die nicht zum TCP/IP-Referenzmodell zählenden Anwendungen und Anwendungen, die direkt vom Nutzer bedient werden, greifen auf die Transport-Dienste des TCP/IP-Referenzmodells mit eigenen Protokollen zu, die geeignete, abstrakte Schnittstellen benötigen, die ebenfalls in der Anwendungsschicht des TCP/IP-Protokollstapels bereitgestellt werden. Die Anwendungsschicht ermöglicht damit eine Anwendung-zu-Anwendung-Kommunikation, während die darunterliegende Transportschicht lediglich eine Host-zu-Host-Verbindung bietet. Aus der Sicht der Betriebssysteme der jeweiligen Endsysteme betrachtet, spricht man anstelle von Anwendungen auch von Prozessen, die miteinander kommunizieren und Informationen austauschen. Die Anwendungsschicht installiert damit eine netzwerkübergreifende Prozess-zu-Prozess-Kommunikation. Ein sendender Prozess erzeugt und sendet Nachrichten über das Internet zu einem empfangenden Prozess. Der empfangende Prozess nimmt die ihm übermittelte Nachricht entgegen und sendet eventuell seinerseits eine Antwort an den Sender zurück.



Sicheres DNS – Domain Name System Security Extensions – Teil 2

Veröffentlicht am von
Kommentar

Eine weitere Angriffsvariante ist der sogenannte Zonendiebstahl (Zone Stealing), bei dem der Angreifer einen nicht autorisierten Zonentransfer initiiert, bei dem die gesamte DNS Zonendatenbank übertragen wird. Die daraus gewonnenen Informationen werden im Anschluss für Angriffe auf den DNS-Cache anfragender DNS-Clients verwendet.

Ein Angreifer kann weiter versuchen, eine dynamische Aktualisierung an einen Nameserver zu senden, mit der üblicherweise Änderungen in der DNS Zonen Datenbank von einem primären an sekundäre Nameserver weitergegeben werden. Wird dabei nicht die Authentizität des Absenders überprüft, kann ein Angreifer damit beliebige Eintragungen in der Datenbank des angegriffenen DNS-Servers vornehmen. Alle DNS-Clients, die daraufhin diesen DNS-Server kontaktieren, erhalten bei einer Anfrage zur Namensauflösung ggf. eine verfälschte IP-Adresse zurück, mit der dann nicht das angefragte Ziel, sondern ein unter der Kontrolle des Angreifers stehender Rechner kontaktiert wird.

Gelingt es einem Angreifer, sich in die Kommunikation zwischen DNS-Client und DNS-Server zu schalten, kann er alle versendeten Nachrichten zwischen diesen beiden Systemen lesen und manipulieren. Diese Variante des Man-in-the-Middle Angriffs wird auch als DNS Hijacking bezeichnet.

Auch DoS Angriffe auf beliebige Rechner lassen sich via DNS einfach bewerkstelligen. Im DNS Protokoll sind die Nachrichten der DNS-Antwort üblicherweise wesentlich länger als die zugehörigen Anfragen. Dies kann ein Angreifer ausnutzen und unter Vorgabe der Absenderadresse des angegriffenen Systems DNS-Anfragen an viele verschiedene DNS-Server stellen. Diese senden ihre (lange) Antwort zurück an die vermeintliche Ursprungsadresse und können damit eine temporäreÜberlast erzeugen. Diese Angriffsvariante wird auch als DNS Amplification bezeichnet.

Um die Sicherheit des Domain Name Systems besser zu gewährleisten und um Angriffe wie die erwähnten zu vermeiden, können die folgenden Technologien, auf die wir in späteren Posts noch eingehen werden, eingesetzt werden:

  • Transaction Signature (TSIG)
  • Domain Name System Security Extensions (DNSSEC)


Sicheres DNS – Domain Name System Security Extensions – Teil 1

Veröffentlicht am von
Kommentar

Wie auch andere Teilsysteme des Internets ist auch das Domain Name System auf Grund seiner weiten Verbreitung zahlreichen Angriffen und Manipulationsversuchen ausgesetzt. Da DNS-Informationen öffentlich sind, liegt das Hauptziel der Angriffe nicht im Bruch der Vertraulichkeit von Informationen, sondern vielmehr in einer gezielten Verletzung der Integrität der via DNS übermittelten Informationen und der Verfügbarkeit.

Die einfachste Variante eines Angriffs auf das DNS besteht in einer Manipulation der Antwort des Nameservers, die dieser auf eine Anfrage hin zurückgibt, d.h. die Zuordnung zwischen Domain-Namen und IP-Adressen wird dabei vorsätzlich verfälscht (DNS Spoofing). Dazu kann der Angreifer einfach in die Rolle des Nameservers schlüpfen und an Stelle des eigentlichen DNS-Servers auf Anfragen des DNS-Clients antwortet. Dies kann bewerkstelligt werden, indem der Angreifer den eigentlichen Nameserver durch eine sogenannte Denial of Service Attacke (DoS) lahmlegt, die dessen Arbeitsaufkommen derart überlastet, dass der Angreifer dem anfragenden Client eine DNS-Antwort liefern kann, bevor der eigentlichen Nameserver dazu wieder in der Lage ist. Auf diese Weise werden falsche bzw. fehlerhafte Einträge im DNS-Cache des anfragenden Clients erzeugt und der Angreifer kann den geplanten Datenverkehr auf eine andere IP-Adresse umlenken, ohne dass der Client dies bemerkt. Das Erkennen derartiger Manipulationen im DNS-Cache ist besonders schwierig, da durch die Praxis der dynamischen Vergabe von IP-Adressen diese heute häufig wechseln.

Die Erzeugung fehlerhafter Einträge im DNS-Cache eines Clients wird als Cache Poisoning bezeichnet. Stellt bei der rekursiven Namensauflösung ein DNS-Server selbst weitere DNS-Anfragen an Nameserver aus anderen DNS-Zonen, zeigt das Cache Poisoning noch schwerwiegendere Folgen, da alle weiteren Anfragen dieses DNS-Servers ebenfalls zuerst aus dessen Cache beantwortet werden und so falsche Zuordnungen weitergegeben werden.

Um einen Angriff via DNS Spoofing zu starten, muss der Angreifer berücksichtigen, dass eine von ihm gefälschte DNS-Antwort von einem DNS-Client nur dann akzeptiert wird, wenn (a) die (zufällig bestimmte) ID der Anfrage und der darauf gesendeten Antwort übereinstimmen, und (b) die Antwort an die korrekte IP-Adresse und Portnummer der Anfrage gerichtet ist.

Ein Angreifer könnte folgendermaßen vorgehen:

  1. Um den verwendeten Quellport des angegriffenen Nameservers zu ermitteln, sendet der Angreifer eine DNS-Anfrage an diesen, in der er eine DNS-Anfrage an seinen eigenen DNS-Server provoziert. Da die meisten Nameserver einen festen Quellport für DNS-Anfragen verwenden, kann davon ausgegangen werden, dass der ermittelte Quellport auch zukünftig genutzt wird.
  2. Jetzt wird eine große Anzahl von DNS-Anfragen mit identischem Inhalt und verschiedenen Absenderadressen erzeugt und an den anzugreifenden Nameservergesendet. Dies kann mit Hilfe von IP-Spoofing, also dem Versenden von IP-Datenpaketen mit falschen IP-Adressen, bzw. mit Hilfe eines sogenannten Bot-Netzwerks erfolgen. Anfragen mit unterschiedlichen IP-Adressen werden trotz identischem Inhalt meist als eigenständige Anfrage behandelt, die eine eigene ID zugewiesen bekommen. Damit wird die Wahrscheinlichkeit erhöht, später die korrekte ID zu erraten.
  3. Der angegriffene Nameserver muss, um die Anfragen beantworten zu können, selbst entsprechende Anfragen an den autoritativen Nameserver senden und wartet auf dessen Antworten.
  4. Jetzt sendet der Angreifer eine große Zahl von DNS-Antworten an den angegriffenen Nameserver zurück, wobei er als Absenderadresse die IP-Adresse des autoritativen Nameservers vortäuscht und den in (1) ermittelten Zielport adressiert. Jede DNS-Antwort wird mit einer unterschiedlichen ID versehen, um zufällig eine gültige Antwort zu erzeugen. Gelingt es dem Angreifer vor dem autoritativen DNS-Server eine gültige DNS-Antwort an den angegriffenen Nameserver zu senden, kann er gefälschte Daten in dessen DNS-Cache einschleusen.

Im zweiten Teil dieses Postes gehen wir auf weitere Angriffsvarianten wie Zone Stealing und DNS Hijacking ein.



Base64 Kodierung

Veröffentlicht am von
Kommentar

Allgemein beschreibt die Base64 Kodierung ein Verfahren zur Kodierung von 8 Bit Binärdaten in eine Zeichenfolge, die nur aus lesbaren ASCII-Zeichen (A–Z, a–z, 0–9, +/=) besteht. Es kommt insbesondere zur Kodierung bei multimedialen E-Mail Inhalten im MIME-Standard zur Anwendung, da für das E-Mail Nachrichtenformat die Verwendung des 7 Bit US-ASCII Codes vorgeschrieben ist. Zur Kodierung werden jeweils drei Bytes des Bytestroms (entspricht 24 Bits) in vier 6 Bits lange Blöcke aufgeteilt. Jeder dieser 6 Bits langen Codeblöcke entspricht einer Zahl zwischen 0 und 63.

Ist die Gesamtzahl der Eingabebytes nicht durch drei teilbar, wird der zu kodierende Text am Ende mit aus Nullbits bestehenden Füllbytes aufgefüllt, so dass sich eine durch drei teilbare Anzahl von Bytes ergibt. Bei einem n Bytes langen binären Bytestrom berechnet sich der Platzbedarf für den Base64-kodierten Inhalt in z Bytes als



Eine kurze Geschichte der E-Mail

Veröffentlicht am von
Kommentar

Bevor Nachrichten mit Hilfe von digitalen Rechnernetzwerken übertragen wurden, konnten diese als Brief oder Telegramm bzw. später auch als Fernschreiben oder Fax übermittelt werden. Allerdings wurde die Übermittlung von einfachen Textnachrichten von den Entwicklern des ARPANETs in den 1960er Jahren eher als nebensächlich betrachtet. So betonte Larry Roberts, der spätere Direktor des ARPA Information Processing Techniques Office (IPTO), dass ein Nachrichtenaustauschsystem (Message Handling System) ein möglicher Anwendungszweck für ein verteiltes Rechnernetzwerk wäre, doch würde dieser Zweck allein den Aufbau des ARPANETs nicht rechtfertigen.

Eine der am Aufbau des ARPANETs beteiligten Firmen war BBN (Bolt, Beraneck, and Newman). Der BBN Ingenieur Ray Tomlinson beschäftigte sich dort Ende der 1960er Jahre mit dem Programm SNDMSG, das für die Übermittlung von Nachrichten zwischen den Benutzern eines Großrechners sorgte und dem CPYNET Protokoll zum Dateitransfer zwischen Rechnern im Netzwerk. Über das SNDMSG Programm konnte ein Benutzer eines Computers einem anderen Benutzer Text in dessen Mailbox hinzufügen. Eine Mailbox war dabei nichts anderes als eine einzelne Datei, die nur ein Benutzer – der Besitzer der Mailbox – lesen konnte.

benutzername@rechnername

Erste Ideen zur Verteilung von Dokumenten über sogenannte Mailinglisten wurden bereits in sehr frühen RFCs dokumentiert, so z.B. RFC 95 und RFC 155. Auch ein erstes rudimentäres Mailbox-Protokoll wurde bereits 1971 in RFC 196 ” A Mail Box Protocol“ spezifiziert. Ebenfalls 1971 kam Tomlinson auf die Idee, CPYNET und SNDMSG zu verbinden, um so Nachrichten an Benutzer auf anderen Rechnern im Netzwerk zu versenden. Dabei kam er auch auf die Idee, den Namen des Benutzers und des jeweiligen Rechners im Netzwerk durch ein ” @“-Zeichen zu verbinden.

In Deutschland wurde die erste Internet E-Mail am 3. August 1984 um 10:14 MEZ von Michael Rotert (* 1950) an der Universität Karlsruhe empfangen. Zu Beginn der 1980er Jahre wurden in zahlreichen Netzwerkumgebungen Systeme zur Nachrichtenübertragung entwickelt, wie z.B. Mailbox-Systeme, X.25, Novell oder BTX. Allerdings wurden diese durch die zunehmende Verbreitung des Internets und des Internet E-Mail Dienstes bis Mitte der 1990er Jahre zusehends verdrängt. Die E-Mail entwickelte sich schnell zum populärsten Dienst im Internet. Im Jahr 2010 wurden täglich 294 Milliarden E-Mails von mittlerweile annähernd 1,88 Milliarden E-Mail Benutzern versendet, wobei der Anteil an unerwünschter SPAM E-Mail erschreckenderweise bei fast 90% lag.



Domain Name System (DNS)

Veröffentlicht am von
Kommentar

Während menschliche Benutzer und die meisten Anwendungsprogramme zur Adressierung entfernter Rechner im Internet symbolische Namen benutzen, verwendet die Netzwerk-Software aus Gründen der Effizienz und der Eindeutigkeit ausschliesslich die 32 Bits bzw. 128 Bits lange binäre IP-Adresse.

In der Anfangszeit des Internet, zur Zeit des ARPANET, wurde die Zuordnung zwischen symbolischen Rechnernamen und ihren binären Adressen mittels einer zentral gelagerte Datei host.txt organisiert, die fortlaufend zu aktualisieren war. Jeweils Nachts forderten dann alle Rechner des ARPANET diese Datei an, um ihre eigenen Adresszuordnungslisten zu aktualisieren. Ein derartiges Vorgehen war allerdings nur solange praktikabel, als das betreffende Netzwerk nur einige hundert Rechner umfasste. Mit dem explosionsartigen Wachstum des Internets wurde schnell klar, dass eine zentrale Verwaltung einer Namens-Adresszuordnung im großen Maßstab nicht mehr sinnvoll war, schon einfach aus dem Grund, weil die zu verwaltenden Zuordnungstabellen schnell viel zu groß und das massenhafte Update zu viel Bandbreite kostete und zu aufwändig wurde (siehe Abbildung).

Nutzung eines Internetdienstes über einen Namensdienst

Darüber hinaus barg dieser flach organisierte Namensraum noch zusätzlich das Problem, dass doppelt vergebene symbolische Namen erkannt und bereinigt werden mussten, was einen erheblichen Administrationsaufwand verursachte.

Zur Lösung dieses Problems wurde von Paul Mockapetris (* 1948) das sogenannte Domain Name System (DNS) entwickelt, das 1983 in den RFCs 882 und 883 spezifiziert und als Internetstandard publiziert wurde. 1987 wurde diese Spezifikation durch die RFCs 1034 und 1035 abgelöst. DNS arbeitet als verteilte Datenbankanwendung und dient dazu, symbolischen Namen binäre IP-Adressen zuzuordnen. Um die verteilte Anwendung sinnvoll zu organisieren, wurde der zur Verfügung stehende Adressraum hierarchisch strukturiert und verschiedenen Abschnitten jeweils eigene DNS-Server zugeordnet, die für die Zuordnung (Mapping) im betreffenden
Adressraumabschnitt verantwortlich sind.



Client-/Server-Interaktionsmodell

Veröffentlicht am von
Kommentar

Betrachten wir zunächst die Hauptakteure im Internet, also die Anwendungen, die über das Internet miteinander kommunizieren. Deren Kommunikation läuft in der Regel nach folgendem Schema ab: Die Anwendung, die den Kommunikationswunsch hegt (Client), stellt eine Anfrage an eine korrespondierende Anwendung auf einem entfernten Rechner (Server) , in der sie ihren Kommunikationswunsch (Request) formuliert. Der Server antwortet daraufhin mit der gewünschten Information oder stellt den gewünschten Dienst bereit (Reply).

Diese Form der Kommunikationsbeziehung wird als Client/Server Paradigma bezeichnet. Die Protokolle der Anwendungsschicht müssen diese beiden unterschiedlichen Seiten einer Kommunikationsbeziehung gleichermaßen bedienen. Dabei steht der Client für die aktive Komponente, die die Kommunikationsbeziehung initiiert, und der Server für die passive Komponente, die darauf wartet, dass ein Client eine Anforderung stellt (siehe Bild). Der Informationsfluss kann dabei in beide Richtungen, vom Client zum Server oder vom Server zum Client, fließen. Betrachten wir das WWW, so stellt der Web-Browser des Benutzers die Clientseite der Kommunikationsbeziehung dar. Der Web-Browser sendet eine Anfrage nach einer bestimmten Informationsressource an einen Web-Server, der die Serverseite der Kommunikationsbeziehung bildet. Das HTTP Protokoll muss also auf der Seite des Web-Browsers Client-Funktionalität und auf der Seite des Web-Servers Serverfunktionalität zur Verfügung stellen.

Client Server Interaktionsmodell

Damit ein Client bestimmte Server-Dienste ansprechen kann, müssen diese adressierbar sein. Die Protokolle der Transportschicht stellen zu diesem Zweck Schnittstellen zur Verfügung, die sogenannten Ports. Jedem Anwendungsprogramm, das über das Internet kommunizieren kann, ist ein bestimmter Port zugeordnet, der durch eine eindeutige Portnummer identifiziert wird (siehe Abschnitt 8.1.3). Diese Portnummer wird dem Anwendungsprogramm von der Netzwerk-Transportsoftware zugeteilt. Client-Anfragen werden dann von der Netzwerk-Software über die so spezifizierte Portnummer zum jeweiligen Server weitergeleitet. Dazu fügt der Client seiner Anfrage die den angeforderten Server-Dienst spezifizierende Portnummer hinzu, so dass die Netzwerk-Software auf Server-Seite die Anfrage an den betreffenden Server weiterleiten kann.

Je nach den Anforderungen des adressierten Dienstes können Client/Server-Dienste auf einen verbindungsorientierten oder einen verbindungslosen Transportdienst zurückgreifen. Der verbindungsorientierte Transportdienst wird dabei üblicherweise von TCP bedient, während der verbindungslose Transport über UDP abgewickelt wird.

Client/Server-Interaktionen im Internet sind allerdings nicht auf eine reine 1:1-Kommunikationsbeziehung beschränkt, sondern können auch komplexere Kommunikationsbeziehungen abbilden. So kann ein Client gleichzeitig verschiedene Server kontaktieren (1:n-Beziehung), denselben Dienst von unterschiedlichen Rechnern, oder unterschiedliche Dienste (und diese mitunter vom selben Rechner) anfordern oder transitive, hierarchische Kommunikationsbeziehungen ausbilden. Auch der vom Client kontaktierte Server selbst kann als Client eines weiteren Servers aktiv werden, um die gewünschte Anfrage des originalen Clients bedienen zu können.