SSL Verbindung uns Ressourcen?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Sicherheitstechnisch ist das sicher Mumpitz. An einem CSS oder Hintergrundbild das sich Arsch und Friedrich runterladen können etwas zu verschlüsseln.

    Aber wie Gritsch schon sagte, man lädt halt alles per ssl runter. Wo verschlüsselt drauf steht, ist auch verschlüsselt drin.

    Letztendlich geben die Browser dann eine Warnung aus. Das verunsichert die User und damit ist das ein KO Kriterium - wie du ja schon bemerkt hast.

    Der Weg um den enormen Overhead zu umgehen (99% deines HTTP Request/Response/HTML/JS/CSS/IMAGE sind Overhead der verschlüsselt wird): Seite mit js machen und die Daten mit JSON o. Ä. hoch und runter schieben.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Manfred Kreß schrieb:

    Sicherheitstechnisch ist das sicher Mumpitz. An einem CSS oder Hintergrundbild das sich Arsch und Friedrich runterladen können etwas zu verschlüsseln.

    Aber wie Gritsch schon sagte, man lädt halt alles per ssl runter. Wo verschlüsselt drauf steht, ist auch verschlüsselt drin.

    Letztendlich geben die Browser dann eine Warnung aus. Das verunsichert die User und damit ist das ein KO Kriterium - wie du ja schon bemerkt hast.

    Der Weg um den enormen Overhead zu umgehen (99% deines HTTP Request/Response/HTML/JS/CSS/IMAGE sind Overhead der verschlüsselt wird): Seite mit js machen und die Daten mit JSON o. Ä. hoch und runter schieben.


    nein, es geht darum dass man keine externen resourcen laden soll/darf weil man ja nie weiß wer diese ändert und somit schadcode eingeschleust werden kann.

    ich habe noch nie gehört dass jemand all seine resourcen mit voller URL angibt anstatt den absoluten pfad zu verwenden.

    ob ein bild oder sonstwas per https oder doch nur per http geladen wird ist heutzutage ja vollkommen egal.

  • gritsch schrieb:

    nein, es geht darum dass man keine externen resourcen laden soll/darf weil man ja nie weiß wer diese ändert und somit schadcode eingeschleust werden kann.

    Er lädt ja nicht wirklich externe Ressourcen. Der Browser mäkelt halt, weil http und https zwei unterschiedliche URLs sind.

    Aber was solls das auseinander zu dröseln. Alles oder nichts! Ja, und so lange man nicht Twitterentwickler ist oder für nen Webserver auf nem kleinen embedded System entwickelt, juckt das wirklich nicht wegen des bisschen overhead von 99%.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Manfred Kreß schrieb:

    gritsch schrieb:

    nein, es geht darum dass man keine externen resourcen laden soll/darf weil man ja nie weiß wer diese ändert und somit schadcode eingeschleust werden kann.

    Er lädt ja nicht wirklich externe Ressourcen. Der Browser mäkelt halt, weil http und https zwei unterschiedliche URLs sind.

    Aber was solls das auseinander zu dröseln. Alles oder nichts! Ja, und so lange man nicht Twitterentwickler ist oder für nen Webserver auf nem kleinen embedded System entwickelt, juckt das wirklich nicht wegen des bisschen overhead von 99%.


    es geht darum dass er jede resource im quellcode mit "https://PFAD" angibt anstatt einfach nur "/PFAD". das sieht der browser (zumindest der ein oder ander) als EXTERNE und somit gefährliche resource.

  • Manfred Kreß schrieb:

    Er lädt ja nicht wirklich externe Ressourcen. Der Browser mäkelt halt, weil http und https zwei unterschiedliche URLs sind.

    Die Ressourcen könnten ja durchaus auf verschiedenen Maschinen liegen.

    Ausserdem geht es nicht nur darum, dass externe Ressourcen eventuell schadhaft sein können, sondern auch, dass allein der Zugriff darauf schon Dinge verraten könnte, die man ansonsten für sicher hält. Wenn ich als Angreifer die Kommunikation mitschneide, sehe ich bei einer SSL-Verbindung allerhöchsten die Hostname des Servers. Kommen jetzt aber nicht-SSL Requests dazu, kann ich etwa an der Reihenfolge der Abfragen nachvollziehen, was der Nutzer grade macht.
    ♥C++