Springe zum Inhalt

Microsoft stellt mit der Library WinHTTP eine Schnittstelle zur Verfügung, mit der Programme Ressourcen per HTTP(S) abrufen können. Sollte das Programm keine Unterstützung für einen Proxy anbieten, so läßt sich mit Microsoft-eigenen Mitteln ein evtl. im Netzwerk erforderlicher Proxy für WinHTTP einstellen.

Systeme kleiner als Windows Vista verwenden dazu das Tool proxycfg, alle anderen netsh im winhttp-Kontext. Um z.B. die Proxy-Einstellungen aus dem Internet Explorer in die Registry für WinHTTP zu importieren, kann folgendes Kommando verwendet werden:

netsh winhttp import proxy source=ie

Die aktuellen Einstellungen lassen sich mit folgendem Kommando anzeigen:

netsh winhttp show proxy

Die Proxy-Einstellungen für WinHTTP können mit folgendem Kommando wieder gelöscht werden:

netsh winhttp reset proxy

32- und 64bit-Systeme

Auf 64bit-Windows ist die Registry zweigeteilt. Es gibt getrennte Einstellungen für 64bit- und 32bit-Programme in der Registry. Unter einem 64bit-Windows muss zum Ansprechen des 32bit-Teils der Registry netsh aus dem Verzeichnis C:\Windows\SysWOW64 aufgerufen werden.

C:\Windows\SysWOW64\netsh winhttp ...

Update

Anscheinend wurde das Problem mit unterschiedlichen Einstellungen für 32Bit- und 64Bit-Systeme unter Windows 8 behoben.

Seit pfSense 2.0 ist ein Zertifikatmanager in die Weboberfläche integriert, mit dem sich Zertifikate, z.B. für IPSEC, erzeugen und signieren lassen.

Bei der Verwendung der mit pfSense erstellten Zertifikate in Strongswan in Versionen kleiner als 4.6.2 kann der private Key nicht geladen werden. Folgende Fehlermeldung erscheint:

charon: 00[LIB] L1 - modulus: ASN1 tag 0x02 expected, but is 0x30
charon: 00[LIB] building CRED_PRIVATE_KEY - RSA failed, tried 8 builders

Ursache ist, dass Strongswan bis Version 4.6.2 nur private Keys im PKCS#1-Format lesen kann. Die aus pfSense exportierten privaten Keys liegen aber im PKCS#8-Format vor.

Mit folgendem Kommando kann der private Schlüssel vom PKCS#8- ins PKCS#1-Format konvertiert werden:

openssl rsa -in key8.pem -out key1.pem

Anschließend kann auch der Schlüssel wieder in Strongswan geladen werden.

1

IPv4 Adressen werden immer knapper und mittlerweile bekommt man bei vielen Hostern schon standardmäßig einen IPv6-Adressblock zum gemieteten Server dazu. Wer wie ich einen Debian-Server verwendet, bei dem die Root-Partition mit LUKS verschlüsselt ist und diese beim Bootvorgang über einen Dropbear-SSH-Zugang freigeschaltet werden muss, wird feststellen, dass nach dem Booten die Interfaces nicht die korrekte IPv6-Konfiguration haben.

Unter Debian kann die Netzwerkschnittstelle für Dropbear über die Datei /etc/initramfs-tools/initramfs.conf nur als IPv4 konfiguriert werden. Nach dem Booten stellen die Debian-Skripte fest, dass eth0 schon konfiguriert ist und verwenden die Einstellungen aus /etc/network/interfaces nicht mehr. Etwaige weitere Einstellungen in dieser Datei haben keine Wirkung, da sie nicht ausgewertet werden.

Abhilfe schafft ein

/sbin/ifdown --force eth0
/sbin/ifup --force eth0

in /etc/rc.local. Damit wird zuerst das Interface eth0 heruntergefahren und damit in einen definierten Zustand versetzt.  Anschließend wird das Interface wieder hochgefahren und die Einstellungen aus /etc/network/interfaces entsprechend angewendet.

Seit gestern findet sich auf der Webseite des beliebten Kryptographieprogramms zur Festplattenverschlüsselung Truecrypt eine Warnung (Update: mittlerweile gibt es die Seite nicht mehr), dass die Software angeblich nicht mehr sicher sei. Ebenso wurde die Software in einer neuen Version veröffentlicht, welche nur noch eine Entschlüsselung der Inhalte zulässt.

truecrypt.org 2014/05

Gleichzeitig wurden alle Verweise auf die ursprüngliche Webseite aus der Software, ja selbst die Verweise auf die Homepage in der Wayback-Machine archive.org komplett entfernt.

Archive.org Truecrypt

Gegen einen Hack bzw. ein Defacement der Webseite sprechen, dass die neu veröffentlichte Version 7.2 mit dem selben Schlüssel signiert wurde, mit dem auch die vorherige, voll funktionsfähige Version 7.1a signiert wurde. Auch sprechen die umfangreichen Änderungen im Sourcecode (Diff-Format), die das Anlegen neuer Truecrypt-Volumes unmöglich machen und nur noch das Entschlüsseln, jedoch nicht mehr das Verschlüsseln ermöglichen, gegen einen schnellen Hack. Ein neu eingebauter Trojaner konnte nicht gefunden werden.

Ein im April 2014 durch Croudfunding mit 60.000 US$ finanzierter Audit von Truecrypt förderte im April 2014 bereits bekannte Fehler zu Tage:

Im April 2014 wurden die Ergebnisse einer kommerziellen Begutachtung der Software veröffentlicht. Die Autoren des Berichts fanden elf Fehler, von denen sie keine als schwer, vier als mittelschwer, vier als leicht und drei in die niedrigste Kategorie „informational“ einstuften. Hinweise auf eine Backdoor wurden nicht gefunden.

Ein weiterer Schritt, der zum Ziel hatte, die Software unter eine etablierte OpenSource-Lizenz zu stellen wurde im Januar 2014 gestartet.

Dies alles lässt viel Raum für Spekulationen. Wie immer, wenn wenige Informationen greifbar sind, sprießen Verschwörungstheorien wie Pilze aus dem Boden. Ohne weiterführende Informationen von den (anonymen) Entwicklern wird sich auch keine befriedigende Antwort finden lassen. Evtl. können die Entwickler aber auch gar keine Antwort geben, was auch meiner favorisierten Theorie entspricht: ihnen wurde ein sogenannter National Security Letter (NSL) überstellt, der sie zu irgendetwas verpflichtet, über das sie anschließend unter Strafandrohung auch nicht reden dürfen. Das wäre in etwa das gleiche Vorgehen, wie es auch der Entwickler von Lavabit, einem Anbieter für verschlüsselte E-Mail-Dienste, wählte. Wäre diese Theorie zutreffend, ist die gewählte Methode, die Anwender vor der Unsicherheit der Software ab jetzt zu warnen, ja sogar die weitere Entwicklung der Software einzustellen ein gangbarer Weg, um die Anwender vor möglicherweise anweisungshalber einzubauenden Hintertüren zu warnen.

Nach all dem ist Folgendes festzustellen:

  • Truecrypt in der Version 7.1a ist, bis auf anders lautende Berichte aus dem noch durchzuführenden Audit, sicher.
  • Truecrypt 7.2 sollte nicht installiert werden, da damit nur noch eine Entschlüsselung möglich ist und nicht ausgeschlossen werden kann, dass sich doch noch eine Hintertür in der Software versteckt.
  • Da die Entwickler von Truecrypt bisher anonym geblieben sind, ist es nicht möglich,  jetzt irgendwelche Wortmeldungen ernst zu nehmen.
  • Die Entwickler haben leider versäumt oder nicht gewollt, dass Truecrypt jemals unter eine anerkannte Opensource-Lizenz gestellt wird. Das wird sich evtl. auch in Zukunft nicht nachholen lassen. Damit ist dieses geniale Stück Software für die Zukunft verloren.

Truecrypt in der Version 7.1a kann nach wie vor aus dem Heise-Softwareverzeichnis für Windows, Mac und Linux heruntergeladen werden.

Bild: Poil