ravenhorst - Software

NoScript und DNT

nospam@example.com (Kai Raven) — Mon, 03 Jan 2011 06:49:48 +0100

Gerade kam ein Update von NoScript für die "Do Not Track" (DNT) Opt-out Header Funktion, die seit 2.0.9 enthalten ist - sprich Browser sendet an jede Website zusätzlichen Tracking Opt-out Header.

Lt. X-Do-Not-Track support in NoScript:

"From now on, a web browser with NoScript installed warns every HTTP server it contacts that its user does not want to be tracked, i.e. that his data must not be collected for profiling and persistent identification purposes. I believe this is a safe assumption about the feelings of most if not all NoScript users."

Richtig.

"As stupid as it may sound (why parties who are interested in tracking you would comply?),"

Eben. Stupid.

"a mean to clearly express your will of not being tracked is going to be useful, especially when backed by law or industry self-regulation, as explained here."

Nicht "besonders", sondern ausschließlich dann, wenn oder sobald die Auswertung und Beachtung von DNT gesetzlich vorgeschrieben ist. Selbstregulierung ist keine Option, sondern nur eine Taktik von Unternehmen und der Politik, einer gesetzlichen Regulierung im Interesse von Internetnutzern, Bürgern und Kunden zu entgehen.

"Therefore it seems in the interest of NoScript users and privacy-concerned netizens in general to participate in this effort."

Nein. Solange die obige Bedingung nicht erfüllt ist, trägt der Header nur zum Browser Fingerprint bei und identifiziert die User, die Anti-Tracking Erweiterungen installiert haben. Der DNT Header wird damit selbst zum Tracking Opt-in Header. Außerdem ist es wenig sinnvoll, wenn Erweiterungen anfangen, schlecht dokumentierte oder von Browseranwendern nicht beachtete bzw. nicht zu ändernde Header Manipulationen durchzuführen.

In diesem Sinne rate ich dazu, noscript.doNotTrack.enabled auf false zu setzen.

Wer Privoxy einsetzt - in die Filterdatei einsetzen:

CLIENT-HEADER-FILTER: kill-optout-header Header filter to remove Do-Not-Track headers.
s@^X-(?:Behavioral-Ad-Opt-Out|Do-Not-Track):.*@@i

In eine Actiondatei (z. B. match-all.action) einsetzen:

+client-header-filter{kill-optout-header} \

bewirkt dann global das:

Re-Filter: filtering 'X-Behavioral-Ad-Opt-Out: 1' (size 26) with 'kill-optout-header' ...
Header: Transforming "X-Behavioral-Ad-Opt-Out: 1" to ""
Re-Filter: ... produced 1 hits (new size 0).
Header: Removing empty header
Re-Filter: filtering 'X-Do-Not-Track: 1' (size 17) with 'kill-optout-header' ...
Header: Transforming "X-Do-Not-Track: 1" to ""
Re-Filter: ... produced 1 hits (new size 0).
Header: Removing empty header

Scheinbare und wirkliche Vermummungen in der Zukunft

nospam@example.com (Kai Raven) — Mon, 15 Nov 2010 20:00:23 +0100

In "Vermummungsverbot im Internet": Vom neuen Personalausweis und Pseudonymen singt Detlef Borchers das hohe Lied vom nPA Pseudonym. Schön und gut, vielleicht auch gut gemacht.

Der Schlüsselsatz ist imo aber "Anbieter, die die Pseudonym-Funktion unterstützen, werden normalerweise eine Erstregistrierung auf ihren Seiten einpflegen, bei der sich ein Nutzer mit einem frei wählbaren Namen und/oder einer E-Mail-Adresse einträgt."

Nicht "und/oder", denn mehrheitlich wird eine E-Mail Adresse anzugeben sein, denn irgendwohin wird der Anbieter Meldungen zur Bestätigung, später bei Fehlern im System, neuen Funktionen usw. usf. senden müssen und wollen. Also brauchen wir auch eine (zumindest) pseudonyme E-Mail Adresse, denn das Angebot soll ja pseudonym und müsste anonym genutzt werden.

Nun stellen wir uns ganz dumm oder die ideale Welt vor, die sich auch der ansgesprochene CDU-Politiker Axel E. Fischer eträumt. In dieser Welt gibt es keine x-beliebigen E-Mail Anbieter mehr, die ohne vorherige korrekte Identifizierung des neuen Kunden mir nichts, dir nichts E-Mail Adressen und Konten verschenken und die Nutzung ihres Dientes anonymisiert erlauben. In dieser Welt soll das Schule machen, was man De-Mail nennt. Ein Modell für die Welt. Also De-Mail oder De-Mail-artige E-Mail Anbieter, bei denen die Eröffnung und Nutzung von E-Mail Konten ebenfalls an vorherige Identifizierung gebunden ist - am Besten mit so etwas wie dem nPA. Aber die De-Mail hat ja auch ein schönes pseudonymes Feature - die Einrichtung pseudonymer E-Mail Adressen. Die sind aber per De-Mail Gesetz nicht nur als solche zu kennzeichnen, sondern sie müssen zwingend aufdeckbar sein. Und mit so einer pseudonymen E-Mail Adresse meldet man sich dann in dieser idealen Welt mit seinem nPA beim Dienste-Anbieter an, um ein pseudonymes Dienste-Konto zu erhalten.

Kein Finger für die externe Festplatte

nospam@example.com (Kai Raven) — Thu, 27 May 2010 13:50:04 +0200

Schick sieht sie ja aus, die Features stimmen und auf Hardware im "Secure All–Terrain Shock–proof rugged design", um ein paar der Attribute zur Vermarktung der externen LaCie Rugged Safe Festplatte zu nennen, stehe ich eh.

Externe Festplatte "Rugged Safe" von LaCie.
Foto: LaCie.

Aber was ist das für ein Blödsinn, zwar eine Verschlüsselung per AES-128 (es kann auch a bisserl mehr sein) und Chip anzubieten, zu der LaCie natürlich wie so viele Hersteller auch verspricht, dass sie "unbrechbar" implementiert sei, aber in die Festplatte einen Fingerabdruck-Sensor einzubauen. Macht man das nur deshalb, weil es mittlerweile üblich, möglich und von den Kosten her annehmbar ist, überall biometrische Verfahren und Techniken für die Authentifizierung und Entschlüsselung zu verbauen?

