RackBlogger

Unsere Telefonanbindung im Büro ist durch einen Leitungsschaden beim Netzbetreiber derzeit ausgefallen.

Nur gut, dass unsere Notfallnummer parallel über SIP zugeführt wird Die Internetverbindung läuft über einen anderen Anbieter (und andere Leitungen).

[Update 11:38] Nun funktioniert’s wieder.

Ende nächster Woche darf ich auf dem IPv6-Kongress in Frankfurt ein Tutorial zum Thema “IPv6 mit der C-Standardbibliothek” halten. Bis dahin wird es hier im Blog wohl recht ruhig bleiben, da ich noch einige Folien und Beispiele vorbereite.

Ich werde dann vom Kongress berichten, und (wenn möglich) die Folien veröffentlichen.

Nach dem Artikel über die DENIC-Passwort-Verschlüsselung erhielt ich eben von einem Blogleser einen Hinweis auf bestehende XSS-Lücken auf unserer Website.

Die Fehler wurden selbstverständlich umgehend behoben. Die betroffenen Scripte stammten aus einer Zeit, zu welcher der Begriff “XSS” noch völlig unbekannt war. Aber das ist eigentlich auch keine akzeptable Ausrede. Dafür ein Anlass, die ganzen alten Scripte mal wieder zu prüfen…

Die Telekom bietet auf ihrem neu eröffneten Entwicklerportal Developer Garden Programmierschnittstellen für einige Dienste wie z.B. SMS-Versand oder Aufbau einer Telefonverbindung.

Wer statt der bereitgestellten SDKs die Webservice-Schnittstelle nutzen will (oder muss) wird es aber nicht leicht haben, wie die Dokumentation zeigt. Diese Lösung mag technisch zwar sauber sein, und in hochkomplexen Systemen wie bei der Telekom auch sicher berechtigt sein, aber vielleicht schießt diese doch etwas am Ziel vorbei. Für den Versand einer SMS-Nachricht werden mindestens 4 SOAP-Nachrichten hin- und hergeschickt, und insgesamt rund 20 kB Daten ausgetauscht…

Für unser SMS-Gateway reicht ein einziger HTTP-Request. Die Authorisierung erfolgt über ein Hash, welches das Passwort, einen Timestamp, alle Nutzdaten sowie eine fortlaufende Seriennummer umfasst. Somit wird kein Klartextpasswort übertragen (unabhängig von der SSL-Verbindung), und der Sendeauftrag kann nicht mehrfach ausgeführt werden. Und ein PHP-Client dafür ist in weniger als 5 Minuten programmiert.

Was hat sich die DENIC eigentlich bei der Seite mit der Passwort-Verschlüsselung gedacht?

Gibt man in dem Feld ein Passwort ein (welches übrigens mindestens 12 Zeichen lang sein soll; ein entsprechende Fehlermeldung erhält man aber erst nach einem erfolglosen Versuch), dann wird dieses unverschlüsselt (!) zum Webserver der DENIC gesendet, und dort der entsprechende Hash-Wert berechnet:

Was soll das bitteschön? Sollen Benutzer dazu ermuntert werden, ihre (möglicherweise “sicheren”) Passwörter unverschlüsselt über’s Netz zu schicken, nur um einen Hash-Wert berechnet zu bekommen?

Die Berechnung von Hashes geht üblicherweise auch komplett in JavaScript - somit müssten überhaupt keine Daten über’s Netz geschickt werden. Wir bieten unseren Kunden so zum Beispiel an, ihre .htaccess-Passwörter zu berechnen.

[UPDATE 18.05.2009] Die Passwort-Verschlüsselung wurde inzwischen von der DENIC-Website entfernt.

Seit über einer Woche ist eine Firma hier im Gebäude damit beschäftigt, die zentrale Telefonanlage zu ersetzen. Die Umstellung soll heute Vormittag erfolgen.

Wir betreiben ja unsere eigene Telefonanlage auf Asterisk-Basis; die zentrale Anlage nutzen wir praktisch nur als “Uplink” ins Festnetz. Aus diesem Grund habe ich unsere Servicerufnummer sowie die Notfallnummern auf eine SIP-Rufnummer umgeleitet, und diese per IP an Asterisk angebunden. Lediglich unsere normale Rufnummer wird heute Mittag für (geplant) max. 2 Stunden nicht erreichbar sein.

[UPDATE] Die Umstellung verlief absolut reibungslos. Nach einer dreiviertel Stunde lief wieder alles.

In vielen anderen Blogs wurde auch schon darauf hingewiesen: es gibt eine Online-Petition gegen die Zensur und Sperrung von Internetseiten.

Das Verfahren der DNS-Sperre ist technisch betrachtet ziemlich lächerlich - der Wegfall der Unschuldsvermutung und das geplante Loggen der Zugriffe auf die Stopp-Seiten sind aber alles andere als lustig. Man muss sich das mal vorstellen: auf einer geheimen (!) Liste stehen Namen von Servern, bei deren Aufruf (egal ob “aktiv” oder als ungewollte Weiterleitung von einer böswilligen Webseite aus) man protokolliert und als “verdächtig” eingestuft wird…

Nach Meinung vieler Experten ist diese Art der Internetzensur kaum geeignet, um aktiv gegen Kinderpornographie vorzugehen, wird aber mit erheblichen Einschnitten in die Grundrechte bezahlt.

Der Hostblogger hat eine interessante Liste an Links zusammengestellt, die ich hier einfach nochmal aufführe und erweitert habe. Der Artikel der c’t (erster Link) fasst die aktuelle Lage schön zusammen:

• Argumente für Kinderporno-Sperren laufen ins Leere (c’t - Magazin für Computertechnik)
• Die dreizehn Lügen der Zensursula (Lutz Donnerhacke / netzpolitik.org)
• Ein Mäntelchen für’s reine Gewissen (ZEIT Online)
• Phoenix und die Kinderporno-Expertin (Stefan Niggemeier, Medienjournalist)
• Die Grenzen des Stopp-Servers (FAZ)
• Nationale Abschottung durch Sperrverfügungen gegen illegale Inhalte im Internet (Gutachten des Max-Planck-Instituts)
• “Seiten zu sperren, hilft nicht” (Berliner Zeitung)

Also: Petition unterzeichnen, und “Zensursula” eine Absage erteilen.

Eben wurde eine Domain von uns zu einem anderen Provider umgezogen. Aus Neugier habe ich mir nach dem KK-ACK den neuen WhoIs-Eintrag mal angesehen.

Manche Mitbewerber haben den Zweck von “Tech-C” und “Zone-C” wohl nicht richtig verstanden, und tragen dort auch den Domaininhaber ein (als Mailadresse aber “info@[provider]”). Obwohl der in sicherlich 99,9% der Fällen nicht die DNS-Server konfiguriert und betreibt…