Login
Newsletter
Werbung

Thema: Debian schließt FTP-Server

14 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von TuxTuxTux am Mi, 26. April 2017 um 12:08 #

Warum dann nicht gleich auf HTTPS?

[
| Versenden | Drucken ]
  • 0
    Von da-real-lala am Mi, 26. April 2017 um 12:20 #

    Soweit ich es verstanden habe, ist es unnötig, weil die Pakete eh schon mit Schlüsseln signiert sind. Apt sagt dann, ob das Repo vertraulich ist.

    Es gibt aber Spiegelserver, die das trotzdem machen:


    You need to install the package apt-transport-https. Then you can use lines like

    deb https://some.server.com/debian stable main

    in your sources.list file. But usually that's not necessary, since the entire content is public anyway and it adds encryption overhead and latency. Since you don't trust an attackers public key, even http traffic is safe from MitM attacks. apt will warn you and fail to install the packages when an attacker injects manipulated packages.

    EDIT: As mentioned in the comments it is indeed more secure to use the TLS repository. Research shows that using apt on unencrypted repositories can indeed pose a security risk as the HTTP transport is vulnerable to replay attacks.

    Quelle

    [
    | Versenden | Drucken ]
    0
    Von Nur ein Leser am Mi, 26. April 2017 um 12:22 #

    Fände ich allein aus Prinzip auch gut. Alles verschlüsseln, was geht.

    Mittels https könnte man verschleiern, das jemand sich Pakete herunterlädt (wobei das vielleicht über die Datenmenge auch ersichtlich ist), und vor allen Dingen WELCHE Pakete geladen werden.
    Die Integrität der Pakete ist durch Checksummen auch bei http sichergestellt, in der Hinsicht ist https kein Vorteil.

    Ob der Privacy-Gewinn in der Praxis den Aufwand für https wert ist, keine Ahnung.

    Ich weiß, das aber auch andere Distributionen ihre Repositories per http anbieten.

    [
    | Versenden | Drucken ]
    0
    Von aef9Gu9u am Mi, 26. April 2017 um 14:16 #

    > Warum dann nicht gleich auf HTTPS?

    waere eher kontraproduktiv, da damit kein Caching auf Clientseite moeglich ist.

    [
    | Versenden | Drucken ]
1
Von mw am Mi, 26. April 2017 um 12:30 #

In der Praxis ist ftp weitaus effektiver als http. Was steckt wirklich dahinter? Etwa daß seit Jahren keine Weieterentwicklung an ftp Servern mehr erfolgt ist? Schade, m. M. n. die zweite schwerwiegende Entscheidung nach systemd, die debian immer weniger qualifiziert.

[
| Versenden | Drucken ]
  • 1
    Von Huuuuuhuuuuuui am Mi, 26. April 2017 um 13:00 #

    Was steckt wirklich dahinter?
    Die transatlantischen Bilderberger-Marsianer! Ich schwör!

    Die stecken auch hinter systemd, pulseaudio und rpm! SIE WOLLEN DEINE FESTPLATTE FÜR EXPERIMENTE VERWENDEN. LAUF!!!

    [
    | Versenden | Drucken ]
    1
    Von Ede am Mi, 26. April 2017 um 13:08 #

    "immer weniger qualifiziert" ist das, was manche hier äussern ...

    [
    | Versenden | Drucken ]
    1
    Von da-real-lala am Mi, 26. April 2017 um 13:48 #

    Zitat Debian News Seite:

    This decision is driven by the following considerations:

    FTP servers have no support for caching or acceleration.
    Most software implementations have stagnated and are awkward to use and configure.
    Usage of the FTP servers is pretty low as our own installer has not offered FTP as a way to access mirrors for over ten years.
    The protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons.

    [
    | Versenden | Drucken ]
    0
    Von aeyohR9e am Mi, 26. April 2017 um 14:22 #

    > In der Praxis ist ftp weitaus effektiver als http

    FTP ist nur dann merklich effektiver, wenn viele kleine Dateien zu uebertragen sind. Dann koennte der Overhead durch HTTP Header tatsaechlich signifikant sein.

    Ansonsten ist FTP nur eine Krankheit: firewall-feindlich, nur fuer anonymen Download brauchbar, unspezifiziertes Datumsformat.

    [
    | Versenden | Drucken ]
    • 0
      Von mohikaner am Mi, 26. April 2017 um 18:41 #

      Wirklich nur bei kleinen Dateien? Dann versuche mal Dateien >30MB mittels HTTP auf einen Server von z. Bsp. Strato zu laden. Viel Spaß.

      [
      | Versenden | Drucken ]
      • 0
        Von aeyohR9e am Mi, 26. April 2017 um 20:25 #

        Wirklich nur bei kleinen Dateien? Dann versuche mal Dateien >30MB mittels HTTP auf einen Server von z. Bsp. Strato zu laden

        Upload hat mit diesem Thema nichts zu tun (es geht um Server, die Debian-Pakete zum Download vorhalten).

        Ausserdem wuerde kein vernuenftiger Mensch heutzutage ueber's Internet etwas via FTP uploaden, da FTP keinerlei Mechanismen unterstuetzt, Passwoerter zu verschluesseln. FTP PUT ist auch noch viel firewall feindlicher als FTP GET (ich kenne nur 'lftp', mit dem Daten via FTP hochgeladen werden koennen; alles andere versagt am Proxy).

        Ich sehe auch keinen Grund, warum HTTP(S) PUT (z.B. von WebDAV genutzt oder durch Javascript anwendbar) langsamer als FTP PUT sein sollte.

        [
        | Versenden | Drucken ]
        • 0
          Von Anonymous am Do, 27. April 2017 um 09:49 #

          Ausserdem wuerde kein vernuenftiger Mensch heutzutage ueber's Internet etwas via FTP uploaden,

          Au weia. Habe ich nicht irgendwo gelesen, dass nur die FTP-Downloads abgeschafft werden, während Maintainer die Pakete weiter per FTP hochladen können?

          Mit Debian benutzt man also eine Disti, die von Unvernünftigen maintained wird ;)

          [
          | Versenden | Drucken ]
        0
        Von ich am Do, 27. April 2017 um 01:23 #

        Das wird wohl eher an Strato liegen. Ich habe schon des öfteren Dateien mit mehreren hundert MB per HTTP bzw WebDAV auf meinen Server geladen. Und das lief ohne Probleme, selbst durch eine NAT und SSH Tunnel.

        [
        | Versenden | Drucken ]
        • 0
          Von Sphäre am Do, 27. April 2017 um 10:00 #

          Liegt tatsächlich an Strato. Mit FTP kein Problem. Uploads über HTTP kannst für große Datein knicken. Wundert mich bei Strato auch nicht, da bekommt man auch nur 1 Million Inodes für ein Filesystem mit 500 GB.

          [
          | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung