Basisinformationstechnologie II – Sommersemester 2016 – 09. Mai 2016
Dr. Jan G. Wieners
Rechnerkommunikation II
Protokolle, Anwendungen
 „Warriors of the Net“
 HTTP
 HTTPS
 Anwendungsschicht
 Email
 SMTP
 POP3
 IMAP
Themenüberblick „Rechnerkommunikation II“
Warriors of the Net
 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
 HTTP
 HTTPS
 Anwendungsschicht
 Email
 SMTP
 POP3
 IMAP
Themenüberblick II
Ethernet, u.a.:
 ISO/OSI Modell:
 Schicht 1 (Physik. Schicht)
und
 Schicht 2 (Sicherungsschicht)
 TCP/IP:
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
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
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
HTTP: Uniform Resource Locator (URL)
Quelle: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/
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
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
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.
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
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
HTTP und die Sicherheit…
Packet Sniffing mit Wireshark
(http://www.wireshark.org/)
HTTP Login auf hki.uni-koeln.de mit Benutzername
„hellobit“ und Passwort „bitpassword“
HTTP Sicherheit: Wireshark
 https://www.ksk-koeln.de
HTTPS FTW!
„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)
http://visual.ly/major-sites-affected-heartbleed
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
http://grahamcluley.com/2014/04/heartbleed-bug-leak-yahoo-password
Anwendungsschicht: Email
…Protokolle?
Absenden / Weiterleiten von Emails:
SMTP  Simple Mail Transfer
Protocol
Abholen von Emails
Email: Protokolle & Co.
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
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
Pretty Good Privacy (PGP), Anwendungsschicht
-----BEGIN PGP MESSAGE----- […]
qANQR1DBwEwD4PSJmhZ2mJoBB/oDkeTMBP+qTZCbrH0x+ltec/FpCwYLrojTKR4O
he1qjeJshaR5j6B0tpYeLGiRf/4OfkKNNDCmRjkT9ofRCgv5GO9sz6WOeZiMWhjU
hT1LF8K84xLvCeXPIwdFNThF3vFktuMTy1fDfl/nFDSjXsigD/3mmbHmN0S9bbUE
XfEaceWPSiHqIZME9Mr57LeySCag2LVBtAVFN4+aMRH9q/YDB4KKXlUcmIR4z64K
WU4fFpdQ7Bp30JCi4L/1R3d9AQgnhdgnv253yYJ1qS+XcVxCcXVEHaChcfUcoNWs
4puujwCdTrcFIEuF9iJeszVxWKFFNOkq9GbQ6w//F/a0tVs2wcBMA24E5h1oRymC
AQf8CzQOAQcJspYpeiD1eibRptJTEFiELgylFmO7lEwGhpUQgfmP9EYBnbuYYMF1
Hr3rWEcZBqVqk6C0XEo04H/I4QXr47wRQEYiiSEo088J6eY2PUySOAnv/ITqC0zq
zv2u+/qGrwiexgqYkLbzh0Yz4LxPZJPUcmoEE/eySfuVUldupxqbBAGZaMLzDNxW
IyETP4zK4NjAzy4NbDmU7A3hF0cBY4BZwapd+o1sbxuZ7PVgAqi1gNF3favGb/u0
KwzevoKFxf1nyePnQwTkQYvG49Eb2vEa0DEVnvpZZvUUPFigqD2X1052pqDrafZ0
eZAqFPCvGVSb8Tgg6wOtZxtgDcHATANGok9/6C2khQEIAJ5CHLfef8DR+e+3mjxL
OkcL+JzD6O3JMIK6iylaLrc/sKsZUUC0JTbvm6KdQU4IheTQkS0t0IEvYO652NL+
PMHmQ4qmyX/natFyUlZOlTGJzhLP/n659Uq4zZg9dmDHNZZPvH/ShvPDBJLacKTO
s5fHxswh9EDjlp+zlfUm8M1C7dGMoKhyciqtl4rK7Ag5/YyRR+kZFA3RFwIFRjyM […]
-----END PGP MESSAGE-----
Vorschläge zur Verhinderung
oder Verminderung von SPAM?
/
 https://commons.wikimedia.org/wiki/File:Universitat_
zu_Koln_Hauptgebaude_ost.jpg
 http://causeitsallaboutthepayno.tumblr.com/post/131
746453874/im-currently-listening-to-adeles-new
 www.giphy.com
 http://www.elandroidelibre.com/wp-
content/uploads/2015/11/spam.jpg
 http://www.golem.de/news/pgp-im-parlament-
warum-mein-abgeordneter-keine-pgp-mail-oeffnen-
kann-1604-120506.html
 https://ec.europa.eu/commission/2014-
2019/oettinger_en
Bildnachweise

