Datenhaufen zu IT und Elektronik.

Kategorie: IT-Security (Seite 15 von 15)

Notizen & Praxis zur IT-Sicherheit – von Responsible Disclosure bis Härtung.

CAcert Nokia

CAcert.org Root Zertifikate unter Nokia S40 und S60 installieren.

Ich habe ein Nokia 6300i. Dieses Gerät tut alles genau so wie ich es benötige. Nur eine Kleinigkeit hat mich gestört.

Immer wenn ich versuche E-Mails von meinem IMAP-Server zu saugen oder E-Mails über meinen SMTP-Server zu verschicken, wird das jeweilige Zertifikat (SSL / TLS) als ungültig gemeldet. Was daran liegt, das ich diese beiden Zertifikate von CAcert habe unterschreiben lassen. Es müssen also die Root-Zertifikate (http://www.cacert.org/index.php?id=3) ins Mobiltelefon!

Natürlich habe ich sofort versucht die Zertifikate ins Gerät zu bekommen. Leider scheiterte es immer an der Meldung: „Dateiformat nicht unterstützt“. Daraufhin habe ich viele und lange sinnlose E-Mails mit dem Nokia-Support getauscht. Leider ohne erfolg. Ich habe das weiter unten mal zusammengeschrieben, hier nun erstmal der genaue Weg die Zertifikate ins Handy zu bekommen:

Zuerst auf dem Rechner eine HTML-Datei mit folgendem Namen erstellen: cert.html

Der Inhalt sollte ca. so ausschauen:

—– HTML-schnipp —–
<?xml version=“1.0″?><!DOCTYPE html PUBLIC „-//WAPFORUM//DTD XHTML Mobile 1.0//EN“ „http://www.wapforum.org/DTD/xhtml-mobile10.dtd“><html xmlns=“http://www.w3.org/1999/xhtml“><head><title>Installing CAcerg.org<br>Root Certificate</title></head><body><p><a href=“root.cer“>Installing Class1 PKI Key</a><br><br><a href=“class3.cer“>Installing Class3 PKI Key</a><br><br><a href=“https://www.kernel-error.de“>Und nun testen..</a></p></body></html>
—– HTML-schnapp —–

Dann die beiden Zertifikate von CAcert.org herunterladen. Einmal das class1 und einmal das class3, jeweils im PEM format.

Diese müssen nun konvertiert werden, ich nutze dafür openssl:

openssl x509 –in root.crt –inform PEM –out root.cer –outform DER

openssl x509 –in class3.crt –inform PEM –out class3.cer –outform DER

Jetzt müssen die Dateien (cert.html, root.cer und class3.cer) ins gleiche Verzeichnis ins Mobiltelefon kopiert werden.

Dort nun übers das Telefonmenu hinklicken und die cert.html öffnen.

Galerie auf dem Nokia 6300i Der Ordner Empfangene Dateien auf dem Nokia 6300i Ordnerinhalt Empfangene Dateien Nokia 6300i

Wenn sich diese geöffnet hat einfach die Links von oben nach unten durchklicken und die jeweiligen Zertifikate speichern.

cert.html Installationsdatei der CAcert Zertifikate

Das ist dann schon alles…. Fertig!

CAcert im Nokia

Hier nun der zusammengeschriebene Teil vom Nokiasupport.

—– NokiaCare schnipp —–
Wir möchten Ihnen mitteilen, dass das X.509 Zertifikat umgewandelt werden muss, bevor Sie es auf Ihr Nokia 6300i übertragen können. Ihr Nokia 6300i unterstützt .p12 Zertifikate.
—– NokiaCare schnapp —–

P12 klang für mich nicht sinnig, probiert habe ich es denn noch… Ohne erfolg! Daher wieder eine E-Mail an den Support, vielleicht muss es ja irgendwo gesondert hin oder sonst was…

—– NokiaCare schnipp —–
Bitte kopieren Sie das *.12 Zertifikat mit der PC Suite auf Ihr Mobiltelefon. Die Datei muß nicht in ein spezielles Verzeichnis kopiert werden. Die Datei wird automatisch von MfE verarbeitet.
—– NokiaCare schnapp —–

Alles klar… geht nicht immer noch die Meldung: „Dateiformat nicht unterstützt“ Lieber noch einmal nachfragen und mein Problem deutlicher erklären!

—– NokiaCare schnipp —–
Übertragen Sie die Datei auf das Mobiltelefon, gehen Sie in den Dateimanager und rufen Sie die Datei auf, dies installiert sich dann automatisch.
—– NokiaCare schnapp —–

Das funktioniert so nicht… Zu dem brauche ich kein Benutzerzertifikat sonder das einer CA…. Noch eine E-Mail an Nokia!

—– NokiaCare schnipp —–
Um private Schlüssel importieren zu können, erstellen Sie bitte eine *.p12-Datei. Diese enthält Ihren privaten Schlüssel und das Benutzerzertifikat. Diese Datei importieren Sie bitte in Ihr NOKIA Mobiltelefon. Dort wird das Zertifikat automatisch erkannt. Zur Speicherung folgen Sie bitte den Hinweisen des Telefons. Nun werden Sie zur Eingabe eines Sicherheitscodes aufgefordert. Beachten Sie bitte dabei, dass die geforderte Sicherheitseingabe ausschließlich aus Ziffern bestehen darf. Das geforderte Passwort wird durch die Zertifizierungsstelle erstellt.
—– NokiaCare schnapp —–

Ich scheine nicht im Stande zu sein mein Problem verständlich in eine E-Mail zu packen! Ich beschließe eine weitere E-Mail zusammen mit meiner Frau zu schreiben (diese entspricht dem durchschnittlichen PC-User)! Und hier ist Nokias Antwort:

—– NokiaCare schnipp —–
Scheinbar haben wir uns bei Ihrem angegebenen Telefonmodell verlesen.Ihr NOKIA 6300i ist ein Gerät der Serie 40. Die Angaben die wir Ihnen gemacht haben, beziehen sich auf S60 Geräte.Dafür möchten wir uns entschuldigen. Sie sollten das entsprechende Zertifikat im Format DER konvertieren und erneut wie angegeben auf Ihr NOKIA Mobiltelefon übertragen.Es sollte sich nun installieren lassen. Wir wünschen Ihnen viel Freude mit den Produkten aus unserem Haus.
—– NokiaCare schnapp —–

Verlesen? Was habe ich denn noch gleich geschrieben *nachschau*

—– Meine Mail schnipp —–
[Country: Germany]

[Language: German]

[Permission to Email: ]

[Permission to SMS: ]

[Permission to Letter: ]

[Permission to Phone: ]

[First name: van de Meer ]

[Last name: Sebastian]

[Street address: Alte Bergstr. 12]

[ZIP: 45549]

[City: Sprockhövel]

[Email address: kernel-error@kernel-error.de]

[Landline: +49 02324 6858622]

[Mobile: +49 0177 5995900] ]

