Luise: Spricht etwas gegen SSL als Standard für Website?

Hallo,

spricht etwas dagegen meinen Besucher die Website nur im SSL-Modus anzubieten? D.h. bei Aufruf von www.test.de wird der Besucher direkt auf https://test.de geleitet?

Natürlich ist das Surfen auch ohne SSL möglich.

Gibt es Vor- oder Nachteile?

Sollte ich den Besucher entscheiden lassen?

Kann es zu Verbindungsproblemen kommen?

Danke und Liebe Grüsse

Luise

  1. Hi,

    spricht etwas dagegen meinen Besucher die Website nur im SSL-Modus anzubieten? D.h. bei Aufruf von www.test.de wird der Besucher direkt auf https://test.de geleitet?
    Natürlich ist das Surfen auch ohne SSL möglich.
    Gibt es Vor- oder Nachteile?

    einen Vorteil sehe ich nicht, solange keine Daten übermittelt werden, die in irgendeiner Weise geheimhaltungswürdig sind.
    Ein Nachteil ist die geringfügig längere Zeit zum Verbindungsaufbau. Das sind zwar nur wenige Zehntelsekunden pro Request, es summiert sich aber bei Seiten mit vielen eingebundenen Ressourcen.

    Kann es zu Verbindungsproblemen kommen?

    Es könnte in seltenen Fällen vorkommen, dass Zwangsproxies, die in Unternehmensnetzwerken für den Verkehr "nach draußen" eingesetzt werden, kein SSL zulassen. Ich hab mal in so einem Unternehmen gearbeitet. Der Grund für diese Einschränkung war: Bei SSL-Verbindungen kann der Proxy prinzipbedingt nicht mitlauschen, also die übertragenen Daten nicht auf Malware oder andere Inhalte checken, die die Firmen-Policy nicht zulassen möchte. Ergo: Nicht kontrollierbar, also gesperrt.

    Ciao,
     Martin

    --
    Realität ist eine Illusion, die durch Unterversorgung des Körpers mit Alkohol entstehen kann.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. hi,

      Es könnte in seltenen Fällen vorkommen, dass Zwangsproxies, die in Unternehmensnetzwerken für den Verkehr "nach draußen" eingesetzt werden, kein SSL zulassen. Ich hab mal in so einem Unternehmen gearbeitet. Der Grund für diese Einschränkung war: Bei SSL-Verbindungen kann der Proxy prinzipbedingt nicht mitlauschen, also die übertragenen Daten nicht auf Malware oder andere Inhalte checken, die die Firmen-Policy nicht zulassen möchte. Ergo: Nicht kontrollierbar, also gesperrt.

      Ein Proxy könnte diese Seiten aber trotzdem cachen. In dem Unternehmen wo ich mal war, haben wir das aber auch nicht gemacht, weil unsere Proxies gleichzeitig die Viren gescannt haben, was in Fall SSL nicht möglich ist und nur deswegen per Policy https-Inhalte directly ausgeliefert wurden.

      --
      Wetter wie immer: Warm aber kalt.
  2. spricht etwas dagegen meinen Besucher die Website nur im SSL-Modus anzubieten?

    Solange keine schützenswerten Daten dabei sind und jeder das gleiche sehen kann, spricht der Sinn dagegen :-)

    die Website nur im SSL-Modus anzubieten
    Natürlich ist das Surfen auch ohne SSL möglich.

    Bisschen widersprüchlich oder nicht?

    Sollte ich den Besucher entscheiden lassen?

    Warum sollte er sich für etwas entscheiden das er wahrscheinlich nicht versteht?

    1. spricht etwas dagegen meinen Besucher die Website nur im SSL-Modus anzubieten?
      Solange keine schützenswerten Daten dabei sind und jeder das gleiche sehen kann, spricht der Sinn dagegen :-)

      Das ist klar.

      Es gibt einige Formular, die genutzt werden, um Daten zu senden / in DB zu speichern, etc ...

      die Website nur im SSL-Modus anzubieten
      Natürlich ist das Surfen auch ohne SSL möglich.
      Bisschen widersprüchlich oder nicht?

      Nur zum Lesen natürlich

      Sollte ich den Besucher entscheiden lassen?
      Warum sollte er sich für etwas entscheiden das er wahrscheinlich nicht versteht?

      Versteht hin oder her, den Benutzer liest überall, dass SSL notwenig ist ... daher will er es auch ...

      Danke an ALLE

      1. Versteht hin oder her, den Benutzer liest überall, dass SSL notwenig ist ... daher will er es auch ...

        Die wenigsten lesen darüber oder wissen was SSL ist.
        Sensible Daten gehören verschlüsselt. Der Rest nicht unbedingt. Danach würd ich handeln.
        Mach keinen Blödsinn und spiel da lange mit Fragen rum. Das klingt für jemanden der sich auskennt nach: wollen Sie Daten sicher oder unsicher übertragen? Damit machst du dir keinen Ruf.

        1. Hallo,

          Sensible Daten gehören verschlüsselt. Der Rest nicht unbedingt. Danach würd ich handeln.

          seh ich auch so. Und ich bin immer wieder verständnislos, wenn Sites ihre Informationen nur verschlüsselt anbieten, bei denen ich als Nutzer ausschließlich passiv Daten abrufe. Was ist beispielsweise an den wöchentlichen Sonderangeboten von Aldi so geheim, dass man sie verschlüsselt übermitteln muss?

          Mach keinen Blödsinn und spiel da lange mit Fragen rum. Das klingt für jemanden der sich auskennt nach: wollen Sie Daten sicher oder unsicher übertragen? Damit machst du dir keinen Ruf.

          ACK. Das verunsichert nur. ;-)

          Ciao,
           Martin

          --
          Kennst du ein eisenhaltiges Abführmittel mit zwölf Buchstaben? - Handschellen.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          1. Hello,

            seh ich auch so. Und ich bin immer wieder verständnislos, wenn Sites ihre Informationen nur verschlüsselt anbieten, bei denen ich als Nutzer ausschließlich passiv Daten abrufe. Was ist beispielsweise an den wöchentlichen Sonderangeboten von Aldi so geheim, dass man sie verschlüsselt übermitteln muss?

            Die GET-Requests wohl kaum. Die wandern trotzdem unverschlüsselt durch das Netz. Es weiß also jeder poplige Obama-Spitzel und jeder Rasputin-Mitarbeiter dass DU bei ALDI geschaut hast.

            Aber was passiert mit den Post-Daten? Die sind Bestandteil der Payload und damit verschlüsselt, oder?

            Anders ist es, wenn man zu Aldi eine VPN-Verbindung aufbauen würde. Dann wären auch die GET-Requests innerhalb der "Hülle".

            Liebe Grüße aus dem schönen Oberharz

            Tom vom Berg

            --
             ☻_
            /▌
            / \ Nur selber lernen macht schlau
            http://bikers-lodge.com
            1. Hi,

              Was ist beispielsweise an den wöchentlichen Sonderangeboten von Aldi so geheim, dass man sie verschlüsselt übermitteln muss?
              Die GET-Requests wohl kaum. Die wandern trotzdem unverschlüsselt durch das Netz.

              nein, mitnichten. Und mit Neffen schon gar nicht.
              Bei HTTPS wird erst die SSL/TLS-Verbindung aufgebaut, und erst dann innerhalb dieses verschlüsselten und "abhörsicheren" Kanals der HTTP-Request gesendet. Ob GET oder POST, ist dabei völlig egal.

              Oder meintest du den ersten Seitenabruf, z.B. von http://www.aldi-sued.de/, der vom Client aus noch unverschlüsselt rausgeht? - Der wird ja dann auch nur mit einem Redirect auf dieselbe Adresse, aber mit HTTPS-Prefix beantwortet.

              Es weiß also jeder poplige Obama-Spitzel und jeder Rasputin-Mitarbeiter dass DU bei ALDI geschaut hast.

              Es kann jeder wissen, dass ich eine Verbindung zum Aldi-Webserver hergestellt habe. Aber ob ich dort Sonderangebote, das Firmenprofil oder Stellenangebote abgerufen habe, weiß keiner. Die Requests sind nicht abhörbar. Theoretisch.

              Aber was passiert mit den Post-Daten? Die sind Bestandteil der Payload und damit verschlüsselt, oder?

              Die Frage ist gegenstandslos, weil alle Requests und Responses verschlüsselt übermittelt werden, nachdem die Verbindung hergestellt ist.

              Anders ist es, wenn man zu Aldi eine VPN-Verbindung aufbauen würde. Dann wären auch die GET-Requests innerhalb der "Hülle".

              Nein, das sind sie bei "gewöhnlichem" HTTPS auch.

              Ciao,
               Martin

              --
              Ja, ja ... E.T. wusste schon, warum er wieder nach Hause wollte.
              Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              1. Hello,

                Anders ist es, wenn man zu Aldi eine VPN-Verbindung aufbauen würde. Dann wären auch die GET-Requests innerhalb der "Hülle".

                Nein, das sind sie bei "gewöhnlichem" HTTPS auch.

                ja, ist klar. Ich habe Adresse und Namen verwechselt.

                Die Adresse (IP) der Gegenstelle ist sichtbar, nicht jedoch der Name (URi). Der steckt schon _im_ Paket. Und wenn ich über einen Proxy gehe, ist halt nur die Adresse des Proxys bekannt, nicht aber die des eigentlichen Ziels, dass der dann für mich ansteuern kann.

                Liebe Grüße aus dem schönen Oberharz

                Tom vom Berg

                --
                 ☻_
                /▌
                / \ Nur selber lernen macht schlau
                http://bikers-lodge.com
  3. Lieber Luise,

    wie schon von meinen Vorrednern angemerkt, lässt sich nicht mitlauschen, was da über SSL übertragen wird. Genau deswegen empfiehlt Edward Snowden, dass man Seiten nur noch und ausschließlich über HTTPS ausliefert.

    Inwiefern das Verwenden von SSL das Lauschen stört, oder inwiefern es dank Kryptokalypse (Heartbleed-Bug u.ä.) kaum nennenswert beeinträchtigt wird, vermag ich nicht zu beurteilen. Es scheint mir aber prinzipiell eine sinnvolle Denkweise zu sein, was Snowden da propagiert.

    Liebe Grüße,

    Felix Riesterer.

    --
    ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:)
    1. Hello,

      wie schon von meinen Vorrednern angemerkt, lässt sich nicht mitlauschen, was da über SSL übertragen wird. Genau deswegen empfiehlt Edward Snowden, dass man Seiten nur noch und ausschließlich über HTTPS ausliefert.

      Das gilt aber nur, wenn sich beide Enden des Übertragungsweges in gesicherten Bereichen befinden. Üblicherweise werden Webseiten aber bei Massenhostern gespeichert und berechnet.

      Man kann aber dank Tagging der Pakte im Backbone sofort feststellen, woher das Paket kommt und dann ggf. gleich direkt in einem der beiden Hosts nachsehen (beim Hoster), was der denn da gleich verschlüsseln will. Bei Verwendung von PHP reicht dazu ein simples Append-Script und schon ist der Mitleser im Bilde.

      Gegen die "Snowden-Normalform" nützt das Verschlüsseln also gar nichts.

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://bikers-lodge.com
  4. Wenn man beides (HTTP und HTTPS) benutzt, muss man dann doch aber auch noch aufpassen, was gesendet wird oder?

    Angenommen öffentliche Daten werden immer über HTTP ausgeliefert. Man loggt sich ein ist in seinem "Control Center" oder was auch immer, sprich "persönliche" schützenswerte Daten. Die laufen dann über SSL, damit ist dann auch der Session-Cookie verschlüsselt. Aber wenn man dann auf eine statische Resource zugreift (eine Grafik, JavaScript- oder auch CSSS-Datei) und die via HTTP übermittelt wird, ist die Session-ID wieder ungeschützt oder?

    MfG
    bubble

    --
    If "god" had intended us to drink beer, he would have given us stomachs. - David Daye
    1. Hallo,

      Wenn man beides (HTTP und HTTPS) benutzt, muss man dann doch aber auch noch aufpassen, was gesendet wird oder?

      ja, unbedingt.

      Allerdings sollte man das tunlichst vermeiden: Mischen impossible!
      Sicher _kann_ man HTTP und HTTPS innerhalb eines Webauftritts mischen, theoretisch sogar innerhalb einer Seite - also etwa das HTML-Dokument mit HTTPS, die eingebundenen Bilder mit HTTP. Sollte man aber nicht.

      Angenommen öffentliche Daten werden immer über HTTP ausgeliefert. Man loggt sich ein ist in seinem "Control Center" oder was auch immer, sprich "persönliche" schützenswerte Daten. Die laufen dann über SSL, damit ist dann auch der Session-Cookie verschlüsselt. Aber wenn man dann auf eine statische Resource zugreift (eine Grafik, JavaScript- oder auch CSSS-Datei) und die via HTTP übermittelt wird, ist die Session-ID wieder ungeschützt oder?

      Zum Beispiel. Cookies, die von der Logik her zum Hauptdokument gehören, werden dann auch bei den untergeordneten Requests wieder mitgesendet - und zwar offen. Andererseits ist es ein Konzeptfehler, wenn z.B. die Session-ID allein eine potentiell kritische Information ist.

      Dennoch warnen die Browser in so einem Fall vor "mixed content", und auch wenn das System so aufgebaut ist, dass keine Gefahr besteht, verunsichert das doch den Nutzer. Vertrauen gewinnt man so nicht.

      Man sollte sich daher überlegen: Brauche ich SSL?
      Falls ja, sollte man es für die gesamte Site durchgängig verwenden, andernfalls komplett lassen.

      So long,
       Martin

      --
      Die späteren Ehen sind oft glücklicher als die erste, weil das natürliche Ende bereits absehbar ist.
        (George Bernhard Shaw)
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
  5. Hi,

    spricht etwas dagegen meinen Besucher die Website nur im SSL-Modus anzubieten? D.h. bei Aufruf von www.test.de wird der Besucher direkt auf https://test.de geleitet?

    Da mußt Du die Stiftung Warentest fragen, ob die das für deren Domain (die Du hier anstelle einer für Beispiele vorgesehenen Domain [example.org, example.com, .test, ...] benutzt) machen wollen.

    Gibt es Vor- oder Nachteile?

    Für https ist ein Zertifikat erforderlich. Sowas kostet normalerweise. Wenn man nicht für bestimmte Zwecke sowieso schon https braucht, kommt es also zu Mehrkosten (+ Mehraufwand, das Zertifikat muß besorgt, installiert und nach gewisser Zeit erneuert werden).

    cu,
    Andreas

    --
    Warum nennt sich Andreas hier MudGuard?
    O o ostern ...
    Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.