Skip to content

security.txt

Kennt ihr noch die Datei robots.txt, die auf verschiedenen Webseiten hinterlegt sind? Dahinter stand der Robots Exclusion Standard und die verschiedenen Bots sollen zuerst die Seite ausweren, bevor sie eine Webpräsenz indexieren. Daneben entstand auch die Idee für eine humans.txt und mit dem “Erschaffen” des .well-known-Verzeichnisses auf dem Webserver gibt es eine ganze Reihe Dateiformate zur Information oder für andere Zwecke.

Seit April 2022 gibt es nun den RFC 9116 für die Datei security.txt. Diese soll anderen helfen, Sicherheitslücken an die richtige Stelle zu melden. Denn oftmals steht das Problem, dass eine Schwachstelle gefunden wurde und es vielleicht unklar ist, wohin diese zu melden ist.

Mail wäre natürlich eine mögliche Wahl. Im besten Fall existiert sogar eine E-Mail-Adresse namens security@. Aber sehr häufig ist dies nicht der Fall. Mails an info@ oder ähnliche Adressen landen eher im Nirwana oder werden mit Standardtextbausteinen beantwortet. Daher ist ein gezielter, standardisierter Weg gut.

Der RFC 9116 definiert hierfür eben die Datei security.txt, die im Unterordner .well-known einer Webpräsenz liegen muss. Die Datei selbst muss über HTTPS erreichbar sein. Ein korrekter Pfad wäre also https://example.com/.well-known/security.txt.

Doch was darf da drin stehen? Naheliegend sind Kontaktinformationen. :-) Spezieller Informationen, an die man Informationen zu Schwachstellen melden kann. Hierfür ist der Eintrag Contact: gedacht. Dieser muss in der Datei enthalten sein und sollte die Kontaktmöglichkeiten in absteigender Reihenfolge enthalten. Daneben benötigt die Datei zwingend ein Ablaufdatum. Eine Minimalversion der Datei kann also so aussehen:

Contact: mailto:security@example.com
Expires: 2023-05-01T12:13:24+02:00

Weiterhin könnt ihr in der Datei Informationen zu einer Policy hinterlegen, welche Sprachen ihr sprecht, ob ihr Leute einstellt, wer in der Vergangenheit Lücken meldete und einen Verweis zu einem Schlüssel machen. Eine erweiterte Version der Datei sähe also so aus:

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

Hier sind mehrere Kontaktmöglichkeiten genannt. Es gibt eine Policy. Die Leute sprechen Deutsch und Englisch und ihr bekommt Infos über andere, die etwas gemeldet haben. Am Schluss findet sich auch ein PGP-Schlüssel. Optimalweise würde der über Web Key Discovery bereit gestellt. Aber das ist ein Thema für einen anderen Beitrag. ;-)

Schließlich könnt ihr den Eintrag auch noch mittels OpenPGP signieren. Dann sähe meine obige Datei so aus:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Contact: mailto:security@example.com
Contact: +49-123-456-7890
Contact: https://example.com/meldeformular.html
Policy: https://example.com/security-policy.html
Preferred-Languages: de, en
Acknowledgments: https://example.com/hall-of-fame.html
Encryption: https://example.com/pgp-key.txt
Expires: 2023-05-01T12:13:24+02:00

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.2.19

[Viele Zeichen, die gpg auswerten kann]
-----END PGP SIGNATURE-----

Wenn ihr also eine Schwachstelle gefunden habt, dann lohnt es sich nach der Datei zu schauen und die dort genannten Kontakte anzusprechen. Ich habe mal ein wenig gegraben. Bei den großen, bekannten Seiten, wie Google, Facebook, Twitter, GitHub usw., fand ich jeweils eine solche Datei. Seiten aus dem Microsoft-Universum wie auch viele chinesische Seiten haben keinerlei solche Informationen.

Ansonsten ist das Bild recht gemischt. Während beispielsweise Facebook und WhatsApp eine security.txt anbieten, hat Instagram keine, obwohl alle zum selben Konzern gehören.

Unter andere namhaften Seiten fand ich nichts bei

  • Reddit
  • Wikipedia
  • Zoom
  • Netflix
  • Stackoverflow
  • Apple
  • und weiteren

Hier ist also noch ein wenig Arbeit zu tun. Wenn die Datei auch bei euch oder eurem Arbeigeber fehlt, sprecht die doch an und bittet die, diese Informationen bereitzustellen (und natürlich bei Bedarf zu aktualisieren).

Siehe auch:

Update: Ich hatte übersehen, dass das Expires:-Feld auch ein Pflichtfeld ist und habe die obige Beschreibung ergänzt. Vielen Dank an Jürgen für den Hinweis!

Einbindung von Flickr doch konform zur DS-GVO

GDPR
GDPR & ePrivacy Regulations von Dennis van der Hejden. Original bei Flickr

