Content tagged net

VDSL von der Telekom mit IPv6 und Debian

posted on

IPv6 is the new normal

Meine letzten IPv6-Tunnel werden langsam überflüssig. Seit letzter Woche haben wir auch im Büro natives IPv6. Die Telekom hat uns auf einen NGN-Anschluss umgestellt.

Setup

IPv6 aktivieren

Kurz zusammengefasst

Für den IPv6-Zugang muss der pppd IPv6 auf der PPP-Verbindung aktivieren. Die Telekom benutzt dann Router-Advertisements (radv) um dem ppp0-Device eine IPv6-Adresse zu geben. Soll IPv6 im LAN weiterverteilt werden, bekommen wir Präfixe hierfür über Präfix-Delegation per DHCPv6. Letzteres kann aber nicht als Ersatz für die Router-Advertisements genutzt werden, da die Telekom nur Präfixdelegation darüber macht.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

DNSsec-Signaturen überprüfen mit Bind

posted on

Wer einen authoritativen Nameserver betreibt sollte die eigenen Zonen mit DNSsec sichern. Hier zeige ich euch, wie ihr einen rekursiven Nameserver so einrichtet, dass der DNSsec-Signaturen prüft. Was ist der Unterschied? Authoritative Nameserver sorgen beim Besitzer einer Domain, dass diese gefunden werden kann. Rekursive Nameserver suchen für einen Internetanschluss die richtige Verbindung zu fremden Domains.

Warum soll ich DNSsec aktivieren?

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Mein DNSsec-Setup

posted on

Vor ein paar Tagen habe ich bereits über einen Teil meines Nameserver-Setups mit Bind geschrieben. Ich habe erklärt, wie DDNS mit bind verwendet werden kann um beispielsweise Kunden die Möglichkeit zu geben Änderungen an Ihren Zonen über ein standardisiertes Protokoll durchzuführen oder die sich häufiger ändernde IP des Internetanschlusses zuhause immer aktuell im DNS zu hinterlegen. Dabei habe ich erwähnt, dass ein interessantes Argument für den Einsatz von DDNS zum Updaten von Zonen auch ist, dass bind in diesem Fall sich automatisch darum kümmert diese erneut zu signieren. Wie dieses Setup funktioniert möchte ich in diesem Artikel beschreiben.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

DDNS mit Bind einrichten

posted on

Der Nameserver Bind bringt von Hause aus die Möglichkeit mit, dass Änderungen in Zonen dynamisch durchgeführt werden können. Dies kann zum Beispiel genutzt werden um selbst etwas wie DynDNS zu realisieren. In der Tat nennt sich das was Bind da implementiert auch DDNS. Spezifiziert ist das Protokoll in RFC 2136: Dynamic Updates in the Domain Name System (DNS UPDATE).

Da ich heute eh den größten Teil dieses Textes als Mini-HOWTO für einen Kollegen geschrieben habe, möchte ich ihn auch hier auf meinem Weblog für andere zur Verfügung stellen. Alle hier verwendeten Befehle sind Befehle von Bind. Unter Debian sind diese Utility-Befehle im Paket dnsutils verpackt. Aktuell benutze ich die Version 9.8.4 von Bind.

Ich zeige in diesem Artikel:

  1. wie man einen kryptografischen Schlüssel zur Sicherung des Zugriffs erstellt,
  2. wie die Konfiguration von Bind angepasst wird,
  3. wie dynamische Updates an Bind geschickt werden und
  4. was zu beachten ist, wenn weiterhin auch klassische Updates an der Zone durchgeführt werden sollen.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Kompatibilität von 8192-Bit-Zertifikaten

posted on

Aufgrund der Tatsache, dass die Hardware mit denen Public-Key-Schlüssel angegriffen werden kann immer leistungsfähiger wird, ist es notwendig, dass auch die Größe der eingesetzten Schlüssel immer weiter vergrößert wird.

Für den Einsatz mit qualifizierten digitalen Signaturen in Deutschland veröffentlicht beispielsweise die Bundesnetzagentur jährlich den sogenannten Algorithmenkatalog. In ihm steht jeweils welche Mindestschlüssellänge bis zu welchem Zeitpunkt als ausreichend angesehen werden kann.

Aktuell wird für den Einsatz von RSA-Schlüsseln bis Ende 2018 beispielsweise empfohlen, dass diese mindestens 2048 Bit lang sein sollten.

