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: Ununhex 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. Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz
  2. Bayerisches Landesamt für Steuern, Nürnberg, München
  3. Continental AG, Frankfurt am Main
  4. DAN Produkte Pflegedokumentation GmbH, Siegen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 54,99€ mit Vorbesteller-Preisgarantie
  2. 2,99€
  3. (u. a. Assassin's Creed Origins PC für 29€)
  4. 14,99€ + 1,99€ Versand oder Abholung im Markt


Haben wir etwas übersehen?

E-Mail an news@golem.de


Raumfahrt: Großbritannien will wieder in den Weltraum
Raumfahrt
Großbritannien will wieder in den Weltraum

Die Briten wollen eigene Raketen bauen und von Großbritannien aus starten. Ein Teil des Geldes dafür kommt auch von Investoren und staatlichen Investitionsfonds aus Deutschland.
Von Frank Wunderlich-Pfeiffer

  1. Esa Sonnensystemforschung ohne Plutonium
  2. Jaxa Japanische Sonde Hayabusa 2 erreicht den Asteroiden Ryugu
  3. Mission Horizons @Astro_Alex fliegt wieder

Razer Huntsman im Test: Rattern mit Infrarot
Razer Huntsman im Test
Rattern mit Infrarot

Razers neue Gaming-Tastatur heißt Huntsman, eine klare Andeutung, für welchen Einsatzzweck sie sich eignen soll. Die neuen optomechanischen Switches reagieren schnell und leichtgängig - der Geräuschpegel dürfte für viele Nutzer aber gewöhnungsbedürftig sein.
Ein Test von Tobias Költzsch

  1. Huntsman Razer präsentiert Tastatur mit opto-mechanischen Switches
  2. Razer Abyssus Essential Symmetrische Gaming-Maus für Einsteiger
  3. Razer Nommo Chroma im Test Blinkt viel, klingt weniger

Smartphone von Gigaset: Made in Bocholt
Smartphone von Gigaset
Made in Bocholt

Gigaset baut sein Smartphone GS185 in Bocholt - und verpasst dem Gerät trotz kompletter Anlieferung von Teilen aus China das Label "Made in Germany". Der Fokus auf die Region ist aber vorhanden, eine erweiterte Fertigung durchaus eine Option. Wir haben uns das Werk angeschaut.
Ein Bericht von Tobias Költzsch

  1. Bocholt Gigaset baut Smartphone in Deutschland

  1. Tom Gruber: Apple verliert letzten Siri-Mitbegründer
    Tom Gruber
    Apple verliert letzten Siri-Mitbegründer

    Apple hat Siri nicht erfunden, sondern die Technik mitsamt eines Unternehmens gekauft. Tom Gruber, einer der drei Gründer, die damals zu Apple wechselten, hat nun gekündigt. Auch Apples Suchchef Vipul Ved Prakash hört auf.

  2. Quartalsbericht: Aus Microsofts Cloud regnet es Dollar-Milliarden
    Quartalsbericht
    Aus Microsofts Cloud regnet es Dollar-Milliarden

    Das neue Microsoft ist ein höchst erfolgreiches Cloud-Unternehmen. Allein in drei Monaten werden fast neun Milliarden US-Dollar Gewinn erwirtschaftet.

  3. VKU: Forderung nach Gutscheinen zum FTTH-Ausbau wird breiter
    VKU
    Forderung nach Gutscheinen zum FTTH-Ausbau wird breiter

    Drei Verbände schlagen Gutscheine für den Glasfaserausbau vor. Dabei ist nun auch der Verband kommunaler Unternehmen. Gefördert werden soll der Tiefbau mit 1.500 Euro, auch für Haushalte die keinen Vertag mit Telekombetreibern haben.


  1. 07:26

  2. 22:45

  3. 19:19

  4. 16:53

  5. 16:44

  6. 16:41

  7. 16:05

  8. 15:29