Großartig beworben wird das Produkt mit der Möglichkeit, neben der Eingabe eines Passworts ganz einfach mit dem Scannen und Abgleich eines einzelnen Fingerabdrucks Zugriff auf die zuvor verschlüsselten Daten zu erhalten. Das wird natürlich Sicherheitsbehörden freuen, wenn sie die LaCie Festplatte beschlagnahmen und nur noch einen Finger des Besitzers auf den Sensor halten müssen, anstatt den Versuch zu starten, das Passwort aus dem Besitzer herauszupressen. Und damit es dabei keine Ausfälle gibt, kann sich der Besitzer der Festplatte auch alle zehn Fingerabdrücke einscannen - prima.

Das gilt natürlich auch für Diebe, wenn die Besitzer und Festplatte zugleich "abgreifen" können und für beide Interessenten der verschlüsselten Daten gilt, dass es ja auch noch die Möglichkeit gibt, sich mit nachgebildeten Fingerabdrücken an dem Sensor zu versuchen, von dem es in dem User Manual auf die FAQ "What is the probability that a fingerprint from an unauthorized user can unlock the Rugged Safe?" nur die beschwörende Antwort gibt: "Such an event is nearly impossible due to the biometry technology. Each human has his own biological identity, including unique fingerprints, thus making unauthorized entry all but unthinkable. To provide further assurance, LaCie has selected a sensor known for its precision." Wer's glaubt, wird seelig.

Was ich noch verstehen und mir vorstellen könnte, wäre eine 2-Wege Authentifizierung/Entschlüsselung, also Fingerabdruck plus zwingendem Passwort.

CryptoStick des GPF e. V. In zukünftiger Version mit integriertem Datenspeicher, so dass sich der zweite Stick erübrigen würde.

Oder noch besser: Wenn in externen Festplatten ein USB-/SmartCard Reader integriert wäre, mit dem ich meinen OpenPGP CryptoStick der German Privacy Foundation und dessen PIN zur Authentifizierung/Entschlüsselung nutzen könnte. Das wäre doch mal was, liebe Hersteller externer Festplatten Bis dahin bleibe ich lieber bei TrueCrypt und dm-crypt/LUKS verschlüsselten Partitionen.

Scroogle - Google - Tor

nospam@example.com (Kai Raven) — Tue, 11 May 2010 18:37:47 +0200

Der beliebte und bekannte Scroogle Proxy Dienst hat aktuell Probleme mit Google, wie zu lesen ist, wenn man Scroogle aufruft bzw. eine Suchanfrage absetzt:

We regret to announce that our Google scraper may have to be permanently retired, thanks to a change at Google. It depends on whether Google is willing to restore the simple interface that we've been scraping since Scroogle started five years ago. Actually, we've been using that interface for scraping since Google-Watch.org began in 2002.

