HTTP - Hypertext Transfer Protcol Wird verwendet seit 1990 1996 erste öffentliche Spezifikation durch RFC 1945 HTTP/1.0, frühere Version unter HTTP/0.9 bekannt. Standardisiert in Version HTTP/1.1 durch RFCs 2068 und 2616 Einfaches und schnelles Protokoll Kommunikation zwischen Benutzeragenten (meist Browser), Proxies, Gateways und Servern Anfrage-Antwort-Schema Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-1 HTTP-Anfragen GET Anfrage nach einer Datei Erwarte diese geschickt zu bekommen Angabe der Protokollversion get /dateien/123.html HTTP/1.0 HEAD wie get, jedoch ohne Dateitransfer POST Daten senden PUT (HTTP/1.1) DELETE (HTTP/1.1) Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-2 1
HTTP/1.0-Antworten 200 OK 201 Created 202 Accepted 204 No Content 301 Moved Permanently 302 Moved Temporarily 304 Not Modified 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 500 Internal server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-3 HTTP-Nachrichtenköpfe Der Kopf einer Anfrage darf folgende Felder enthalten: Authorization - Übergabe eines Passworts o.ä. From - Angabe der E-mailadresse des anfragenden Benutzers If-Modified-Since - Macht get conditional Referer - Angabe, woher der Link kam User- - Angabe von Produkt und Versionsnummer Der Kopf einer Antwort darf folgende Felder enthalten: Location - eine URL Server - Angabe von Produkt und Versionsnummer WWW-Authenticate - Aufforderung zur Authorisierung Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-4 2
HTTP-Datenübertragung Felder des Kopfes eines Datenblocks Allow - Liste der erlaubten Anfragen Content-Encoding - Art der Kodierung des Datenblocks, z.b. x-gzip Content-Length - Länge des Datenblocks in Byte Content-Type - z.b. text/html Expires Last-Modified Je nach Art der Nachricht können Felder erforderlich, optional oder nicht vorgesehen sein. Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-5 HTTP-Authentisierung Nur Authentisierung des Client vorgesehen Prozedur: Server schickt auf eine Anfrage die Antwort 401 (Unauthorized). Die Antwort enthält ein WWW-Authenticate-Feld mit einer challenge. Client sendet mit der erneuten Anfrage ein Authorization-Feld, das eine gültige Antwort die challenge enthält. Art der challenge ist nicht durch HTTP festgelegt. Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-6 3
HTTP-Sicherheitsprobleme Persönliche Daten auf Web-Servern Mißbrauch von Server Log-Dateien Refer-, From- und User--Feld Vertraulichkeit bei der Datenübertragung Klartextübertragung Passwörter in URI (URL) Dateisicherheit auf Server Pfadnamen außerhalb des Serverbereichs abblocken! Große Abhängigkeit von DNS-Dienst Falsche Proxies und Caches Trennung unterschiedlicher logischer Server auf einem Physischen ist oft kritisch bei der Implementierung des Servers Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-7 SSL fuer HTTP S-HTTP: Secure HTTP HTTP-Erweiterung für Vertraulichkeit durch Verschlüsselung (symmetrisch und unsymmetr.) (Server-) Authentisierung Digitalen Signatur Kapselung von HTTP in S-HTTP Zusätzliche Felder für Schlüsselaustausch oder Schlüsselindizierung Integrität einer Nachricht und Authentisierung des Senders durch Message Authentication Code (MAC) Auch HTTP-Anfragen und Felder der Köpfe werden verschlüsselt Verhandlung der Kommunikationspartner über das Verschlüsselungsverfahren Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-8 4
E-mail Zusammen mit WWW meist genutzter Internet-Dienst 1997: 270 Milliarden E-mails E-mail-en Benutzer- Transport- Filter- Speicher- SMTP - Simple Mail Transfer Protocol (RFC 821) Adressierung und Versand Formatierung der E-mail (RFC 822) E-mail-Listen Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-9 Aufbau des E-mail-Systems Benutzer- Sender und empfängt E-mail nach Benutzer-Interaktion Transport- Ist zuständig für die Zustellung von E-mail Speicher- Speichert E-mails bis sie vom Empfänger entgegengenommen und gelöscht werden Filter- Verhindert Weiterleitung unerwünschter E-mail Ändert Adressierung Sendet automatische Antworten Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-10 5
Aufbau des E-mail-Systems Benutzer- Filter- Transport- Filter- SMTP SMTP Filter-? Benutzer- SMTP Transport- Filter- POP, IMAP Speicher- Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-11 SMTP Simple Mail Transfer Protocol Definiert durch RFC 821 Kommunikation zwischen einem Client, der eine E-mail zustellen möchte und einem Server, der dies tun soll. Wichtige SMTP Kommandos: HELO Identifizierung des Clients MAIL FROM: Identifizierung des Senders der E-mail RCPT TO: Einer oder mehrere Empfänger der E-mail VRFY und EPND Zustellbarkeit einer Adresse prüfen DATA Beginn der Übertragung der eigentlichen E-mail QUIT Beenden der Verbindung Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-12 6
Einige SMTP-Antworten 220 <domain> Service ready 221 <domain> Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> 354 Start mail input; end with <CRLF>.<CRLF> 500 Syntax error, command unrecognized [This may include errors such as command line too long] 502 Command not implemented 503 Bad sequence of commands 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 571 (RFC 1893) Error when trying to forward a message [E.g. relaying is not allowed] Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-13 SMTP-Sitzung, Beispiel 1 telnet example.com 25 220 mail.example.de ESMTP Sendmail 8.10.1/8.10.1; Mon, 26 Jun 2000 08:10:00 +0200 (CEST) HELO test 250 mail.example.de Hello test [1.1.1.1], pleased to meet you VRFY kunz 250 kunz User kunz@example.de QUIT 221 mail.example.de closing connection VRFY kunz 550 kunz... User unknown VRFY kunz 252 Cannot VRFY user; try RCPT to attempt delivery Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-14 7
SMTP-Sitzung, Beispiel 2 telnet example.de 25 220 mail.example.de ESMTP Sendmail 8.10.1/8.10.1; Mon, 26 Jun 2000 08:11:00 +0200 (CEST) HELO test 250 mail.example.de Hello test [1.1.1.1], pleased to meet you MAIL FROM: <hinz@hinzkunz.de> 250 hinz@hinzkunz.de...sender ok RCPT TO: <kunz> 250 kunz@example.de...recipient ok DATA 354 Enter mail, end with "." on a line by itself From: hinz@hinzkunz.de To: kunz Subject: Hallo Hallo Kunz, bis bald.. 250 e5pl2kr19462 Message accepted for delivery QUIT 221 mail.example.com closing connection Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-15 SMTP-Sitzung, Beispiel 3 telnet example.de 25 220 mail.example.de ESMTP Sendmail 8.10.1/8.10.1; Mon, 26 Jun 2000 08:12:00 +0200 (CEST) HELO test 250 mail.example.de Hello test [1.1.1.1], pleased to meet you MAIL FROM: <hinz@hinzkunz.de> 250 hinz@hinzkunz.de...sender ok RCPT TO: <sonstwer@sonstwo.de> 250 sonstwer@sonstwo.de...relaying denied QUIT 221 mail.example.com closing connection Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-16 8
Formatierung der E-mail (RFC 822) Einige Felder des E-mail-Kopfes: To E-mail Adressen und Optional Namen der Empfänger Cc Durchschriftenempfänger Bcc Durchschriftenempfänger, unsichtbar für andere Empfänger From Autor Sender Absender Subject Betreff Date Lokales Datum und lokale Uhrzeit Received Transportvermerk, eine Zeile je Transport- Reply-To Antwortadresse Message-Id global eindeutige Identifikation dieser einzelnen E-mail Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-17 Beispiel einer E-mail Return-Path: <ich@hier.de> Received: from tokyo.ccrle.nec.de (root@tokyo1.berlin.ccrle.nec.de [192.168.100.30]) by kyoto.berlin.ccrle.nec.de (8.9.3/8.9.3) with ESMTP id WAA05037 for <quittek@kyoto.berlin.ccrle.nec.de>; Sun, 25 Jun 2000 22:59:33 +0200 From: ich@hier.de Received: from test (yamato1.berlin.ccrle.nec.de [192.168.100.29]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with SMTP id e5pl2kr19462 for <quittek>; Sun, 25 Jun 2000 23:03:19 +0200 (CEST) Date: Sun, 25 Jun 2000 23:03:19 +0200 (CEST) Message-Id: <200006252103.e5PL2kR19462@tokyo.ccrle.nec.de> To: quittek@ccrle.nec.de Subject: Tach Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-18 9
Standardformat des Received-Feldes Received: from H1 (H2 [A.B.C.D]) by H3 (V1/V2) with SMTP id MID; for <ADR>; DATE mit H1 H2 H3 V1 V2 SMTP MID ADR DATE Identifikation, die mit dem HELO-Kommando gesendet wurde Name, der der Internet-Adresse A.B.C.D des Clienten entspricht Rechner, der diesen Eintrag vorgenommen hat Versionsnummer des Transport-en Versionsnummer der Konfiguration des Transport-en Benutztes Protokoll zum Transport der E-mail lokale eindeutige Identifikation der E-mail Adresse, die mit dem RCPT TO-Kommando angegeben wurde lokales Datum und Uhrzeit des Empfangs der E-mail Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-19 Transport- Sendmail Von Eric Allman, UC Berkeley, seit 1980 90% aller Transport-en sind Sendmail oder Sendmail- Varianten von Dritten. Ständige Aktualisierung und Stopfen von Sicherheitslücken Aktuelle Version: 8.10.0, 8.10.1, 8.10.2 je nach Betriebssystem Alternativen: qmail, exim, Post.Office, pmdf, smail Konfiguration sendmail.cf /etc/aliases $HOME/.forward Vorlesung Rechnernetze Institut für Informatik Freie Universität Berlin 1-20 10