[Phone model: Nokia 6300]

[IMEI: ]

[Shop number: ]

[CID: ]

[Contact topic: Nokia Mobiltelefone und Zubehör]

[Message: Sehr geehrte Damen und Herren,  wie lassen sich weitere X.509 Root Zertifikate einer CA in meinem 6300i importieren? Mit besten Grüßen  S. van de Meer]

[Operator: E-plus]

[Operating system: Linux]
—– Meine Mail schnapp —–

Öhm… egal! Ich probiere es mal (auch wenn ich das natürlich schon probiert habe)!

Komisch immer noch die gleiche Meldung: „Dateiformat nicht unterstützt“

—– NokiaCare schnipp —–
Bezüglich Ihrer Anfrage möchten wir Ihnen mitteilen, dass Sie das DER-typ X509v3 Zertifikat für Ihr S40 Handy benötigen. Sie müssen das CER (Base64) Zertifikat ins DER (binary Format) konvertieren.
—– NokiaCare schnapp —–

Da ich genau das schon probierte habe ich an diesem Punkt die Zusammenarbeit mit dem Nokia Support aufgegeben! Ich habe nun begonnen herumzubasteln und zu testen! Der installierte Opera wird auf dem Gerät zum Browsen benutzt, scheint aber nicht wirklich etwas mit der Systemeigenen CA-Liste zutun zu haben (wie sein großes Vorbild halt). Daher bringt es mir auch nichts mit dem Teil auf irgendwelchen Webseiten herumzufummeln. Irgendwann habe ich mal probiert welche Formate unterstützt werden. Interessanterweise ging bei HTML nicht der Opera auf, sondern der „systemeigene“ Browser. An dieser Stelle ist mir dann die oben stehende Idee gekommen!

