Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › HTTPS: Fritzbox bekommt Let's Encrypt…

Wo ist da nun das Problem?

  1. Thema

Neues Thema Ansicht wechseln


  1. Wo ist da nun das Problem?

    Autor: Apfelbrot 16.12.17 - 23:17

    Das es dann eine Liste mit Hostnamen von Fritzboxen gibt?

    Seit wann ist das nicht bekannt sein eines Hostnamen denn bitteschön ein Sicherheitsfeature?

    Jemand stellt seine Fritzbox von außen Zugreifbar ins Internet.
    Wen jucken da Hostnamen?

    Das ist genau so wie der Schwachfug dass die IHK anscheinend in den Fi-Si Prüfungen erwartet dass "SSID Verstecken" ein Sicherheitsfeature wäre....

  2. Re: Wo ist da nun das Problem?

    Autor: gaym0r 17.12.17 - 03:04

    Wird nun eine Schwachstelle bekannt, mit der man von außen Zugriff auf die Fritzbox erlangen könnte, muss man sich nur noch dieser Liste bedienen und hat alle IP-Adressen von Fritzboxen. Das ist OK für dich? OK.

  3. Re: Wo ist da nun das Problem?

    Autor: xploded 17.12.17 - 11:23

    gaym0r schrieb:
    --------------------------------------------------------------------------------
    > Wird nun eine Schwachstelle bekannt, mit der man von außen Zugriff auf die
    > Fritzbox erlangen könnte, muss man sich nur noch dieser Liste bedienen und
    > hat alle IP-Adressen von Fritzboxen. Das ist OK für dich? OK.

    Man konnte ja im letzten Jahr deutlich sehen, wie viel es bringt, wenn Router in keiner Liste stehen. Da hat es ja Monate gedauert, bis die ganzen Telekom Router angegriffen wurden. Ach halt, das waren ja nur Stunden...
    Hier wird zwar ein "scheinbares" Problem besprochen aber die Ursache vollkommen außer Acht gelassen. Nicht das Zertifikat ist das Problem, sondern der Weg, wie der User darauf zugreift.

  4. Re: Wo ist da nun das Problem?

    Autor: Anonymer Nutzer 17.12.17 - 12:03

    Ja aber den kompletten ivp4-Adressraum abscannen geht mit einem Botnetz schnell, wenn ein Angreifer aber kein Botnetz zur Hand hat, ist die Einstiegshürde größer, wenn er im Dunkeln fischen muss, statt eine vorgegebene Liste abarbeiten kann, oder?

    Vor allem weil es dann die Effektivität der 'security-by-obscurity'-Portvergabe weiter untergräbt.
    Aber ja, mit Botnetz ist so eine Liste für jeden versierten Angreifer egal. Ein allgemeines Tool zum Portscannen für das eigene Botnetz ist da sicher eh schon längst vorhanden.

  5. Re: Wo ist da nun das Problem?

    Autor: Tuxgamer12 17.12.17 - 12:08

    xploded schrieb:
    --------------------------------------------------------------------------------
    > Man konnte ja im letzten Jahr deutlich sehen, wie viel es bringt, wenn
    > Router in keiner Liste stehen. Da hat es ja Monate gedauert, bis die ganzen
    > Telekom Router angegriffen wurden. Ach halt, das waren ja nur Stunden...

    Sehr schön, dass du das ansprichst - das ist nämlich genau extrem schönes Beispiel, wie cool Liste mit z.B. Fritzboxen tatsächlich ist.

    NEEE, die Telekom Router wurden letztes Jahr gar nicht angegriffen! Die hatten anderes Betriebssystem, das damit schlicht und einfach nicht anfällig für die Lücke war, die ausgenutzt wurde.

    Die Telekom-Router sind halt einfach so ***, dass sie aufgrund der Packete massenhaft abgeschmiert sind - was schlicht und einfach Pech für den Angreifer war.

    Mit einer Liste der zu hackenden Router wäre das nicht passiert! Da hätte der Hacker still und heimlich die passenden Router hacken können - ohne dass versehentlich 1,25 Millionen Telekom-Router abschmieren und der Hacker ungewollt im Rampenlicht der Aufmerksamkeit steht.

    Also ja - security by obscurity kann nie die wirklich Lösung sein. So eine Liste "ach ja, die und die und die Router laufen mit FritzOS" ist dennoch einfach nur Mist und berechtigte Kritik.

  6. Re: Wo ist da nun das Problem?

    Autor: xploded 17.12.17 - 17:40

    So wie ich mich erinnere, wurde der Schadcode sehr wohl aufgespielt auf die Router - und hat nicht wie gewünscht funktioniert.
    Aber es ist schon Recht: Lieber auf ein falsches Zertifikat zugreifen und hoffen, das es wirklich die eigene Fritte ist.

    Wie schön, das man auch immer wieder liest, den "gesamten IP Bereich scannen".
    Wenn man weiß, welche Subnetze die großen ISP nutzen, muss man gar nicht den "gesamten" Bereich scannen.

    Im Umkehrschluss heißt es nun: Mit einem falschen Zertifikat bin ich sicher, man kann mich ja nicht finden. Dauert ja viel zu lange den "gesamten" IP Bereich zu scannen. Ist zwar falsch, aber wen schert es...
    Ich freue mich schon auf die nächste kritische Lücke mein Nicht-AVM Routern. Da schreibe ich dann direkt drunter: Leute, kann nichts passieren! Gibt ja keine Liste.
    Also ich als Angreifer würde mich einen Scheiss um die Liste kümmern, da bekomme ich dann ja nur die Adressen derer, die wirklich LE einsetzen. Ich würde trotzdem die Subnetze abgrasen, da finde ich wenigstens alle und nicht nur die paar die LE einsetzen. Zeitlich etwas aufwendiger aber dafür auch lohnender.

  7. Re: Wo ist da nun das Problem?

    Autor: ul mi 17.12.17 - 18:20

    Das wird dich jetzt erschrecken, aber der Server sieht. welchen Hostnamen die Anfrage haben will und kann sich dann unterschiedlich verhalten (mit SNI vor dem SSL-Verbindungsaufbau).
    Im Grundsatz kann der Server also auf alle Anfragen, die nicht genau zum Namen schurzelfurz08154711.my.fritz.box (oder whatever) wollen, zum Beispiel einen 403 liefern, oder gleich den kompletten TLS-Verbindungsaufbau ablehnen. (Dafür müsste man das HTTP-Server-Handling vermutlich entsprechend handklöppeln und nicht einfach busybox nehmen, von daher wird das die Fritzbox nicht so machen, aber von den Protokollen her ginge das.)

  8. Re: Wo ist da nun das Problem?

    Autor: Tuxgamer12 17.12.17 - 18:40

    xploded schrieb:
    --------------------------------------------------------------------------------
    > So wie ich mich erinnere, wurde der Schadcode sehr wohl aufgespielt auf die
    > Router - und hat nicht wie gewünscht funktioniert.

    Das war der erste Gedanke, als massig Telekomrouter ausgefallen sind. Später hat man sich den Angriff bisschen besser angeschaut - hast dann wohl nicht mehr verfogt (oder ich habe etwas nicht mitbekommen?).

    Empfehle jedenfalls den Artiekl: http://www.spiegel.de/netzwelt/gadgets/telekom-hackerangriff-nicht-die-telekom-router-waren-das-ziel-a-1123805.html

    > Aber es ist schon Recht: Lieber auf ein falsches Zertifikat zugreifen und
    > hoffen, das es wirklich die eigene Fritte ist.

    Mir ist völlig (!) schleierhaft, wie du hier von "hoffen" sprechen kannst. Also ICH weiß, was mein Zertifikat ist (bzw. mein Browser weiß es) - von daher weiß ich, dass es mein Gerät (und auch meine Fritte, wenn ich eine hätte) ist.

    Für einen Service, den sowieso ich nur nutzen will, jedem Internetnutzer mitzuteilen, was mein Zertifikat ist; ich wüsste nicht, was das bringen sollte.

    > Wie schön, das man auch immer wieder liest, den "gesamten IP Bereich
    > scannen".
    > Wenn man weiß, welche Subnetze die großen ISP nutzen, muss man gar nicht
    > den "gesamten" Bereich scannen.

    Wüsste nicht, wieso du mir das jetzt schreibst - kann mich nicht erinnern, etwas der Art geschrieben zu haben.

    > Im Umkehrschluss heißt es nun: Mit einem falschen Zertifikat bin ich
    > sicher, man kann mich ja nicht finden.

    Bullshit. Sorry - aber das behauptest allein du.

    > Dauert ja viel zu lange den
    > "gesamten" IP Bereich zu scannen. Ist zwar falsch, aber wen schert es...
    > Ich freue mich schon auf die nächste kritische Lücke mein Nicht-AVM
    > Routern. Da schreibe ich dann direkt drunter: Leute, kann nichts passieren!
    > Gibt ja keine Liste.

    Jetzt machst du dich ziemlich lächerlich.

    Verstehe halt, dass es "Sicherheit" kein absoluter Stand ist. Ich kann nur noch einmal wiederholen:

    "Also ja - security by obscurity kann nie die wirklich Lösung sein. So eine Liste "ach ja, die und die und die Router laufen mit FritzOS" ist dennoch einfach nur Mist und berechtigte Kritik."

    Niemand hat behauptet, dass diese Liste der "Weltuntergang" ist. Aber es sind nun einmal Informationen, die Hacker nutzen könnten (wohlgemerkt: könnten) - und damit definitiv berechtigt, darauf grundsätzlich mal hinzuweisen.

  9. Re: Wo ist da nun das Problem?

    Autor: xploded 17.12.17 - 18:58

    ul mi schrieb:
    --------------------------------------------------------------------------------
    > Das wird dich jetzt erschrecken, aber der Server sieht. welchen Hostnamen
    > die Anfrage haben will und kann sich dann unterschiedlich verhalten (mit
    > SNI vor dem SSL-Verbindungsaufbau).
    > Im Grundsatz kann der Server also auf alle Anfragen, die nicht genau zum
    > Namen schurzelfurz08154711.my.fritz.box (oder whatever) wollen, zum
    > Beispiel einen 403 liefern, oder gleich den kompletten
    > TLS-Verbindungsaufbau ablehnen. (Dafür müsste man das HTTP-Server-Handling
    > vermutlich entsprechend handklöppeln und nicht einfach busybox nehmen, von
    > daher wird das die Fritzbox nicht so machen, aber von den Protokollen her
    > ginge das.)

    Es wird sich nun erschrecken, aber das läuft anders. Der Server liefert ein Zertifikat aus, und zwar das, was in seinem (virtuellen) Host eingetragen ist. Es juckt den Server nicht einen Meter, ob es passt oder gültig ist. So kann man ein beliebiges Zertifikat einbinden - egal ob es passt oder abgelaufen ist.
    Die Prüfung ob es gültig ist (Zertifikatkette), passt (Hostname) und nicht abgelaufen bzw. zurückgezogen wurde findet auf der Clientseite statt.
    In deinem Beispiel sagt der Client nur: Du wolltest HTTPS://1.2.3.4 hier kommt nun aber HTTPS://irgendwas.irgendwo.de - das ist gefährlich, wirklich fortzufahren?

  10. Re: Wo ist da nun das Problem?

    Autor: xploded 17.12.17 - 19:22

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > Mir ist völlig (!) schleierhaft, wie du hier von "hoffen" sprechen kannst.
    > Also ICH weiß, was mein Zertifikat ist (bzw. mein Browser weiß es) - von
    > daher weiß ich, dass es mein Gerät (und auch meine Fritte, wenn ich eine
    > hätte) ist.
    >
    > Für einen Service, den sowieso ich nur nutzen will, jedem Internetnutzer
    > mitzuteilen, was mein Zertifikat ist; ich wüsste nicht, was das bringen
    > sollte.

    Hier kann man nachlesen, warum und welchen Zweck:
    https://www.certificate-transparency.org/

    >
    >
    > Niemand hat behauptet, dass diese Liste der "Weltuntergang" ist. Aber es
    > sind nun einmal Informationen, die Hacker nutzen könnten (wohlgemerkt:
    > könnten) - und damit definitiv berechtigt, darauf grundsätzlich mal
    > hinzuweisen.

    Jo, könnten sie ja. Kann und will ich ja nicht abstreiten, aber ist doch eigentlich viel zu aufwendig und zu wenig Ertrag. Filter doch mal die Liste, das sind doch gar nicht viele. Alles was älter wie 60 Tage ist kannst wegwerfen (man kann es natürlich versuchen, aber da LE nach 60 Tagen erneuert ist wahrscheinlich tot...) - da bleiben doch gar nicht so viele über. Und das sind dann nicht mal alles Fritten, da sind ja nen paar Raspis, Nextcloud, Owncloud, NAS und so ein Kram drunter.

    Mir fehlt eigentlich ein sinnvolles Ende des Artikels. Zum Beispiel: Wenn sie von außen auf ihre Fritzbox zugreifen wollen, empfehlen wir den Zugang über den eingebauten VPN Server der Fritzbox.

  11. Re: Wo ist da nun das Problem?

    Autor: Tuxgamer12 17.12.17 - 20:15

    xploded schrieb:
    --------------------------------------------------------------------------------
    > Tuxgamer12 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Mir ist völlig (!) schleierhaft, wie du hier von "hoffen" sprechen
    > kannst.
    > > Also ICH weiß, was mein Zertifikat ist (bzw. mein Browser weiß es) - von
    > > daher weiß ich, dass es mein Gerät (und auch meine Fritte, wenn ich eine
    > > hätte) ist.
    > >
    > > Für einen Service, den sowieso ich nur nutzen will, jedem Internetnutzer
    > > mitzuteilen, was mein Zertifikat ist; ich wüsste nicht, was das bringen
    > > sollte.
    >
    > Hier kann man nachlesen, warum und welchen Zweck:
    > www.certificate-transparency.org

    Sorry, aber WHAT?

    Ich habe so bisschen das Gefühl, du durchschaust dieses Zertifikat-Zeugs noch nicht so ganz. Aus der verlinkten Seite:

    "Specifically, Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority."

    Gut - also wenn ICH mir ein Zertifikat generiere, werde ich wohl ziemlich sicher sein, dass ICH dieses Zertifikat gerade erstellt habe. Logisch? Und da ich praktisch die Instanz bin, die dieses Zertifikat akzeptiert hat, bin ich mir wohl ziemlich sicher, dass da alles OK ist. Logisch?

    Verstehst du, das ganze Problem ist, du bekommst Zertifikat XY und musst entscheiden, ob du diesem vertraust.
    Weil du eben nicht die Zertifikate von jeder Website dieser Welt kennen kannst, kannst du diese Frage ja selber nicht beantworten. Deshalb gibt es diese Instanzen zum Signieren, die dir sagen: "Zertifikat XY kannst du vertrauen". Und du musst dann nur noch diesen Signierungs-Instanzen vertrauen.

    Da hier in der Vergangenheit trotzdem auch Mist gebaut wurde, gibt es "Google's Certificate Transparency project".

    Da ich mir (und du dir) offensichtlich selbst vertrauen kann (wow) - merkst, dass man sich dann das alles sparen kann?

    > Und das sind dann nicht mal alles Fritten, da sind ja nen paar Raspis, Nextcloud,
    > Owncloud, NAS und so ein Kram drunter.

    Hinter einer Fritzbox? Worum es ja geht?

    > Mir fehlt eigentlich ein sinnvolles Ende des Artikels. Zum Beispiel: Wenn
    > sie von außen auf ihre Fritzbox zugreifen wollen, empfehlen wir den Zugang
    > über den eingebauten VPN Server der Fritzbox.

    Wäre nicht verkehrt, gehört aber nicht zwingend zu einer neutralen Berichtserstattung. Na, wäre vermutlich tatsächlich gutes Ende gewesen - vor allem nach einem Satz wie "Viele Anwender verwenden ihre Fritzbox anscheinend auch, um den HTTPS-Port 443 direkt an dahinter stehende Server weiterzuleiten." ohne weiteren Erklärungen.

  12. Re: Wo ist da nun das Problem?

    Autor: Tuxgamer12 17.12.17 - 20:19

    xploded schrieb:
    --------------------------------------------------------------------------------
    > Es wird sich nun erschrecken, aber das läuft anders.

    Es wird dich erschrecken, aber du liegst falsch. ul mi hats doch gut geschrieben:

    >> (mit SNI vor dem SSL-Verbindungsaufbau)

    Wenn man halt nicht weiß, was SNI ist, Tipp: Kurz nachschauen. So Wikipedia ist immer gute Anlaufstelle. Ist dann meistens besser, als total am Thema vorbeizureden.

    https://de.wikipedia.org/wiki/Server_Name_Indication

  13. Re: Wo ist da nun das Problem?

    Autor: xploded 17.12.17 - 22:37

    Tuxgamer12 schrieb:
    --------------------------------------------------------------------------------
    > xploded schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Es wird sich nun erschrecken, aber das läuft anders.
    >
    > Es wird dich erschrecken, aber du liegst falsch. ul mi hats doch gut
    > geschrieben:
    >
    > >> (mit SNI vor dem SSL-Verbindungsaufbau)
    >
    > Wenn man halt nicht weiß, was SNI ist, Tipp: Kurz nachschauen. So Wikipedia
    > ist immer gute Anlaufstelle. Ist dann meistens besser, als total am Thema
    > vorbeizureden.
    >
    > de.wikipedia.org

    Und der Server überprüft immer noch nicht, ob das Zertifikat zu ihm passt und/oder gültig ist. Wenn dem so wäre, würde es keine "roten" Seiten mehr geben (das Zertifikat ist ungültig).
    Ich kenne SNI - ich nutze SNI. Kleiner Tipp: Legt mal nen vhost an und schmeisst dem irgendein Zertifikat eines anderen Hosts rein. Kostet keinen Aufwand und kaum Zeit. Ihr werdet sehen: Das "falsche" Zertifikat wird vom SERVER ausgeliefert - der CLIENT wird merken, das es nicht passt (rote Seite). Genauso wie der Server ein abgelaufenes Zertifikat ausliefert - weil es ihn einfach nicht juckt.

  14. Re: Wo ist da nun das Problem?

    Autor: 0xDEADC0DE 18.12.17 - 09:19

    Das ist genauso wie bei den geheimen Telefonnummern:

    Wenn du nicht willst, dass sie veröffentlicht wird, würdest du dann wollen, dass sie in einer für jeden einsehbaren und leicht durchsuchbaren Datenbank/Liste auftaucht?

    Wohl eher kaum.

    Manche geben auf Facebook aber auch an, dass sie im Urlaub sind... da freut sich jeder Einbrecher.

    Das ist also schon ein Problem, man muss keine Einladung versicken, wenn das andere für einen tun.

  15. Re: Wo ist da nun das Problem?

    Autor: Tuxgamer12 18.12.17 - 10:03

    xploded schrieb:
    --------------------------------------------------------------------------------
    > Ich kenne SNI - ich nutze SNI. Kleiner Tipp: Legt mal nen vhost an und
    > schmeisst dem irgendein Zertifikat eines anderen Hosts rein. Kostet keinen
    > Aufwand und kaum Zeit. Ihr werdet sehen: Das "falsche" Zertifikat wird vom
    > SERVER ausgeliefert - (...)

    Ich bitte dich und kann nur noch einmal wiederholen:
    ul mi hat das doch klar und (eigentlich) unmissverständlich ausgedrückt.

    "oder gleich den kompletten TLS-Verbindungsaufbau ablehnen."

    In anderen Worten: Du liferst nicht ein "flasches" Zertifikat aus, du lieferst GAR KEINES aus und eine nette Fehlermeldung ;).

    Und jetzt will ich dich mal sehen, wie dein Client jetzt ohne Zertifikat eine TLS-Verbindung weiter aufbaut.

  16. Re: Wo ist da nun das Problem?

    Autor: xploded 18.12.17 - 10:17

    Was sind denn diese ganzen "nicht vertrauenswürdigen Verbindungen"? Erklär mir die mal. Bitte. Danke!
    Du willst nun nicht sagen, das die unverschlüsselt sind?

  17. Re: Wo ist da nun das Problem?

    Autor: Tuxgamer12 18.12.17 - 10:33

    xploded schrieb:
    --------------------------------------------------------------------------------
    > Was sind denn diese ganzen "nicht vertrauenswürdigen Verbindungen"? Erklär
    > mir die mal. Bitte. Danke!
    > Du willst nun nicht sagen, das die unverschlüsselt sind?

    Doppelte Verneinung, also: Ja - natürlich sind die verschlüsselt. Natürlich hast du bei den nicht vertrauenswürdigen Verbindungen Recht. Da hat dir jemand ein Zertifikat gesendet, das nicht zum Domainnamen passt oder dem du eben nicht vertraust.

    Wenn dir jemand nach SNI kein Zertifikat zuschickt, kannst du die Website gar nicht (mit https) besuchen - bekommst auch noch nicht einmal eine http-Fehlermeldung.

    Wie dein Browser in diesem Fall den Fehler anzeigt - keine Ahnung. Hatte ich auch noch nicht. Würde auch nicht wirklich darauf wetten, dass das überall (vor allem serverseitig) implementiert ist.

    Wie ul mi bereits geschrieben hat ist es aber definitiv laut Protokoll möglich eine Verbdinung nach SNI zu verweigern.

  18. Re: Wo ist da nun das Problem?

    Autor: GodsBoss 19.12.17 - 20:24

    > > Das wird dich jetzt erschrecken, aber der Server sieht. welchen
    > Hostnamen
    > > die Anfrage haben will und kann sich dann unterschiedlich verhalten (mit
    > > SNI vor dem SSL-Verbindungsaufbau).
    > > Im Grundsatz kann der Server also auf alle Anfragen, die nicht genau zum
    > > Namen schurzelfurz08154711.my.fritz.box (oder whatever) wollen, zum
    > > Beispiel einen 403 liefern, oder gleich den kompletten
    > > TLS-Verbindungsaufbau ablehnen. (Dafür müsste man das
    > HTTP-Server-Handling
    > > vermutlich entsprechend handklöppeln und nicht einfach busybox nehmen,
    > von
    > > daher wird das die Fritzbox nicht so machen, aber von den Protokollen
    > her
    > > ginge das.)
    >
    > Es wird sich nun erschrecken, aber das läuft anders. Der Server liefert ein
    > Zertifikat aus, und zwar das, was in seinem (virtuellen) Host eingetragen
    > ist. Es juckt den Server nicht einen Meter, ob es passt oder gültig ist. So
    > kann man ein beliebiges Zertifikat einbinden - egal ob es passt oder
    > abgelaufen ist.
    > Die Prüfung ob es gültig ist (Zertifikatkette), passt (Hostname) und nicht
    > abgelaufen bzw. zurückgezogen wurde findet auf der Clientseite statt.
    > In deinem Beispiel sagt der Client nur: Du wolltest 1.2.3.4 hier kommt nun
    > aber irgendwas.irgendwo.de - das ist gefährlich, wirklich fortzufahren?

    Der Vorposter sprach von HTTP-Servern generell, nicht einer speziellen Implementierung (welche eigentlich?). Ich kann problemlos einen Server schreiben, der prüft, ob Zertifikate, die er ausliefern soll, noch gültig sind. Und genau so natürlich einen, der nur eine beliebige Hostnamen erlaubt und bei allen anderen dichtmacht.

    Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. cbs Corporate Business Solutions Unternehmensberatung GmbH, Heidelberg, Dortmund, München, Hamburg, Stuttgart
  2. über duerenhoff GmbH, Raum Mannheim
  3. BWI GmbH, Bonn
  4. Pfennigparade SIGMETA GmbH, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 44,98€ + USK-18-Versand
  2. 39,99€
  3. 2,99€
  4. 54,99€ mit Vorbesteller-Preisgarantie (Release 05.10.)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Gigabit: 5G-Planungen gehen völlig an den Nutzern vorbei