Dies betrifft aber natürlich nicht nur qualifizierte Signaturen sondern beispielsweise auch die verschlüsselte Übertragung von Webseiten mit dem HTTPS-Protokoll. Auch hierfür werden meistens RSA-Schlüssel eingesetzt. Üblicherweise trifft man auf Webservern dabei meistens Schlüssel der empfohlenen Länge an. (Ergebnis einer nicht repräsentativen Überprüfung einiger Websites durch mich.)

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Site schnellstens aus Google entfernen: alles außer robots.txt sperren

posted on

Diese Woche bekomme ich einen Anruf von einem Bekannten: er entwickelt gerade eine Website für einen Kunden. Und obwohl die Seite noch nicht fertig ist, taucht sie schon im Suchindex von Google auf. Er hatte vergessen die Seite während der Entwicklung mit einem Passwortschutz zu versehen. Er fragte mich, ob ich eine Idee habe, wie er dieses Versäumnis so schnell als möglich korrigieren könne.

Wir sind nun gemeinsam ein paar Möglichkeiten durchgegangen das Problem zu beheben:

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Probleme mit TLS-Verbindungen bei StartSSL-Zertifikaten

posted on

Ich greife mit zwei E-Mail-Programmen auf meinen Mailaccount zu. Das eine ist mutt, das andere ist Thunderbird. Während ich mit mutt keine Probleme habe, kann ich seit zwei Tagen mit Thunderbird nicht mehr auf mein E-Mail-Konto zugreifen.

Wenn ich es probiere, dann sehe ich Thunderbird für etwa 20 Sekunden versuchen eine Verbindung mit dem Mailserver aufzubauen. Nach diesen 20 Sekunden stellt sich Thunderbird wieder so als hätte es nicht versucht E-Mails abzufragen. Es kommt also auch keine Fehlermeldung oder dergleichen.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

Virtuelles Hosting für HTTPS mit Apache und mod_gnutls

posted on

Die IPv4-Adressen gehen aus – so ließt man. Im Februar 2011 wurde die letzte freie Adresse in Europa vergeben. Was seitdem getan wird: nichts. Trotzdem leiste ich meinen Beitrag: ich spare IPv4-Adressen mit virtuellem Hosting auch für HTTPS.

HTTPS und die IP-Adressen

Der wichtigste Grund warum ein Webserver mehrere IP-Adressen hat ist HTTPS. Für jede HTTPS-Domain brauchte man bisher eine eigene IP-Adresse. Die Verschlüsselung von HTTPS wird aktiviert bevor der Webbrowser dem Server sagt welche Webadresse er abrufen möchte. Das Problem dabei: das Zertifikat welcher Domain soll der Server nun benutzen? Verwendet er das falsche meckert der Browser. Eine rote Seite erscheint und warnt den Internetnutzer, dass da etwas nicht stimmt und die Seite vielleicht unsicher ist. Das wollen wir nicht!

Die Lösung bisher: jede Domain hat eine eigene IP-Adresse. Muss ein Webserver eine HTTPS-Anfrage beantworten, schaut er welche IP-Adresse angesprochen wurde. Kein Problem, das kann er. Für jede IP-Adresse weiß er die zugehörige Domain. Er kann das richtige Zertifikat nutzen.

Schon 2003 aber wurde Server Name Indication (engl. für „Andeutung des Servernamens“) erfunden RFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitions Moderne Browser übermitteln hiermit schon bevor verschlüsselt wird welche Domain sie erwarten. Wenn sich der Browser an diesen Standard hält, dann kann der Webserver auch ohne verschiedene IP-Adressen erkennen welches Zertifikat er nutzen muss.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

History of Matthias Wimmer's PGP and GPG keys

posted on

PGP-signed version of this history.

KeyID Fingerprint Date Expires (sign/encrypt) Status
70D6C898 CAEC A12D CE23 37A6 6DFD 17B0 7AC7 631D 70D6 C898 2006-08-10 2010-01-01/2010-01-01 This is my main GPG key since 2006-08-10.
C9CD24F7 85A0 801A 2392 424F 69AB 5A63 C6D6 197D C9CD 24F7 2003-03-06 2008-03-04/2008-03-04 Key in use for special purposes. Please don't use it for e-mail.
4E59C7E6 B0F5 9D8C 28A8 34B6 FDE1 410A 3D27 3DDA 4E59 C7E6 2003-01-21 2007-01-01/2006-01-01 Key still exists, but only used for migration-signing to new key anymore.
8D8B4A2E 6F81 B414 B8A1 1806 A333 A18E 0142 F366 8D8B 4A2E 2001-01-11 *** revoked *** Public and private key still exist, never used for e-mail/not used anymore
AA839AF9 85E8 0EE5 C852 363C FC19 BD5F 27FE 6356 AA83 9AF9 2000-03-06 *** revoked *** Public and private key still exist, but not used anymore.
034FDE2A EA16 DEA8 4146 12EE 3B56 68D8 0A70 794E 034F DE2A 1999-09-15 *** revoked *** Public and private key still exist.
55DB8129 AF 14 32 B5 69 38 30 6E 3A B8 13 8D 66 A8 66 AE 1999-04-27 never :-( Lost private key!
B3D1AF25 8C 79 81 AA ED 95 4D 0B 8F 53 09 52 9A 39 32 49 1998-05-25 *** revoked *** Public and private key still exist, revoked because e-mail address is not used anymore.
730BD791 ??? 1997-07-05 never Lost public key, private key still exists.
D9954A11 ??? 1996-10-23 never Lost public key, private key still exists.
3336E4E9 ??? 1996-07-24 never Shared key (for the sysops of my former mailbox), I am not the only one that has the private key. Public key lost.
8B674F75 DE 51 C1 7E E4 99 4B 9D 5B 76 06 B2 DF 00 64 F1 1996-07-18 *** revoked *** Public and private key still exist, revoked because e-mail address is not used anymore.

There exist some even older keys that I have never used in the internet and that only contain FidoNet addresses. These keys are completely lost. I neither have the public nor the private keys anymore.

Change history

2006-08-10: Marked key AA839AF9 as revoked, updated signing-expire-date for key 4E59C7E6, added new key 70D6C898
2003-12-04: Updated expiry information for 4e59c7e6

IMUnified - Protokoll

posted on

IMUnified hat vor etwa zwei Jahren angekündigt, ein Protokoll zu schaffen, das es ermöglichen soll, verschiedene Instant Messaging Systeme mit einem Client zu benutzen. Gründungsmitglieder waren unter anderem MSN, Odigo und Yahoo!.

Inzwischen ist es wieder ruhig geworden, ob IMU jemals ernsthaft eingesetzt wird, wird wage ich fast zu bezweifeln. Aber immerhin kann beispielsweise der Yahoo!-Messenger das Protokoll, man muss es nur mit ein paar Registry-Änderungen unter Windows einschalten. Danach hat man die Möglichkeit, sich zusätzlich zu Yahoo! auch in andere IM Dienste anzumelden.

Dies habe ich zum Anlass genommen, mir IM Unified doch einmal anzuschauen und habe ein paar Sessions mit einem Network-Sniffer protokolliert. Das Protokoll ist an sich sehr einfach aufgebaut und erinnert etwas an Protokolle wie SMTP oder HTTP.

Alle Daten werden über eine TCP/IP-Verbindung ausgetauscht. Der Client konnektiert hierzu auf den Port 11319 des Servers. Über diese Verbindung macht er zunächst ein Login-Handshake und tauscht danach Daten aus. Der Austausch erfolgt in Blöcken.

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »

IMUnified - protocol

posted on

In 2000, IM Unified announced to create a protocol that enables an instant messaging client to join different IM services. Founding members were MSN, Odigo, Yahoo! and others.

Since then I have not heard much of IMU. I don't even think that their IMIP protocol will ever be used really. But it does exist and e.g. the Yahoo! messenger client supports it. You only have to change some values in the Windows registry. Afterwards, you're client is able to join other IM services like Odigo with the Y! messenger.

For no other reason than to see how IMIP works I've dumped some IMIP sessions with a network sniffer. The IMIP protocol is very simple structured and looks a bit like SMTP or http.

All data is exchanged over a TCP/IP connection. The clients connects to port 11319 at the server. Firstly, it performs the login handshake and afterswards, it is exchanging messages, presences and other data. All data is exchanged in blocks.

All blocks have a structure of lines. Every line is finished by \r\n (carriage return, line feed). The first line contains the type of a block, the second line contains the size of the block (first two lines not counted). It is a decimal ASCII number containing the size in bytes. Starting at the third line, there are head lines, optionally followed by an empty line, optionally followed by a block body. If the body is empty, the empty line can be absent. (The Y! messenger is allways sending the empty line, the Odigo server isn't.)

weiterlesen | read more | lee mas | lê mais | 閱讀更多 »


Unless otherwise credited all material Creative Commons License by Matthias Wimmer