This interface (here's a sample from years ago) was remarkably stable all that time. During those eight years there were only about five changes that required some programming adjustments. Also, this interface was available at every Google data center in exactly the same form, which allowed us to use 700 IP addresses for Google.

That interface was at www.google.com/ie but on May 10, 2010 they took it down and inserted a redirect to /toolbar/ie8/sidebar.html. It used to have a search box, and the results it showed were generic during that entire time. It didn't show the snippets unless you moused-over the links it produced (they were there for our program, so that was okay), and it has never had any ads. Our impression was that these results were from Google's basic algorithms, and that extra features and ads were added on top of these generic results. Three years ago Google launched "Universal Search," which meant that they added results from other Google services on their pages. But this simple interface we were using was not affected at all.

usw.

Da Scroogle immer ganz praktisch bei der Nutzung von Tor war, um den lästigen "We're sorry" Meldungen und Captcha Anfragen zu entgehen, muss schnell ein temporärer Ersatz her: Entweder man nimmt Ixquick oder man sucht sich bei Mycroft einen anderen Ersatz und kann dann dort direkt das passende Search Engine Plugin in Firefox installieren.

Mit zwei Anonymouse oder auch dem "Ninja" Plugin klappt das ganz gut. Und da eh alle Suchanfragen bei mir per Privoxy und Tor gefiltert und anonymisiert an den Suchdienst rausgehen... Aber mir wäre lieber, wenn das Scroogle wieder geregelt bekommt Nur wenn man einen Suchdienst erwischt, den Google selbst als "Gefährder" einstuft oder der Suchdienst die IP des Tor Exit Node an Google weiterreicht, kann man wieder schlechte Karten bei Google haben.

Update: Mal wieder viel Geschrei um nix, laut Scroogle scrapes back to life kann wieder gescroogelt werden

Siehe auch:
Heise - EU-Datenschützer fordern echte Anonymisierung von Suchanfragen (27.05.2010)

Panopticlick Experimente gegen Web-Tracking

nospam@example.com (Kai Raven) — Wed, 27 Jan 2010 15:29:34 +0100

Die Electronic Frontier Foundation (EFF) bietet mit Panopticlick ein nettes Spielchen (oder Experiment) mit ernstem Hintergrund für alle Internetuser an, die sich für die Anonymisierung ihrer Browser- bzw. WWW-Nutzung interessieren oder anders gesagt, wie ihr Webbrowser konfiguriert ist und deshalb welche Informationen ausspuckt, die er mit einer Teilmenge der Browser anderer Nutzer in einer gegebenen Gesamtmenge gemeinsam hat oder auch nicht. Noch einfacher: "Zeig mir, welchen Browser und wie Du ihn nutzt und ich sage Dir, wer Du bist und wo Du bist". Die meisten Internetnutzer dürfte es nicht interessieren

Den ernsten Hintergrund bildet die Identifizierung und Wiedererkennung von Webbrowsernutzern - das Optimum wäre: stets ein und desselben Nutzers, Verfolgung der Nutzung oder des Konsums von Webseiteninhalten über Webseiten und Websites hinweg und seine Geolokalisierung, an der sich Nutznießer und Auftraggeber der Werbeindustrie, manche Internet-Zugangsprovider, Dienste- und Inhalteanbieter oder auch Geheimdienste versuchen.

Ähnlich wie beim Anontest vom JonDonym Anonymisierungsdienst oder bei browserspy.dk wertet Panopticlick den charakteristischen User-Agent und HTTP_ACCEPT Header aus und sofern Javascript aktiviert ist (was bereits ein Kriterium an sich ist), installierte Browser Plugins, Zeitzone, Bildschirmauflösung, Farbtiefe, Systemschriften, ob Cookies und "Supercookies" per Flash LSOs und DOM-Storage möglich sind.

Bei EFFs Panopticlick werden die Daten aber nicht nur für jeden einzelnen User ausgewertet, angezeigt und wieder verworfen, sondern anonymisiert in einer Datenbank gespeichert und mit den Datensätzen aller anderen User abgeglichen, um zur besagten Aussage zu kommen, wie einzigartig und identifizierbar man in der Gesamtmenge ist. Also die gleiche Aussage, an der auch die angesprochenen Kreise interessiert sind. Je mehr und länger User mit ihren verschiedenen Betribessystemen, Browsern und Konfigurationen mitmachen, desto aussagekräftiger wird der Scorewert, den man nach dem Panoption Test erhält und desto aussagekräftiger die Antwort, die man sich von dem Panopticlick Experiment seitens der EFF erhofft: Wie gut lassen sich mit "Web-Tracking" Methoden digitale Fingerabdrücke für Browsernutzer erstellen und wie effektiv sind sie?

Einschränkend muss man sagen, dass man eigentlich umso besser in der Menge aller Browsernutzer verschwinden müsste, je mehr man den eigenen Browser genauso nutzt wie die Mehrheit oder zumindest der Durchschnitt aller Internetnutzer - wie ich annehme: mit veralteten Versionen, mit allen nur denkbaren Plugins und Erweiterungen vollgeknallt bis zum Anschlag, Javascript und Flash schön aufgedreht, Cookies immer dabei und natürlich ohne Anonymisierung

Kleiner Tipp zur neuesten Firefox-Version am Rande: Die finden ja nicht nur diese überflüssigen Minimalthemes names "Personas" ganz toll, sondern auch die Geo-Lokalisierung per Google Lokalisierungsdienste, die man aber laut Anleitung einfach und generell deaktivieren kann. Wird aber auch nur eine Teilmenge der Teilmenge abschalten, wie ich die feature-geilen Internetuser kenne.

Siehe auch:
EFF - Web Browsers Leave 'Fingerprints' Behind as You Surf the Net (17.05.2010)

Digitale DNA und Fingerabdrücke für DARPAs Cyber Genome Programm

nospam@example.com (Kai Raven) — Wed, 27 Jan 2010 11:16:18 +0100

"Ziel des Cyber Genome Programms ist es, revolutionäre Techniken für Cyber-Verteidigung und -Ermittlungen zur Sammlung, Identifizierung, Charakterisierung und Einordnung der Eigenschaften und Verbindungen von digitalen Artefakten zu entwicklen, die von Software, Daten und / oder Nutzern erfasst wurden, um die Strafverfolgungsbehörden, Spionageabwehr und Cyber-Verteidigungsteams des US-Verteidigungsministeriums zu unterstützen. Digitale Artefakte können von aktuellen Systemen (traditionelle Computer, PDAs und / oder verteilten Informationssystemen wie "Cloud Computer") erfasst werden, von kabelgebundenen und Fun-Netzwerken oder von Speichermedien. Die zu erfassenden Formate können elektronische Dokumente oder Software (um bösartige Software - Malware einzuschließen) umfassen. Das Cyber Genome Programm wird verschiedene Programmphasen und Technikfelder umspannen. Jedes der Technikfelder wird das Cyber Äquivalent zu Fingerabdrücken oder zur DNA entwicklen, um das digitale Gegenstück zu Genotypen genauso wie zu beobachteten und von ihnen abgeleiteten Phänotypen zu entwickeln, um Identität, Abstammung und den Ursprung digitaler Artefakte und Butzer zu bestimmen."

So lautet die verquaste und nebulöse Zielbeschreibung eines der neuen Programme des Strategic Technology Office der DARPA, die sie ständig ausstößt, anlässlich der Einladung zu einer ersten Informationsveranstaltung für interessierte Forschungseinrichtungen und Unternehmen, die während der vierjährigen Laufzeit von den 43 Millionen US$ profitieren wollen, die für das Cyber Genome Programm von der DARPA ausgeschüttet werden.

Diskussionen, Programme und Politik zu Cyber-Defense, Cyber-Crime, Cyber-Spionage, Cyber-Terrorismus und Cyber-War haben ja international und insbesondere in den USA zur Zeit Hochkonjunktur. Nach den konventionellen Kriegen der Vergangenheit und Gegenwart, den Drohungen von Kriegen und Anschlägen mit ABC-Waffen, nachdem auch der Orbit mit Spionagesatelliten und militärischen Abwehrsystemen kolonisiert wurde und die kleine oder organisierten Kriminalität im Real-Life plagt, drängen sich seit einiger Zeit die militärischen und polizeilichen Fronten im Internet und in Netzwerken in den Mittelpunkt.

Je nach Ausrichtung sind es mal wieder die "Horden der gelben Gefahr", die ihre Hacker- und Spionagebrigaden ins virtuelle Feld führen oder die "ausländischen Spione des Westens", die zu "Cyber" Krieg und "Cyber" Spionage blasen. Übergreifend geeint im Krieg gegen einen nicht-staatlichen "Cyber" Terrorismus als Fortsetzung des "Krieges gegen den Terror" mit Militär- und Polizeinsatz außerhalb der Netze, der bis jetzt mehr als Schreckgespenst existiert. Und wäre es nicht schrecklich genug, gibt es auch noch das große Feld der "Cyber" Kriminellen, denen – wenn man den Pressemeldungen und -mitteilungen folgen will – tagtäglich Millionen zum Opfer fallen und die Millionen von Internetnutzern, die sich "cyber-kriminell" betätigen können oder das Potential zum "Cyber-Kriminellen" oder "Cyber-Terroristen" in sich bergen, wenn man sie und das Netz nicht der fürsorgenden und strengen Regulierung, Kontrolle, Überwachung und Strafverfolgung unterwirft.

Tatsächlich gibt es vieles vom "Cyber-Bösen" – mehr oder weniger. Eben vieles, was auch außerhalb der Netze und Netzwerke existiert und sich technisch umsetzen lässt. Ist ja eine Binsenweisheit. Deshalb ist verständlich, dass man auch in Unternehmen, staatlichen Institutionen, Netzwerken und im Internet tatsächlichen Bedrohungen und Gefahren mit sinnvollen und abgewogenen Maßnahmen und Techniken begegnet. Das sich darüber alle Geister streiten und das Pendel im letzten Jahrzehnt immer mehr und einseitig in Richtung Sicherheit und Ordnung ausgeschlagen ist, dürfte klar sein.

So mag auch ein Projekt wie das "Cyber Genome Programm" wie viele ähnliche Programme nur ein zweckmäßiger Ansatz zur Bekämpfung des "Cyber-Bösen" sein, wenn es nicht schon aufgrund seiner nebulösen Umschreibung nach Dingen wie Techniken zur "Online-Durchsuchung", der Deep Packet Inspection Durchleuchtung in Systemen wie Einstein, dem Durchsieben des Netzwerkverkehrs mit Überwachungsprogrammen, der Nutzeridentifizierung oder der IP-Spurverfolgung stinken würde. Zumal, wenn eine eine Behörde des US-Militärs, das sich auf dem Gebiet der "Sammlung, Identifizierung, Charakterisierung und Einordnung" biometrischer Merkmale sehr engagiert zeigt, davon anfängt, Begriffe und Techniken der DNA- und Genom-Analyse auf uns und unsere Daten zu übertragen.

Siehe auch:
NewScientist - A telescope that sets its sights on cyber-crime (04.02.2010)
Federal Computer Week - DARPA: Calling all cyber geneticists (29.01.2010)
Federal Computer Week - DARPA eyes digital fingerprints to track computer attacks (26.01.2010)
Heise - Europäischer Polizeikongress: Deutschland stellt sich der Cyber-Herausforderung (02.02.2010)

Gerüchte zu Skype von der Counter Terror Expo

nospam@example.com (Kai Raven) — Thu, 12 Feb 2009 16:19:18 +0100

Etwas aus der Gerüchteküche zur VoIP Lösung Skype auf der gerade in London stattfindenden "Counter Terror Expo '09" liefert uns heute der Register Beitrag NSA offering 'billions' for Skype eavesdrop solution. Wie es in dem Beitrag heißt, habe ein CEO eines Unternehmens, das den Geheimdiensten Equipment zuliefert, gesteckt, dass die NSA wie auch andere Geheimdienste und Polizeibehörden so genervt von der P2P Weiterleitung der Gespräche und der Verschlüsselung mit Ebays Skype sei, dass die NSA in der Szene mit dem Angebot hausieren würde, der Firma, die der NSA eine Lösung anbieten könne, um jedes Skype Gespräch abzufangen (sonst hätte es ja keinen Sinn) und die Verschlüsselung zu knacken, mit Milliarden reich belohnen würde.

Nun ja, das Gerücht wäre genauso gut als Versuch geeignet, den Glauben der Skype-Nutzer an den Schutz ihrer Gespräche weiter zu schwächen. Etwas fies merkt der Register an, dass sich doch Ebay selbst den "Bonus" für ein NSA Backdoor in die Tasche stecken könnte. Gar nicht so abwegig, wenn man sich anschaut, wie Ebay und Skype in China agiert.

No De-Mail

nospam@example.com (Kai Raven) — Wed, 04 Feb 2009 15:09:20 +0100

Zur "De-Mail", den sogenannten "Bürgerportalen", dem "Datensafe", dem damit verbundenen elektronischen Personalausweis (ePA) mit dessen elektronischer Identifizierungsfunktion (eID) habe ich u. a. in den Beiträgen E-Gov 2.0 Perso 2.0 für Big Brother 2.0, Elektronische Ausweise und Portale für den kontrollierten Portalbürger, Gesetzentwurf zu elektronischem Personalausweis und elektronischer Identifizierung oder Bitte halten Sie Ihren ePA an das Lesegerät mehr als genug geschrieben und ihnen auch nichts weiter hinzuzufügen.

Zum heutigen Beschluss des Gesetzentwurfs zur Regelung von Bürgerportalen und zur Änderung weiterer Vorschriften des Bundesinnenministeriums durch die Bundesregierung, erklärte unser Bundesinnenminister in der Pressemitteilung des BMI:

"Mit De-Mail wollen wir für alle Bürgerinnen und Bürger eine einfache Möglichkeit schaffen, im Internet zuverlässig, sicher und vertraulich zu kommunizieren. Jede und Jeder soll in die Lage versetzt werden, sich gegen unerwünschtes Mitlesen, Diebstahl wichtiger Daten, Betrug im Internet und gegen Spam besser zu schützen. De-Mail steht für Fortschritt, IT und IT-Sicherheit made in Germany."

Ich erkläre dagegen, dass ich Euren ePA mit RFID Funkchip, biometrischer Erfassung, eID und Eure "De-Mail Infrastruktur" nicht benötige, denn mit TLS/SSL verschlüsseltem Versand und Erhalt meiner E-Mails für den Transport, der Anwendung von OpenPGP für die Inhaltsverschlüsselung und dem Gebrauch von Tor, I2P Mail und Remailern kann ich genauso gut und dazu weniger kontrolliert "zuverlässig, sicher und vertraulich" per E-Mail ohne "unerwünschtes Mitlesen" kommunizieren. Wenn es sein muss, auch per S/Mime, aber hier kamen nie S/Mime verschlüsselte E-Mails an. Ich brauche genauso wenig wie die Anti-Spam "Features" bei irgendwelchen E-Mail Providern Euer "De-Mail" Anti-Spam System, um von Spam unbelastet meine E-Mails und Mailinglisten zu lesen. Und schon gar nicht brauche ich irgendeinen "Datentresor" bei irgendeinem Bürgerportal-Provider, denn ich verlasse mich lieber auf meine eigene Datensicherung und -verschlüsselung.

Insbesondere, wenn solche Angebote von den gleichen Leuten kommen, die Vorratsdatenspeicherung, das BKA-Gesetz, das BSI-Gesetz und all die anderen Sicherheitsgesetze verbrochen haben.

Das Einzige, was ich damit nicht kann, ist der Erhalt und Versand von E-Mails mit Verschlüsselung und Signaturen durch "rechtssichere" Zertifikate. Aber sollte ich die eines Tages benötigen, würde ich mir lieber eine Signaturkarte und ein Lesegerät kaufen, als mir Euren ePA und Eure "De-Mail" andrehen zu lassen, wenn es sie dann noch gibt oder sie erlaubt sind. Ihr werdet schon alles daransetzen, dass die "De-Mail" und "ePA" Verweigerer irgendwann direkt oder indirekt diskriminiert werden.

Die rhetorische Frage "Geht mit De-Mail die E-Post ab?", die Ihr durch Euren "Bundes-CIO" ausrichten lasst, beantworte ich deshalb für mich ganz einfach mit:

Siehe auch:
Bundesbeauftragter für Datenschutz / Informationsfreiheit - Schaar sieht Verbesserungsbedarf beim Bürgerportalgesetz (04.02.2009)
beck-Blog - Entwurf zum Bürgerportalgesetz liegt vor: De-Mail für Alle soll pro Jahr bis zu 1,4 Mrd € sparen (04.02.2009)
sicherheitsblog - Das Bürgerportalgesetz: De-Mail im Detail (04.02.2009)
BMI - De-Mail geht in die Testphase: So einfach wie E-Mail und so sicher wie die Papierpost (08.10.2009)

P.S.: Da nicht alle den Links folgen: Die obige Grafik ist ohne "No" Bestandteil der BMI-Pressemitteilung zum Beschluss des Bürgerportal-Gesetzes.

TrueCrypt, Backups, Rettung und ein DAU

nospam@example.com (Kai Raven) — Sat, 31 Jan 2009 12:51:34 +0100

Eine kleine Story zu TrueCrypt (unter Windows), Backups und warum man sich ein paar Gedanken machen sollte.

Gestern war es dann endlich so weit. Nach einem Start und mehrmaliger Eingabe des TrueCrypt Passworts kam das, was im TrueCrypt Manual so beschrieben wird: "If you repeatedly enter the correct password but TrueCrypt says that the password is incorrect, it is possible that the master key or other critical data are damaged". In diesem Fall muss die TrueCrypt Rettungs-CD zum Einsatz kommen, um die Schlüsseldaten wiederherzustellen, die während der Systemverschlüsselung über ein ISO Image erstellt und gebrannt werden kann. "Kann" – denn man kann das Image auch mit einem der Tools für virtuelle Laufwerke auf eine virtuelle CD schreiben, wie das einige Nutzer machen, die der Brennvorgang nervt. Ich nehme als Tool die bekannten Daemon Tools (ohne Adware) und hatte das auch so gemacht. Das ISO Image hatte ich in TrueCrypt Containern auf USB-Stick und Partition gespeichert, aber mit dem Hintergedanken, das bei Bedarf zu brennen, nicht gebrannt. Ein falscher Hintergedanken, wenn man nur einen CD/DVD Brenner im Rechner hat.

Zum Beginn der Beschäftigung mit und dem Einsatz von TrueCrypt hatte ich mir außerdem überlegt, wie man für Windows und TrueCrypt Backups und/oder Images machen kann, die selbst wiederum mit TrueCrypt gesichert sind, denn verschlüsselte Partitionen und unverschlüsselte Backups/Images sind unsinnig und deshalb auch in ein paar Webforen nachgelesen, wie es andere Nutzer damit halten. Dafür gibt's verschiedene Vorgehensweisen. Meine ist folgende:

Ich habe eine WD SATA Festplatte in dem externen MX-1 Gehäuse von Antec, mit dem ich übrigens sehr zufrieden bin. Auf der befinden sich wie auf der internen Festplatte TrueCrypt verschlüsselte Partitionen. Eine Windows BartPE/XPE Boot-CD enthält das Image-Programm TrueImage von Acronis, TrueCrypt und verschiedene andere Sachen. Mit der boote ich regelmäßig und entschlüssle/mounte mit TrueCrypt die Partitionen auf der externen Festplatte. Dann werden von interessierenden Partitionen der internen Festplatte mit TrueImage Images ohne Komprimierung und die Acronis eigene Verschlüsselung in die TrueCrypt Partitionen auf der externen Festplatte erstellt, damit es schnell geht. Für die verschlüsselte Systempartition gibt es zwei "TrueImages" in zwei TrueCrypt Partitionen: Eines per "Sektor-für-Sektor" der Systempartition im verschlüsselten Zustand in die eine externe TrueCrypt Partition und eines nach gemounteter Systempartition ohne Pre-Boot Authentifizierung, bei dem der entschlüsselte Inhalt komplett in das Acronis Image auf der anderen externen TrueCrypt Partition gespeichert wird. Da sich das erste Image bereits im verschlüsselten Zustand befindet, könnte man das Image auch auf einer unverschlüsselten Partition ablegen, das zweite Image dient dazu, zumindest und immer an Daten zu kommen, wenn es mit dem ersten Image nicht hinhaut.

Eigentlich unverzeilich, bin ich diesem Schema gefolgt, ohne jemals selbst ausprobiert zu haben, ob eine Wiederherstellung mit Acronis, dessen Images, der Boot-CD und TrueCrypt überhaupt funktioniert, weil diverse Leute ausführlich berichtet hatten, dass es funktioniert. Man sollte sich aber trotzdem nicht darauf verlassen.

Der zweite DAU Fehler war, wie bereits angedeutet, die nicht gebrannte TrueCrypt Rettungs-CD, denn mit dem nachträglichen Brennen wurde es nichts über meine BartPE/XPE und eine Knoppix-CD, denn mit nur einem Laufwerk muss man natürlich die Boot-CD mit einem Rohling wechseln und danach ging nichts mehr mit Brennen – falls es da nicht eine Vorgehensweise oder einen Trick gibt, der mir nicht eingefallen ist. Damit auch keine Möglichkeit, das beschädigte Schlüsselmaterial wiederherzustellen.

Um mir zu behelfen und zum Brennen zu kommen, habe ich dann ein weiteres Image der aktuellen unzugänglichen Systempartition erstellt, wieder per Sektor-für-Sektor. Danach habe ich das alte Acronis Image der Systempartion wiederhergestellt, das per Sektor-für-Sektor erzeugt wurde. Für diejenige, die das auch so mit Acronis machen wollen oder müssen: Man muss wiederum die Sektor-für-Sektor Methode aktivieren, dann zuerst die Partition und als weitere "Partition" den MBR auswählen. Danach löscht Acronis zuerst die existierende Partition, stellt sie aus dem Image wieder her und danach wird der MBR wiederhergestellt.

Danach kam der Zeitpunkt, ob das alles so klappt mit der Vorgehensweise und den Acronis Images. Nach einem Neustart ging es aber wie gewohnt mit der TrueCrypt Pre-Boot Authentifizierung nebst Entschlüsselung der Systempartition und erfolgreichem Booten des "alten" Windows weiter – die zu späte Bestätigung der Vorgehensweise. Mit dem "alten" Windows habe ich dann das ISO Image der TrueCrypt Rettungs-CD auf eine CD-RW gebrannt und danach den ganzen Zauber erneut durchgeführt, sprich Booten mit der BartPE/XPE CD, Wiederherstellen des Images der unzugänglichen Systempartition mit Acronis, Einlegen der TrueCrypt Rettungs-CD, Neustart und Reparatur des TrueCrypt Schlüssels der Systempartition mit der Restore Key data Funktion im Menü der Rettungs-CD. Tja und danach war wieder alles in Butter. Abgesehen von der rot angelaufenen Stirn aufgrund der Zusammenstöße mit dem Schreibtisch

Paperkey für das GnuPG Schlüssel-Backup

nospam@example.com (Kai Raven) — Fri, 23 Jan 2009 12:31:34 +0100

Für die GnuPG Anwender, die es benötigen.

David Shaw, einer der Entwickler im GnuPG Team, hat für *nix und Windows Version 1.0 des Paperkey Programms veröffentlicht.

Um ein Backup des eigenen Schlüsselpaares in Datenform zu pflegen, kann man entweder die Schlüsselringdateien komplett als Kopie oder den geheimen Schlüssel als Datei exportieren und ihn auf einem Datenträger speichern. Da ein Datenträger verloren gehen, beschädigt werden oder nach längerer Zeit seine Lesbarkeit verlieren kann, ist es ggf. sinnvoll, für ein zusätzliches Backup auf das gute alte Papier und Drucker auszuweichen.

Um ein Backup des eigenen Schlüsselpaares in Papierform anzulegen, könnte man einfach den geheimen Schlüssel mit ASCII Hülle exportieren und den Inhalt ausdrucken. Zum späteren Wiederherstellen des Schlüsselpaars kann dann der Ausdruck entweder per OCR eingelesen oder abgetippt und das Ergebnis wieder mit GnuPG importiert werden. Der Nachteil bei dieser Methode ist die Menge an Zeichen, die der Export enthält, denn darin ist alles enthalten, was einen Schlüssel ausmacht, inklusive des öffentlichen Schlüsselmaterials.

Das bedeutet, dass sich der Ausdruck unter Umständen auf mehrere Seiten Papier verteilt bzw. die Schriftgröße stark verkleinert werden muss und sich damit die Wahrscheinlichkeit erhöht, dass sich beim Einlesen und Abtippen Fehler einstellen und deshalb eine Wiederherstellung fehlschlägt.

Hier setzt Paperkey an, das aus dem exportierten geheimen Schlüssel in Binärform nur die relevantesten Anteile extrahiert und sie ebenfalls in ASCII Zeichen auswirft, die dann zu einem komprimierten Ausdruck auf Papier führen, der viel besser zur späteren Wiederherstellung geeignet ist. Zur vollständigen Wiederherstellung des Schlüsselpaars ist neben dem eingelesenen oder abgetippten Ausdruck der öffentliche Schlüssel nötig, der sich bei den meisten GnuPG Anwendern auch nach einem Schlüsselverlust auf einem Schlüsselserver befindet, auf einer Webpage angegeben wird oder in anderer Form bereits existiert.

Zu Paperkey gibt es eine kurze Anleitung, die aber nicht vollständig ist und zu keinem vollständigen Ergebnis führt, deshalb hier die "vollständige" Version:

Erstellung des Paperkey Backups

Export des geheimen Schlüssels in Binärform in die Datei SchlüsselIDsec:

gpg -o SchlüsselIDsec --no-armor --export-options no-export-clean,export-minimal --export-secret-keys Schlüssel-ID
Erzeugung der komprimierten Version der relevanten Schlüsselbestandteile des geheimen Schlüssels für den Ausdruck:

paperkey --secret-key SchlüsselIDsec --output SchlüsselIDpaper.txt

Für meinen zurückgezogenen Schlüssel 0x0A146804 reduziert sich das auf folgenden Output:
```
# Secret portions of key 5AB6B450D8CC132B80B17F24431C6A350A146804
# Base 16 data extracted Fri Jan 23 10:21:51 2009
# Created with paperkey 1.0 by David Shaw

# File format:
# a) 1 octet:  version of the paperkey format (currently 0).
# b) 1 octet:  OpenPGP key version (currently 4)
# c) n octets: Key fingerprint (20 octets for a version 4 key)
# d) 2 octets: 16-bit big endian length of the following secret data
# e) n octets: secret data: an OpenPGP secret key or subkey as specified in
#              RFC 4880, starting with the string-to-key usage octet and
#              continuing until the end of the packet.
# Repeat fields b through e as needed to cover all subkeys.
# To recover, use the fingerprint to match an existing public key with the
# corresponding secret data, then append field e to the public key to
# create a secret key.
# Each base 16 line ends with a CRC-24 of that line.
# The entire block of data ends with a CRC-24 of the entire block of data.

  1: 00 04 5A B6 B4 50 D8 CC 13 2B 80 B1 7F 24 43 1C 6A 35 0A 14 68 04 0C08F6
  2: 00 53 FE 0A 03 08 24 28 E0 0F 13 57 BB 10 60 3B 5B 31 C9 7B F3 69 08B4F5
  usw.
 17: 4B AD 65 E2 E9D940
 18: 5B7490
```
Das ist doch im Gegensatz zur anfangs erwähnten Methode erheblich weniger, gut einzulesen und zur Not auch gut abzutippen. Genauso wie beim tatsächlichen geheimen Schlüssel ist auch die Ausdruckversion durch die Passphrase geschützt, denn natürlich ist die Verschlüsselung durch die Passphrase und den gewählten symmetrischen Algorithmus ebenfalls Bestandteil im Ausdruck.

Ist die Passphrase nicht im "Susi" Style gewählt, sondern ausreichend lang, in ihrer Zusammensetzung ausreichend komplex und ein starker symmetrischer Algorithmus gewählt, kann auch ein Ausdruck in die Hände der Möchtegern-Cracker des BKA, BND oder anderer Geheimdienste fallen, wenn es sich nicht verhindern lässt. Sollte man spätestens seit Annes Story mit dem PGP Schlüssel wissen und beherzigen. Wer es etwas paranoider haben möchte und sich selbst im Umgang mit GnuPG nicht vertraut, kann ja noch eine symmetrische Verschlüsselungsschicht um das Paperkey Backup legen und den Ciphertext ausdrucken (aber zusätzliche Passphrase nicht vergessen!)

gpg --cipher-algo TWOFISH --s2k-digest-algo SHA256 -ac SchlüsselIDpaper.txt
Die SchlüsselIDpaper.txt Datei ausdrucken, den Ausdruck abheften, verbuddeln, verstecken usw. und danach wie die SchlüsselIDsec Datei "rückstands- und spurenlos" löschen, wie es immer so schön in den Sicherhheitsgesetzen heißt.

Wiederherstellung des Schlüsselpaares mit Paperkey

Davon ausgehend, dass man nicht mehr über die GnuPG Schlüsselring- oder Schlüsseldateien verfügt, wird der eigene öffentliche Schlüssel über die oben genannten Quellen bezogen.
Da der öffentliche Schlüssel meistens in ASCII Form vorliegt oder erhalten wird, konvertiert man die Datei mit dem öffentlichen Schlüssel in seine Binärform:

gpg --dearmor SchlüsselID.asc (mit SchlüsselID.asc.gpg als Resultat)
Wiederherstellung des geheimen Schlüssels in seine Binärform mit dem Paperkey "Ausdruck" (entweder bereits auch als Datei vorliegend oder eingelesen/abgetippt) und dem öffentlichen Schlüssel:

paperkey --pubring SchlüsselID.asc.gpg --secrets SchlüsselIDpaper.txt --output SchlüsselIDsec
Import der Dateien mit dem geheimen und öffentlichen Schlüssel:

gpg --import --import-options no-import-clean,import-minimal SchlüsselIDsec
gpg --import --import-options no-import-clean,import-minimal SchlüsselID.asc.gpg
Vetrauenswert für eigenen Schlüssel wiederherstellen und aktuelle Fremd-Zertifikate von Schlüsselserver importieren:

gpg --edit-key SchlüsselID
trust
5

gpg --refresh-keys SchlüsselID

Danach kann das Schlüsselpaar wie gewohnt mit GnuPG genutzt werden. Die Vorgehensweise habe ich auch mit einem aktuell aktiven Schlüssel anwenden können.

Die --*armor Option, Import- und Export-Optionen dienen dazu, jenseits möglicher Optionen, die bereits in der gpg.conf vom Nutzer oder anderen Programmen gesetzt wurden, doppelte Zertifikate im Schlüssel zu vermeiden und die für Paperkey benötigte Binärform anzuwenden. Die Änderung des Vetrauenswerts des Schlüssels nach Wiederherstellung kann unterbleiben, wenn zuvor beim Export/Backup des geheimen Schlüssels auch die Vetrauenswerte mit gpg --export-ownertrust > mytrust.asc exportiert wurden, so dass sie nach Wiederherstellung des Schlüssels mit gpg --import-ownertrust mytrust.asc wieder importiert werden können. Die Vetrauenswertedatei kann man natürlich ebenfalls als Backup ausdrucken.

RequestPolicy gegen CSRF für Mozilla Browser

nospam@example.com (Kai Raven) — Wed, 21 Jan 2009 11:16:44 +0100

Ich möchte Euch noch eine Erweiterung für Mozilla Browser vorstellen, mit der man eine weitere "Sicherheitsschicht" um die Browser legen kann.

Sie betrifft alle Anfragen und Verbindungen, die der Browser von einer Webpage einer Website, die aktuell aufgerufen wurde, zu einer anderen Website startet, um von der anderen Website Bilder, Skripte, eingebetten Frames usw. nachzuladen, die dann als Objekte der aktuell aufgerufenen Webpage angezeigt werden oder um Funktionen einer aktuellen oder fremden Webanwendung auszuführen und zu verändern, wobei beide Websites unterschiedliche Server betreffen können. Wurde die aufgerufene oder die andere Webpage/Website manipuliert oder dem Nutzer eine URL zu- und untergeschoben (z. B. über die beliebten Spam- und Phishing Mails), die manipulierte Websites aufrufen, kann das u. a. für die Cross-Site Request Forgery Angriffe (XSRF/CSRF & Co.) ausgenutzt werden.

Bei verschiedenen Angriffen spielen deshalb immer Anfragen eine große Rolle, die vom Nutzer unbemerkt im Hintergrund abgewickelt werden, wenn er sich eine Webpage "anschaut" und dortige Webanwendungen nutzt. Klar, könnte man auch ständig alle Anfragen selbst beobachten, überwachen und nachprüfen, aber das wäre beim alltäglichen Surfen kaum zu praktizieren. Hier setzt die RequestPolicy Erweiterung an, die ähnlich wie bei NoScript, RefControl und anderen Erweiterungen alle Anfragen gegen White- und Blacklist prüft. Nur das im Fokus der RequestPolicy Erweiterung die oben geschilderten Anfragen zu Domains fremder Websites stehen, während zum Beispiel mit NoScript das Verbeiten und Zulassen von Javascript, Plugins, iFrames usw. im Mittelpunkt steht, wobei auch NoScript mittlerweile verschiedene Schutzfunktionen gegen Cross-Site Anfragen und Scripting integriert hat, weshalb der Autor der RequestPolicy seine Erweiterung auch als Ergänzung zu NoScript sieht.

Zu RequestPolicy ein Beispiel von der Installation bis zur Anwendung anhand des letzten Beitrags im Weblog:

Nach der Installation zeigt RequestPolicy eine Auswahl von Standard-Whitelists an, die man aktivieren kann, um den Whitelists bereits vor dem Start Regelsätze hinzuzufügen, die Anfragen zu einem Zielrechner, von einem Ursprungsrechner oder zwischen einem Ursprungsrechner und einem fremden Zielrechner zulassen, weil sie als "sicher" gelten. Zum Beispiel enthält die "Europa und Russland" Whitelist die erlaubte Anfrage von der Domain (Quelle) "amazon.de" zu " images-amazon.com" (Ziel, von der für die Website von http://www.amazon.de/ Bilder geladen werden). Allerdings sind in den Whitelists nur die Hauptdomain und keine Subdomains erfasst. Wer zuerst generell alle Anfragen verbieten will, um sich selbst Whitelists aufzubauen, aktiviert keine Whitelist. Wer sich später entscheidet, doch eine der Whitelists zu nutzen, kann das später nachhholen.

In den Einstellungen kann man die grobe Überprüfung ("Base domain") weiter bis zur Überprüfung des Protokolls, der vollständigen Domain und des Ports verschärfen, um erlaubte Anfragen einzugrenzen. Für eine Whitelist Regel würde das zum Beispiel bedeuten, dass bei der ersten Stufe für Bilderanfragen von blog.kairaven.de zu hp.kairaven.de über http/https/ftp die Regel gelten würde: kairaven.de -> kairaven.de erlaubt, bei der letzten Stufe nur http://blog.kairaven.de/ -> http://hp.kairaven.de:80 erlaubt.

Das Bild (es könnte auch ein Javascript, ein CSS oder sonst was sein) wurde blockiert, weil es nicht von http://blog.kairaven.de, sondern von http://hp.kairaven.de stammt. Bei Bilddateien, die über Anfragen zu einer anderen Domain geladen werden, zeigt RequestPolicy einen Rahmen und beim Darüberfahren mit der Maus die Adresse der Zieldomain an.

Über das Kontextmenü des RequestPolicy Icons in der Statuszeile wird angezeigt, zu welchen fremden Domains/Adressen Anfragen ergehen sollen, die deshalb aufgrund der 3. Stufe zur Überprüfung blockiert wurden. Über das Kontextmenü und das Untermenü zu einer blockierten Anfrage kann man dann ähnlich wie bei NoScript die Anfragen von einer Quelle, zu einem Ziel oder zwischen Quelle und Ziel permanent oder temporär erlauben.

Die Entscheidung, die über das Kontextmenü getroffen wurde als Regel in der "Quelle-zu-Ziel" Whitelist.

Den größtmöglichen Sicherheitslevel für die Funktionen, die RequestPolicy bietet, der aber auch mit maximalem Einrichtungsaufwand einhergeht, erreicht man also, wenn keine vorkonfigurierte Whitelist und die höchste "Strictness" Überprüfung aktiviert, aber nur die "Quelle-zu-Ziel" Whitelist verwendet wird.

Die RequestPolicy Erweiterung kann über die Homepage der Erweiterung oder, da sie noch im Experimentalstadium ist, nach Login über die Firefox Add-ons Seite installiert werden. Wie man auf der Seite zu aktuellen und geplanten Features von PolicyRequest nachlesen kann, hat der Autor mit PolicyRequest viel vor. Wie gesagt ist sie noch experimentell. Andererseits besteht die Möglichkeit, dass Erweiterungen wie NoScript und AdBlock Funktionen von PolicyRequest übernehmen. Zu erwähnen ist auch, dass es neben PolicyRequest auf Firefox Add-ons eine Reihe anderer Erweiterungen gibt, die sich ebenfalls CSRF und XSS annehmen. Zu begrüßen wäre es, wenn in zukünftigen Mozilla Browsern die Funktionen einer Reihe von Sicherheits-Erweiterungen fest integriert würden, die sich als nützlich und absichernd erwiesen haben, denn die Liste der Erweiterungen, mit denen man seinen Browser zusätzlich absichern muss, wird immer länger.

Da es sich anbietet, hier mal wieder das beliebte Spiel "Zeigst Du mir Deine Erweiterungen, zeig ich Dir meine". Aktuell installierte Erweiterungen, dir direkt oder indirekt der Sicherheit, dem Datenschutz und Anonymisierung dienen:

Via:
ha.ckers Blog - RequestPolicy Firefox Extension

Ein FlashGot-Wget "Download-Manager" für Firefox

nospam@example.com (Kai Raven) — Tue, 20 Jan 2009 11:30:06 +0100

Bisher nutzte ich unter Windows für Downloads mit Firefox immer die FlashGot Erweiterung (vom Programmierer stammt auch NoScript) mit dem Free Download Manager, der Feedreader brachte auch noch seinen eigenen Download-Manager für Podcasts, Movies usw. mit. Mal direkt oder über Tor, I2P und JonDonym für anonymisierte Downloads. Die beiden Download-Manager hatten die meiste Zeit nichts zu tun und so etwas gefällt mir nicht. Auch wenn ich mir bei den niedrigen Speicherpreisen jetzt den Arbeitsspeicher aufgerüstet habe, um demnächst etwas mit Virtualisierung herumzuspielen.

Da ich Wget in der Konsole ebenso gerne für Downloads nutze und es zu dessen Einbindung in FlashGot auf der Features Seite ein Beispiel gab (was mir nicht ausreichte), habe ich mir mit ein paar Batchdateien, der Wget Portierung des GnuWin32 Projekts und ein paar weiteren Sachen einen minimalen Wget "Download-Manager" gebastelt, der dann im FlashGot Kontextmenü von Firefox so aussieht:

Die "NoProxy" Menüeinträge rufen, wie der Name schon sagt, Wget für den Download ohne Proxy und Weiterleitung an Tor, I2P oder JonDonym auf, bei den "Proxy" Menüeinträgen werden Downloads über den Privoxy Proxy und ggf. einen Anondienst abgewickelt, für FTP Downloads statt Privoxy über JonDonym, da Privoxy kein FTP unterstützt.

"NoSSLcheck" ist für SSL/TLS verschlüsselte Downloads von Servern da, die nur selbst signierte Zertifikate anbieten und deshalb nicht gegen die CA-Zertifikate geprüft werden können bzw. bei CA-Zertifikaten, die man noch nicht einer Datei mit einem Paket aller CA-Zertifikate hinzugefügt hatte, aber wo man trotzdem etwas herunterladen möchte.

Aufruf mit "Wget-Proxy", Download über Privoxy und Tor. Erfolgreicher Download, da Wget das Server-Zertifikat nach Prüfung gegen das CA-Zertifikat anerkannt hat.

Aufruf mit "Wget-Proxy", Download über Privoxy und Tor. Abbruch des Downloads, da der Server nur ein selbst signiertes Server-Zertifikat anbietet, das nicht gegen ein CA-Zertifikat geprüft werden kann.

Aufruf mit "Wget-Proxy-NoSSLcheck", Download über Privoxy und Tor. Kein Abbruch des Downloads, da Wget angewiesen wurde, das Server-Zertifikat nicht zu überprüfen.

Bei Menüeinträgen ohne "NoSSLcheck" werden immer Server-Zertifikate gegen die CA-Zertifikate geprüft und deshalb ein Download abgebrochen, wenn etwas nicht mit den Host- und Zertifikatangaben stimmt. Was aufgrund von Angriffsmöglichkeiten und Schlampereien bei den CAs auch nicht unbedingt eine Garantie bietet, wie man immer wieder erfahren muss.

Natürlich kann man die Liste beliebig für weitere Zwecke und Funktionen von Wget erweitern.

Für die Datei mit dem Paket aller CA-Zertifikate habe ich mich der Zertifikatespeicher der Browser und OpenSSL bedient. Man kann natürlich auch selbst alle CA Sites absurfen und sich die Zertifikate selbst besorgen und "behandeln". Weitere Methoden werden in der readme Datei genannt.

Falls es jemanden interessiert oder für diejenigen, für die das Ganze nützlich sein könnte, habe ich die Batchdateien und eine eingerichtete wgetrc Datei in ein Archiv gepackt. In der readme Datei steht auch alles Weitere ausführlich erklärt. Verbesserungsvorschläge und Tipps sind wie immer willkommen.

Vermutlich kommen ein paar Leser angerannt, die mir sagen wollen, das sei alles zu kompliziert und Download-Manager XY viel besser, schöner, bunter und mächtiger. Aber genau die wollte ich eben nicht. Was die Wget Geschichte nicht kann – wie zum Beispiel der Free Download Manger, ist die automatische Konvertierung von Filmchen, die man bei YouTube herunterlädt. Aber dafür gibt es dann auch wieder einfache Tools.

Siehe auch:
WackGet