Gigabit
5G-Planungen gehen völlig an den Nutzern vorbei

Fast täglich hören wir Erklärungen aus der Telekommunikationsbranche, was 5G erfüllen müsse und warum sonst das Ende der Welt drohe. Wir haben die Konzerngruppen nach Interessenlage kartografiert.
Ein IMHO von Achim Sawall

  1. Fixed Wireless Access Nokia bringt mehrere 100 MBit/s mit LTE ins Festnetz
  2. Funklöcher Telekom bietet freiwillig hohe 5G-Netzabdeckung an
  3. 5G Telekom hat ihr Mobilfunknetz mit Glasfaser versorgt

Galaxy A9 im Hands on: Samsung bietet vier
Galaxy A9 im Hands on
Samsung bietet vier

Samsung erhöht die Anzahl der Kameras bei seinen Smartphones weiter: Das Galaxy A9 hat derer vier, zudem ist auch die restliche Ausstattung nicht schlecht. Aus verkaufspsychologischer Sicht könnte die Einstufung in die A-Mittelklasse bei einem Preis von 600 Euro ein Problem sein.
Ein Hands on von Tobias Költzsch

  1. Auftragsfertiger Samsung startet 7LPP-Herstellung mit EUV
  2. Galaxy A9 Samsung stellt Smartphone mit vier Hauptkameras vor
  3. Galaxy J4+ und J6+ Samsung stellt neue Smartphones im Einsteigerbereich vor

Mate 20 Pro im Hands on: Huawei bringt drei Brennweiten und mehr für 1.000 Euro
Mate 20 Pro im Hands on
Huawei bringt drei Brennweiten und mehr für 1.000 Euro

Huawei hat mit dem Mate 20 Pro seine Dreifachkamera überarbeitet: Der monochrome Sensor ist einer Ultraweitwinkelkamera gewichen. Gleichzeitig bietet das Smartphone zahlreiche technische Extras wie einen Fingerabdrucksensor unter dem Display und einen sehr leistungsfähigen Schnelllader.
Ein Hands on von Tobias Költzsch

  1. Keine Spionagepanik Regierung wird chinesische 5G-Ausrüster nicht ausschließen
  2. Watch GT Huawei bringt Smartwatch ohne Wear OS auf den Markt
  3. Ascend 910/310 Huaweis AI-Chips sollen Google und Nvidia schlagen

  1. iFixit: Auch der Surface Laptop 2 ist nahezu nicht reparierbar
    iFixit
    Auch der Surface Laptop 2 ist nahezu nicht reparierbar

    Microsofts Surface Laptop 2 ist ein ebenso kaum reparierbares Gerät wie der Vorgänger. Die Wahrscheinlichkeit ist hoch, dass beim Öffnen Beschädigungen auftreten. Das ist auch wenig sinnvoll: Komponenten sind verlötet, der Akku ist fest eingeklebt.

  2. Funklöcher: Telekom nimmt 400 neue Mobilfunkstandorte in Betrieb
    Funklöcher
    Telekom nimmt 400 neue Mobilfunkstandorte in Betrieb

    Die Telekom hat ihr Mobilfunknetz erneut etwas verbessert. Neue Standorte sollen Funklöcher schließen und die Datentransferrate erhöhen. Doch es gibt Kritik am Mobilfunkausbau in Deutschland.

  3. Viertürer: Porsche baut Elektrosportwagen E Cross Turismo
    Viertürer
    Porsche baut Elektrosportwagen E Cross Turismo

    Porsche hat die Serienfertigung seines zweiten Elektrosportautos beschlossen. Durch den Bau des Mission E Cross Turismo entstehen in Zuffenhausen 300 neue Arbeitsplätze.


  1. 10:59

  2. 10:49

  3. 10:39

  4. 10:15

  5. 09:19

  6. 09:11

  7. 08:15

  8. 07:43