SSH/OpenSSH

SSH (SecureShell) ist inzwischen sehr verbreitet. Es hat bzw. sollte Telnet überall ersetzt haben. SSH nutz eine Verschlüsselung um zwischen zwei Rechnern Daten auszutauschen. SSH kann aber noch vieles mehr. Z.B. kannst du mit scp einfach, schnell und sicher Dateien von einem Rechner auf einen anderen Kopieren.

scp dateien user@rechner:/pfad

Du kannst aber auch X-Weiterleitungen sehr einfach realisieren. Hierzu musst du einfach in deine sshd_config folgende Option auf yes setzten.

X11Forwarding yes

Mal angenommen du besitzt ein altes (SEHR) altes Notebook. Dieses Notebook hat gerade noch genug Leistung zum Hochfahren und starten des X-Servers. Dieses Notebook könntest du jetzt als eine Art X-Terminal benutzen. D.h.: du tipperst ein:

ssh -X rechner

in deine X-Konsole und meldest dich nun mit deinen Usernamen an einem Zweitrechner in deinem Netzwerk an, welcher etwas mehr Leistung hat und auch gleich noch die Programme installiert sind, mit denen du jetzt gerne auf dem Notebook arbeiten willst. Du tipperst nach der Anmeldung also ooffice oder was du halt gerade brauchst ein. Darauf bekommst du dann nur die GUI auf dein Notebook. Die gesamte Datenverarbeitung und Rechenleistung für das genutzte Programm kommt nun vom anderen Rechner.

Bist du mal über eine sehr schwache Leitung an dein System angeschlossen kann dir die Option -C sehr helfen. Diese sorgt dafür das der gesamte Datenstrom komprimiert wird. So ist die zu übertragende Datenmenge kleiner und alles sollte flotter gehen.

ssh -C rechner

Wie sicher ist dieses SSH denn nun?

Man kann sagen, recht sicher. Es gibt natürlich keine absolute Sicherheit und es hängt auch immer ein großer Teil vom User und der Konfiguration ab.

Du solltes also einige Punkte in der Konfiguration seines SSH-Servers ändern. Diese liegt fast immer unter: /etc/ssh/ und schimpft sich sshd_config!

– Nur SSH2
Das SSH1 Protokoll gilt als unsicher. Programme wie z.b.: ettercap sind in der Lage hier Kennwörter und Usernamen herauszulesen. Zu dem bietet SSH2 eine ganze Stange mehr an Möglichkeiten. Daher sollte nur das Protocol 2 genutzt werden.

Protocol 2

– Root-Login is nicht

Der User Root braucht keinen direkten Login. Wer wirklich von extern auf seinem Rechner administrieren will der kann als User auch su oder sudo benutzen. Da SSH2 wohl kaum zu entschlüsseln ist, wird ein Angreifer es meist mit Brute Force versuchen. Er braucht zu dem Kennwort welches er damit bekommen möchte erst mal einen Usernamen. Da er Root haben will und dieser wohl auch immer auf einer Linux-Kiste zu finden ist, wird er es auch auf diesen Account probieren. Verbieten wir jetzt aber den Login für den User Root kann der Angreifer es sehr lange Probieren 😛

PermitRootLogin no

– Kein User/Passwort verfahren

Die Geschichte mit dem Brute Force hatten wir ja jetzt. Was aber wenn der Angreifer einen Usernamen von unserem System kennt. Dann ist es erstmal nur noch eine Frage der Zeit. Tja und da die meisten User keine „guten“ Passwörter haben….. Viel besser ist es wenn der User ein Zertifikat hat, mit welchem er sich anmelden darf. Weiter unten zeige ich wie es gemacht wird. Hier aber erstmal das User/Passwort verfahren verbieten!

