News Schnellere verschlüsselte Websites mit „HTTPi“

Steffen

Technische Leitung
Administrator
Registriert
März 2001
Beiträge
17.184
Das weitgehend übliche unverschlüsselte Übertragen einer Website ermöglicht das Ausspionieren von Passwörtern und anderen sensiblen Daten insbesondere in offenen WLANs. Verschlüsselung in Form von HTTPS verhindert jedoch das Caching übertragener Daten und kann Websites daher langsamer machen. Diese Schwäche soll „HTTPi“ lösen.

Zur News: Schnellere verschlüsselte Websites mit „HTTPi“
 
Das ist keine Schwäche von HTTPs, sondern gut so. Microsoft will nur wieder einen proprietären und patentierten Standard etablieren (wie ihre FAT-Dateisysteme) und versuchen mehr Macht an sich zu reissen.

Wenn sich dieser Müll durchsetzt, dann fress ich einen Besen.
 
Zuletzt bearbeitet:
Doch, macht sogar sehr oft Sinn. Große Teile einer Website könnte man cachen, https unterbindet das aber.
Wenn nur noch die wichtigen Teile forciert jedesmal neu übertragen werden, ist das in Summe eine recht brauchbare Entlastung für Server.
 
@fromdadarkside

im Gegenteil. Ist doch im Artikel erklärt. HTTPS kann nicht gecacht werden und so müssen bei jedem aufruf alle daten neu übertragen werden, anstatt das man z.B. das webseitenlogobanner einfach aus dem lokalen Cache lädt, was intelligenter und schneller wäre.

Und das "i" steht am ende, da es ja HyperTextTransportProtocolintegrity (HTTPi, also Integrität) heißt. Genau so steht HTTPs auch für HyperTextTransportProtocolsecure
 
Es geht wohl eher um Zertifikate. Ein Website weisst sich bei HTTPS per Zertifikat aus. Dieses muss jedesmal neu heruntergeladen werden und damit einher geht eine neue Verschlüsselung der Daten. Daher sind die die gecached Daten Müll.

Ganz klar wie HTTPi nun arbeiten soll, ist mir auch nicht. Jedoch die Intention, nämlich verschlüsselte Seite Cachebar zu machen finde ich sehr gut. Das trifft weniger den Homeuser als mehr Firmen die nen Proxy zur Sicherheit zwischenschalten. Die Vertraulichkeit, sprich das man sicher sein kann, dass man wirklich z.B. mit der Sparkassen Webseite spricht und nicht mit einer Phishing-Seite macht sowieso nur in ganz speziellen Bereichen Sinn. Beim Webmail reicht mir auch eine nicht zertifizierte Seite, meine Mails sollte aber trotzdem verschlüsselt übertragen werden wohin gegen ich mir schon sicher sein möchte das ich auf Sparkasse.de meinen PIN eintippe... und gerade bei Webportalen etc. ist es schon ganz schön wenn man mal so ein bisschen von der Seite im Cache liegen hat - geht dann alles deutlich schneller.

Allerdings kommt's von MS und das war bisher immer nix gutes!
 
jan4321 schrieb:
im Gegenteil. Ist doch im Artikel erklärt. HTTPS kann nicht gecacht werden und so müssen bei jedem aufruf alle daten neu übertragen werden, anstatt das man z.B. das webseitenlogobanner einfach aus dem lokalen Cache lädt, was intelligenter und schneller wäre.

Ich glaube kaum, dass HTTPS auch auf das Lokale Caching Einfluss hat. Das wäre Implementierunssache des Browsers.
 
Zuletzt bearbeitet von einem Moderator: (Beitrag wieder hergestellt. Bitte dazu auch die Forenregeln beachten.)
jaein per default cacht nur der IE SSL Objekte, allen anderen muss man das explizit sagen, was auch gut so ist. Hier geht es ja auch vor allem um die dauernde verschlüsselung immer gleicher Daten. Bei HTTPs rechnet man mit 0,5-1% CPU last pro Verbindung HTTPi soll eigentlich nicht das Cachen von HTTPs obekten ermöglichen, sondern eine Separation von Objekten, die über HTTPs übertragen werden müssen und solchen, für die auch das HTTP vollkommen ausreicht, und somit von Proxys wieder gecacht werden (gerade große Provider Proxys wie bei der Telekom etz. können somit dem eigentlichen Webservern sehr viel Arbeit wieder abnehmen).

