nicht angemeldet
Linuchs
Rolf B
Rolf B
Linuchs
localhorst
TS
Auge
localhorst
localhorst
localhorst
TS
localhorst
Rolf B
dedlfix
Moin,
nachdem der FF genervt hat, dass die http-Verbindung nicht sicher ist, habe ich mit tagelanger Programmanpassung zu https gewechselt.
Nun motzt auch Filezilla FTP: „Unverschlüsseltes FTP ist unsicher. Bitte wechseln Sie zu FTP über TLS.“
Wenn sich Server und Client verschlüsselt unterhalten können, ohne dass ich einen Code eingebe, was hindert denn einen Lauscher, sich dieselbe Technik wie der Browser anzueignen und mitzuhören?
Und wenn ich zu TLS wechsle, welche Arbeiten zieht das nach sich?
fragt Linuchs
Hallo Linuchs,
ohne dass ich einen Code eingebe,
Du nicht. Aber der Server schickt Dir ein HTTPS-Zertifikat, in dem sein Hostname drinsteht, und das von einer vertrauenswürdigen Instanz beglaubigt ist.
Dafür hat dein Computer eine Liste von Stammzertifikaten, die aus der Distributionsquelle (oder von Microsoft Update) regelmäßig aktualisiert werden. Natürlich ist irgendwo die Wurzel allen Vertrauens hinterlegt, wo dieser Anchor Of Trust hängt und wie seine Befestigung regelmäßig überprüft wird (Zertifikate verfallen nach ein paar Jahren), darüber weiß ich zu wenig um es darstellen zu können.
Basierend auf dem validierten Zertifikat des Servers kann der Client nun einen Transportschlüssel generieren und mit dem public key im Zertifikat verschlüsseln. Der Server hat den private key und kann es entschlüsseln.
Bei einer Man-In-The-Middle Attacke hat der MITM das Problem, kein beglaubigtes Zertifikat ausstellen zu können, in dem der Hostname des eigentlichen Servers steckt. Es sei denn, eins der Stammzertifikate ist kompromittiert. Was durchaus schon vorgekommen ist und eine Menge Aufregung ausgelöst hat.
Rolf
Hallo Ingrid,
noch ein Nachtrag: Außer Zertifikatbetrügern wie DigiNotar oder StartCom gibt es Men in the Middle, die sich dein Vertrauen erschleichen können.
(1) Ein Virus oder Wurm auf deinem Computer, der Admin-Rechte erlangt hat. Der kann ein eigenes Stammzertifikat importieren und die HTTPS-Verbindung damit beglaubigen.
(2) Wenn dein Computer in einem Unternehmensnetzwerk steckt, vertraut er dem zentralen Domänencontroller und bekommt von ihm seine Stammzertifikate. Darunter befindet sich dann typischerweise auch ein internes Unternehmenszertifikat. HTTPS Verbindungen können vom Internet-Proxy dann aufgebrochen werden und zum Innendienst-Client hin mit dem Unternehmenszertifikat signiert werden. Der Browser vertraut diesem Betrug und der Arbeitgeber kann HTTPS-Verbindungen überwachen. Ist zwar scheiße, aber immer noch besser als ein generelles Verbot aller https-Verbindungen (was mein Arbeitgeber gemacht hat, bevor man den Systemern den Trick mit dem Unternehmens-Zertifikat verraten hat). Aber immerhin sehe ich das in meinem Browser - jede HTTPS-Seite, die ich aufrufe, ist schön ordentlich mit dem Zertifikat meines Arbeitgebers beglaubigt, statt
Rolf
gibt es Men in the Middle, die sich dein Vertrauen erschleichen können.
Wo*men bitte sehr. Warum müssen im positiven Umfeld (z.B. Stellenanzeigen) die Frauen immer eingeschlossen werden, bei Gaunern aber nicht?
Komisch auch, dass Bei Datenklau immer Hacker erkannt werden, wie machen es Hacker*innen, unerkannt zu bleiben?
Hallo Linuchs,
hallo Alle,
gibt es Men in the Middle, die sich dein Vertrauen erschleichen können.
Wo*men bitte sehr. Warum müssen im positiven Umfeld (z.B. Stellenanzeigen) die Frauen immer eingeschlossen werden, bei Gaunern aber nicht?
Vielleicht, weil Du denen als Mann ohnehin eher früher als später auf den Leim gehst, egal, ob sie offiziell als Gaunerinnen gelten ;-)
LG + Gesundheit
Localhorst
Hello,
gibt es Men in the Middle, die sich dein Vertrauen erschleichen können.
Wo*men bitte sehr. Warum müssen im positiven Umfeld (z.B. Stellenanzeigen) die Frauen immer eingeschlossen werden, bei Gaunern aber nicht?
Vielleicht, weil Du denen als Mann ohnehin eher früher als später auf den Leim gehst, egal, ob sie offiziell als Gaunerinnen gelten ;-)
Haha, kommt auf die Optik und das Verhalten an ;-P
Aber sind wir im Zwischenmenschlichen nicht alle kleine Gauner?
Da gucke ich nur mal in die asozialen Medien und vergleiche die Angebote mit der Wirklichkeit.
Glück Auf
Tom vom Berg
Hallo
Wenn sich Server und Client verschlüsselt unterhalten können, ohne dass ich einen Code eingebe, was hindert denn einen Lauscher, sich dieselbe Technik wie der Browser anzueignen und mitzuhören?
Wer nicht im Besitz der nötigen Schlüssel ist, kann nicht lauschen.
Und wenn ich zu TLS wechsle, welche Arbeiten zieht das nach sich?
Wenn der Server entsprechend konfiguriert ist, muss im FTP-Programm nur die Konfiguration der Verbindung angepasst werden. Das betrifft normalerweise das Protokoll und den Port, manchmal, wenn auch selten, auch den Servernamen.
Tschö, Auge
Hallo Linuchs,
hallo Alle,
Wenn sich Server und Client verschlüsselt unterhalten können, ohne dass ich einen Code eingebe, was hindert denn einen Lauscher, sich dieselbe Technik wie der Browser anzueignen und mitzuhören?
Er kann ruhig "mithören". Solange er deinen privaten Schlüssel nicht hat, bekommt er nur buntes Rauschen zu hören/lesen. Mindestlänge des Schlüssels wächst allerdings mit wachsender Rechenleistung täglich.
Und wenn ich zu TLS wechsle, welche Arbeiten zieht das nach sich?
Kommt darauf an, ob Du einen privaten Schlüssel geschützt an die richtige Seite transportieren kannst.
Lies vielleicht auch hier
Über den Browser und HTTPS wird der geschützte Schlüsselaustausch durch eine dem Browser bekannte Zertifizierungsstelle ermöglicht. Durch diese wird ein verschlüsselter Nachrichtenaustausch mit dem richtigen Partner gewährleistet. Es kann sich also niemand als ein Anderer ausgeben.
LG + Gesundheit
Localhorst
Wenn sich Server und Client verschlüsselt unterhalten können, ohne dass ich einen Code eingebe, was hindert denn einen Lauscher, sich dieselbe Technik wie der Browser anzueignen und mitzuhören?
https://www.internetsociety.org/deploy360/tls/basics/:
For this reason, TLS uses asymmetric cryptography for securely generating and exchanging a session key. The session key is then used for encrypting the data transmitted by one party, and for decrypting the data received at the other end. Once the session is over, the session key is discarded.
Übersetzt:
Für diesen Zweck benutzt TLS zunächst asymmetrische Kryptographie(¹) um auf sicherem Weg einen Sitzungsschlüssel(²) zu generieren und zu übertragen. Dieser Sitzungsschlüssel wird dann für das Verschlüsseln und Entschlüsseln der Daten benutzt. Wenn die Sitzung beendet wird, wird der Schlüssel verworfen.
¹) Also Paare von öffentlichen und privaten Schlüsseln. Der Sender einer Nachricht verschlüsselt mit seinem privatem und dem öffentlichen Schlüssel des Empfängers, der Empfänger entschlüsselt mit seinem privaten und dem öffentlichen Schlüssel des Versenders. Diese können automatisch generiert sein und außerdem können diese Schlüsse signiert sein. Dazu haben die anderen geschrieben.
²) Du hast den Sitzungsschlüssel „Code“ genannt.
Hallo Raketenerklärbär,
hallo Alle,
ich möchte an dieser Stelle selber eine Frage stellen, die mich schon seit Jahren beschäftigt:
Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Imho dürfte das nicht funktionieren, wenn nicht diverse zusätzliche Maßnahmen getroffen werden. Die Kommunikation müsste aufgebrochen werden, der Client ein (gefaktes) Zertifikat des Proxies akzeptieren, und der Proxy selber dann die Kommunikation mit der Gegenstelle aufnehmen, so wie bei HTTP. Ist das so richtig?
Ein Fachlehrer einer staatlichen Stelle hat mich für diese Darstellung mal als Blödmann bezeichnet. Selbstverständlich könne man einfach einen HTTPS-Proxy zwischenschalten (Microsoftlandschaft). Hat er recht?
Was wäre nötig, um die HTTPS-Kommunikation aufzubrechen?
Oder haben Windows-Netze da Geheimnisse eingebaut, die sowas quasi auf Knopfdruck möglich machen?
LG + Gesundheit
Localhorst
Ih kenne es bislang nur so und das erscheint mir auch schlüssig, bzw. beantwortet dann hoffentlich auch Deine Frage: SSL Termination ist die Aufgabe des vorgeschalteten Frontends mit dem jeweiligen Client. Alles, was danach passiert: Port X und unverschlüsselt. Es mag Setups geben, bei denen das nicht gewünscht sein mag, mir kamen noch keine unter.
Hallo Mitleser,
hallo Alle,
Ih kenne es bislang nur so und das erscheint mir auch schlüssig, bzw. beantwortet dann hoffentlich auch Deine Frage: SSL Termination ist die Aufgabe des vorgeschalteten Frontends mit dem jeweiligen Client. Alles, was danach passiert: Port X und unverschlüsselt. Es mag Setups geben, bei denen das nicht gewünscht sein mag, mir kamen noch keine unter.
Bahnhof?
Kannst Du diese kryptische Antwort für mich bitte noch entschlüsseln, bzw. ausführlicher beantworten, aka die Bezüge zu meinem Text eindeutiger herstellen?
LG + Gesundheit
Localhorst
Er meint wohl, dass die Verbindung zwischen Proxy und Client unverschlüsselt stattfindet. Dazu muss der Proxy freilich allerhand umschreiben. z.B. HTTP-Header.
Hallo Raketenerklärbär,
hallo Alle,
Er meint wohl, dass die Verbindung zwischen Proxy und Client unverschlüsselt stattfindet. Dazu muss der Proxy freilich allerhand umschreiben. z.B. HTTP-Header.
Ja wie jetzt?
Wenn der Browser eine HTTPS-Ressource anfordert, aber über einen Proxy arbeiten muss, kann der Proxy dem Browser dann unbemerkt HTTP unterjubeln?
LG + Gesundheit
Localhorst
Alles, was danach passiert: Port X und unverschlüsselt. Es mag Setups geben, bei denen das nicht gewünscht sein mag, mir kamen noch keine unter.
Bahnhof?
Passwörter und Benutzernamen, ggf. Bankdaten gehen dann also im Klartext durchs Firmennetz? Das sollte aber der Vertsand, wenn der nicht reicht der Datenschutzbeauftragte und der Betriebsrat ein paar Stoppschilder aufbauen.
Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Ja. Die Kommunikation zwischen Proxy und dem eigentlichen Server läuft so als sei der Proxy der Client: Der Proxy entschlüsselt also die Daten und verschlüsselt die wieder für den Client. (und visa versa)
Der Client verbindet sich mit dem Proxy, schickt die Anfrage an diesen als wäre dessen IP bei der Namensauflösung herausgekommen. Demnach kommuniziert der Client mit dem Proxy und muss dem alles glauben - also dessen Public-Key, insbesondere der neuen, privaten Zertifikatskette vertrauen: Weil der Proxy verschlüsselt hat muss dem Client vorgemacht werden, dass die für diese zweite Verschlüsselung genutzten Schlüssel für den ursprünglichen Server gültig seien. Das geht also durchaus, birgt aber die Gefahr, dass, wenn der Proxy gehackt wurde, jegliche Kommunikation aller Netzteilnehmer zu jedem Webserver betroffen ist.
Das ist im Vergleich wie ein "sicheres" Atomkraftwerk.
Ansonsten kann für Kommunikation zum Port 443 z.B. in der Default-Squid-Konfiguration festgelegt werden dass diese einfach direkt durchgeleitet (getunnelt) wird ohne die Verschlüsselung „anzufassen“. Freilich kann dann auch nichts gechached werden und niemand kann sagen, was da getunnelt wird. Das macht man also NICHT bei einem Reverse-Proxy, weil man damit ein ganz nettes Loch in die Firewall bohrt.
Zurück zu Deinem Anliegen: Da die Browser selbst cachen ist der Gewinn hier in Verhältnis zum Aufwand und zu den entstehenden Gefahren sehr klein.
Darüber, was passiert, wenn der Client das Netzwerk wechselt (Laptops, Tablets, ...) und dann die Kommunikation mit dem selben Server nicht mehr nur zu einer anderen IP sondern auch plötzlich mit anderen Keys laufen soll denke ich jetzt mal nicht nach. Wäre ich Browser würde ich mich sehr unwohl fühlen und das den Benutzer auch wissen lassen.
Hello,
Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Ja. Die Kommunikation zwischen Proxy und dem eigentlichen Server läuft so als sei der Proxy der Client: Der Proxy entschlüsselt also die Daten und verschlüsselt die wieder für den Client. (und visa versa)
Bist Du sicher, dass das so möglich ist? Dann müsste der Standard-Gateway und die ganze Route davor auf die gleiche Weise gehackt werden können.
Wenn der "HTTPS-Proxy" arbeiten soll, dann müsste er alle Zertifikate fälschen und auch den DNS dafür umswitchen. ER müsste Zugriff auf die die Zertifiziererliste der nachgeordneten Clients haben und deren öffentliche Schlüssel austauschen.
Wenn das möglich ist, wird TLS zu einem Mythos verstümmelt. Ist die Super-Fachwelt schon so korrupt, dass sie diesen Mythos klaglos aufrecht erhält?
Glück Auf
Tom vom Berg
Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Ja. Die Kommunikation zwischen Proxy und dem eigentlichen Server läuft so als sei der Proxy der Client: Der Proxy entschlüsselt also die Daten und verschlüsselt die wieder für den Client. (und visa versa)
Bist Du sicher, dass das so möglich ist?
Ja.
Wenn der "HTTPS-Proxy" arbeiten soll, dann müsste er alle Zertifikate fälschen
Eben. Dafür wird ein eigenes(!) Root-Zertifikat auf allen Clients installiert und mit diesem werden die vom Proxy verwendeten Keys beglaubigt. Via Windows-PKI-Server (Private Key Infrastructure) ist das in Windows-Netzen durchaus möglich.
Lesestoff:
Hallo Raketenerklärbär,
hallo Alle,
Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Ja. Die Kommunikation zwischen Proxy und dem eigentlichen Server läuft so als sei der Proxy der Client: Der Proxy entschlüsselt also die Daten und verschlüsselt die wieder für den Client. (und visa versa)
Bist Du sicher, dass das so möglich ist?
Ja.
Wenn der "HTTPS-Proxy" arbeiten soll, dann müsste er alle Zertifikate fälschen
Eben. Dafür wird ein eigenes(!) Root-Zertifikat auf allen Clients installiert und mit diesem werden die vom Proxy verwendeten Keys beglaubigt. Via Windows-PKI-Server (Private Key Infrastructure) ist das in Windows-Netzen durchaus möglich.
Lesestoff:
Das würde also bedeuten, dass ich aus einem (Windows-)Firmennetz heraus kein sicheres Banking mehr betreiben kann? Und VPN-Verbindungen mit Hilfe der in der Windows-Domain eingebundenen Windows-Clients wären dann auch unmöglich?
LG + Gesundheit
Localhorst
Hallo localhorst,
Firmennetz heraus kein sicheres Banking mehr
Du sollst in der Firma ja auch arbeiten und nicht deine privaten Bankgeschäfte erledigen 😉. Aber, ja, für den Proxy ist dieser Datenverkehr offen. Ob es damit unsicher ist, hängt davon ab, was der Proxy loggt. Vermutlich nicht sämtliche Inhalte der Kommunikation. Die Inhalte werden ggf. auf verdächtige Bytemuster gescannt, und dann wieder verschlüsselt. Das passiert abgeschlossen im Proxy.
Sollte ein Bastard Admin From Hell am Werk sein, ist das natürlich kein Schutz.
Beim VPN weiß ich es nicht, dazu kenne ich mich zu wenig aus. Wenn das VPN die https-Verschlüsselung als einzige Transportsicherung nutzt, dann würde ich sagen: es ist genauso offen. Aber da gilt das gleiche wie beim Banking: Du sollst arbeiten, nicht via VPN die neueste GoT-Folge von HBO laden. Und wenn Du für deine Arbeit ein VPN brauchst, kann das ein Firmen-Proxy gerne loggen. Es sind ja betriebliche Daten.
Rolf
Hallo Rolf,
hallo Alle,
Sollte ein Bastard Admin From Hell am Werk sein, ist das natürlich kein Schutz.
Nein, sowas ist selbstverständlich vollkommen unmöglich.
Es gibt doch auch keine Diesel-Motorsteuerungs-Abschaltvorrichtungen. Zumindest hat kein Führungsmitarbeiter jemals sowas angeordnet!
LG + Gesundheit
Localhorst
Oder haben Windows-Netze da Geheimnisse eingebaut, die sowas quasi auf Knopfdruck möglich machen?
„PKI“
Aber da gerade zehntausende Admins vor gehackten Exchange-Servern hocken will ich über Windows-Dienste und deren Sicherheit kein Wort verlieren.
Tach!
Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Ein Proxy ist ein Stellvertreter. Er ist eigentlich kein Zwischenspeicher. Es gibt jedoch einige Software, die beides vereint, Proxy und Web-Cache, aber auch anderes.
HTTPS leitet ein Proxy genauso weiter wie HTTP. Ein Proxy im eigentlichen Sinne verhält sich damit quasi wie ein Router, aber beschränkt auf bestimmte Anwendungsprotokolle (HTTP/HTTPS) und nicht allgemein für Netzwerkpakete.
Der Sinn, einen Proxy statt Routingregeln zu verwenden, ist üblicherweise, weil man weitere Funktionalität haben möchte. Zum Beispiel Zugangsbeschränkungen interner Nutzer auf bestimmte Teile des Webs.
Bei HTTPS schaltet der Proxy im einfachsten Falle auf Durchzug. Ohne die Verschlüsslung aufzubrechen, kennt er nur die IP-Adressen der beteiligten und - wenn SNI verwendet wird - auch den Hostnamen des Ziels. Damit sind seine Möglichkeiten sehr eingeschränkt. Man kann über solche Proxys über Port 443 eine ganze Menge andere Protokolle tunneln.
Soll der Proxy den Inhalt auswerten können, muss er die Verschlüsslung nach außen hin selbst übernehmen, nach innen hin entweder unverschlüsselt kommunizieren (dann aber logischerweise über HTTP) oder selbst verschlüsseln. Das passt aber den Browsern nicht, ohne denen händisch zu erklären, dass das verwendete Zertifikat vertrauenswürdig ist. Denn dieses Zertifikat wird sich nicht gegen die in den Browsern gespeicherte Liste vertrauenswürdiger Zertifikataussteller verifizieren lassen.
dedlfix.
Hallo dedlfix,
hallo Alle,
Ist es möglich, für HTTPS einen Proxy zwischenzuschalten, so wie dies für HTTP möglich ist? Also, dass Dateien, die durch mehrere Clients zeitnah angefordert werden, gecached werden?
Ein Proxy ist ein Stellvertreter. Er ist eigentlich kein Zwischenspeicher. Es gibt jedoch einige Software, die beides vereint, Proxy und Web-Cache, aber auch anderes.
HTTPS leitet ein Proxy genauso weiter wie HTTP. Ein Proxy im eigentlichen Sinne verhält sich damit quasi wie ein Router, aber beschränkt auf bestimmte Anwendungsprotokolle (HTTP/HTTPS) und nicht allgemein für Netzwerkpakete.
Der Sinn, einen Proxy statt Routingregeln zu verwenden, ist üblicherweise, weil man weitere Funktionalität haben möchte. Zum Beispiel Zugangsbeschränkungen interner Nutzer auf bestimmte Teile des Webs.
Bei HTTPS schaltet der Proxy im einfachsten Falle auf Durchzug. Ohne die Verschlüsslung aufzubrechen, kennt er nur die IP-Adressen der beteiligten und - wenn SNI verwendet wird - auch den Hostnamen des Ziels. Damit sind seine Möglichkeiten sehr eingeschränkt. Man kann über solche Proxys über Port 443 eine ganze Menge andere Protokolle tunneln.
Soll der Proxy den Inhalt auswerten können, muss er die Verschlüsslung nach außen hin selbst übernehmen, nach innen hin entweder unverschlüsselt kommunizieren (dann aber logischerweise über HTTP) oder selbst verschlüsseln. Das passt aber den Browsern nicht, ohne denen händisch zu erklären, dass das verwendete Zertifikat vertrauenswürdig ist. Denn dieses Zertifikat wird sich nicht gegen die in den Browsern gespeicherte Liste vertrauenswürdiger Zertifikataussteller verifizieren lassen.
Also scheitert das Verständnis hier nur an einer eineindeutigen Begriffsbestimmung?
Im beschriebenen Fall ging es eindeutig darum, die schwache Internetanbindung durch einen cachenden Proxy zu entlasten, da der gesamte Teilnehmerkreis im LAN überwiegend dieselben Ressourcen zu unterschiedlichen Zeitpunkten (0 bis 100 Sec Differenz) benötigte. Allerdings handelte es sich um Ziele, die nur über HTTPS + HSTS erreichbar waren.
LG + Gesundheit
Localhorst
Tach!
Im beschriebenen Fall ging es eindeutig darum, die schwache Internetanbindung durch einen cachenden Proxy zu entlasten, da der gesamte Teilnehmerkreis im LAN überwiegend dieselben Ressourcen zu unterschiedlichen Zeitpunkten (0 bis 100 Sec Differenz) benötigte. Allerdings handelte es sich um Ziele, die nur über HTTPS + HSTS erreichbar waren.
Ein Web-Cache kann Ressourcen nicht wiedererkennen, wenn er von ihnen kein eindeutiges Merkmal bestimmen kann. Inhalte mit Transportverschlüsslung sehen nach außen hin jedenfall unterschliedlich aus, weil jeder Transport eigene Schlüssel verwendet. Somit fällt ein Caching verschlüsselt übertragener Inhalte aus. Um das Ziel einer zentralen Speicherung zu erreichen, muss die zentrale Stelle die Transportverschlüssung entfernen können.
dedlfix.
Hallo localhorst,
da der gesamte Teilnehmerkreis im LAN überwiegend dieselben Ressourcen zu unterschiedlichen Zeitpunkten (0 bis 100 Sec Differenz) benötigte.
Wie kommst Du auf diese Annahme? Selbst eine sehr homogene Nutzergruppe muss doch nicht zwingend die gleichen (statischen) Ressourcen nutzen.
Wie ich schon in einem anderen Beitrag erwähnte - der Proxy in unserer Firma bricht https auf, und verschlüsselt dann neu. Unsere Firmen PCs sind so geschaltet, dass sie dem Proxy-Zertifikat vertrauen. Der Proxy könnte also cachen. Das ist aber nicht der Zweck des Aufbrechens. Der Proxy scannt jeden Netzwerkverkehr und weist alles ab, was auch nur irgendwie verdächtig ist. Unser Softwarelieferant hat vor kurzem seinen Server, auch den DNS-Namen, gewechselt, und jetzt muss ich erstmal den outgesourceten Admins hinterherrennen, dass sie den neuen Server als vertrauenswürdig konfigurieren. Denn das .7z Archiv, in dem ich Software geliefert bekomme, enthält JAR Files und es ist natürlich ein brutales Verbrechen, JAR Files aus beliebiger Quelle downzuloaden. 7z Archive sind ohnehin erstmal kein zulässiger Dateityp, neinneinnein, lieber Rolf, gleich steht die Betriebssicherheit vor deiner Homeoffice-Türe!
Und ob sich Caching da am Proxy lohnt? Wenn eine größere Gruppe von Firmenmitarbeitern über einen Proxy auf eine Webseite zugreift, dann wird das - mutmaßlich - eine cloud-gehostete Firmenanwendung sein, und deren Inhalte sind nicht statisch, d.h. nicht caching-fähig. Es gibt sicherlich auch Informationsressourcen wie Arbeitsrichtlinien, Betriebsnachrichten und so, aber ich glaube nicht, dass das der Löwenanteil der transferierten Daten ist.
Rolf
Hallo Rolf,
da der gesamte Teilnehmerkreis im LAN überwiegend dieselben Ressourcen zu unterschiedlichen Zeitpunkten (0 bis 100 Sec Differenz) benötigte.
Wie kommst Du auf diese Annahme? Selbst eine sehr homogene Nutzergruppe muss doch nicht zwingend die gleichen (statischen) Ressourcen nutzen.
TV über Internet, Ansprache der Bundeskanzlerin oder Tatort.
Gruß
Jürgen
JürgenB