4. Welche Informationen stehen auf dem Etikett des IP-
Pakets?
Wofür wird das Local Area Network (LAN) verwendet?
Welche Aufgabe hat der Router?
Was ist ein Proxy? Welche Aufgabe hat ein Proxy?
Welche Aufgabe hat eine Firewall?
Für welche Art von Paketen sind (im Film) die Eingänge 25
und 80 reserviert?
Fragen zum Kurzfilm
8. Ethernet, u.a.:
ISO/OSI Modell:
Schicht 1 (Physik. Schicht)
und
Schicht 2 (Sicherungsschicht)
TCP/IP:
IPv4: 134.95.115.23
IPv6: Hex.-Not., 8 Blöcke, je 16 Bit
9. Ethernet, u.a.:
ISO/OSI Modell:
Schicht 1 (Physik. Schicht)
und
Schicht 2 (Sicherungsschicht)
TCP/IP:
IPv4: 134.95.115.23
IPv6: Hex.-Not., 8 Blöcke, je 16 Bit
TCP: Transmission Control Protocol,
Verbindungsorientiertes Protokoll
10. HTTP: Client / Server Modell
Quelle: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/
Client Server
12. HTTP: Uniform Resource Locator (URL)
Quelle: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/
Drei Standards:
HTTP
HTML
URLs
13. HTTP: Uniform Resource Locator (URL)
IP-Adresse herausfinden?
Quelle: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/
Drei Standards:
HTTP
HTML
URLs
14.
15.
16.
17.
18.
19.
20. HTTP Request-Methoden
GET – Ressourcen vom Server anfordern; die
URL enthält alle benötigten Informationen, um
die Ressourcen zu lokalisieren und an den
Client zu senden.
POST – Daten zur Verarbeitung an den
Server senden.
PUT – Ressource wird erstellt bzw. geändert,
sofern sie bereits existiert.
DELETE – Ressource löschen
HEAD – Server veranlassen,
Kopfinformationen der Nachricht erneut zu
senden.
21. HTTP Request-Methoden
GET – Ressourcen vom Server anfordern; die
URL enthält alle benötigten Informationen, um
die Ressourcen zu lokalisieren und an den
Client zu senden.
POST – Daten zur Verarbeitung an den
Server senden.
PUT – Hochladen einer Ressource
DELETE – Ressource löschen
HEAD – Server veranlassen,
Kopfinformationen der Nachricht erneut zu
senden.
Status Codes
1xx – Informationen
2xx – Erfolgreiche Operation
204: Antwort enthält keinen
Nachrichteninhalt / -körper
3xx – Umleitung
301: Moved Permanently: Ressource wurde
verschoben und findet sich nun unter neuem
URL.
304: Nicht verändert: Ressource hat sich
nicht verändert; Client soll Version der
Ressource verwenden, die sich in seinem
Cache befindet.
4xx – Clientfehler
5xx – Serverfehler
503: Service Unavailable
22. Beispiel: Formulareingabe im Browser
GET
Informationen sind Teil der URL; Übergabe von Paaren aus
Argument und Wert
Beispiel Google Suche:
http://www.google.de/#hl=de&source=hp&q=hello+world&aq=f
&aqi=g10&aql=&oq=&gs_rfai=&fp=8889134438f330ab
POST
Informationen (Argument-/Wert Paare) werden unverschlüsselt(!)
im Hintergrund (in den HTTP Kopfdaten) übertragen
HTTP: Argumentübergabe
24. Packet Sniffing mit Wireshark
(http://www.wireshark.org/)
HTTP Login auf hki.uni-koeln.de mit Benutzername
„hellobit“ und Passwort „bitpassword“
HTTP Sicherheit: Wireshark
29. „Der unsichtbare Super-GAU im Netz [...]
Angriff auf den heiligen Gral der Verschlüsselung“
(Zeit Online, 08.04.2014)
„Die Sicherheitslücke „Heartbleed“ ist ein
Totalschaden im Internet und zeigt, dass es neue
Sicherheitsstandards für das Netz braucht.“
(FAZ Online, 13.04.2014)
31. Heartbleed
Programmfehler in älteren OpenSSL-Versionen
2012: Erweiterung von OpenSSL um Heartbeat-Verfahren
„Heartbeat“: Versand von 16 KB beliebiger Daten, um
Serververbindung zu prüfen
Knackpunkt: Keine Überprüfung, ob angegebene Menge mit
tatsächlicher Länge der transformierten Heartbeat-Daten übereinstimmt
Wenn angegebene Menge > tatsächliche Länge: Server füllt das max.
64 KB große Loch mitunter mit sensiblen Daten (Schlüssel,
Benutzerinformationen, Kennwörter)
OpenSSL
Freie TLS-Software (Transport Layer
Security, früher Secure Sockets Layer),
freie Alternative: GnuTLS
ISO/OSI: Sitzungsschicht (Schicht 5)
TCP/IP: zwischen Transport- und
Anwendungsschicht
35. Absenden / Weiterleiten von Emails:
SMTP Simple Mail Transfer
Protocol
Abholen von Emails
Email: Protokolle & Co.
36. POP3 / SMTP / IMAP: ggf. ungesichert / unverschlüsselt
„Wenn die Regierungen in früheren Zeiten die Privatsphäre
der Bürger verletzen wollten, mußten sie einen gewissen
Aufwand betreiben, um die Briefpost abzufangen, unter
Dampf zu öffnen und zu lesen oder Telefongespräche
abzuhören und womöglich zu protokollieren. […]
Heute ersetzt die Elektronische Post allmählich die
herkömmliche Briefpost […]. Im Gegensatz zur Briefpost sind
E-Mails unglaublich leicht abzufangen und auf interessante
Stichwörter hin elektronisch zu prüfen. Das läßt sich ohne
weiteres, routinemäßig, automatisch und nicht nachweisbar in
großem Maßstab bewerkstelligen.“
(Phil Zimmermann, zitiert nach Singh, Simon: Geheime Botschaften. Die Kunst der Verschlüsselung von der
Antike bis in die Zeiten des Internet. Deutscher Taschenbuch Verlag. München. 2000. S. 357.)
Email: Sicherheit
37. Vgl. golem.de: http://www.golem.de/news/ueberwachung-millionfache-e-mail-
filterung-der-geheimdienste-ohne-richter-1202-90072.html (27.02.2012):
„Laut einem Bericht des Parlamentarischen Kontrollgremiums
(PKG) haben die Geheimdienste Verfassungsschutz,
Bundesnachrichtendienst und Militärischer Abschirmdienst
(MAD) im Jahr 2010 die Inhalte von Millionen E-Mails
durchsucht und dabei in über 37 Millionen elektronischen
Nachrichten verdächtige Suchbegriffe gefunden. Die
Versechsfachung gegenüber dem Vorjahr sei der Zunahme
von Spam geschuldet, hieß es zur Begründung. Gesucht
wurde nach rund 15.300 Begriffen aus den Bereichen
Terrorismus, Massenvernichtungswaffen und Schleusung. In
nur 213 Fällen ergaben sich durch die millionfache E-Mail-
Überwachung verwertbare Hinweise für die Geheimdienste.“
Email: Sicherheit
Transmission Control Protocol
Fiber Distributed Data Interface (Glasfaser, Lichtwellen-Metro-Ring)
Grundlage von Token Bus ist das Token, das im Netzwerk von einer Station zur benachbarten Station weitergeleitet wird. Die benachbarte Station wird bei Token Bus (im Gegensatz zu Token Ring) anhand einer Adresse bestimmt. Dazu erhöht die sendende Station ihre Knoten-ID um den Wert 1, um den Nachbar zu adressieren.
Der Name Bus ergibt sich dadurch, dass das Token über das gesamte Netz gesendet und von allen Stationen empfangen wird. Nur die Station mit der nächsthöheren Knoten-ID darf das Token entgegennehmen. Wird das ankommende Token nicht benötigt, wird ein neues Token mit der Nachbaradresse erstellt und weitergeschickt.
Transmission Control Protocol
Fiber Distributed Data Interface (Glasfaser, Lichtwellen-Metro-Ring)
Grundlage von Token Bus ist das Token, das im Netzwerk von einer Station zur benachbarten Station weitergeleitet wird. Die benachbarte Station wird bei Token Bus (im Gegensatz zu Token Ring) anhand einer Adresse bestimmt. Dazu erhöht die sendende Station ihre Knoten-ID um den Wert 1, um den Nachbar zu adressieren.
Der Name Bus ergibt sich dadurch, dass das Token über das gesamte Netz gesendet und von allen Stationen empfangen wird. Nur die Station mit der nächsthöheren Knoten-ID darf das Token entgegennehmen. Wird das ankommende Token nicht benötigt, wird ein neues Token mit der Nachbaradresse erstellt und weitergeschickt.
Transmission Control Protocol
Fiber Distributed Data Interface (Glasfaser, Lichtwellen-Metro-Ring)
Grundlage von Token Bus ist das Token, das im Netzwerk von einer Station zur benachbarten Station weitergeleitet wird. Die benachbarte Station wird bei Token Bus (im Gegensatz zu Token Ring) anhand einer Adresse bestimmt. Dazu erhöht die sendende Station ihre Knoten-ID um den Wert 1, um den Nachbar zu adressieren.
Der Name Bus ergibt sich dadurch, dass das Token über das gesamte Netz gesendet und von allen Stationen empfangen wird. Nur die Station mit der nächsthöheren Knoten-ID darf das Token entgegennehmen. Wird das ankommende Token nicht benötigt, wird ein neues Token mit der Nachbaradresse erstellt und weitergeschickt.
Transmission Control Protocol
Fiber Distributed Data Interface (Glasfaser, Lichtwellen-Metro-Ring)
Grundlage von Token Bus ist das Token, das im Netzwerk von einer Station zur benachbarten Station weitergeleitet wird. Die benachbarte Station wird bei Token Bus (im Gegensatz zu Token Ring) anhand einer Adresse bestimmt. Dazu erhöht die sendende Station ihre Knoten-ID um den Wert 1, um den Nachbar zu adressieren.
Der Name Bus ergibt sich dadurch, dass das Token über das gesamte Netz gesendet und von allen Stationen empfangen wird. Nur die Station mit der nächsthöheren Knoten-ID darf das Token entgegennehmen. Wird das ankommende Token nicht benötigt, wird ein neues Token mit der Nachbaradresse erstellt und weitergeschickt.
Tim Berners Lee
CERN
URI
URN einheitlicher Name für Ressourcen, Resource Identifier mit dem Schema URN: Dauerhafter, ortsunabhängiger Bezeichner für eine Ressource
Anders gesagt werden URNs dazu benutzt, Ressourcen eindeutige und dauerhaft gültige Namen zu geben, um sie somit eindeutig identifizieren zu können
Eine Ressource kann dabei alles sein, was sich irgendwie eindeutig beschreiben lässt – also auch sehr abstrakte oder nicht greifbare Dinge (wie beispielsweise eine Weltanschauung, ein Konzept oder eine gemessene Strahlung), aber auch konkrete Dinge wie beispielsweise ein bestimmtes Buch.
URL: URLs waren ursprünglich die einzige Art von URIs, weshalb der Begriff URL oft gleichbedeutend mit URI verwendet wird.
Nachrichten herumgeschickt und ausgetauscht
Header, Briefkopf
Der Client baut eine Verbindung zum Server auf. Der Server authentisiert sich gegenüber dem Client mit einem Zertifikat. Der Client überprüft hierbei die Vertrauenswürdigkeit des X.509-Zertifikats und ob der Servername mit dem Zertifikat übereinstimmt. Optional kann sich der Client mit einem eigenen Zertifikat auch gegenüber dem Server authentisieren. Dann schickt entweder der Client dem Server eine mit dem öffentlichen Schlüssel des Servers verschlüsselte geheime Zufallszahl, oder die beiden Parteien berechnen mit dem Diffie-Hellman-Schlüsselaustausch ein gemeinsames Geheimnis. Aus dem Geheimnis wird dann ein kryptographischer Schlüssel abgeleitet. Dieser Schlüssel wird in der Folge benutzt, um alle Nachrichten der Verbindung mit einem symmetrischen Verschlüsselungsverfahren zu verschlüsseln und zum Schutz von Nachrichten-Integrität und Authentizität durch einen Message Authentication Code abzusichern.
Heartbleed Bug
Ein Heartbeat (engl. für „Herzschlag”) ist eine Netzwerkverbindung zwischen zwei (oder mehr) Rechnern in einem Cluster, um sich gegenseitig darüber zu benachrichtigen, dass sie betriebsbereit sind und ihre Aufgaben noch erfüllen können, also „am Leben” sind.
Wenn die Benachrichtigungen eines anderen Rechners ausbleiben, geht ein Programm auf dem „überlebenden” Rechner davon aus, dass dieser Partner-Pendant nicht mehr verfügbar ist (z. B. durch einen Defekt oder einen Programmfehler) und dass es dafür sorgen soll, dass diese Aufgaben von einem noch funktionierenden Rechner übernommen werden.
Ist die angegebene Länge größer als die tatsächliche Länge, so kopiert die OpenSSL-Implementierung über das Ende des Eingabepuffers hinaus Daten aus dem Heap in den Ausgabepuffer. Aufgrund der fehlenden Überprüfung kann ein Angreifer mit einer Anfrage bis zu 64 kByte[2] des Arbeitsspeichers der Gegenstelle auslesen.
Programmfehler in älteren OpenSSL-Versionen
2012: Erweiterung von OpenSSL um Heartbeat-Verfahren
„Heartbeat“: Versand von 16 KB beliebiger Daten, um Serververbindung zu prüfen
Knackpunkt: Keine Überprüfung, ob angegebene Menge mit tatsächlicher Länge der transformierten Heartbeat-Daten übereinstimmt
Wenn angegebene Menge > tatsächliche Länge: Server füllt das max. 64 KB große Loch mitunter mit sensiblen Daten (Schlüssel, Benutzerinformationen, Kennwörter)
Public-Key-Verfahren mit Schlüsselpaaren:
Öffentlicher Schlüssel: Verschlüsselung von Daten für den Empfänger
Privater Schlüssel: Besitzt Empfänger, kennwortgeschützt
Asymmetrische Verschlüsselung:
Knackpunkt nach Siegert: Die Geschichte der Email (2008): „Zu keinem Zeitpunkt während des Kommunikationsaufbaus […] zwischen sendendem und empfangendem Server wird die Echtheit des Absenders überprüft“
Knackpunkt nach Siegert: Die Geschichte der Email (2008): „Zu keinem Zeitpunkt während des Kommunikationsaufbaus […] zwischen sendendem und empfangendem Server wird die Echtheit des Absenders überprüft“