-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Schlagwort: OpenSSL (Seite 2 von 2)

TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL

19. Mai 2014 / / Keine Kommentare

Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.

Zertifikat holen

Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:

openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 \
  -servername smtp.kernel-error.de 2>/dev/null | \
  openssl x509 -outform PEM > /tmp/server.crt

Das Zertifikat liegt jetzt in /tmp/server.crt.

Hash berechnen

Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:

Usage0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung)
Selector0 = ganzes Zertifikat, 1 = nur Public Key (SPKI)
Matching Type0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512

Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:

dig _25._tcp.smtp.kernel-error.de TLSA +short

Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):

# Selector 0 (Full Certificate), SHA-256
openssl x509 -in /tmp/server.crt -outform DER | openssl sha256
# Ausgabe: SHA2-256(stdin)= 94c8e1bd...

Bei Selector 1 (nur SPKI, Public Key) und SHA-256:

# Selector 1 (SPKI), SHA-256
openssl x509 -in /tmp/server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | openssl sha256

Den berechneten Hash mit dem Wert aus dem TLSA-Record vergleichen. Stimmen sie überein, ist der Record korrekt.

Schnelltest mit posttls-finger

Wer nicht alles von Hand machen will: posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf in einem Schritt:

posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de

In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.

Wer DANE für den eigenen Mailserver einrichten will, findet die Anleitung unter Postfix mit DANE und DNSSEC absichern. Die Grundlagen zu DANE und TLSA-Records erklärt der Beitrag DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern. Fragen? Einfach melden.

Perfect Forward Secrecy für Postfix und Dovecot konfigurieren

15. Februar 2014 / / Keine Kommentare

Perfect Forward Secrecy (PFS) sorgt dafür, dass jede TLS-Verbindung einen eigenen temporären Schlüssel verwendet. Selbst wenn jemand den privaten Schlüssel des Servers in die Hände bekommt, kann er damit früher aufgezeichnete Verbindungen nicht entschlüsseln. Für E-Mail ist das besonders relevant, weil Mailverkehr gern auf Vorrat mitgeschnitten wird.

PFS bekommt man durch ECDHE- oder DHE-Schlüsselaustausch. Moderne OpenSSL-Versionen und aktuelle Postfix/Dovecot-Releases machen das Richtige von Haus aus. Trotzdem lohnt sich ein Blick auf die Konfiguration, um sicherzustellen, dass keine veralteten Protokolle oder Cipher-Suiten aktiv sind.

Postfix

Die relevanten Einstellungen in der main.cf:

# Eingehend (smtpd)
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = medium

# Ausgehend (smtp)
smtp_tls_security_level = dane
smtp_tls_protocols = >=TLSv1.2
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_mandatory_ciphers = medium

# Cipher-Präferenz beim Server
tls_preempt_cipherlist = yes

>=TLSv1.2 schaltet TLS 1.0 und 1.1 ab. tls_preempt_cipherlist = yes lässt den Server die Cipher-Reihenfolge bestimmen, nicht den Client. Postfix sortiert AEAD-Ciphers (GCM, CHACHA20) automatisch nach vorn, PFS-Ciphers haben Vorrang. Die medium-Stufe schließt alles unterhalb von 128-Bit-Verschlüsselung aus.

Für den ausgehenden Versand ist smtp_tls_security_level = dane die beste Wahl. Damit prüft Postfix TLSA-Records per DANE. Gibt es keinen TLSA-Record, fällt Postfix auf opportunistisches TLS zurück. Wer zusätzlich MTA-STS auswertet, deckt auch Server ohne DNSSEC ab.

Dovecot

In /usr/local/etc/dovecot/conf.d/10-ssl.conf (FreeBSD) bzw. /etc/dovecot/conf.d/10-ssl.conf (Linux):

ssl = required
ssl_min_protocol = TLSv1.2
ssl_prefer_server_ciphers = yes
ssl_options = no_ticket

ssl = required erzwingt TLS für alle Verbindungen. ssl_min_protocol = TLSv1.2 schließt alte Protokolle aus. ssl_prefer_server_ciphers = yes gibt dem Server die Kontrolle über die Cipher-Wahl. no_ticket deaktiviert TLS Session Tickets, die PFS untergraben können wenn der Ticket-Key kompromittiert wird.

Eine explizite Cipher-Liste ist bei aktuellem OpenSSL nicht nötig. Die Defaults bevorzugen ECDHE mit AEAD. Wer es trotzdem einschränken will:

ssl_cipher_list = ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20:!aNULL:!eNULL
ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

ssl_cipher_list gilt für TLS 1.2, ssl_cipher_suites für TLS 1.3. Bei TLS 1.3 ist PFS immer aktiv, da gibt es keine Cipher-Suiten ohne Schlüsselaustausch mehr.

Testen

# Postfix (STARTTLS auf Port 25)
openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Postfix (Implicit TLS auf Port 465)
openssl s_client -connect smtp.kernel-error.de:465 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (STARTTLS auf Port 143)
openssl s_client -starttls imap -connect imap.kernel-error.de:143 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