PasswordAuthentication no

Das Public-Key-Verfahren (jetzt kommt die Beschreibung) ist da viel besser. Zuerst bauen wir einen schön langen Schlüssel auf dem Client:

ssh-keygen -b 4068 -t dsa

Nun tauchen im Homeverzeichniss des Users, mit dem wir den Schlüssel erstellt haben, unter: ~/.ssh/ zwei Dateien auf: id_dsa und id_dsa.pub. Den Publickey id_dsa.pub packen wir nun auf den Server. Direkt in die Datei authorized_keys (vielleicht müssen wir diese noch mit der Hilfe von touch anlegen). Die Datei sollte im Homeverzeichniss des zu autorisierenden Users im Ordner .ssh angelegt werden. Haben wir das alles so eingetragen brauchen wir kein Kennwort mehr.

Wie wäre es mit einem Tunnel durch die Firewall?

OK… klingt ja ganz nett. Aber warum sollte ich einen Tunnel in meine Firewall machen?
Das kann ich dir erklären. Stell dir mal vor du sitzt mit deinem Notebook in einem Netzwerk wo du dir nicht sicher bist das keiner deine Verbindungen abhört oder gar die Verbindungen über bestimmte Ports blockiert sind. Du willst nun aber eine E-Mail schreiben! Oder bestimmte Ports sonst wie durch diese oder eine andere Firewall verschlüsselt tunneln.

Um einen einfachen Tunnel zu basteln musst du jetzt nur noch folgendes machen:
Computer2:

ssh -N -R 5555:localhost:22 user@erreichbarer_rechner

Jetzt passiert etwas feines 🙂 Denn nun geht am „erreichbarer_rechner“ der Port 5555 auf und der beamt dann alles durch den Tunnel an Computer2 an den Port 22 weiter.

Du kannst nun also sitzen wo du willst. Sobald du versuchst dich auf Port 5555 mit dem Computer „erreichbarer_rechner“ zu verbinden, wird deine Anmeldeanfrage direkt an Computer2 weitergeleitet. So bekommst du also sofort das Login von Computer 2.

ssh erreichbarer_rechner -p 5555

Geil, was?

GPG


GPG ==> GNU Privacy Guard
GPG ist die freie Version von PGP. Jeder Mensch mit etwas Hirn
sollte seine E-Mails und Daten signieren oder wenn nötig verschlüsseln.
So kann man sicher gehen, dass die signierten Daten unverändert sind und zum
Anderen sind die Daten, durch die Verschlüsselung, recht sicher.

Bisher ist es nur über Bruteforce Angriffe auf den geheimen Schlüssel möglich
ohne das Passwort an die verschlüsselten Daten zu gelangen. Hierzu benötigt der Angreifer
aber ersteinmal den geheimen Schlüssel. Um es einem Angreifer aber selsbt dann noch schwer
zu machen sollte das Passwort selbst sehr lang sein, Zahlen, Sonderzeichen sowie Groß- und
Kleinschreibung enthalten.
23784728247$$“8##1_seu2n181JIONc8 ==> als Passwort ist da schon super, wenn man es behalten kann ;-P
Um so länger um so mehr Möglichkeiten. Sind dazu noch Sonderzeichen, Zahlen und die Groß- und
Kleinschreibung zu beachten, ist es nach heutigem Ermessen kaum in einem Menschenleben heraus zu bekommen.

Ich signiere JEDE meiner E-Mails. Sollet ihr eine E-Mail von mir
bekommen, welche nicht signiert ist. Dann ist diese E-Mail
sehr wahrscheinlich NICHT von mir!!!
Jetzt müsst ihr natürlich nur noch checken können ob die Signatur echt
ist.
Aus diesem Grund oder wenn ihr mir verschlüsselte Daten senden wollt braucht
ihr natürlich den öffentlichen Schlüssel 🙂
Hier könnt ihr ihn anfragen: kernel-error@kernel-error.com
Wer gpg auf seinem Rechner installiert hat nutzt einfach folgenden Konsolenbefehl:

gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 0F9874D8

Der Befehl wird natürlich von dem User in der Konsole ausgeführt, welcher auch den Schlüssel haben will.

Fingerprint:

80CF 9044 6B58 67DA 3A55 854A F01C 3E04 0F98 74D8

Weitere Informationen gibt es bei mir oder am besten noch unter:
http://www.gnupg.org

Wie arbeite ich mit GPG?

GPG kann vollständig aus der Konsole heraus konfiguriert und benutzt werden.
Ich möchte hier keine Anleitung zu GPG erstellen, sondern nur einen Überblick
über einige der wichtigsten Funktionen geben.

Mit folgendem Befehl stößt man die Erstellung eines eigenen Schlüsselpaares an:

gpg --gen-key

Jetzt werden einige Fragen zum zukünftigen Schlüsselbesitzer und dazu gestellt, wie der
Schlüssel aussehen soll. Mit kurzem überlegen wird jeder diese Fragen ohne Vorkenntnisse selbst beantworten können.

Über den Befehl:

gpg --list-keys

Werden nun alle Schlüssel am „Schlüsselbund“ des Benutzers angezeigt. Hier sollte nun auch
der gerade erstellte zu bewundern sein.

Es kann vorkommen, dass man sein Passwort zu seinem Schlüssel vergisst, den Schlüssel selbst verliert
oder Unbefugte Zugriff auf diesen erhalten. Daher ist es ganz sinnvoll sich ein Widerrufszertifikat
zu erstellen. Mit dessen Hilfe kann man später seinen Schlüssel widerrufen. Der Befehl hierzu ist:

gpg --output revoke.asc --gen-revoke deine@e-mail.adresse

Klar ist hier wohl, den Privat-Key und das Widerrufszertifikat irgendwo zu sichern und vor
unbefugtem Zugriff zu schützen!

Nun kann man schon munter E-Mails sowie Daten signieren und verschlüsseln. KDE-User sollten sich
das Programm kgpg mal genauer anschauen (http://developer.kde.org/~kgpg/). In fast jedem
E-Mailclient lässt sich GPG integrieren. Microsoft Windows Benutzer schauen bitte hier.

Jetzt ist es natürlich ganz praktisch, wenn jemand unsere Signatur (also unsere digitale Unterschrift)
auch überprüfen kann. Dazu benötigt er aber unseren öffentlichen Schlüssel.
Von diesem können wir eine Kopie mit folgendem Befehl in eine Datei exportieren:

gpg --armor --export deine@e-mail.adresse > meinschluessel.asc

Die Datei können wir nun selbst weitergeben oder gleich, mit folgendem Befehl, auf einen Schlüsselserver laden:

gpg --keyserver wwwkeys.uk.pgp.net --send-key deine@e-mail.adresse

Will man einen fremden Schlüssel aus einer Datei importieren nutzt man:

gpg --import newkey.txt

Vom Schlüsselserver holt man ihn sich so:

gpg --keyserver wwwkeys.uk.pgp.net --recv-keys 0xkeyid

Im Zusammenhang mit GPG sollte man unbedingt hier vorbeischauen.

Signiert der Kernel Error meinen Schlüssel?

Klar, kein Problem. Na ja fast kein Problem 😉
Du packst dir zwei staatlich beglaubigte Dokumente mit Lichtbild, welche deine Identität
bestätigen. Wenn du diese hast, schickst du mir eine E-Mail in der du mich bittest deinen
Schlüssel zu signieren. Auf diese bekommst von mir eine Antwort mit mehr Informationen.

Natürlich werde ich vor dem Signieren dein Gesicht mit deinem Schlüssel und den Dokumenten
vergleichen. Wir müssen uns dazu also real treffen. Passt alles zusammen bekommst du meine Signatur!
Fragen und Anregungen einfach per E-Mail an Sebastian van de Meer: kernel-error@kernel-error.com


Natürlich lässt sich mein Schlüssel auch per pka von meinem DNSsec (Artikel DNSsec) geschützten DNS Server hohlen (GPG im DNS)

CAcert


Jeder der etwas mit EDV vertraut ist, wird mir sicher zustimmen. Daten im Rechner oder aus dem Internet sind schön und gut. Nur sind sie auch wirklich vom Autor, welcher im Dokument steht? Sind die Daten vielleicht verändert worden? Unterhalte ich mich auch gerade wirklich mit dem Server oder hat mit ein Hacker über einen fake-dns auf seinen Server geleitet?

 

Genau um solche Dinge sicher zu stellen, gibt es Zertifikate. Eine gute Möglichkeit für Privatleute oder kleine Firmen ist da CAcert.

CAcert:

CAcert ist eine gemeinschaftsbetriebene nicht kommerzielle Zertifizierungsstelle (Root CA), die kostenfrei X.509-Zertifikate für verschiedene Einsatzgebiete ausstellt. Damit soll eine Alternative zu den kommerziellen Roots CAs geboten werden, die zum Teil recht hohe Gebühren für ihre Zertifikate erheben. Die Dienstleistungen der CAcert sind allgemein. Jeder kann sich Zertifikate auf seinem Namen bzw. auf seinen Server ausstellen lassen, nachdem er seine Identität ausreichend belegt hat.

Zertifikate
Folgende Zertifikate und Signaturen werden angeboten:

Client-Zertifikate
Diese Zertifikate sind personalisiert, sie dienen zum Beispiel zum Verschlüsseln und Signieren von E-Mails und anderen Daten, aber auch Authentifikation an Servern oder zum Signieren von Softwarecode.

Server-Zertifikate
Server-Zertifikate stellen die Identität eines Servers sicher und dienen als Basis für verschlüsselte SSL/TLS-Verbindungen. Es gibt eine Bandbreite von Diensten, bei denen Server-Zertifikate zum Einsatz kommen. Dazu gehören u. a. HTTPS, FTP(S), SMTP(S), POP(S) und IMAP(S).

Signatur des PGP-Schlüssels
Man kann den eigenen PGP-Schlüssel zur Signatur einreichen. Die CAcert bestätigt dann die Identität des Schlüsselbesitzers.

Assurance / Identitätsprüfung
Um ein Zertifikat zu erhalten, muss man sich zunächst auf der Seite https://www.cacert.org/index.php?id=1 als Benutzer anmelden. Jedem Benutzerkonto sind Punkte (Assurance Points) zugeordnet, die auf verschiedenen Wegen von anfänglich 0 bis auf 150 Punkte erhöht werden können. Die Punkte geben an, wie genau die Identität eines Benutzers überprüft wurde (bis 100 Punkte) bzw. wieviele Punkte er beim Überprüfen der Identität eines anderen Benutzers vergeben darf (ab 100 Punkten).

Die Authentifikation der eigenen Identität gegenüber CAcert kann auf zwei Arten erfolgen:
Zum einen besteht ein Netzwerk aus Freiwilligen (Web of Trust), gegenüber denen sich der neue Benutzer ausweisen kann, um Punkte zu erhalten. Eine Liste der freiwilligen Assurer ist auf der Internetseite zu finden. Sie können maximal 35 Punkte vergeben. Bei besonderen Veranstaltungen wie z.B. Messen können Super-Assurer sofort die maximalen 150 Punkte vergeben.
Zum anderen sind ‚Vertrauenswürdige Dritte‘ (Trusted Third Parties) wie Notare zugelassen, die aufgrund ihrer Position (Beruf) die Identität des Benutzers bestätigen können. Hier können auch bis zu 150 Punkte erlangt werden.

Quelle:
http://de.wikipedia.org/wiki/CAcert
http://www.cacert.org/

Ich selbst bin auch ein solcher Assurer und kann die begehrten Punkte vergeben.
Interessierte schicken mir bitte eine kurze E-Mail. Dann können wir ein Treffen absprechen!


Wer sich für CAcert interessiert, sollte sich auch unbedingt den Beitrag: „StartSSL“ anschauen.
Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