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.
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.
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.
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.
> 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.
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.
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
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.
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.
Warum dann nicht gleich auf HTTPS?
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
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.
> Warum dann nicht gleich auf HTTPS?
waere eher kontraproduktiv, da damit kein Caching auf Clientseite moeglich ist.
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.
Die stecken auch hinter systemd, pulseaudio und rpm! SIE WOLLEN DEINE FESTPLATTE FÜR EXPERIMENTE VERWENDEN. LAUF!!!
"immer weniger qualifiziert" ist das, was manche hier äussern ...
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.
> 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.
Wirklich nur bei kleinen Dateien? Dann versuche mal Dateien >30MB mittels HTTP auf einen Server von z. Bsp. Strato zu laden. Viel Spaß.
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.
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
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.
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.