# Dovecot (Implicit TLS auf Port 993)
openssl s_client -connect imap.kernel-error.de:993 2>/dev/null | grep -E "Protocol|Cipher|Server Temp Key"

Entscheidend ist die Zeile Server Temp Key. Steht dort X25519, ECDH P-256 oder DH 2048, ist PFS aktiv. Mit OpenSSL 3.5+ und entsprechender Konfiguration sieht man dort auch X25519MLKEM768 für Post-Quantum-Schlüsselaustausch.

Siehe auch: Post-Quantum TLS für E-Mail

Fragen? Einfach melden.

Sicheres SSL / TLS Zertifikat

27. September 2013 / / Keine Kommentare

Es ist Zeit für ein neues Serverzertifikat. Im Standard sind dieses RSA Schlüssel mit einer Länge von 2048 Bit und SHA1 als Hash Algorithmus für Signaturen. Bei SHA1 bekommt man leider etwas Bauchschmerzen… 2048 Bit Keys sind nun ebenfalls nicht SO lang. Theoretisch noch „sicher“ aber wer will es schon darauf anlegen?

Nun wurde über Jahre an SSL / TLS Zertifikaten dieser Art festgehalten. Meist um kompatibel mit älteren Systemen zu sein. So können zum Beispiel die Betriebssysteme Windows XP sowie das darauf basierende Server Betriebssysteme von der Firma Microsoft, Windows Server 2003, nicht mit SHA2 umgehen.

Ich werde für die nächste Zertifikatsrunde auf 4096 Bit lange Schlüssel und SHA2 (SHA256) setzten. Selbst wenn ich damit einige Windows XP Benutzer abhängen werde!

Natürlich braucht man zusätzlich eine CA, welche mit X.509 Zertifikaten dieser Art umgehen kann. StartCOM / StartSSL kann dieses glücklicherweise. Ich erstelle die Zertifikate jeweils mit openSSL (Patch nicht vergessen!).

Key erstellen:

openssl req -new -outform PEM -out http.cert -sha256 -newkey rsa:4096 -nodes -keyout http.key -keyform PEM -days 730 -x509

Zertifizierungsanforderung (CSR) erstellen:

openssl req -new -key http.key -out http.csr -sha256

Die von er CA Unterzeichnete CSR einpflegen:

cat http.key http.crt > http.pem

Diffie Hellman Parameter erstellen und einfach mit ins pem werfen:

openssl gendh 4096 >> http.pem

Ja, es sind 4096bit für DH. dieses kann etwas dauern. Ist aber am Ende nötig damit zum Beispiel der Apache >=2.4 diese Bits auch nutzen kann!

Noch Fragen?

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

Unix / Linux Openssl Zertifikat pem konvertieren zu Microsoft Windows pfx

14. Mai 2013 / / Keine Kommentare

Man man man… Da bittet ein Kollege um ein Zertifikat, ich schraube das schnell zusammen und schiebe es im als .PEM – Base64-kodiertes Zertifikat, umschlossen von „—–BEGIN CERTIFICATE—–“ und „—–END CERTIFICATE—–“ zu.

