The iphone.dsbcontrol.de, app.dsbcontrol.de and light.dsbcontrol.de servers only support TLS v1.0, which is an obsolete, insecure protocol.
This issue shall track possible client-side mitigations and other actions.
[The main issue has been solved as of August 22nd. It is still open to track responses to the latest email sent to a heinekingmedia representative.]
The `iphone.dsbcontrol.de`, `app.dsbcontrol.de` and `light.dsbcontrol.de` servers only support TLS v1.0, which is an obsolete, insecure protocol.
This issue shall track possible client-side mitigations and other actions.
[The main issue has been solved as of August 22nd. It is still open to track responses to the latest email sent to a heinekingmedia representative.]
Heinekingmedia has been informed about this and other issues earlier today, August 11th, 2019. The message's content will be provided here at a later date, as well as any responses.
Heinekingmedia has been informed about this and other issues earlier today, August 11th, 2019. The message's content will be provided here at a later date, as well as any responses.
The dsbmobile.de IHK skin ihkmobile.dsbcontrol.de (also available at other domains) allows connecting via a secure TLS v1.2 connection, as does the corresponding skinned client (presumably) (Android: de.ihkbb.dsbmobile).
For the IHK skin, content is mirrored from app.dsbcontrol.de (used in dsbmobile.de) or light.dsbcontrol.de (linked to by the "iPhone service" iphone.dsbcontrol.de/iPhoneService.svc) (both insecure) to a place somewhere at www22content.dsbcontrol.de or www21content.dsbcontrol.de. The resource locations may sometimes be similar, however, a different auth token is needed in (and provided by) the IHK system.
Obtaining it is difficult, however: reading the Android client's traffic showed that it is posting and receiving obscure base64-lookalike messages whose structure is currently unknown.
The `dsbmobile.de` IHK skin `ihkmobile.dsbcontrol.de` (also available at other domains) allows connecting via a secure TLS v1.2 connection, as does the corresponding skinned client (presumably) (Android: `de.ihkbb.dsbmobile`).
For the IHK skin, content is mirrored from `app.dsbcontrol.de` (used in `dsbmobile.de`) or `light.dsbcontrol.de` (linked to by the "iPhone service" `iphone.dsbcontrol.de/iPhoneService.svc`) (both insecure) to a place somewhere at `www22content.dsbcontrol.de` or `www21content.dsbcontrol.de`. The resource locations may sometimes be similar, however, a different auth token is needed in (and provided by) the IHK system.
Obtaining it is difficult, however: reading the Android client's traffic showed that it is posting and receiving obscure base64-lookalike messages whose structure is currently unknown.
On or around August 22nd, Heinekingmedia has disabled the SSLv2 protocol that caused a security vulnerability and enabled TLS v1.2 on dsbmobile.de as well as iphone., light. and app.dsbcontrol.de.
For transparency, communication with Heinekingmedia is provided below.
August 11th, 2019 to info at digitales-schwarzes-brett.de
Sehr geehrte Damen und Herren,
in ihrem Produkt DSB sind mir mehrere Details aufgefallen, die Sicherheitsbedenken aufkommen lassen.
Die Server, die hinter iphone.dsbcontol.de, app.dsbcontrol.de und light.dsbcontrol.de stehen, unterstützen höchstens TLS v1.0, was ein hinfälliges, unsicheres Protokoll ist.
Da mindestens einer dieser Server SSL 2 unterstützen, sind alle diese Dienste gegenüber DROWN-Attacken verwundbar, was Angreifern erlauben könnte, Inhalte zu entschlüsseln.
Weitergehend verbieten dsbmobile.de sowohl als auch die oben genannten Subdomänen unsichere Verbindungen nicht, was Clients (also meist Nutzern, die dsbmobile.de in ihre Adresszeile eintippen) erlaubt, ihr Passwort im Klartext zu übertragen.
Ich fordere Sie hiermit dazu auf, die von mir genannten Schwachstellen zügigst zu beheben, indem Sie Unterstützung für TLS v1.3 hinzufügen und schnellstmöglich SSL v2 deaktivieren.
Mit freundlichen Grüßen
Fynn Godau
August 13th, 2019
Sehr geehrter Herr Godau,
vielen Dank für Ihre E-Mail. Wir sind uns der Unterstützung der Protokolle bewusst.
Wir haben diese bisher nicht deaktiviert, da wir noch einige User mit sehr alten Endgeräten hatten, die unsere Dienste noch genutzt haben. Diese wurde von uns informiert das wir die Unterstützung einstellen und werden planmäßig am 23.08 die Unterstützung dieser Protokolle einstellen.
Wir bedanken uns sehr für diesen Hinweis. Ich werde Sie nach erfolgter Deaktivierung noch einmal kontaktieren.
Bei Rückfragen können Sie sich gerne direkt an mich wenden.
Mit freundlichen Grüßen
██████ █████████
August 22nd, 2019
Sehr geehrter Herr Godau,
die Umstellung ist auf unserer Seite erfolgt. Die von Ihnen genannten Protokolle sind in diesem Zuge deaktiviert worden.
Bei Rückfragen können Sie sich gerne direkt an mich wenden.
Mit freundlichen Grüßen
██████ █████████
On or around August 22nd, Heinekingmedia has disabled the SSLv2 protocol that caused a security vulnerability and enabled TLS v1.2 on `dsbmobile.de` as well as `iphone.`, `light.` and `app.dsbcontrol.de`.
For transparency, communication with Heinekingmedia is provided below.
August 11th, 2019 to info at digitales-schwarzes-brett.de
>Sehr geehrte Damen und Herren,
>
>in ihrem Produkt DSB sind mir mehrere Details aufgefallen, die Sicherheitsbedenken aufkommen lassen.
>
>Die Server, die hinter `iphone.dsbcontol.de`, `app.dsbcontrol.de` und `light.dsbcontrol.de` stehen, unterstützen höchstens TLS v1.0, was ein hinfälliges, unsicheres Protokoll ist.
>
>Da mindestens einer dieser Server [SSL 2 unterstützen](https://www.ssllabs.com/ssltest/analyze.html?d=app.dsbcontrol.de), sind alle diese Dienste gegenüber [DROWN-Attacken](https://drownattack.com/) verwundbar, was Angreifern erlauben könnte, Inhalte zu entschlüsseln.
>
>Weitergehend verbieten `dsbmobile.de` sowohl als auch die oben genannten Subdomänen unsichere Verbindungen nicht, was Clients (also meist Nutzern, die `dsbmobile.de` in ihre Adresszeile eintippen) erlaubt, ihr Passwort im Klartext zu übertragen.
>
>Ich fordere Sie hiermit dazu auf, die von mir genannten Schwachstellen zügigst zu beheben, indem Sie Unterstützung für TLS v1.3 hinzufügen und schnellstmöglich SSL v2 deaktivieren.
>
>Mit freundlichen Grüßen
>
>Fynn Godau
August 13th, 2019
>Sehr geehrter Herr Godau,
>
>
>
>vielen Dank für Ihre E-Mail. Wir sind uns der Unterstützung der Protokolle bewusst.
>
>
>
>Wir haben diese bisher nicht deaktiviert, da wir noch einige User mit sehr alten Endgeräten hatten, die unsere Dienste noch genutzt haben. Diese wurde von uns informiert das wir die Unterstützung einstellen und werden planmäßig am 23.08 die Unterstützung dieser Protokolle einstellen.
>
>Wir bedanken uns sehr für diesen Hinweis. Ich werde Sie nach erfolgter Deaktivierung noch einmal kontaktieren.
>
>
>
>Bei Rückfragen können Sie sich gerne direkt an mich wenden.
>
>
>
>
>
>Mit freundlichen Grüßen
>
>██████ █████████
August 22nd, 2019
>Sehr geehrter Herr Godau,
>
>
>
>die Umstellung ist auf unserer Seite erfolgt. Die von Ihnen genannten Protokolle sind in diesem Zuge deaktiviert worden.
>
>
>
>Bei Rückfragen können Sie sich gerne direkt an mich wenden.
>
>
>
>Mit freundlichen Grüßen
>
>██████ █████████
Heinekingmedia has been contacted about a still unresolved issue with allowing insecure connections on iphone.dsbcontrol.de as well as a privacy issue on dsbmobile.de due to connections to Google. None of these still outstanding issues directly affect DSBDirect. Communication is provided nonetheless.
August 28th, 2019
Sehr geehrt█ ███ ██████ █████████,
es ist zu begrüßen, dass Sie das SSL v2-Protokoll deaktiviert haben.
Mir ist noch aufgefallen, dass iphone.dsbcontrol.de weiterhin komplett unverschlüsselte Verbindungen zulässt. Da dies nicht die Stelle ist, an die Nutzer normalerweise ihr Passwort übermitteln, mag dies unbedenklich erscheinen. Allerdings muss ich doch fragen, ob es Clients gibt, die dorthin unverschlüsselte Verbindungen aufbauen? Wenn ja, dann sollten auch diese unbedingt schnellstmöglich aus dem Betrieb genommen werden.
Außerdem ist mir noch aufgefallen, dass bei Besuch der Startseite von dsbmobile.de Verbindungen zu verschiedenen Google-Domains aufgebaut werden (ajax.googleapis.com, fonts.googleapis.com, font.gstatic.com). Als ich lokal die Verbindung zu diesen Domains verhindert habe, verlor die Seite keinerlei Funktionalität. Um den Datenschutz der Nutzer zu gewährleisten, sollten bei Gebrauch der Webseite keine Verbindungen zu Google-Servern aufgebaut werden!
Mit freundlichen Grüßen
Fynn Godau
Heinekingmedia has been contacted about a still unresolved issue with allowing insecure connections on `iphone.dsbcontrol.de` as well as a privacy issue on `dsbmobile.de` due to connections to Google. None of these still outstanding issues directly affect DSBDirect. Communication is provided nonetheless.
August 28th, 2019
>Sehr geehrt█ ███ ██████ █████████,
>
>es ist zu begrüßen, dass Sie das SSL v2-Protokoll deaktiviert haben.
>
>Mir ist noch aufgefallen, dass `iphone.dsbcontrol.de` weiterhin komplett unverschlüsselte Verbindungen zulässt. Da dies nicht die Stelle ist, an die Nutzer normalerweise ihr Passwort übermitteln, mag dies unbedenklich erscheinen. Allerdings muss ich doch fragen, ob es Clients gibt, die dorthin unverschlüsselte Verbindungen aufbauen? Wenn ja, dann sollten auch diese unbedingt schnellstmöglich aus dem Betrieb genommen werden.
>
>Außerdem ist mir noch aufgefallen, dass bei Besuch der Startseite von `dsbmobile.de` Verbindungen zu verschiedenen Google-Domains aufgebaut werden (`ajax.googleapis.com`, `fonts.googleapis.com`, `font.gstatic.com`). Als ich lokal die Verbindung zu diesen Domains verhindert habe, verlor die Seite keinerlei Funktionalität. Um den Datenschutz der Nutzer zu gewährleisten, sollten bei Gebrauch der Webseite keine Verbindungen zu Google-Servern aufgebaut werden!
>
>Mit freundlichen Grüßen
>
>Fynn Godau
It is to be noted that Android versions below 4.4.2 only support TLS 1.0, not 1.2, according to the chart on ssllabs.com.
It is to be noted that Android versions below 4.4.2 only support TLS 1.0, not 1.2, according to the chart on [ssllabs.com][ssl].
[ssl]: https://www.ssllabs.com/ssltest/viewClient.html?name=Android&version=4.3&key=61
Having received no response for three weeks, I contacted the heinekingmedia representative again, summarizing my previous points.
September 16th, 2019
Sehr geehrt█ ███ ██████ █████████,
mit Nachdruck muss ich erneut darauf hinweisen, dass iphone.dsbcontrol.de weiterhin nicht verhindert, dass Passwörter unverschlüsselt übertragen werden.
Auch baut die Startseite dsbmobile.de weiterhin ungefragt Verbindungen zu Google-Servern auf. Dies schadet aktiv dem Datenschutz der Nutzer! Deswegen sollten diese Verbindungen unterlassen werden.
Mit freundlichen Grüßen
Fynn Godau
Having received no response for three weeks, I contacted the heinekingmedia representative again, summarizing my previous points.
September 16th, 2019
> Sehr geehrt█ ███ ██████ █████████,
>
>mit Nachdruck muss ich erneut darauf hinweisen, dass `iphone.dsbcontrol.de` weiterhin nicht verhindert, dass Passwörter unverschlüsselt übertragen werden.
>
>Auch baut die Startseite `dsbmobile.de` weiterhin ungefragt Verbindungen zu Google-Servern auf. Dies schadet aktiv dem Datenschutz der Nutzer! Deswegen sollten diese Verbindungen unterlassen werden.
>
>Mit freundlichen Grüßen
>
>Fynn Godau
Ist nicht das einzige. jquery(1.7! urlat),... werden auch weiterhin von den Google Servern geholt. Sollte eigentlich nicht sein.
Auf der Hauptseite wird auch, wie schon genannt, Google Analytic hereingeholt. Auch wird das zwar in der Datenschutzerklärung genannt, allerdings müsste Google noch als CDN gekennzeichnet werden (wg. jquery). Wird nicht gemacht.
PS: 1. Deutsche Antwort:)
Voll traurig:(
https://pastebin.com/mUAgBiCj
Ist nicht das einzige. jquery(1.7! urlat),... werden auch weiterhin von den Google Servern geholt. Sollte eigentlich nicht sein.
Auf der Hauptseite wird auch, wie schon genannt, Google Analytic hereingeholt. Auch wird das zwar in der Datenschutzerklärung genannt, allerdings müsste Google noch als CDN gekennzeichnet werden (wg. jquery). Wird nicht gemacht.
PS: 1. Deutsche Antwort:)
As of October 4th, 2019 or earlier, iphone.dsbcontrol.de is offline. #36
The endpoint app.dsbcontrol.de, which DSBDirect is now using, unfortunately does allow insecure, HTTP without S connections. The question whether any clients establish insecure connections and transfer credentials over it remains unanswered.
Obfuscation is not a transport encryption substitute.
As of October 4th, 2019 or earlier, `iphone.dsbcontrol.de` is offline. #36
The endpoint `app.dsbcontrol.de`, which DSBDirect is now using, unfortunately does allow insecure, `HTTP` without `S` connections. The question whether any clients establish insecure connections and transfer credentials over it remains unanswered.
Obfuscation is not a transport encryption substitute.
erfreut stellte ich am 19. September fest, dass iphone.dsbcontrol.de glaubhaft demonstrierte, dass keine unverschlüsselten Verbindungen dorthin aufgebaut werden, da bei http-Verbindungen immer der (zwar nicht ganz passende) Fehlercode 404 ausgegeben wurde.
Heute bemerkte ich, dass iphone.dsbcontrol.de abgeschaltet worden ist und Mobilclients – schon seit längerer Zeit – jetzt Anfragen an https://app.dsbcontrol.de/JsonHandler.ashx/GetData stellen. Dabei fällt mir erneut auf, dass dort Anfragen, die ohne Transportverschlüsselung gestellt werden, problemlos beantwortet werden. Zwar können dorthin Passwörter nicht direkt im Klartext übertragen werden, aber ein base64-encodeter ge-gzip-ter JSON in einem weiteren JSON versteckt ist kein hinreichender Ersatz. Um sicherzustellen, dass keine Clients unverschlüsselt Zugangsdaten übertragen, sollten auch hier unverschlüsselte Verbindungen nicht beantwortet werden.
Leider muss ich auch erneut darauf hinweisen, dass dsbmobile.de weiterhin ungefragt versucht, Schriftarten von Google-Servern nachzuladen. Wie ich bereits mehrfach erwähnte, bin ich der Meinung, dass dieses Verhalten dem Datenschutz der Nutzer schadet und deshalb unterlassen werden sollte.
Mit freundlichen Grüßen
Fynn Godau
October 4th, 2019
>Sehr geehrt█ ███ ██████ █████████,
>
>erfreut stellte ich am 19. September fest, dass `iphone.dsbcontrol.de` glaubhaft demonstrierte, dass keine unverschlüsselten Verbindungen dorthin aufgebaut werden, da bei `http`-Verbindungen immer der (zwar nicht ganz passende) Fehlercode `404` ausgegeben wurde.
>
>Heute bemerkte ich, dass `iphone.dsbcontrol.de` abgeschaltet worden ist und Mobilclients – schon seit längerer Zeit – jetzt Anfragen an `https://app.dsbcontrol.de/JsonHandler.ashx/GetData` stellen. Dabei fällt mir erneut auf, dass dort Anfragen, die ohne Transportverschlüsselung gestellt werden, problemlos beantwortet werden. Zwar können dorthin Passwörter nicht direkt im Klartext übertragen werden, aber ein base64-encodeter ge-`gzip`-ter JSON in einem weiteren JSON versteckt ist kein hinreichender Ersatz. Um sicherzustellen, dass keine Clients unverschlüsselt Zugangsdaten übertragen, sollten auch hier unverschlüsselte Verbindungen nicht beantwortet werden.
>
>Leider muss ich auch erneut darauf hinweisen, dass `dsbmobile.de` weiterhin ungefragt versucht, Schriftarten von Google-Servern nachzuladen. Wie ich bereits mehrfach erwähnte, bin ich der Meinung, dass dieses Verhalten dem Datenschutz der Nutzer schadet und deshalb unterlassen werden sollte.
>
>Mit freundlichen Grüßen
>
>Fynn Godau
Verbindungsaufbau zu app.dsbcontrol.de über Port 80 nicht mehr möglich.
Die Google Schriftarten werden lokal geladen.
Vielen Dank für Ihr Feedback
Mit freundlichen Grüßen
██████ █████████
October 15th, 2019
>
>Hallo Herr Godau,
>
>
>
>wir haben die angesprochenen Punkte aktualisiert.
>
> * Verbindungsaufbau zu app.dsbcontrol.de über Port 80 nicht mehr möglich.
> * Die Google Schriftarten werden lokal geladen.
>
>
>
>Vielen Dank für Ihr Feedback
>
>
>
>Mit freundlichen Grüßen
>
>██████ █████████
ihre Aussage, der Verbindungsaufbau zu app.dsbcontrol.de sei über Port 80 nicht mehr Möglich, konnte ich nicht bestätigen. So fragt dieser Befehl beispielsweise die verfügbaren Pläne für den Demozugang ab:
curl -X POST http://app.dsbcontrol.de/JsonHandler.ashx/GetData -H 'Content-Type: application/json;charset=utf-8' -d '{"req":{"Data":"H4sIAAAAAAAAA6tWciwo8ExRslJS0lEKLU4tArMNLcwtDAyhIgHlQJGC0qSczGSgCFB5WGpRcWZ+HlDUSM8UKOSSWpaZnAoxwr8YIQvk+iTmpZcmpkMlXRJLUmHixSWhBSlwvlNpXkpOKsQdtQCIWvS6lAAAAA==","DataType":1}}'
Wobei bemerkenswerterweise http im Einsatz ist. Ich bitte um Nachbesserung!
Mit freundlichen Grüßen
Fynn Godau
October 15th, 2019
>Sehr geehrt█ ███ ██████ █████████,
>
>ihre Aussage, der Verbindungsaufbau zu app.dsbcontrol.de sei über Port 80 nicht mehr Möglich, konnte ich nicht bestätigen. So fragt dieser Befehl beispielsweise die verfügbaren Pläne für den Demozugang ab:
>
>`curl -X POST http://app.dsbcontrol.de/JsonHandler.ashx/GetData -H 'Content-Type: application/json;charset=utf-8' -d '{"req":{"Data":"H4sIAAAAAAAAA6tWciwo8ExRslJS0lEKLU4tArMNLcwtDAyhIgHlQJGC0qSczGSgCFB5WGpRcWZ+HlDUSM8UKOSSWpaZnAoxwr8YIQvk+iTmpZcmpkMlXRJLUmHixSWhBSlwvlNpXkpOKsQdtQCIWvS6lAAAAA==","DataType":1}}'`
>
>Wobei bemerkenswerterweise `http` im Einsatz ist. Ich bitte um Nachbesserung!
>
>Mit freundlichen Grüßen
>
>Fynn Godau
<head><title>Dokument verschoben</title></head>
<body><h1>Objekt verschoben</h1>Dieses Dokument befindet sich möglicherweise <a HREF="https://app.dsbcontrol.de/JsonHandler.ashx/GetData">hier</a>.</body>
Das ist doch genau, was der HTTP-Standard vorsieht, wenn der Traffic auf HTTPS umgeleitet werden soll.
Dass der Server den Port dann ummernoch unter :80 verrichbar ist, hat Kompatiblitätsgründe und muss gemäß Standard so sein. Wenn man das im Browser eintippt, wird man aber sehen, dass als Status-Code ein 30X geliefert wird und der Browser den Traffic daher automatisch auf :443 weiterleitet.
```
<head><title>Dokument verschoben</title></head>
<body><h1>Objekt verschoben</h1>Dieses Dokument befindet sich möglicherweise <a HREF="https://app.dsbcontrol.de/JsonHandler.ashx/GetData">hier</a>.</body>
```
Das ist doch genau, was der HTTP-Standard vorsieht, wenn der Traffic auf HTTPS umgeleitet werden soll.
Dass der Server den Port dann ummernoch unter :80 verrichbar ist, hat Kompatiblitätsgründe und muss gemäß Standard so sein. Wenn man das im Browser eintippt, wird man aber sehen, dass als Status-Code ein `30X` geliefert wird und der Browser den Traffic daher automatisch auf :443 weiterleitet.
Ja.Es wird meistens ein Redirect auf https gesendet. In der http Anfrage stehen aber dann keine Antwort Daten. Diese sollten nur über https kommen. Ist aber hier nicht der Fall (oder war es auch nach der Antwort noch. kann das vom handy nicht prüfen)
Ja.Es wird meistens ein Redirect auf https gesendet. In der http Anfrage stehen aber dann keine Antwort Daten. Diese sollten nur über https kommen. Ist aber hier nicht der Fall (oder war es auch nach der Antwort noch. kann das vom handy nicht prüfen)
Ich bekomme bei einer http Anfrage jetzt nur noch folgendes:
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=UTF-8
< Location: https://app.dsbcontrol.de/JsonHandler.ashx/GetData
< Server: Microsoft-IIS/7.5
< X-Powered-By: ASP.NET
< Date: Wed, 16 Oct 2019 12:17:39 GMT
< Connection: close
< Content-Length: 203
Schön. Hat sich erledigt. http ist nun nicht mehr möglich.
So. kleines Update:
Ich bekomme bei einer http Anfrage jetzt nur noch folgendes:
```
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html; charset=UTF-8
< Location: https://app.dsbcontrol.de/JsonHandler.ashx/GetData
< Server: Microsoft-IIS/7.5
< X-Powered-By: ASP.NET
< Date: Wed, 16 Oct 2019 12:17:39 GMT
< Connection: close
< Content-Length: 203
```
Schön. Hat sich erledigt. http ist nun nicht mehr möglich.
Schön, dass das endlich geklärt ist. Als ich das getestet habe, wurde die Antwort noch ganz normal, also wie über https auch, beantwortet.
October 16th, 2019
Sehr geehrter Herr Godau,
vielleicht war zu Ihrem Test die Änderung noch nicht auf allen Servern aktiv.
Aktuell kommt folgende Antwort:
<head><title>Dokument verschoben</title></head> <body><h1>Objekt verschoben</h1>Dieses Dokument befindet sich möglicherweise <a HREF="https://app.dsbcontrol.de/JsonHandler.ashx/GetData">hier</a>.</body>
Mit freundlichen Grüßen
██████ █████████
Schön, dass das endlich geklärt ist. Als ich das getestet habe, wurde die Antwort noch ganz normal, also wie über `https` auch, beantwortet.
October 16th, 2019
>Sehr geehrter Herr Godau,
>
>
>
>vielleicht war zu Ihrem Test die Änderung noch nicht auf allen Servern aktiv.
>
>Aktuell kommt folgende Antwort:
>
>
>
>`<head><title>Dokument verschoben</title></head> <body><h1>Objekt verschoben</h1>Dieses Dokument befindet sich möglicherweise <a HREF="https://app.dsbcontrol.de/JsonHandler.ashx/GetData">hier</a>.</body>`
>
>
>
>Mit freundlichen Grüßen
>
>██████ █████████
Da es wegen dem neuen Endpoint (#81) noch einige Sicherheitsbedenken gibt, habe ich mal eine E-Mail an heinekingmobile verfasst:
12.4.2020
Sehr geehrte Damen und Herren,
erstmal vielen Dank für die neue API in DSBmobile 3.0.12.
Allerdings, wie bei den letzten APIs, sind uns mehrere Sicherheitsbedenken gekommen:
Der Endpoint mobileapi.dsbcontrol.de unterstützt noch http Anfragen, welche unverschlüsselt sind und dritte die Zugangsdaten über eine Man-in-the-middle Attacke ausspionieren könnten. Dies sollte umgehend eingestellt werden.
Der Endpoint unterstützt zwar TLS, allerdings nicht die neuste Version (TLS 1.3). Ich bitte um Nachbesserung
IPv6 Unterstützung: Sehr viele Menschen haben mittlerweile schon die Möglichkeit, die nächste Generation von IP Adressen anzusprechen. Der Host unterstützt leider nur IPv4. IPv6 ist sehr wichtig, da kaum nohc IPv4 Adressen frei sind und deswegen IPv4 überholt werden wird.
Nach einem SSL Test (https://www.ssllabs.com/ssltest/analyze.html?d=mobileapi.dsbcontrol.de) musste ich leider feststellen, dass das Gateway neben schwache kryptografischen Verfahren (Cipher Suites), auch das veralteten Versionen von TLS unterstützt. Ich bitte, dass neben TLS 1.2 nur noch TLS 1.3 unterstützt wird.
Ich fordere, dass diese sicherheits Mängel umgehend beseitigt werden.
Vielen Dank
Mit freundlichen Grüßen
Moritz Zwerger
Da es wegen dem neuen Endpoint (#81) noch einige Sicherheitsbedenken gibt, habe ich mal eine E-Mail an heinekingmobile verfasst:
12.4.2020
>Sehr geehrte Damen und Herren,
>erstmal vielen Dank für die neue API in DSBmobile 3.0.12.
>Allerdings, wie bei den letzten APIs, sind uns mehrere Sicherheitsbedenken gekommen:
>1. Der Endpoint mobileapi.dsbcontrol.de unterstützt noch http Anfragen, welche unverschlüsselt sind und dritte die Zugangsdaten über eine Man-in-the-middle Attacke ausspionieren könnten. Dies sollte umgehend eingestellt werden.
>2. Der Endpoint unterstützt zwar TLS, allerdings nicht die neuste Version (TLS 1.3). Ich bitte um Nachbesserung
>3. IPv6 Unterstützung: Sehr viele Menschen haben mittlerweile schon die Möglichkeit, die nächste Generation von IP Adressen anzusprechen. Der Host unterstützt leider nur IPv4. IPv6 ist sehr wichtig, da kaum nohc IPv4 Adressen frei sind und deswegen IPv4 überholt werden wird.
>4. Nach einem SSL Test (https://www.ssllabs.com/ssltest/analyze.html?d=mobileapi.dsbcontrol.de) musste ich leider feststellen, dass das Gateway neben schwache kryptografischen Verfahren (Cipher Suites), auch das veralteten Versionen von TLS unterstützt. Ich bitte, dass neben TLS 1.2 nur noch TLS 1.3 unterstützt wird.
>Ich fordere, dass diese sicherheits Mängel umgehend beseitigt werden.
>Vielen Dank
>Mit freundlichen Grüßen
>Moritz Zwerger
So. Jetzt ist das ganze erledigt (bis zur nächsten API^^):
20.04.20
Sehr geehrter Herr Zwerger,
vielen Dank für Ihre Nachricht. Ich hoffe es geht Ihnen gut.
Wir nutzen aktuell die ruhigen Tage um die Serverinfrastruktur umzustellen. Ich denke bis zum Ende der Woche werden sich einige der genannten Punkte erledigt haben.
Gerade bei den TLS Standards dürfen wir leider die Unterstützung der Altgeräte nie vernachlässigen. Wir haben aufgrund der hohen Installationszahlen noch immer einige tausend Geräte mit Android 4.0 im Einsatz,
diese werden wir jetzt mit einem der nächsten Updates aktiv darüber informieren, dass wir diese Android Version leider nicht mehr unterstützten. Anschließend ziehen wir den Standard entsprechend auf den Webservern hoch.
Der genannte http Zugriff wurde inzwischen wieder deaktiviert, keine unserer Apps hat über diesen kommuniziert.
Bei Rückfragen können Sie jederzeit wieder auf mich zukommen.
Mit freundlichen Grüßen
████████ ██████████
So. Jetzt ist das ganze erledigt (bis zur nächsten API^^):
20.04.20
>Sehr geehrter Herr Zwerger,
>vielen Dank für Ihre Nachricht. Ich hoffe es geht Ihnen gut.
Wir nutzen aktuell die ruhigen Tage um die Serverinfrastruktur umzustellen. Ich denke bis zum Ende der Woche werden sich einige der genannten Punkte erledigt haben.
Gerade bei den TLS Standards dürfen wir leider die Unterstützung der Altgeräte nie vernachlässigen. Wir haben aufgrund der hohen Installationszahlen noch immer einige tausend Geräte mit Android 4.0 im Einsatz,
diese werden wir jetzt mit einem der nächsten Updates aktiv darüber informieren, dass wir diese Android Version leider nicht mehr unterstützten. Anschließend ziehen wir den Standard entsprechend auf den Webservern hoch.
Der genannte http Zugriff wurde inzwischen wieder deaktiviert, keine unserer Apps hat über diesen kommuniziert.
>Bei Rückfragen können Sie jederzeit wieder auf mich zukommen.
>Mit freundlichen Grüßen
>████████ ██████████
Wie beispielsweise durch den SSLLabs-Test ersichtlich wird, haben sie jetzt tatsächlich TLS 1.0 und TLS 1.1 abgeschaltet, auch für app.dsbcontrol.de.
Damit ist diese App auf älteren Geräten kaputt gegangen. Mit der Library Conscrypt kann man jedoch auch auf älteren Android-Versionen neuere TLS-Standarts unterstützen.¹ Ich habe das gerade im Emulator auf Android 4.0 probiert; das klappt auch. Deshalb würde ich diese Änderungen pushen und noch heute #82 mergen und ein Update releasen, damit die App so schnell wie möglich auf älteren Geräten wieder benutzbar ist.
¹Bei unserer App funktioniert das ganz gut, weil wir das native mit HttpURLConnection machen. DSBmobile benutzt Retrofit und OkHttp (ohne es zu crediten), da geht das vermutlich nicht so einfach.
Wie beispielsweise durch [den SSLLabs-Test](https://www.ssllabs.com/ssltest/analyze.html?d=mobileapi.dsbcontrol.de) ersichtlich wird, haben sie jetzt tatsächlich TLS 1.0 und TLS 1.1 abgeschaltet, auch für `app.dsbcontrol.de`.
Damit ist diese App auf älteren Geräten kaputt gegangen. Mit der Library [Conscrypt](https://conscrypt.org) kann man jedoch auch auf älteren Android-Versionen neuere TLS-Standarts unterstützen.¹ Ich habe das gerade im Emulator auf Android 4.0 probiert; das klappt auch. Deshalb würde ich diese Änderungen pushen und noch heute #82 mergen und ein Update releasen, damit die App so schnell wie möglich auf älteren Geräten wieder benutzbar ist.
¹Bei unserer App funktioniert das ganz gut, weil wir das native mit `HttpURLConnection` machen. DSBmobile benutzt Retrofit und OkHttp (ohne es zu crediten), da geht das vermutlich nicht so einfach.
fynngodau
The
iphone.dsbcontrol.de,app.dsbcontrol.deandlight.dsbcontrol.deservers only support TLS v1.0, which is an obsolete, insecure protocol.This issue shall track possible client-side mitigations and other actions.
[The main issue has been solved as of August 22nd. It is still open to track responses to the latest email sent to a heinekingmedia representative.]
Heinekingmedia has been informed about this and other issues earlier today, August 11th, 2019. The message's content will be provided here at a later date, as well as any responses.
The
dsbmobile.deIHK skinihkmobile.dsbcontrol.de(also available at other domains) allows connecting via a secure TLS v1.2 connection, as does the corresponding skinned client (presumably) (Android:de.ihkbb.dsbmobile).For the IHK skin, content is mirrored from
app.dsbcontrol.de(used indsbmobile.de) orlight.dsbcontrol.de(linked to by the "iPhone service"iphone.dsbcontrol.de/iPhoneService.svc) (both insecure) to a place somewhere atwww22content.dsbcontrol.deorwww21content.dsbcontrol.de. The resource locations may sometimes be similar, however, a different auth token is needed in (and provided by) the IHK system.Obtaining it is difficult, however: reading the Android client's traffic showed that it is posting and receiving obscure base64-lookalike messages whose structure is currently unknown.
On or around August 22nd, Heinekingmedia has disabled the SSLv2 protocol that caused a security vulnerability and enabled TLS v1.2 on
dsbmobile.deas well asiphone.,light.andapp.dsbcontrol.de.For transparency, communication with Heinekingmedia is provided below.
+1
Heinekingmedia has been contacted about a still unresolved issue with allowing insecure connections on
iphone.dsbcontrol.deas well as a privacy issue ondsbmobile.dedue to connections to Google. None of these still outstanding issues directly affect DSBDirect. Communication is provided nonetheless.It is to be noted that Android versions below 4.4.2 only support TLS 1.0, not 1.2, according to the chart on ssllabs.com.
Having received no response for three weeks, I contacted the heinekingmedia representative again, summarizing my previous points.
As of September 19th, 2019,
iphone.dsbcontrol.de404s if it is contacted viaHTTPwithoutS.Voll traurig:( https://pastebin.com/mUAgBiCj
Ist nicht das einzige. jquery(1.7! urlat),... werden auch weiterhin von den Google Servern geholt. Sollte eigentlich nicht sein.
Auf der Hauptseite wird auch, wie schon genannt, Google Analytic hereingeholt. Auch wird das zwar in der Datenschutzerklärung genannt, allerdings müsste Google noch als CDN gekennzeichnet werden (wg. jquery). Wird nicht gemacht.
PS: 1. Deutsche Antwort:)
As of October 4th, 2019 or earlier,
iphone.dsbcontrol.deis offline. #36The endpoint
app.dsbcontrol.de, which DSBDirect is now using, unfortunately does allow insecure,HTTPwithoutSconnections. The question whether any clients establish insecure connections and transfer credentials over it remains unanswered.Obfuscation is not a transport encryption substitute.
Bemerkenswerterweise wurde das bisher immer angehängte "Bei Rückfragen können Sie sich gerne direkt an mich wenden." diesmal ausgelassen.
Das ist doch genau, was der HTTP-Standard vorsieht, wenn der Traffic auf HTTPS umgeleitet werden soll.
Dass der Server den Port dann ummernoch unter :80 verrichbar ist, hat Kompatiblitätsgründe und muss gemäß Standard so sein. Wenn man das im Browser eintippt, wird man aber sehen, dass als Status-Code ein
30Xgeliefert wird und der Browser den Traffic daher automatisch auf :443 weiterleitet.Ja.Es wird meistens ein Redirect auf https gesendet. In der http Anfrage stehen aber dann keine Antwort Daten. Diese sollten nur über https kommen. Ist aber hier nicht der Fall (oder war es auch nach der Antwort noch. kann das vom handy nicht prüfen)
So. kleines Update:
Ich bekomme bei einer http Anfrage jetzt nur noch folgendes:
Schön. Hat sich erledigt. http ist nun nicht mehr möglich.
Schön, dass das endlich geklärt ist. Als ich das getestet habe, wurde die Antwort noch ganz normal, also wie über
httpsauch, beantwortet.Da es wegen dem neuen Endpoint (#81) noch einige Sicherheitsbedenken gibt, habe ich mal eine E-Mail an heinekingmobile verfasst:
12.4.2020
So. Jetzt ist das ganze erledigt (bis zur nächsten API^^):
20.04.20
Wie beispielsweise durch den SSLLabs-Test ersichtlich wird, haben sie jetzt tatsächlich TLS 1.0 und TLS 1.1 abgeschaltet, auch für
app.dsbcontrol.de.Damit ist diese App auf älteren Geräten kaputt gegangen. Mit der Library Conscrypt kann man jedoch auch auf älteren Android-Versionen neuere TLS-Standarts unterstützen.¹ Ich habe das gerade im Emulator auf Android 4.0 probiert; das klappt auch. Deshalb würde ich diese Änderungen pushen und noch heute #82 mergen und ein Update releasen, damit die App so schnell wie möglich auf älteren Geräten wieder benutzbar ist.
¹Bei unserer App funktioniert das ganz gut, weil wir das native mit
HttpURLConnectionmachen. DSBmobile benutzt Retrofit und OkHttp (ohne es zu crediten), da geht das vermutlich nicht so einfach.Super. Mir wurde von HKM nochmals soeben bestätigt, dass es abgeschaltet wurde. Feel free to merge:)
Da jetzt alle Clients einigermaßen sichere Verbindungen aufbauen, schließe ich dieses Issue.
Übrigens ist die APK-Größe jetzt 7.9 MB… :(