7. Juni 2009
Eigentlich Offtopic und nur weil sich die Geschichte des größten Diamantenraubs in Antwerpen bei Wired wirklich spannend liest:
The Untold Story of the World’s Biggest Diamond Heist
Und wenn man zwischen den Zeilen liest, findet man vielleicht auch die eine oder andere Idee für einen Penetrationstest mit Physical Security Komponente.
(via Security4all)
Wenn ich mal etwas Zeit habe, finde ich es recht spannend, uralte RFCs durchzublättern um zu sehen, wie sich die Netzwerkprotokolle entwickelt haben und welche Gedanken man sich ursprünglich zu verschiedenen Diensten gemacht hat. Ich möchte daraus eine sehr unregelmäßige Reihe machen, in der ich für mich RFCs festhalten kann, die mir aus verschiedenen Gründen aufgefallen sind.
Das ist aus heutiger Sicht ein recht lustiger RFC. Praktisch jeder ist der Meinung, ein Byte besteht natürlich aus 8 Bit. Ich glaube mich daran erinnern zu können, dass einer meiner Azubis so etwas sogar in der Fachinformatiker-Prüfung hatte. 1971 war das noch etwas anders: „Crocker implies in RFC 123 that control of this parameter is given to the 3rd level programs and that both sender and receiver may specify values of the byte size to the NCP.“ Auf Deutsch: Die beteiligten Kommunikationsendpunkte legen die Größe ihres Bytes fest. Und dann folgt ein nettes Beispiel mit Bytes von 3 und 5 Bit. Kann sich heute keiner mehr vorstellen, so etwas. Erklärt aber, warum die ISO-Einheit „Oktett“ und nicht „Byte“ ist.
Klar, HTTP ist Port 80, SSH ist Port 22, POP3 ist Port 110 usw. Aber wie fing das mit den Portnummern eigentlich an? „I would like to collect information on the use of socket numbers for „standard“ service programs. For example Loggers (telnet servers) Listen on socket 1. Recently Dick Watson suggested assigning socket 5 for use by a mail-box protocol (RFC196).“ Sehr schön. Daraus hat sich erst diese und dann diese Liste entwickelt. Warum ist eigentlich Telnet von 1 auf 23 gewandert?
Auch so ein Schmankerl. Vor allem wegen der Vorstellung, dass Nachrichten auf Papier direkt digital abgebildet werden sollen: „It is the sender’s responsibility to control the length of the print line and page. If more than 72 characters per line are sent, or if more than 66 lines are sent without a form feed, then the receiving site can handle these situations as appropriate for them.“ Eine Seite besteht also aus 66 Zeilen mit je 72 Anschlägen. Und genau so müssen digitale Mails auch aufgebaut werden. Könnte direkt von den Internetausdruckern kommen, dieser RFC.
Das waren noch Zeiten, als die UCLA einen Rechner ungestraft „SEX“ nennen konnte. Das hat sich dann aber auch innerhalb einer Woche geändert!
Auch nicht unspannend, wie früh und konkret sich das Militär immer wieder in die Entwicklung eingemischt hat. Datenübertragung zwischen zwei Computern mittels Satellit konnte sich 1972 sonst niemand leisten.
Da hat sich doch tatsächlich jemand Gedanken über erweiterte Zeichensätze gemacht. Man muss sich das mal vorstellen, 96 Character in ASCII war damals schon innovativ, viele haben noch mit 64 Zeichen (ohne Kleinbuchstaben) gearbeitet. „Anyone can register a new character. Each character has a unique number, 17 bits should be enough even to include Chinese. Finally, the character has a design which is a picture on a 50 by 50 dot matrix.“ 17 Bit … sowas.
An der Qualität der Handbücher und Dokumentation hat sich seither auch nichts geändert. Meiner Mutter bräuchte ich mit dieser Doku FTP jedenfalls nicht erklären.
FTP ist sowieso eines der Protokolle die mich mit dem ursprünglich geplanten aber oft nur teilweise implementierten Funktionsumfang immer wieder überraschen. Beispielsweise die Übertragung von einem FTP-Server direkt zu einem anderen FTP-Server mit einer Kombination aus Active und Passive FTP. Ich kenne kaum einen FTP-Client der das kann, inzwischen verbieten das aber auch die meisten FTP-Server wegen Bounce und ähnlichen Angriffen. Gibt es eigentlich irgendeinen FTP-Server oder Client, der den HASP-Mode implementiert?
Irgendwann mehr …