Vor kurzem stellte ich mir hier im Blog die Frage, ob man noch Bilder des Dienstes Flickr einbinden kann. Nach meiner Prüfung kam ich zu dem Schluss, dass dies nicht mehr der Fall ist und entfernte die Bilder aus meinem Blog.

Heute hielt ich einen Workshop, der u.a. auch die Datenschutz-Grundverordnung zum Thema hatte. Dort fragte mich ein Teilnehmer, ob denn das Land Thüringen eine korrekte Datenschutzerklärung (DSE) hat. Der folgende Abschnitt brachte mich dann doch ins Staunen:

Flickr

Innerhalb unseres Onlineangebotes können Funktionen und Inhalte des Dienstes Flickr eingebunden sein. Flickr ist ein Foto- und Bilder-Dienst des amerikanischen Unternehmens SmugMug Inc. (67 E. Evelyn Ave, Suite 200
Mountain View, California, U.S.)Wenn Sie selber Flickr aktiv nutzen und ein Bild oder Video veröffentlichen, können wir ihn ebenfalls sehen, wenn Sie ihn jedermann zugänglich gemacht haben oder wenn wir Ihnen über Flickr folgen. Ebenfalls können wir Ihre Angaben auf Flickr sehen, wenn thueringen.de Ihrem Profil folgt. Einzelheiten zur Verarbeitung der Daten bei Flickr und den Sichtbarkeitseinstellungen entnehmen Sie bitte den Datenschutzbedingungen von Flickr bzw. Oath (ehemals Yahoo): policies.oath.com/ie/de/oath/privacy/index.html  

Das heißt, das Land Thüringen ist der Meinung, rechtmäßig Flickr-Bilder einbinden zu können. Wie kann das sein?

Weder Flickr noch Yahoo! noch eine der anderen Firmen steht bisher auf der Privacy-Shield-Liste. Und die Datenschutzbedingungen von Flickr gaben doch bisher auch nichts her. Aber: Unter anderen ist das Datenschutzcenter von Oath mit verlinkt. Dort steht gleich am Anfang:

Für Produkte oder Dienste von Oath, auf die ohne Anmeldung bei einem Account zugegriffen wird, gilt diese Datenschutzerklärung für diese Produkte und Dienste ab 25. Mai 2018.  

Flickr gehört mit zu Oath. Also gelten diese Bedingungen auch für Flickr. In der DSE steht drin, dass die Oath (EMEA) Limited in Dublin diese Dienste bereitstellt und damit wohl Verantwortlicher im Sinne der DS-GVO ist. Also werden die Daten von einem Unternehmen mit Sitz in der EU verarbeitet und die DS-GVO möchte ja den freien Verkehr personenbezogener Daten fördern (oder zumindest nicht einschränken).

Weiterhin erklärt Oath, dass sie die Standardvertragsklauseln der EU-Kommission verwenden bzw. nur Daten mit Unternehmen austauschen, die nach Privacy Shield zertifiziert sind.

Insgesamt scheint die Datenschutzerklärung den Anforderungen der Art. 13 und 14 DS-GVO zu entsprechen. Und auch inhaltlich ist es jetzt so, dass man wohl doch bedenkenlos Bilder von Flickr in seinem Blog einbinden kann.

Call for action: Please send me an encrypted file

tl;dr: Please encrypt a file and send it to me together with a (short) description, how I can make it readable for me.

Everyone is talking about encryption and nobody does it. This is a short summary of my initial asumption. Did you ever try to encrypt a file and to send it someone? How did you do it?

This is a fairly simple and basic task which you can present in a beginner’s course:

Assume another person uses a public computer (Internet cafe, library, etc.). You want to send a file to this person and keep the content confidential to other people. Encrypt a file on your computer and send it to the person.

I ask myself how you would do it. Thatswhy I decided to conduct a little experiment: Dear reader, please encrypt a (no so big) file and send it to me (via mail to enc2018@kubieziel.de, you can use my PGP key if you like, comment this post or use some other means to contact me). Add some information which to decrypt the file. You have no idea how to do this? I desperately want to know about it. Please write a mail or leave a comment. You tried and failed? I desperately want to know about it. Please write a mail or leave a comment. I would like to know how easy or hard this task is.

I plan to analyse the data on a anonymous basis and will introduce some tools in later posts.

Aufruf: Schick mir eine verschlüsselte Datei

tl;dr: Bitte verschlüsselt eine Datei und schickt mir diese zusammen mit einer (kurzen) Beschreibung, wie ich die lesbar mache.

Alle Welt redet von Verschlüsselung und keiner macht es. So könnte man meine These kurz zusammenfassen. Habt ihr schonmal versucht, eine Datei zu verschlüsseln und diese jemand anderem zuzusenden? Wie habt ihr dies angestellt?

Aus meiner Sicht ist das eine einfache, grundlegende Aufgabe, die man in jedem Anfängerkurs stellen könnte:

Stelle dir vor, dein Gegenüber nutzt einen öffentlichen Computer (Internetcafe, Bibliothek etc.). Du möchtest mit diesem eine Datei austauschen, deren Inhalt nur ihr beide kennt. Verschlüssele eine Datei auf deinem Rechner und übermittle diese an dein Gegenüber.

Ich frage mich nun, wie ihr das machen würdet. Daher habe ich mich zu einem kleinen Experiment entschlossen: Liebe Leserinnen und Leser, bitte verschlüsselt eine (nicht allzugroße) Datei und schickt mir diese zu (per E-Mail an enc2018@kubieziel.de, hinterlasst einen Kommentar oder kontaktiert mich anderweitig) . Legt ein paar Informationen bei, wie ich die wieder entschlüsseln kann. Ihr wisst nicht, wie ihr das machen könnt? Schreibt mir bitte unbedingt eine Mail an enc2018@kubieziel.de oder hinterlasst unten einen Kommentar und erzählt mir davon. Ihr habt es probiert und seid daran gescheitert? Schreibt mir bitte unbedingt eine Mail an enc2018@kubieziel.de oder hinterlasst unten einen Kommentar und erzählt mir davon. Ich würde gern wissen, wie einfach oder schwierig dies für euch ist.

Ich plane, die Umfrage später anonymisiert auszuwerten und ggf. in weiteren Beiträgen verschiedene Werkzeuge vorzustellen.

 

TLS-Bingo -- Wer bietet mehr?

Ich hatte heute den verwegenen Plan und wollte die Webseite des sächsischen Landtages per HTTPS aufrufen. Der Browser stoppte mich und zeigte eine schöne Fehlermeldung:

Edas
Fehlermeldung zum Zertifikat von edas.landtag.sachsen.de

Also dem Zertifikat traut der Browser nicht. Außerdem fehlen dem weitere Bestandteile. Das Zertifikat ist eigentlich für eine andere Domain und schon längst abgelaufen.

Hier frage ich mich, ob jemand schon mal eine Liste von Zertifikatsfehlern gesehen hat, die länger ist, als die obige. :-)

Securityheaders.io

Viele von euch kennen vielleicht die Seite SSLLabs.com, bei der sich die Einstellungen bezüglich TLS testen lassen. Wer wissen möchte, wie gut die Daten auf einer verschlüsselten Webseite geschützt sind, kann den Namen eingeben und SSLabs führt dann verschiedene Tests durch. Nach Beendigung gibt die Seite eine Einschätzung aus.

SSLLabs für kubieziel.de
SSL-Einstellungen für kubieziel.de im Dezember 2015

Nun ist TLS nicht die einzige Baustelle, was die Sicherheit im Web betrifft. Es gibt zahlreiche Schwachstellen, die ausgenutzt werden. Für einige dieser Schwachstellen wurden neue HTTP-Header eingeführt.

So gibt es beispielsweise einen, der dem Browser auffordert, die Seite ausschließlich über HTTPS aufzusuchen (HSTS). Die meisten aktuellen Browser unterstützen den Header. Daneben gibt es Header, die Schutz vor so genanntem Cross-Site-Scripting (XSS) bieten sollen sowie weitere mehr.

Die Seite securityheaders.io hat es sich zum Ziel gemacht, die Header der Webseiten zu testen und ein ähnliches Rating wie SSLLabs auszugeben. Auch hier erhaltet ihr einen schnellen Überblick über die Sicherungsmaßnahmen. Allerdings habe ich Einstellungen gefunden, wo das Rating aus meiner Sicht nicht gerechtfertigt ist. Die Seite hatte HSTS gesetzt und erhielt trotzdem nur ein sehr schlechtes Rating. Laut Aussage der Entwickler sind die aber dabei, das zu ändern. Testet die Seite doch mal aus!

Meine Seite hat derzeit folgendes Rating:

Bewertung der HTTP-Header bei kubieziel.de
Bewertung der HTTP-Header bei kubieziel.de

Wie ihr seht, fehlt derzeit CSP und das Key Pinning. Bei letzterem lässt sich aus meiner Sicht viel falsch machen. Da will ich erstmal noch ein paar Gedanken reinstecken, bevor ich den setze. Und CSP muss ich testen, inwieweit das mit dem Blog Probleme gibt. Wenn das passiert ist, steht einem A+ nichts mehr im Wege. :-)

Neues TLS-Zertifikat

Der Webserver hat seit heute ein neues Zertifikat. Ich bin jetzt von CAcert auf Let’s Encrypt umgestiegen. Bei den Übernauten ist die Einrichtung sehr einfach. Nachdem die Befehle uberspace-letsencrypt, letsencrypt certonly und uberspace-prepare-certificate eingegeben wurden, war alles fertig.

Wenn ihr das Zertifikat prüfen wollt, hier ist der SHA-256-Hash:

B8:8A:B3:34:0E:5F:97:6A:88:F0:A7:E7:91:73:F4:50:42:29:0A:73:07:54:68:2D:96:EB:36:29:BB:FC:58:A8
tweetbackcheckcronjob