Aber der größte vorteil ist, das man von vornherein verhindert, das überflüssige daten verschlüsselt werden und somit viel CPU last und Netzwerkoverhead vermeidet, weswegen es für viele Serverbetreiber ein ernstzunehmender Grund ist, auf HTTPs zu verzichten (allein cb hier z.B. sollte seine Forenlogins normalerweise per HTTPs schützen, aber durch den enormen overhead ist es einfach eine zu große Belastung für den Server und auf die Dauer zu teuer) . Sehr schön anschaulich erklärt finde ich das auf Seite 7 im verlinkten Paper
 
Zuletzt bearbeitet:
Die Idee ist absoluter Schwachsinn, SSL-Inhalte würden sich schon lange cachen lassen, wenn die Browser-Hersteller sich nur dazu entschließen würden.

Für statische Inhalte (Bilder, JavaScript, CSS...) gibt es schon seit einem Jahrzehnt HTTP-Header um den Browser anzuweisen die Inhalte zu cachen (ETAG, Expires, ...), allerdings ignorieren diese das komplett, man müsste also nur bei den Browsern ansetzen und denen das einbauen, statt eine HTTP-Erweiterunge zu definieren :rolleyes:
Dann lieber Googles Vorschläg für ein binäres HTTP-Protokoll, das ist deutlich sinniger.

Sollen die Browser die SSL-Inhalte nicht cachen, setzt man eben keine Caching-Header und die Sache wäre erledigt, und das sogar vollkommen im Rahmen der Specs.
 
ice-breaker schrieb:
Die Idee ist absoluter Schwachsinn, SSL-Inhalte würden sich schon lange cachen lassen, wenn die Browser-Hersteller sich nur dazu entschließen würden.
Jetzt lies nochmal in der News nach, um welches Caching es wirklich geht. Deine Ausführung geht am Ansatz von HTTPi völlig vorbei.
 
Die Grafik auf Seite 8 sagt doch schon alles aus:

HTTP Total Object Size: 1532 MB
HTTPi Total Object Size: 21.95 MB


HTTP Publicly Cacheable Objects: 1385 MB
HTTPi Publicly Cacheable Objects: 19.39 MB
 
du meinst wohl s anstatt i ;)

HTTP: 346,629 1532 MB 251,826 (72.65%) 1385 MB (90.41%)
HTTPS: 5,036 21.95 MB 3,659 (72.66%) 19.39 MB (88.33%)
 
Der Artikel ist grober Unfug. Man cached nicht die Verbindung sondern die Daten. Die meisten Browser haben nur die Default-Einstellung, keine Daten die via HTTPS gekommen sind zu speichern, da diese sensitive Informationen beinhalten könnten, die dann ungeschützt im Browsercache liegen würden.

Wem dieses Risiko bekannt ist und der damit leben kann (z.B. weil die Platte eh verschlüsselt ist oder er regelmäßig den Cache löscht) kann seinem Browser mitteilen, doch bitte auch die Daten die via HTTPS kommen zu cachen.

Microsofts HTTPi konkurriert zu Googles SPDY. Bei beiden Ansätzen geht es darum, die Kosten für den Handshake zu minimieren...
 
Find ich problematisch. Man müsste im Browser so etwas sehr deutlich machen, dass auch der dümmste anzunehmende Nutzer erkennt "Das ist jetzt nicht vertraulich, aber echt". Zu groß ist die Gefahr, dass man an Stellen, wie HTTPS Pflicht wäre vom Betreiber HTTPi untergejubelt bekommt. Wenn Sony Passwörter im Klartext speichert würden die auch für alles HTTPi nehmen. Rechenlast schön und gut, ich nehme lieber die richtige Verschlüsselung.

P.S.: Bei wikipedia steht auch, dass das eigentlich rechenintensive der Verbindungsaufbau ist und nicht unbedingt die Verschlüsselung selber?!
 
Das ist doch inzwischen nicht mehr relevant, da moderne CPUs AES in Hardware beschleunigen. Da muss der Admin nur dran denken, das auch bevorzugt zu verwenden, indem er beispielsweise im Apache SSLCipherSuite verwendet. Dann sollte das auch für CDN mit 10GBit kein Thema mehr sein.
 
Also nachdem ich den Artikel gelesen habe kommt mir da gleich ein Nachteil in den Sinn:

HTTPS verschlüsselt alles gleichmäßig. Wenn man mitschneiden würde müsste man alles entschlüsseln um an Passwörter o.ä. zu gelangen.

HTTPi verschlüsselt nur die Passwörter. Wenn man mitgeschnitten hat, sucht man sich also genau die Stellen raus an denen verschlüsselt wurde und entschlüsselt.
Ergo weniger Aufwand für den Verschlüsslungsknacker und vermutlich schnellerer Erfolg.

.. oder habe ich das Verfahren jetzt nur falsch verstanden?
 
Zurück
Oben