Wenn man sich folgende Versionsgeschichte des Artikels Linux Boarde ansieht, fragt man sich, warum da die https links in http geändert wurden. https://www.mikrocontroller.net/wikisoftware/index.php?title=Linux_Boards&action=history Was spricht dafür, was dagegen? Wenn ich was ändere/aktualisiere kopiere ich einfach den Link hinein, egal ob nun https oder http... Wie seht ihr das?
Jep. Würde mich auch mal interessieren, zumal die verwendung von sicheren Verbindungen ja erstmal nie verkehrt ist.
Jan schrieb: > zumal die verwendung von > sicheren Verbindungen ja erstmal nie verkehrt ist. Zum Lesen in einem öffentlich zugänglichen Forum??? ...
Hannes Lux schrieb: > Zum Lesen in einem öffentlich zugänglichen Forum??? muss doch nicht jeder, an dem zufällig mein Traffic vorbeigeht wissen, was ich mir genau durchlese. Zum Beispiel, wenn der Spross mehr Ahnung vom heimischen Netz hat als der alte Herr ist es doch ganz gut, wenn die Seite über den Bau von Reizstromgeräten verschlüsselt übertragen wird. Oder noch schlimmer, die Frage, wie man einen Pointer um 1 erhöht.
Vlad Tepesch schrieb: > an dem zufällig mein Traffic vorbeigeht Ja wer kommt da infrage? Neugierige Endanwender doch sicherlich nicht, oder? Die Betreiber der am Routing beteiligten Server interessiert das doch sicherlich nicht. ...
Hannes Lux schrieb: > Ja wer kommt da infrage? Neugierige Endanwender doch sicherlich nicht, > oder? Vlad Tepesch schrieb: > Zum Beispiel, wenn der Spross mehr Ahnung vom heimischen Netz hat als > der alte Herr Im lokalen Netz kann, wer das kann, durchaus den gesamten Verkehr abgreifen...
Uhu Uhuhu schrieb: > Im lokalen Netz kann, wer das kann, durchaus den gesamten Verkehr > abgreifen... und was macht er dann mit den TLS verschlüsselten Daten? Das Rauschen archivieren? Die Bytes in aufsteigender Reihenfolge sortieren?
Werden die (internen) Links nicht sowieso automatisch von der Foren/Wiki-software auf https umgestellt, wenn man die aktuelle Seite über https betrachtet?
Norbert schrieb: > und was macht er dann mit den TLS verschlüsselten Daten? wieso verschlüsselt? eine normale http-Verbindung ist doch immer noch plaintext oder hab ich irgendwas verschlafen?
Step 1: Vlad Tepesch schrieb: > Zum Beispiel, wenn der Spross mehr Ahnung vom heimischen Netz hat als > der alte Herr ist es doch ganz gut, wenn die Seite über den Bau von > Reizstromgeräten verschlüsselt übertragen wird. Also https und somit TLS verschlüsselt! Step 2: Uhu Uhuhu schrieb: > Im lokalen Netz kann, wer das kann, durchaus den gesamten Verkehr > abgreifen... Step 3: Ich schrieb: und was macht er dann mit den TLS verschlüsselten Daten? Meine Anmerkung bezog sich auf das Abgreifen des lokalen verschlüsselten Verkehrs (zwischen Alice und Bob). Das ist zwar möglich, jedoch Aufgrund des fehlenden Schlüsselpaars (für Eve) einigermaßen sinnarm ;-)
Norbert schrieb: > und was macht er dann mit den TLS verschlüsselten Daten? Hättest du gelesen, worum es gerade ging, wäre dir die Blödheit deines Einwandes eventuell aufgefallen...
Ich will dir ausnahmsweise auf die Sprünge helfen: Hannes' Frage war: Hannes Lux schrieb: > Ja wer kommt da infrage? Neugierige Endanwender doch sicherlich nicht, > oder? Meine Antwort: > Im lokalen Netz kann, wer das kann, durchaus den gesamten Verkehr > abgreifen... Und nun troll dich.
Uhu Uhuhu schrieb: > Meine Antwort: >> Im lokalen Netz kann, wer das kann, durchaus den gesamten Verkehr >> abgreifen... Isch haben abär gargein lokaliges Netz mit anderen Üsern als mir... Es ging mir nicht darum, ob Familienmitglieder oder Kollegen mitlesen können, sondern darum, welcher Betreiber von Gateways, Nodes, oder wie immer man die Forward-Stationen im Netz nennt, die Muße hat, öffentlich zugängliche Texte eines Forums mitzulesen. Wer hierfür https braucht, leidet wohl an Verfolgungswahn. Man kann es auch übertreiben. ...
Norbert schrieb: > Step 1: > > Vlad Tepesch schrieb: >> Zum Beispiel, wenn der Spross mehr Ahnung vom heimischen Netz hat als >> der alte Herr ist es doch ganz gut, wenn die Seite über den Bau von >> Reizstromgeräten verschlüsselt übertragen wird. > > Also https und somit TLS verschlüsselt! Hä, hast du dir die Beiträge überhaupt durchgelesen? Falls ja, lies sie noch mal und versteh sie! Hannes Lux schrieb: > Isch haben abär gargein lokaliges Netz mit anderen Üsern als mir... > > Es ging mir nicht darum, ob Familienmitglieder oder Kollegen mitlesen > können, siehst du, an manche Sachen denkt man eben nicht > sondern darum, welcher Betreiber von Gateways, Nodes, oder wie > immer man die Forward-Stationen im Netz nennt, die Muße hat, öffentlich > zugängliche Texte eines Forums mitzulesen. es geht nicht um das manuelle Mitlesen, es geht um automatische Profilbildung über DPI und Stichwortsuche > Wer hierfür https braucht, leidet wohl an Verfolgungswahn. so ein Quatsch hab ich ja noch nie gehört. *Alu-Hut-aufsetz* > Man kann es auch übertreiben. und weißt du, was dein ISP macht? Es ist schon von Fällen berichtet worden, in dem unterschiedliche Anschlussteilnehmer (ich glaube es ging um Kabel) in einem Netz waren und den gesamten Datenverkehr der anderen gesehen haben. Außerdem: vielleicht sucht man ja mal zu Referatszwecken oder ähnlichem nach instabilen Chemischen Verbindungen und an anderer Stelle, weils ein Hobby ist, nach Mikrocontrollern und Details zu Timern. Wenn man Glück hat, kriegt man dann bei der nächsten USA-Einreise eine Sonderbehandlung am Flughafen.
Hannes Lux schrieb: > Jan schrieb: >> zumal die verwendung von >> sicheren Verbindungen ja erstmal nie verkehrt ist. > > Zum Lesen in einem öffentlich zugänglichen Forum??? Wenn du in einem öffentlichen WLAN bist kann jeder beim Login dein Passwort mitlesen oder deine Session kapern. Entsprechende Tools sind selbst für Anfänger benutzbar: http://codebutler.github.com/firesheep/tc12 Mal andersrum gefragt: welchen Grund gibt es, SSL nicht zu verwenden?
Andreas Schwarz schrieb: > Mal andersrum gefragt: welchen Grund gibt es, SSL nicht zu verwenden? Die Verwendung von (Software)Proxies wie Proxomitron?
und vielleicht auch der höhere Ressourcenverbrauch auf Handy und Co??
Andreas Schwarz schrieb: > Mal andersrum gefragt: welchen Grund gibt es, SSL nicht zu verwenden? Evtl. schlechteres Browser-Caching (z.b. von bildern etc)
Caching ist bei aktuellen Browsern unabhängig davon, ob SSL verwendet wird oder nicht.
troll schrieb: > und vielleicht auch der höhere Ressourcenverbrauch auf Handy und Co?? Seit vielen Jahren wird eine einmal etablierte TLS Verbindung wiederholt genutzt (recycled) und somit entsteht der erhöhte Ressourcenverbrauch nur einmal beim initialen Verbindungsaufbau (asymmetrische Verschlüsselung). Die darauf folgende symmetrische Verschlüsselung der Nutzdaten braucht nur minimal (im Sinne von 'kaum messbar') höhere Resourcen.
Norbert schrieb: > im Sinne von 'kaum messbar' Das glaub ich nicht. Auf Serverseite wird sich das mit Sicherhet durch erhöhte Prozessorlast bemerkbar machen. Wenn man Daten von einer verschlüsselten Platte auf eine andere verschlüsselte kopiert, merkt man das auch ganz deutlich.
Uhu Uhuhu schrieb: > Das glaub ich nicht. Auf Serverseite wird sich das mit Sicherhet durch > erhöhte Prozessorlast bemerkbar machen. Praktisch nicht. Ein aktueller Prozessor verschlüsselt mehrere GByte/s mit AES.
Andreas Schwarz schrieb: > Praktisch nicht. Ein aktueller Prozessor verschlüsselt mehrere GByte/s > mit AES. Gut, mit Hardware-AES ist das wohl kein Problem. Das hat wohl mein derzeitiger Intel Zweikern 64-Bit Prozessor noch nicht - den kann man mit dem Umkopieren verschlüsselter Datenträger unter Linux im Sinne der Wortes zum Schwitzen bringen.
troll schrieb: > und vielleicht auch der höhere Ressourcenverbrauch auf Handy und Co?? Uhu Uhuhu schrieb: > Das glaub ich nicht. Auf Serverseite wird sich das mit Sicherhet durch > erhöhte Prozessorlast bemerkbar machen. > > Wenn man Daten von einer verschlüsselten Platte auf eine andere > verschlüsselte kopiert, merkt man das auch ganz deutlich. 1. Ich bezog mich zunächst einmal auf das was troll schrieb und er zielte auf Endgeräte ab. 2. Festplattenverschlüsselung ist nicht im Geringsten mit einer TLS-Verschlüsselung vergleichbar. Der initiale Overhead ist das 'Handshaking' und die asymmetrische Verschlüsselung bis die TLS Verbindung etabliert und die symmetrischen Schlüssel ausgetauscht sind, danach geht's ab wie Schmitts Katze.
Norbert schrieb: > 2. Festplattenverschlüsselung ist nicht im Geringsten mit einer > TLS-Verschlüsselung vergleichbar. Beide nutzen für den Nutzdatentransport eine symmetrische Verschlüsselung und wenn kein Hardware-AES verfügbar ist, dann kostet auch die symmetrische Verschlüsselung ganz merkbar Prozessorleistung - wie der Session-Key ausgehandelt wird und ob überhaupt, interessiert dann nicht mehr.
Auch ohne AES-NI schafft ein Prozessor mehrere 100 MB/s, bei dem Durchsatz den ein Webserver üblicherweise hat ist das also auch zu vernachlössigen.
Hannes Lux schrieb: > Wer hierfür https braucht, > leidet wohl an Verfolgungswahn. Man kann es auch übertreiben. Auch du bist potentieller Terrorist. Einer von 80 Millionen in Deutschland.
vn nn schrieb: > Auch du bist potentieller Terrorist. Richtig, genau wie Du... Und ich habe sogar schon Zündgeräte für Brückenzünder entwickelt (und gebaut) und habe ständig Aceton und Wasserstoffperoxyd vorrätig. Passt alles ins Raster des Terrorismus. Allerdings nutze ich die Technik und die Chemikalien für andere (friedliche) Zwecke. ...
Hannes Lux schrieb: > Richtig, genau wie Du... Genaugenommen nicht, denn auch wenn in Österreich bereits die selben Stasimaßnahmen ergriffen wurden, wurde immerhin noch kein Generalverdacht geäußert. Ich genieße also ncoh mein Terrorismusfreies leben. Hannes Lux schrieb: > Allerdings nutze ich die Technik und > die Chemikalien für andere (friedliche) Zwecke. Jetzt streitest du deine terroristischen Hintergedanken auch noch ab, damit reitest du dich nur noch tiefer hinein. ;)
http://www.heise.de/newsticker/meldung/Ueberwachung-Russland-setzt-auf-schwarze-Listen-und-DPI-1741599.html http://www.spiegel.de/netzwelt/web/internetzensur-russland-startet-schwarze-liste-fuer-websites-a-864903.html Wird mit der Nutzung von SSL erschwert, der Overhead ist marginal, Proxycaches sind bei heutigen Bandbreiten Blödsinn, und der Browser cached selbst, auch auf mobilen Geräten.
DPI schrieb: > Proxycaches sind bei heutigen Bandbreiten Blödsinn Das nicht unbedingt, weils immer noch massiv Zeit sparen würde (bezogen auf zentrale Proxies für viele User), nur gibt es kaum noch Inhalte, die sich cachen lassen. Web-Caching stammt aus der Zeit, als Webseiten statisch waren. Heute sind die hochfrequentierten Seiten überwiegend dynamisch erzeugt und lassen sich nicht cachen.
A. K. schrieb: > Das nicht unbedingt, weils immer noch massiv Zeit sparen würde (bezogen > auf zentrale Proxies für viele User), nur gibt es kaum noch Inhalte, die > sich cachen lassen. Web-Caching stammt aus der Zeit, als Webseiten > statisch waren. Heute sind die hochfrequentierten Seiten überwiegend > dynamisch erzeugt und lassen sich nicht cachen. Bei Proxys für viele User sind die Platten langsamer als die direkten Zugriffe.
DPI schrieb: > Bei Proxys für viele User sind die Platten langsamer als die direkten > Zugriffe. Ich meinte damit eigentlich keine Proxies für ganz Deutschland. Die Zeiten mit 8MB Hauptspeicher und 30ms Plattenzugriffen sind ausserdem passé. Dafür leben wir jetzt aber in Zeiten, in denen das Frontend eines dämlichen CMS erst einmal wartet, bis das Backend die ganz Indexseite beisammen hat, um sie erst dann, nach 0,5-1s, en bloc übers Netz zu schieben. Nicht etwa inkrementell, damit der Browser schon mal anfangen kann. Solange dreht der Browser also Däumchen, bis er anfangen kann, die daran hängenden 500 Objekte sukzessive einzusammeln. Was er nur mit so 10-20 am Stück macht.
A. K. schrieb: > Das nicht unbedingt, weils immer noch massiv Zeit sparen würde (bezogen > auf zentrale Proxies für viele User), nur gibt es kaum noch Inhalte, die > sich cachen lassen. Würde ich so nicht unbedingt behaupten, gerade CSS/JS/IMG Files ändern sich selten, und wo du CMS ansprachst auch dort wird meist gecached und der Inhalt ändert sich nicht im Sekundentakt. Setzt natürlich vorraus das die Software das vernünftig macht, habe das bei einem meiner Projekte mal spaßeshalber nachgerüstet incl. ETag and 304 Response, das bringt doch schon noch mal so 50%-70% 'Speed'. DPI schrieb: > Wird mit der Nutzung von SSL erschwert Oder es werden halt alle SSL-Sites erstmal per-se gesperrt wie es in einigen Firmennetzen gemacht wird...
Läubi .. schrieb: > Würde ich so nicht unbedingt behaupten, gerade CSS/JS/IMG Files ändern > sich selten, Die Images sind allerdings auch nicht das Problem, denn an denen hängen keine weiteren Inhalte dran. Wenn die ein paar Zehntelsekunden verzögern, dann stört das kaum. Kritisch sind Ketten von aufeinander verweisenden Javascripts, weil sich da die Latenzen bös addieren. JS/CSS wiederum cachen die nicht so gern, jedenfalls nicht seitens des Clients, weils Änderungen zwar nicht oft geben mag, aber wenn, dann bitte sofort. Wenn dann noch der Webdesigner die Werbung oben und die eigenen Inhalte unten reinschreibt, so dass sich der Browser zuerst mit der Werbung abkämpft und diese Server natürlich grad Schluckauf haben... Aber das ist ein anderes Thema. Man sollte Webdesigner dazu zwingen, ihre Seiten grundsätzlich nur per Tablet mit UMTS testen zu dürfen. Wegen der Latenzen, denn da ist auch ne steinzeitliche 30ms Disk schneller. Und nicht lokal übers Gigabit direkt vom Server, ohne vor Freigabe das unter realistischeren Bedingungen auch nur mal auszuprobieren. > und wo du CMS ansprachst auch dort wird meist gecached Nja, ich habe da so meine eigenen Erfahrungen. Beispielsweise mit einem CMS, aus dem die Indexseite nie vor Ablauf von 0,5s rauskam, oft deutlich länger. Und solange der Browser die nicht mal ansatzweise hat tut er nichts. Cache geht anders. Klar, man könnte das anders machen. Hat man da aber leider nicht.
A. K. schrieb: > JS/CSS wiederum cachen die nicht so gern, jedenfalls nicht > seitens des Clients, weils Änderungen zwar nicht oft geben mag, > aber wenn, dann bitte sofort. Halte ich für ein Gerücht, wenn der Server natürlich behauptet die Datei habe sich geändert obwohl dem nicht so ist bringt das natürlich nichts. Gerade mal auf uC.net probiert, 192.5 KB (178.8 KB vom Cache) sagt das Netzwerkmodul von FireBug, man hat eher den Fall das Sachen aus dem Client-Cache kommen die man gerne nochmal gehabt hätte, wird auf uC.net auch mittels ANhang eines Timestamps verhindert, trotzdem landen die meisten Anfragen bei einem 304 Not Modified und werden dann aus dem Cache bezogen. A. K. schrieb: > Klar, man könnte das anders machen. Hat man da aber leider nicht. Leider sind halt für viele die hinter HTTP stehenden Mechanismen völlig unbekannt und damit auch das Wissen wo man ggf. sinnvoll noch was rausholen kann (das hat aber nun mit HTTPS vs HTTP nun garnix mehr zu tun ;-).
Läubi .. schrieb: > Halte ich für ein Gerücht, wenn der Server natürlich behauptet die Datei > habe sich geändert obwohl dem nicht so ist bringt das natürlich nichts. Bei JS/CSS ist entscheidend, ob überhaupt nachgefragt werden muss. Denn wenn man das tun muss, dann hat man einen ganz wesentlichen Vorteil von Caching schon verloren: die geringe Latenz. Es geht also eher um die Frage, ob der Server dem Client oder dem Proxy ein zeitweises Caching ohne Rückfrage überhaupt erlaubt.
Ok, in dem Fall hast du natürlich Recht, dafür ist mir aber auch noch keine Sinnvolle Lösung eingefallen wie man das "Gültig bis" Datum handeln kann, trotzdem ist das laden von uC.net immerhin mit 1,21s noch immer 40sek schneller als die 2,0s wenn alle Daten neu abgerufen werden.
Läubi .. schrieb: > dafür ist mir aber auch noch > keine Sinnvolle Lösung eingefallen wie man das "Gültig bis" Datum > handeln kann Den HTTP-Entwicklern zu Glück schon ;) – der Expires-Header. Der ist hier für alle statischen Dateien auf ca. 7 Tage gesetzt, und du wirst auch feststellen können, dass dein Browser nach diesen Dateien nicht öfter als alle 7 Tage fragt. Erst wenn die 7 Tage abgelaufen sind, dann fragt er nach der aktuellen Datei, und bekommt ggf. 304 Not Modified zurück.
Andreas Schwarz schrieb: > Den HTTP-Entwicklern zu Glück schon Ja, das ist schon klar, aber wenn man Daten hat die sich potentiell ändern, kann man halt dem Browser nicht nachträglich sagen, dass das mit den sieben Tagen dann doch nicht mehr so ist weil man eben doch gerade heute noch schnell ein Update einspielen musste ;-) Man kann halt schlecht in die Zukunft blicken...
Dafür ist es üblich, den URL zu ändern, indem man eine Versionsnummer oder einfach einen Timestamp anhängt: https://www.mikrocontroller.net/stylesheets/screen.css?1351772065
Andreas Schwarz schrieb: > Dafür ist es üblich, den URL zu ändern, indem man eine > Versionsnummer oder einfach einen Timestamp anhängt Timestamp würde aber ja bewirken, dass doch jedes mal nachgefragt wird, eine Versionsnummer ist aber eine gute Idee soweit man diese sinnvoll bestimmen kann, zumindest bei "eingebettetem" Inhalt müsste das gut klappen.
Timestamp der letzten Änderung meinte ich.
Ok, das wäre in der Tat recht einfach umsetzbar!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.