Category Archives: Allgemein

CoronaV19 vs. Influenza

Um sich mal einen Überblick über die Lage zugeben, hier ein Vergleich der Zahlen vom Robert-Koch-Institute vom 28.2.2020 für Deutschland:

GRIPPE/Influenza: 98.500* Infizierte
SARS-VoV-2:         53 Infizierte

Meint, wir haben mehr Grippekranke in dieser Session diesem Land, als es derzeit  Corona Infizierte (83k) weltweit gibt.

Im Influenza-Wochenbericht des RKI stehen dazu folgende Belege:

„Für die 8. Meldewoche (MW) 2020 wurden nach Infektionsschutzgesetz (IfSG) bislang 17.898 labor-diagnostisch bestätigte Influenzafälle an das Robert Koch-Institut übermittelt (Datenstand: 25.2.2020).“ und „Seit der 40. MW 2019 wurden insgesamt 98.442 labordiagnostisch bestätigte Influenzafälle an das RKI übermittelt“

Die Dunkelziffer dürfte größer sein, schon weil dieser Bericht die letzte aka diese Woche noch gar nicht berücksichtigt.

Quelle: https://www.rki.de/DE/Content/InfAZ/N/Neuartiges_Coronavirus/Fallzahlen.html

Quelle: https://influenza.rki.de/

Datenschutz: Wie peinlich T-Online ist

Posted on by

Peinlicher, aber nicht ganz unerwarteter, Fauxpas von T-Online:

2020-02-25 04:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 04:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 05:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 06:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 07:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 08:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 09:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-53): retry time not reached for any host for 'rx.t-online.de'
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support
2020-02-25 10:55:03 1j69ZJ-0001iL-S3 == tosa@rx.t-online.de R=dnslookup T=remote_smtp defer (-38) H=rx.t-online.de [194.25.134.67]: a TLS session is required, but the server did not offer TLS support

angemerkt sein, daß die Server für Kundenmails davon nicht betroffen sind. Das ändert aber nichts daran.

T-Online mit Datenschutzverstoß

Der Verzicht auf TLS stellt meiner Meinung nach, mal einen soliden Verstoß gegen Artikel 32 DSGVO dar, weil man als Mailserverbetreiber ja vorher nicht wissen kann, ob da drüber Personenbezogene Daten transportiert werden sollen oder nicht. Hellsehen, was einem einer jemals schicken wird, kann man ja nicht und daher muß man zwangsläufig vorher die Sicherheit der Datenübertragung aktiviert haben, weil nachträglich Sicherheit herstellen geht in dem Fall nun mal nicht.

Artikel 32
Sicherheit der Verarbeitung
(1) Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen  Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; diese Maßnahmen schließen unter anderem Folgendes ein:

a) die Pseudonymisierung und Verschlüsselung personenbezogener Daten;

Das kombiniert mit Artikel 4 2. schließt den Transport von Daten mit in den Begriff „Verarbeitung“ ein und erzwingt, weil der Aufwand praktisch nicht vorhanden ist und somit auch keine Kosten entstehen, die Verschlüsselung von Emails beim Transport durch den Einsatz von aktuellen Techniken ( STARTTLS mit TLS 1.2+).

In dem Fall wären es tatsächlich Personenbezogene Daten gewesen, weswegen unser Mailserver so eingestellt ist, daß er das in dem Fall auf keinen Fall über unsichere Leitungen schicken darf.

Die Adresse tosa@rx.t-online.de ist übrigens eine T-Online Adminadresse, falls man mal mit seinem Server gesperrt ist(, weil T-Onlinekunden Spams an ihre echten Adressen einfach ungefiltert an T-Onlineadressen weiterleiten) . Ich gehe mal davon aus, daß wie bei großen Organisationen üblich, Links nicht weiß was Rechts hätte tun sollen.

Die notwendigen Schritte den Verstoß abzustellen, werde ich jetzt anstoßen.

Update: 18:50 Uhr

Es gab Antwort von T-Online… und jetzt schön hinschauen… nicht lachen…

Received: from mailout02.t-online.de ([194.25.134.17])
	by userserver with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	(Exim 4.93)
	(envelope-from <postmaster@rx.t-online.de>)
	id ---
	for unsere@adresse; Tue, 25 Feb 2020 13:26:31 +0100
Received: from fwd37.aul.t-online.de (fwd37.aul.t-online.de [172.20.27.137])
	by mailout02.t-online.de (Postfix) with SMTP id ---
	for <unsere@adresse>; Tue, 25 Feb 2020 13:26:31 +0100 (CET)
Received: from mail.t-online-team.de (SU1DYkZrrhdrbk+8MoWoNLfFvJAGt3hYNV-3h42o51p2-46yGQLhcUQTxiv6TV2wPu@[194.25.187.129]) by fwd37.t-online.de
	with (TLSv1:ECDHE-RSA-AES256-SHA encrypted)
	esmtp id ---; Tue, 25 Feb 2020 13:26:30 +0100
From: Deutsche Telekom E-Mail Engineering ************* <postmaster@rx.t-online.de>
Date: Tue, 25 Feb 2020 13:26:31 +0100
Organization: Deutsche Telekom AG
X-Mailer: Forte Agent 6.00/32.1186
Content-Type: text/plain; charset=ISO-8859-1

Diese Email ist der nächste Verstoß gegen den Datenschutz, weil in der DSGVO steht drin, daß man auch bei internem Datentransport an die Absicherung denken muß.

Wie man sieht nutzt der erste Mailserver (mail.t-online-team.de) auf dem Weg zu unserem Mailserver (oberster Eintrag) TLSv1.0 , ein seit spätestens 2015 final geknacktes Protokoll. Der nächste interne Server  (fwd37.aul.t-online.de) benutzt für den internen Transport zu mailout02.t-online.de gleich gar keine Verschlüsselung mehr. Der letzte Mailserver mailout02.t-online.de macht dann endlich mal was richtig auf dem weg zu uns und benutzt TLSv1.2.

D.b. das „mailout02.t-online.de“ und „fwd37.aul.t-online.de“ können entweder miteinanders kein gemeinsames Protokoll finden, oder haben TLS/SSL gar nicht im Programm. Da aber jeder von denen auf der jeweils anderen Seite der Verbindung irgendwie TLS kann, muß da bei T-Online das Chaos pur herrschen. Ob das absichtlich, unabsichtlich oder fahrlässig so ist, werden die Datenschutzbehörden klären.

„Hallo T-Online, das Jahr 2005 will seinen Uralt-Zeichensatz zurück haben!“

Von dem ISO-8859-1 Fail des Mailprogramms will ich gar nicht erst anfangen, aber wirklich, was für einen uralt Krempel nutzen die da??? de-latin1 und TLSv1 passen historisch natürlich gut zusammen 🙂

Ältere Fälle:

Willkommen im Club der TLS Verweigerer: Apache Foundation!

BSI aktualisiert Mailserver auf TLS 1.2.. ABER

Sächsische Polizei benutzte gebrochene Verschlüsselung

PHP: kleines Problem in 7.3 mit . + –

Posted on by

Da meldet sich doch mein Kalender heute mit der Meldung, er könnte den Termin nicht modifizieren, weil der Server einen 500er Fehler produziert hat. Der Aufruf des Webinterfaces verlief zunächst einmal ohne Befund.

PHP 8 ist bald da!

Der eigentliche Fehler im Script ist eigentlich ganz einfach, hat aber große Auswirkungen auf PHP Programme. Ich wage sogar die These, daß dieser Fehler in PHP 8 zu einem Y2K Problem wird: Fixbar, aber es wird trotzdem knallen.

Kleine Einführung, damit Sie dem auch folgen können:

PHP ist eine Programmiersprache die auf Webservern zum Einsatz kommt.

E= 3+1  ergibt E=4  ( Addition )
E= 3-1    ergibt E=2  ( Subtraktion )
„Hallo“ . “ “ . „Welt“  ergibt in PHP „Hallo Welt“
„Obj->F“ meint, Zugriff auf ein FELD (F) im Objekt (Obj) , wird in der Objektorientierten Programmierung von PHP benutzt. „$this->“ meint dabei das Objekt in dessen Kontext die Operation ausgeführt wird, sprich „meint sich selbst“.

„+-“ sind nummerische Operationen,  „.“ ist eine lexikalische Anweisung auf Textblöcke in PHP.

Schauen wir uns erstmal den Fehler an, den SabreDAV hier als Kalenderbackend produziert:

[Wed Jan 08 16:03:28.700531 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] PHP Fatal error: Uncaught ErrorException: The behavior of unparenthesized expressions containing both ‚.‘ and ‚+’/‘-‚ will change in PHP 8: ‚+’/‘-‚ will take a higher precedence in /home/<username>/cal/vendor/sabre/vobject/lib/Sabre/VObject/RecurrenceIterator.php:829: <cgiwrapper>
[Wed Jan 08 16:03:28.700685 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] Stack trace:: <cgiwrapper>
[Wed Jan 08 16:03:28.700946 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #0 /home/<username>/cal/vendor/composer/ClassLoader.php(386): exception_error_handler(): <cgiwrapper>
[Wed Jan 08 16:03:28.701145 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #1 /home/<username>/cal/vendor/composer/ClassLoader.php(386): include(): <cgiwrapper>
[Wed Jan 08 16:03:28.701369 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #2 /home/<username>/cal/vendor/composer/ClassLoader.php(278): Composer\\Autoload\\includeFile(): <cgiwrapper>
[Wed Jan 08 16:03:28.701539 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #3 [internal function]: Composer\\Autoload\\ClassLoader->loadClass(): <cgiwrapper>
[Wed Jan 08 16:03:28.701741 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #4 /home/<username>/cal/lib/Sabre/CalDAV/Backend/PDO.php(520): spl_autoload_call(): <cgiwrapper>
[Wed Jan 08 16:03:28.702034 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #5 /home/<username>/cal/lib/Sabre/CalDAV/Backend/PDO.php(461): Sabre\\CalDAV\\Backend\\PDO->getDenormalizedData(): <cgiwrapper>
[Wed Jan 08 16:03:28.702503 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #6 /home/<username>/cal/lib/Sabre/CalDAV/CalendarObject.php(96): Sabre\\CalDAV\\Backend\\PDO->updateCalendarObject(): <cgiwrapper>
[Wed Jan 08 16:03:28.702713 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #7 /home/<username>/cal/lib/Sabre/DAV/Server.php(888): Sabre\\CalDAV\\CalendarObject->put(): <cgiwrapper>
[Wed Jan 08 16:03:28.703037 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #8 [internal function]: Sabre\\DAV in /home/<username>/cal/vendor/sabre/vobject/lib/Sabre/VObject/RecurrenceIterator.php on line 829: <cgiwrapper>

Da wird also die fehlende Klammerung von Operationen mit „.“ „-“ oder „+“ angekreidet. Erstmal komisch, bis man den Sourcecode dazu sieht:

$this->currentDate->modify(‚+‘ . $this->interval-1 . ‚ weeks‘);

PHP 7.3 meckert hier also darüber, daß der Entwickler davon ausgeht, daß eine mathematische Operation Vorrang vor einer lexikalischen Operation hat. Vom Ablauf steht dort in etwa:

$TVAR = $this->interval
$TVAR = $TVAR – 1
$TSTRING1 = StringAusZahl( $TVAR )
$TSTRING2 = FügeStringsZusammen( „+“, $TSTRING1, “ weeks“ )
RufeFunktionAuf(  $this->currentDate->modify , $TSTRING2 )

Das geht nur, weil der Operator „-“ hier Vorrang hat im Parser. Wenn das nicht mehr der Fall ist, also „.“ gleichrangig mit „-“ wäre, dann knallts, weil dann käme das raus ( oder noch etwas völlig anderes ):

$TVAR = $this->interval
$TVAR = $TVAR – „1 weeks“

Und hier wäre es dann auch schon vorbei, weil das nicht geht. Man kann keinen String von einer Zahl abziehen. Deswegen muß man jetzt eine Klammerung vornehmen, die eindeutig macht, was da wie subtrahiert werden soll und was dann als Zahl behandelt werden soll.

IMHO wäre das schon ein ParserBug in PHP 0.1 gewesen, der es nie in die Stable von PHP hätte schaffen dürfen. Das Parserverhalten jetzt in PHP 7.3 zu ändern bricht ziemlich hart mit vorhandenem Code und wird totsicher für Probleme rund um den Globus führen.

So müßte es jetzt für PHP 7.3 + PHP 8 geändert werden, damit es später noch funktioniert:

$this->currentDate->modify(‚+‘ . ($this->interval-1) . ‚ weeks‘);

Jetzt ist klar, daß hier „-“ Vorrang vor „.“ hat. Problem gelöst.