Sicherheitslücke in apt
- OrangeJuice
- Beiträge: 625
- Registriert: 12.06.2017 15:12:40
Re: Sicherheitslücke in apt
Sollte man aufgrund des Fehler, wenn man Debian per NetInstall installiert hat, mit dem neuen Image die Installation erneut machen?
- novalix
- Beiträge: 1909
- Registriert: 05.10.2005 12:32:57
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: elberfeld
Re: Sicherheitslücke in apt
Ne, auf keinen Fall. Ein Upgrade mit den Fixes reicht völlig aus.OrangeJuice hat geschrieben:24.01.2019 16:36:29Sollte man aufgrund des Fehler, wenn man Debian per NetInstall installiert hat, mit dem neuen Image die Installation erneut machen?
Du solltest aber für den Fall, dass Du weitere Rechner mit Debian ausrüsten willst, das gefixte Image benutzen.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.
Darum ist das Richtige selten, lobenswert und schön.
Re: Sicherheitslücke in apt
Medium (CD oder USB-Stick) rein, booten, durchklicken, neustarten.... Auch nicht viel schwieriger als ein handelsübliches Linux.uname hat geschrieben:Wie installiert man eigentlich Windows, wenn es nicht vorinstalliert ist? Ich glaube ich werde alt.
Zuletzt geändert von Glur am 24.01.2019 21:26:20, insgesamt 1-mal geändert.
Re: Sicherheitslücke in apt
Hi. Habe ich das richtig erfasst?
Das aktuelle alt (und apt-get) hat eine Lücke. Ein man-in-the-middle konnte damit bei jedem ausgeführen apt -Befehl auf jedem Debian PC ein beliebiges Kommando als root zur Ausführung unterschieben? [Paranoia an] Da nsx u.a. Wissensbegierig einrichtungen über Jahre hinweg die zentralen internetknoten überwacht haben (und potentiell auch den Datenverkehr manipulieren konnten), ist es denkbar, dass nahezu allen apt-nutzern ein root-kit untergeschoben wurde? [Paranoia aus] ... Ich will nicht trollen, möchte nur die potentielle Reichweite einschätzen. Rootkits würde man nur mittels Neuinstallation weg bekommen; außer das rootkit wurde ins uefi geschrieben. [Paranoia wirklich aus]. ???
Das aktuelle alt (und apt-get) hat eine Lücke. Ein man-in-the-middle konnte damit bei jedem ausgeführen apt -Befehl auf jedem Debian PC ein beliebiges Kommando als root zur Ausführung unterschieben? [Paranoia an] Da nsx u.a. Wissensbegierig einrichtungen über Jahre hinweg die zentralen internetknoten überwacht haben (und potentiell auch den Datenverkehr manipulieren konnten), ist es denkbar, dass nahezu allen apt-nutzern ein root-kit untergeschoben wurde? [Paranoia aus] ... Ich will nicht trollen, möchte nur die potentielle Reichweite einschätzen. Rootkits würde man nur mittels Neuinstallation weg bekommen; außer das rootkit wurde ins uefi geschrieben. [Paranoia wirklich aus]. ???
Re: Sicherheitslücke in apt
Wann und wo bitte habe ich das denn geschrieben? Zitat falsch gelaufen?Glur hat geschrieben:24.01.2019 18:08:59Medium (CD oder USB-Stick) rein, booten, durchklicken, neustarten.... Auch nicht viel schwieriger als ein handelsübliches Linux.albundy hat geschrieben:Wie installiert man eigentlich Windows, wenn es nicht vorinstalliert ist? Ich glaube ich werde alt.
@Glur
Wir auch immer du es geschafft hast, aber du hast mich falsch zitiert. Guck mal:
viewtopic.php?f=1&t=172027&p=1196254&hi ... t#p1196254
Das hatte @uname geschrieben!
- jph
- Beiträge: 1049
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: Sicherheitslücke in apt
Das Projekt hat m.E. vorbildlich reagiert und ad hoc Debian 9.7 herausgeschoben. Einzige Änderung gegenüber 9.6: gefixtes apt, damit die Installationsimages sauber sind.
Re: Sicherheitslücke in apt
Oh ja, da ist wohl irgendwas schief gegangen... Sorry
-
- Beiträge: 196
- Registriert: 11.03.2018 23:09:05
Re: Sicherheitslücke in apt
Ja, die Erwägungen leuchten ein.MSfree hat geschrieben:24.01.2019 08:44:40Zu Verschlüsselung habe ich eine eigene Meinung. Ich halte es in diesem Fall für gefährlich, anzunehmen, daß man mit HTTPS keine Redirects einbauen könnte. Der Fehler wäre durch HTTPS nicht vermeidbar gewesen, er wäre nur dank Verschlüsselung erst viel später aufgefallen und die "bösen Jungs" hätten mehr Zeit gehabt, echten Schaden anzurichten.debianuser4782 hat geschrieben:24.01.2019 00:56:39Nun ist eine Diskussion über https bei apt entfacht.
In wiefern schützt TOR vor Redirects? Wie soll HTTPS vor Redirects schützen?Bzw für die Zukunft: Ist hier eine Verwendung von onion-services eine Alternative zu https?
OK, das Redirect-Problem wurde jetzt sowieso geflickt, aber der nächste Fehler lauert bestimmt schon. Meiner Meinung sind HTTPS und TOR nur Security by Obscurity, schützen letzten Endes also nicht. Unverschlüsselte Verbindungen könnte jeder (ganz nach dem Open Source Gedanken) mit einfachsten Mitteln wie tcpdump oder den Logs, die squid produziert, selbst kontrollieren, Verschlüsselung macht das so gut wie unmöglich.
Bitte nicht mißverstehen. Bei meinen Onlinebestellungen möchte ich meine Kreditkartendaten auch nicht unverschlüsselt übertragen wissen.
Onlinebanking betreibe ich sowieso nicht, weil mir bewußt ist, daß man vor allem im Bankensektor mit HTTPS nur Sicherheit vortäuschen will. Die Banken haben eine lange Tradition darin, technische Unzulänglichkeiten juristisch als "sicher" deklarieren zu lassen. Ja, wenn ein Jurist sagt, das ist sicher, dann wird das wohl stimmen. Beispiel?
https://de.wikipedia.org/wiki/Chaos_Com ... b#Btx-Hack
Wie ich inzwischen herausfinden konnte, ist Diskussionsgegenstand lediglich "https in source.list in Debian per default", da es über das Paket "apt-transport-https" ja schon eine Möglichkeit gibt "https" in der sources.list zu verwenden:
With the apt-transport-https package installed, you can instead use https://... in all of the above lines to use the repositories over encrypted HTTPS connections. https://wiki.debian.org/SourcesList
Anders scheint bei einer über onion-strings torifizierte sources.list kein https vorgesehen zu sein, wie in folgenden Listen [1] und im Thread [2] sowie im wiki [3] zu sehen:
[1]
https://onion.debian.org/
https://onion.torproject.org/
[2]
https://tor.stackexchange.com/questions ... ists-https
[3]
https://wiki.debian.org/SourcesList:
Here is an example sources.list using the onion services for Debian 9/Stretch:
Code: Alles auswählen
deb tor+http://vwakviie2ienjx6t.onion/debian stretch main
deb-src tor+http://vwakviie2ienjx6t.onion/debian stretch main
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main
deb-src tor+http://sgvtcaew4bxjd7ln.onion/debian-security stretch/updates main
deb tor+http://vwakviie2ienjx6t.onion/debian stretch-updates main
deb-src tor+http://vwakviie2ienjx6t.onion/debian stretch-updates main
Re: Sicherheitslücke in apt
Dann hast du den von dir auf Seite 1 verlinkten Thread aber nur oberflächlich gelesen, genau wie [2], was mit der Thematik überhaupt nicht zu tun hat!? Verbindungen zu Onion Services sind Ende-zu-Ende verschlüsselt.debianuser4782 hat geschrieben:24.01.2019 22:31:07Anders scheint bei einer über onion-strings torifizierte sources.list kein https vorgesehen zu sein, wie in folgenden Listen [1] und im Thread [2] sowie im wiki [3] zu sehen:
...
[2]
https://tor.stackexchange.com/questions ... ists-https
-
- Beiträge: 196
- Registriert: 11.03.2018 23:09:05
Re: Sicherheitslücke in apt
Ich ging davon aus, man könne onion-services zusätzlich zu https verwenden und dies würde dann entsprechend in der sources.list so abgebildet. Also in etwa: https verschachtelt durch Tor.tobo hat geschrieben:24.01.2019 23:33:33Dann hast du den von dir auf Seite 1 verlinkten Thread aber nur oberflächlich gelesen, genau wie [2], was mit der Thematik überhaupt nicht zu tun hat!? Verbindungen zu Onion Services sind Ende-zu-Ende verschlüsselt.debianuser4782 hat geschrieben:24.01.2019 22:31:07Anders scheint bei einer über onion-strings torifizierte sources.list kein https vorgesehen zu sein, wie in folgenden Listen [1] und im Thread [2] sowie im wiki [3] zu sehen:
...
[2]
https://tor.stackexchange.com/questions ... ists-https
Re: Sicherheitslücke in apt
Https zu einem Onion Service geht grundsätzlich schon. Aber a) weiß ich nicht, ob apt das formal (deb tor+https://...) kann und b) weiß ich nicht, ob überhaupt irgendwelche Mirrors existieren, die sich ein Zertifikat haben ausstellen lassen!? Zum Hintergrund (Onion über https) kannste ja mal hier lesen:debianuser4782 hat geschrieben:25.01.2019 00:02:55Ich ging davon aus, man könne onion-services zusätzlich zu https verwenden und dies würde dann entsprechend in der sources.list so abgebildet. Also in etwa: https verschachtelt durch Tor.
https://blog.torproject.org/facebook-hi ... ttps-certs
Anders aber als hier im Thread behauptet, wäre der apt-Fehler mit https oder tor so nicht ausnutzbar gewesen. Dazu müsste dann schon der entsprechende Spiegel-Server kompromittiert sein, aber dann wäre ja eh Essig...
- KBDCALLS
- Moderator
- Beiträge: 22359
- Registriert: 24.12.2003 21:26:55
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
Re: Sicherheitslücke in apt
Mal so nebenbei ,bevor ihr euch die Köpfe heißredet.
und die Dateiliste des Pakets
und die Dateiliste des Pakets
Code: Alles auswählen
/usr/lib/apt/methods/tor /usr/lib/apt/methods/tor+copy /usr/lib/apt/methods/tor+file /usr/lib/apt/methods/tor+http /usr/lib/apt/methods/tor+https /usr/lib/apt/methods/tor+mirror+copy /usr/lib/apt/methods/tor+mirror+file /usr/lib/apt/methods/tor+mirror+http /usr/lib/apt/methods/tor+mirror+https /usr/share/doc/apt-transport-tor/README.md.gz /usr/share/doc/apt-transport-tor/changelog.gz /usr/share/doc/apt-transport-tor/copyright
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
- Kennst du unsere Verhaltensregeln
- Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.
Re: Sicherheitslücke in apt
Man kann ja auch nur apt-transport-https und dann URLs der Form https:// verwenden, wobei das Problem ja sowieso eher innerhalb von "apt" lag.
Re: Sicherheitslücke in apt
So? Meines Wissens ist niemand bekannt der die Lücke ausgenutzt hat. Der Entdecker hat lediglich ein Szenario aufgezeigt, wie die Lücke hätte ausgenutzt werden könnte, die mit https nicht funktioniert hätte. Auf andere Art und weise wäre es problemlos möglichgewesen. – Nämlich indem man einen Mirror auf macht. Das dürfte sowieso die um Größenordnungen einfachere Variante sein als sich irgend wo zwischen mich und den sowieso meist wenige km entfernten Mirror ins Glasfaserkabel einzuklinken. Normalerweise liegt man da ja sogar beim gleichen Anbieter.wäre der apt-Fehler mit https oder tor so nicht ausnutzbar gewesen.
Nein. Debian Mirrors darf jeder Betreiben, der will. Da gibt es absichtlich keine Kontrollen, weil man da um jeden freiwilligen froh ist. Apt kontrolliert die Echtheit der Pakete. Deswegen ist das kein Problem. Sind die nicht vom Maintainer unterschrieben, werden sie nicht installiert.tobo hat geschrieben:25.01.2019 02:01:43Dazu müsste dann schon der entsprechende Spiegel-Server kompromittiert sein, aber dann wäre ja eh Essig...
Hilft natürlich nichts gegen Sicherheitslücken in apt selbst, wenn diese vor oder in der Signaturprüfung liegen.
Die Diskussion gibt es seit Jahren: Wenn apt einen Fehler in der Signaturprüfung hätte (Das davor in den 10 Zeilen Download Lücken sein könnten hatte vorher niemand angenommen.) könnte https und kontrollierte Mirrors helfen. Man hätte eine doppelte Absicherung. Auf der anderen Seite holt man sich die Gefahr ins Haus, dass die TLS-Implementierung alleine anfällig ist. Apt mit https-Support ist etwa doppelt so groß wie ohne. Und der aller meiste Teil, der in apt gemacht wird ist eh nach der Signaturprüfung und damit nicht angreifbar. Man würde sich die Angriffsfläche vervielfachen. Auch die Statistik spricht für http: GnuTLS hatte deutlich mehr Sicherheitslücken als apt. Man hätte sich den Teufel mit dem Blezebub ausgetrieben.
Und das zu einem hohen Preis: Man müsst jetzt plötzlich alle Mirror-Betreiber kontrollieren und würde sich vor allem die ganze Caching-Struktur kaputt machen. Während Webcaches sonst eher tot sind lebt das im Debianuniversum noch: Debian hat nur wenige private nutzer sondern eher tausenden ähnlichen Geräten. Und während mirrors und apt-cache voraussetzen dass überall die sources.lst korrekt angepasst ist, und für jede Quelle einzeln eingerichtet und gewartet werden muss ist ein squid ein 0 effort Teil den man sogar Transparent für den Clienten machen kann. Vor unseren Server-VMs steht ein squid. Der hat immer >90% Cache-Hits. Weil das halt alle irgend wie eine übliche Linux-Distro die regelmäßig Updates macht da stehen hat. Würden die auf https umsteigen würde sich der Traffic zum Mirror mehr als verzehnfachen. – Und der ist dann noch mehr Aufwand weil sichergestellt werden muss, das er nicht kompromittiert wird.
Kurz: Nutzen von https ist eher zweifelhaft bis kontroproduktiv. Der Aufwand wäre aber riesig.
Deswegen macht keiner https. Insbesondere security.debian.org hat explizit https abgeschaltet, weil sie meinen lieber schnelle Sicherheitsupdates mit Proxy als irgend welche schlecht gewarteten zusätzlichen Mirrors, die wegen fehlendem Caching her müssen.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: Sicherheitslücke in apt
Liegt vielleicht auch daran, dass das neue, aktualisierte .deb-Paket kein Geheimnis darstellt. Entscheidend ist nur, dass die Integrität gewahrt wird. Soll heißen, dass das .deb-Paket bitgenau beim Client so verarbeitet wird, wie es vom Server bereitgestellt wurde. Durch geeignete Prüfsummen, Keyrings und deren korrekte Überprüfung sollte das kein Problem sein. Und das war hier nicht sichergestellt. Somit ein Fehler von apt. Im übrigen sollte sich apt oder egal welche Anwendung NIE auf TLS-Transportverschlüsselung verlassen.wanne hat geschrieben:Deswegen macht keiner https. Insbesondere security.debian.org hat explizit https abgeschaltet, weil sie meinen lieber schnelle Sicherheitsupdates mit Proxy als irgend welche schlecht gewarteten zusätzlichen Mirrors, die wegen fehlendem Caching her müssen.
Re: Sicherheitslücke in apt
Ich sehe da jetzt erstmal keinen Widerspruch.wanne hat geschrieben:29.01.2019 06:02:29So? Meines Wissens ist niemand bekannt der die Lücke ausgenutzt hat. Der Entdecker hat lediglich ein Szenario aufgezeigt, wie die Lücke hätte ausgenutzt werden könnte, die mit https nicht funktioniert hätte.wäre der apt-Fehler mit https oder tor so nicht ausnutzbar gewesen.
Was dann aber unabhängig zum verwendeten Protokoll wäre.Auf andere Art und weise wäre es problemlos möglichgewesen. – Nämlich indem man einen Mirror auf macht. Das dürfte sowieso die um Größenordnungen einfachere Variante sein als sich irgend wo zwischen mich und den sowieso meist wenige km entfernten Mirror ins Glasfaserkabel einzuklinken.
Kontrollierte Mirrors - sowas wie Debian Enterprise Edition?Die Diskussion gibt es seit Jahren: Wenn apt einen Fehler in der Signaturprüfung hätte (Das davor in den 10 Zeilen Download Lücken sein könnten hatte vorher niemand angenommen.) könnte https und kontrollierte Mirrors helfen. Man hätte eine doppelte Absicherung.
Davon redet keiner. Die Sicherheitsmechanismen von APT ändern sich ja nicht, nur weil das transportverschlüsselt wird!? Das ist nicht Oder- sondern Und-Verknüpft.Auf der anderen Seite holt man sich die Gefahr ins Haus, dass die TLS-Implementierung alleine anfällig ist.
Ich bin ja auch für weniger und kleinere Software, man darf aber auch nicht das große Ganze aus den Augen verlieren. Bei den staatlichen/wirtschaftlichen Begehrlichkeiten heutzutage muss das Anliegen doch sein, dass die Kommunikationstränge verschlüsselt sind und selbstverständlich ist das aufwendiger, als unverschlüsselt Daten zu übertragen. Und selbst wenn GNU TLS eine Bugmaschine wäre, was wäre denn dann das Worstcase-Szenario? Dass du auf das Sicherheitsniveau von APT zurückfällst und keinen Deut darunter.Apt mit https-Support ist etwa doppelt so groß wie ohne. Und der aller meiste Teil, der in apt gemacht wird ist eh nach der Signaturprüfung und damit nicht angreifbar. Man würde sich die Angriffsfläche vervielfachen. Auch die Statistik spricht für http: GnuTLS hatte deutlich mehr Sicherheitslücken als apt. Man hätte sich den Teufel mit dem Blezebub ausgetrieben.
Warum, um was zu erreichen?Und das zu einem hohen Preis: Man müsst jetzt plötzlich alle Mirror-Betreiber kontrollieren
Ja, es muss ja auch einen guten Grund geben, wieso das nicht längst der Default ist!?und würde sich vor allem die ganze Caching-Struktur kaputt machen.
- jph
- Beiträge: 1049
- Registriert: 06.12.2015 15:06:07
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Greven/Westf.
Re: Sicherheitslücke in apt
Meiner Meinung nach ist es unredlich, den Btx-Hack von vor 35 Jahren (den jüngeren Forenteilnehmern wirst du erst mal erklären müssen, was Btx überhaupt war) anzuführen und daraus zu schlussfolgern, dass die Banken seitdem nichts dazugelernt hätten.MSfree hat geschrieben:24.01.2019 08:44:40Onlinebanking betreibe ich sowieso nicht, weil mir bewußt ist, daß man vor allem im Bankensektor mit HTTPS nur Sicherheit vortäuschen will. Die Banken haben eine lange Tradition darin, technische Unzulänglichkeiten juristisch als "sicher" deklarieren zu lassen. Ja, wenn ein Jurist sagt, das ist sicher, dann wird das wohl stimmen. Beispiel?
https://de.wikipedia.org/wiki/Chaos_Com ... b#Btx-Hack
Full disclosure: ich arbeite in einer Rechenzentrale, habe aber mit IT-Security nichts zu tun.
- KBDCALLS
- Moderator
- Beiträge: 22359
- Registriert: 24.12.2003 21:26:55
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Dortmund
-
Kontaktdaten:
Re: Sicherheitslücke in apt
Das die Banken was gelernt haben da kann man schon berechtigte Zweifel dran haben. Zum Beispiel wie mit Leuten umgegangen wird denen die Ec-Karte gestohlen und dann das Konto geplündert wird , und denen dann unterstellt das man den Ganoven die Pin auf dem Silbertablett serviert hat, (Anscheinsbeweis) . Obwohl es Beweise gibt wie die Ganoven an die Pin kommen, nur das wird einfach ignoriert.jph hat geschrieben:29.01.2019 21:48:22
Meiner Meinung nach ist es unredlich, den Btx-Hack von vor 35 Jahren (den jüngeren Forenteilnehmern wirst du erst mal erklären müssen, was Btx überhaupt war) anzuführen und daraus zu schlussfolgern, dass die Banken seitdem nichts dazugelernt hätten.
Full disclosure: ich arbeite in einer Rechenzentrale, habe aber mit IT-Security nichts zu tun.
Was haben Windows und ein Uboot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
Kaum macht man ein Fenster auf, gehen die Probleme los.
EDV ist die Abkürzung für: Ende der Vernunft
Bevor du einen Beitrag postest:
- Kennst du unsere Verhaltensregeln
- Lange Codezeilen/Logs gehören nach NoPaste, in Deinen Beitrag dann der passende Link dazu.
Re: Sicherheitslücke in apt
Eine Lücke im der http Implementierung wie sie jetzt gefunden wurde ist dann ja auch völlig harmlos, weil danach die Signaturen überprüft werden. Oder?tobo hat geschrieben:29.01.2019 19:49:31Davon redet keiner. Die Sicherheitsmechanismen von APT ändern sich ja nicht, nur weil das transportverschlüsselt wird!? Das ist nicht Oder- sondern Und-Verknüpft.
Wenn also ein Bug im http ist fällt man lediglich auf das Sicherheitsniveau von PGP? Dann haben wir ja im Moment kein Problem.Und selbst wenn GNU TLS eine Bugmaschine wäre, was wäre denn dann das Worstcase-Szenario? Dass du auf das Sicherheitsniveau von APT zurückfällst und keinen Deut darunter.
Ne sorry, wenn dein TLS eine remote-Code Execution oder Speicher auslesen im TLS hat, dann interessierst du dich nicht mehr dafür , ob apt sicher ist. Du hast neie root shell.
Mehr Sicherheit als aktuell. Um den aktuellen Bug auszunutzen, musst du mindestens ein MITM sein. Wenn du lediglich https machst kann das weiterhin jeder, der die 5min investiert sich ein TLS-Zertifikat zu klicken. Normalerweise sichert sich TLS dagegen ab, indem es die Domain der URL im Browser mit der im Zertifikat abgleicht. Apt ist aber keine interaktive Browseranwendung, wo du gegen die Addresszeile abgleichen kannst. Du forderst Pakete an, die je nach Laune von völlig unterschiedlichen URLs kommen können. – Je nach dem was Debian gerade als schnell erachtet. Liefert dir irgend jemand ein passendes Paket nimmt apt im Moment jede Domain. Ein Angreifer würde sich also einfach ein kostenloses Zertifikat holen können, dass zu einer Domain gehört die ihm legitim gehört.Und das zu einem hohen Preis: Man müsst jetzt plötzlich alle Mirror-Betreiber kontrollieren
TLS meckert nicht apt meckert nicht. Bingo! Und erzähl mir nichts von kompliziert:
Du hast vorher gemeint, dass da irgend jemand NSA style mäßig irgend wo heimlich Kabel manipuliert. Das war mal einfach, aber häute kannst du da dicke Bücher drüber schreiben, wie man das mit Glasfaser oder DSL noch hinbekommt.
Wie gesagt der mit Abstand einfachste weg den aktuellen Bug auszunutzen ist einfach einen eigenen Mirror zu betreiben. Und da hilft absolut kein TLS.
Nein. Weil es mit https deutlich sicherer wird.Ja, es muss ja auch einen guten Grund geben, wieso das nicht längst der Default ist!?
rot: Moderator wanne spricht, default: User wanne spricht.
Re: Sicherheitslücke in apt
Da du mich ja gezielt falsch verstehen willst, verstehst du mich nicht richtig.
Wo habe ich das gesagt: anderer Thread, anderes Forum?wanne hat geschrieben:30.01.2019 11:23:01Du hast vorher gemeint, dass da irgend jemand NSA style mäßig irgend wo heimlich Kabel manipuliert.
Re: Sicherheitslücke in apt
Nein. Deine aussagen waren schlicht falsch. Ich habe sie nur konsequent weiter gedacht. Da ist halt eben keine Und-Verknüpfung. (Und auch keine Oder) Für Lücken wie die aktuelle ist halt die erste Schicht, die die zählt. Deswegen hat PGP den Bug im http-Code nicht ausmerzen können und deswegen könnte es das auch nicht im Fall von https. – Nur das https ungleich komplizierter ist und deswegen anfälliger für Fehler.tobo hat geschrieben:30.01.2019 11:43:43Da du mich ja gezielt falsch verstehen willst, verstehst du mich nicht richtig.
Das war halt der Angriff den https verhindert hätte. Alle einfacheren hätte es nicht verhindert.Wo habe ich das gesagt: anderer Thread, anderes Forum?
rot: Moderator wanne spricht, default: User wanne spricht.