Bit sosem 2016-wieners-sitzung-07_rechnerkommunikation-ii

  • 1.
    Basisinformationstechnologie II –Sommersemester 2016 – 09. Mai 2016 Dr. Jan G. Wieners Rechnerkommunikation II Protokolle, Anwendungen
  • 2.
     „Warriors ofthe Net“  HTTP  HTTPS  Anwendungsschicht  Email  SMTP  POP3  IMAP Themenüberblick „Rechnerkommunikation II“
  • 3.
  • 4.
     Welche Informationenstehen 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
  • 5.
     HTTP  HTTPS Anwendungsschicht  Email  SMTP  POP3  IMAP Themenüberblick II
  • 7.
    Ethernet, u.a.:  ISO/OSIModell:  Schicht 1 (Physik. Schicht) und  Schicht 2 (Sicherungsschicht)  TCP/IP:
  • 8.
    Ethernet, u.a.:  ISO/OSIModell:  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/OSIModell:  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
  • 11.
    HTTP: Uniform ResourceLocator (URL) Quelle: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/
  • 12.
    HTTP: Uniform ResourceLocator (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 ResourceLocator (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
  • 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 imBrowser  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
  • 23.
    HTTP und dieSicherheit…
  • 24.
    Packet Sniffing mitWireshark (http://www.wireshark.org/) HTTP Login auf hki.uni-koeln.de mit Benutzername „hellobit“ und Passwort „bitpassword“ HTTP Sicherheit: Wireshark
  • 27.
  • 29.
    „Der unsichtbare Super-GAUim 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)
  • 30.
  • 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
  • 32.
  • 33.
  • 34.
  • 35.
    Absenden / Weiterleitenvon 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
  • 38.
    Pretty Good Privacy(PGP), Anwendungsschicht -----BEGIN PGP MESSAGE----- […] qANQR1DBwEwD4PSJmhZ2mJoBB/oDkeTMBP+qTZCbrH0x+ltec/FpCwYLrojTKR4O he1qjeJshaR5j6B0tpYeLGiRf/4OfkKNNDCmRjkT9ofRCgv5GO9sz6WOeZiMWhjU hT1LF8K84xLvCeXPIwdFNThF3vFktuMTy1fDfl/nFDSjXsigD/3mmbHmN0S9bbUE XfEaceWPSiHqIZME9Mr57LeySCag2LVBtAVFN4+aMRH9q/YDB4KKXlUcmIR4z64K WU4fFpdQ7Bp30JCi4L/1R3d9AQgnhdgnv253yYJ1qS+XcVxCcXVEHaChcfUcoNWs 4puujwCdTrcFIEuF9iJeszVxWKFFNOkq9GbQ6w//F/a0tVs2wcBMA24E5h1oRymC AQf8CzQOAQcJspYpeiD1eibRptJTEFiELgylFmO7lEwGhpUQgfmP9EYBnbuYYMF1 Hr3rWEcZBqVqk6C0XEo04H/I4QXr47wRQEYiiSEo088J6eY2PUySOAnv/ITqC0zq zv2u+/qGrwiexgqYkLbzh0Yz4LxPZJPUcmoEE/eySfuVUldupxqbBAGZaMLzDNxW IyETP4zK4NjAzy4NbDmU7A3hF0cBY4BZwapd+o1sbxuZ7PVgAqi1gNF3favGb/u0 KwzevoKFxf1nyePnQwTkQYvG49Eb2vEa0DEVnvpZZvUUPFigqD2X1052pqDrafZ0 eZAqFPCvGVSb8Tgg6wOtZxtgDcHATANGok9/6C2khQEIAJ5CHLfef8DR+e+3mjxL OkcL+JzD6O3JMIK6iylaLrc/sKsZUUC0JTbvm6KdQU4IheTQkS0t0IEvYO652NL+ PMHmQ4qmyX/natFyUlZOlTGJzhLP/n659Uq4zZg9dmDHNZZPvH/ShvPDBJLacKTO s5fHxswh9EDjlp+zlfUm8M1C7dGMoKhyciqtl4rK7Ag5/YyRR+kZFA3RFwIFRjyM […] -----END PGP MESSAGE-----
  • 42.
    Vorschläge zur Verhinderung oderVerminderung von SPAM?
  • 43.
  • 44.
     https://commons.wikimedia.org/wiki/File:Universitat_ zu_Koln_Hauptgebaude_ost.jpg  http://causeitsallaboutthepayno.tumblr.com/post/131 746453874/im-currently-listening-to-adeles-new www.giphy.com  http://www.elandroidelibre.com/wp- content/uploads/2015/11/spam.jpg  http://www.golem.de/news/pgp-im-parlament- warum-mein-abgeordneter-keine-pgp-mail-oeffnen- kann-1604-120506.html  https://ec.europa.eu/commission/2014- 2019/oettinger_en Bildnachweise

Hinweis der Redaktion

  • #8 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.
  • #9 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.
  • #10 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.
  • #11 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.
  • #14 Tim Berners Lee CERN
  • #17 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.
  • #20 Nachrichten herumgeschickt und ausgetauscht
  • #21 Header, Briefkopf
  • #29 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.
  • #30 Heartbleed Bug
  • #33 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.
  • #34 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)
  • #40 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:
  • #43 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“
  • #44 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“