Nun versucht dieser das Zertifikat auf seinem Windows Server zu importieren. Klappt aber so einfach nicht. Microsoft hätte nämlich gerne das Zertifikat als .PFX (.P12 – PKCS#12, kann öffentliche Zertifikate und private Schlüssel (Kennwort-geschützt) enthalten.) Macht ja auch Sinn wenn es eh in einer Zertifikatsverwaltung liegt und dass ganze Kennwortgeschützt ist. So ist es etwas sicherer, wenn die Datei mal jemanden in die Hände fällt, der es nicht haben soll!

Wie also nun aus PEM ein PFX machen? Openssl hilft:

# openssl pkcs12 -export -out telefon.de.pfx -inkey telefon.de.key -in telefon.de.crt -certfile CACert.crt

telefon.de.key sowie telefon.de.crt sollten wir beim einfachen erstellen des Zertifikates per Openssl ja bereits haben. CACert.crt ist einfach der Zertifikat der CA, mit welchem unsere CSR unterschrieben wurde. Noch Fragen?

Siehe auch: Elliptic Curve Zertifikate mit OpenSSL

Fragen? Einfach melden.

OpenSSL ich kann es mir nicht merken

10. Mai 2012 / / Keine Kommentare

Jetzt mal unter Freunden, was ist bloß los mit meinem Kopf? Da aktiviere ich gerade für einen Kunden am Microsoft Exchangeserver Outlook Anywhere. Der Kunde hat ein selbstsigniertes Zertifikat auf seinem Server. Also quängelt Outlook natürlich bei der Verbindung über https „Das böse Zertifikat vom bösen Proxyserver… bla bla“. Nun will ich einfach mal schnell das Zertifikat haben um es auf der Windose importieren zu können und reiße schnell auf meiner Solariskiste ein Terminalfenster auf und tippe:

# openssl öhm ähhh öhm… *MIST*

Warum kann ich mir das nicht merken? Irgendwas mit sclient slclient?!?! Dann aber sicher -connect und host:port. Es kann doch nicht sein dass ich jedes mal in die Manpage schauen muss oder?

Folgendes ist natürlich der richtige Aufruf:

$ openssl s_client -connect www.kernel-error.de:443

Vielleicht schaffe ich es ja jetzt mir mal zu merken das es s_client heißt, nachdem ich es hier aufgeschrieben habe. Warum zum Teufel kann ich mir s_client einach nicht merken? Das regt mich auf!

 

 

 

 

Siehe auch: PEM zu PFX konvertieren

Fragen? Einfach melden.

GeoTagging

1. August 2011 / / Keine Kommentare

GeoTagging mit dem i-gatU GT200e Gentoo Linux und Digikam… 

Ich habe von meiner Frau einen GPS Datenlogger zum Geburtstag geschenkt bekommen. Damit hat sie mir auch direkt meinen Wunsch nach so einem Gerät erfüllt. Danke.  Allen jenen welche durch eine Suche auf diesen Beitrag gestoßen sind muss ich wohl kaum erzählen was und zu welchem Zweck man dieses kleine Gerät einsetzten kann. Besitzer eines Smartphones werden wohl meist auch nur müde lächeln. Daher reiße ich nur kurz an, was ich mit dem Teil möchte. Angeschlossen und geladen wird der GT-200e von i-gatU per USB. Ich habe zusätzlich die Möglichkeit das Gerät per Bluetooth zu verbinden. So zum Beispiel mit meinem Nokia Mobiltelefon (ja, vielleicht kaufe ich irgendwann mal etwas neuers). Kismet auf meinem Notebook oder oder oder…. Die aktuelle GPS Position kann mit dem Gerät per Knopfdruck oder je nach Einstellung automatisch im Intervall gespeichert werden. Da ein Akku verbaut ist kann es dieses komplett als Stand-Alone Gerät. Genau dieses ist mein Hauptplan…. Ich packe es einfach in meine Tasche oder befästige es an meiner Spiegelreflexkamera und/oder Digitalkamera und lasse es einfach mitlaufen. Die Akkulaufzeit reichte bei mir schon für 3 Tage, dann habe ich aufgehört zu testen. Dieses kleine Ding hängt nun also an meiner Canon EOS 450D und schreibt alle paar Sekunden meinen genauen Standort auf. Zuhause kann ich nun diese Daten vom Gerät als GPX Datei auslesen und zusammen mit meiner Bilderverwaltungssoftware Digikam, die Bilder meiner Kamera mit den GPS Koordinaten vermischen. Somit ist in den Metadaten jedes Bildes gespeichert an welcher Position genau ich es aufgenommen habe. Natürlich lässt sich anhand der Wegpunkte die genaue Strecke, Geschwindigkeit, Höhe usw… Errechnen und in lustige Grafiken gießen. Dieses ist für mich dass Abfallprodukt. Wie so oft reicht es auch i-gatU sich hinsichtlich Treiber- und Softwareunterstützung um die Microsoft Windows und Apple MacOS Benutzer zu kümmern. Linux Benutzer müssen sich halt selbst irgendwie kümmern und das haben sie getan. Es gibt das Progrämmchen igotu2gpx der Linux Kernel kommt ab Versionen größer 2.6.3 problemlos mit dem Gerät zurecht. Um igotu2gpx kompilieren zu können sind im groben folgende Abhängigkeiten zu erfüllen: – qt4 – boost – libusb – chrpath – marble – openssl Dieses sollte sich auf jeder gängigen Distribution durch den Paketmanager erledigen lassen. Unterwegs kümmert sich nun der GT200e um die genaue Positionsbestimmung. Zuhause kann ich dann die Wegpunkte mit igotu2gpx in eine gpx Datei exportieren. Digikam verbindet dann die Bilder mit der passenden GPS Position. Dieses funktioniert über die Uhrzeit. Die Kamera hängt beim Knipsen eines Bildes automatisch die Uhrzeit an das Bild. Diese kann nun mit den Zeiten aus dem gpx Export verglichen werden. So lässt sich herausfinden an welcher Position man gerade beim Knipsen des Bildes gewesen ist. Vorausgesetzt die Kamera hat auch die richtige Uhrzeit und das richtige Datum. GPX track data imported in Digikam GPS coordinates assigned to photos in Digikam Geotagged photo positions displayed on map i-gotU GT200e GPS logger next to Nokia phone i-gotU GT200e connected via Bluetooth

Fragen? Einfach melden.

CAcert Nokia

19. August 2009 / / Keine Kommentare

Veraltet: Nokia S40 und S60 gibt es nicht mehr, und CAcert hat es nie in die Browser-Truststores geschafft. Dieser Beitrag ist nur noch als Zeitdokument interessant.

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 6858622Click2Dial icon] [Mobile: +49 0177 5995900Click2Dial icon] ] [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!
Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