Adressanzeige im Browserfenster

[Karl Heinz]

Hallo,

gebe ich eine URL in der Adressleiste des Browserfensters ein und drücke Enter so ändert sich die URL im Adressfenster des Browsers.

Teilweise kann ich das nachvollziehen, wenn z.B. von „ohne www“ auf „mit www“ umgeleitet (301 oder 302) wird.

Teilweise kann ich das allerdings nicht nachvollziehen, weil http verschwindet https hingegen nicht.

Nachfolgend ein Beispiel:

1.) http://www.fotoadvent.de wird umgewandelt in www.fotoadvent.de 2.) https://www.fotoadvent.de wird nicht umgewandelt 3.) http://fotoadvent.de wird umgewandelt in www.fotoadvent.de 4.) https://fotoadvent.de wird umgewandelt in https://www.fotoadvent.de

Frage zu 1 und zu 3:

Warum verschwindet das http:// nach der Betätigung von Enter?

Frage zu 2 und zu 4:

Warum verschwindet das https:// nach der Betätigung von Enter nicht?

Allgemeine Frage:

Die Domäne wird ja sowohl bei http als auch bei https geladen. Wie kann ich denn nun herausfinden ob die Domäne http, https oder beides verwendet?

[Der Martin]

Hi,

gebe ich eine URL in der Adressleiste des Browserfensters ein und drücke Enter so ändert sich die URL im Adressfenster des Browsers.

sollte eigentlich nicht, außer in Sonderfällen.

Teilweise kann ich das nachvollziehen, wenn z.B. von „ohne www“ auf „mit www“ umgeleitet (301 oder 302) wird.

Ja, eine Umleitung (Redirect) ist so ein Sonderfall.

Teilweise kann ich das allerdings nicht nachvollziehen, weil http verschwindet https hingegen nicht.

Das ist eine schlechte Angewohnheit mancher Browser, z.B. Firefox. Das Präfix http:// wird in der Anzeige weggelassen, weil es der Default ist. Dem Firefox kann man diese Unart AFAIR abgewöhnen, indem man die Einträge browser.urlbar.formatting.enabled und browser.urlbar.trimURLs in about:config auf false setzt.

1.) http://www.fotoadvent.de wird umgewandelt in www.fotoadvent.de
2.) https://www.fotoadvent.de wird nicht umgewandelt
3.) http://fotoadvent.de wird umgewandelt in www.fotoadvent.de
4.) https://fotoadvent.de wird umgewandelt in https://www.fotoadvent.de

Frage zu 1 und zu 3:

Warum verschwindet das http:// nach der Betätigung von Enter?

Weil das der Normalfall ist, mit dem man den Nutzer nicht weiter behelligen möchte.

Frage zu 2 und zu 4:

Warum verschwindet das https:// nach der Betätigung von Enter nicht?

Weil das ein Sonderfall ist (verschlüsselte Verbindung), über den der Nutzer Bescheid wissen soll.

Die Domäne wird ja sowohl bei http als auch bei https geladen.

Hä?

Wie kann ich denn nun herausfinden ob die Domäne http, https oder beides verwendet?

Ausprobieren. Es gibt meines Wissens keinen anderen Weg, das herauszufinden.

So long,
 Martin

[Jörg Reinholz]

Moin!

1.) http://www.fotoadvent.de wird umgewandelt in www.fotoadvent.de
2.) https://www.fotoadvent.de wird nicht umgewandelt
3.) http://fotoadvent.de wird umgewandelt in www.fotoadvent.de
4.) https://fotoadvent.de wird umgewandelt in https://www.fotoadvent.de

Die Domäne wird ja sowohl bei http als auch bei https geladen.

Hä?

Karl Heinz meint die Weiterleitung von http://fotoadvent.de zu http://www.fotoadvent.de und von https://fotoadvent.de zu https://www.fotoadvent.de - welche aber die Betreiber von fotadvend.de bestellt und bezahlt haben. für welche der feurige Fuchs nicht verantwortlich ist. Der tut nur brav was ihm gesagt wird:

---request begin---
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows rv:32.0) Gecko/20100101 Firefox/32.0
Accept: */*
Host: fotoadvent.de   ###### <- schaust Du hier 
Connection: Keep-Alive

---request end---
HTTP-Anforderung gesendet, warte auf Antwort... 
---response begin---
HTTP/1.1 302 Found
Date: Mon, 23 Nov 2015 20:19:45 GMT
Server: Apache
Location: http://www.fotoadvent.de/    ###### <- schaust Du hier 

Jörg Reinholz

[dedlfix]

Tach!

Warum verschwindet das http:// nach der Betätigung von Enter?

Das ist das spezifische Verhalten von Browsern. Da gibt es keine technisch bedingten Hintergründe. Die Browser werfen das raus, weil es wohl nicht für den Anwender wichtig ist.

Frage zu 2 und zu 4:

Warum verschwindet das https:// nach der Betätigung von Enter nicht?

Das hingegen ist (derzeit noch) wichtig, um Verschlüsslung anzuzeigen. Soweit ich mich erinnere, will der Chrome das in Zukunft aber genau andersrum machen. https soll Standard werden und http-Seiten als unsicher gebrandmarkt werden.

Die Domäne wird ja sowohl bei http als auch bei https geladen. Wie kann ich denn nun herausfinden ob die Domäne http, https oder beides verwendet?

Die Domäne kann dafür nichts. Die hat mit Protokollen nichts am Hut. Die Webserver-Konfiguration legt fest, ob er HTTP- und/oder HTTPS-Requests behandelt und was er dabei jeweils ausliefert. Wenn das eine oder andere nicht unterstützt wird, gibts entsprechende Fehlermeldungen. Welche da im einzelnen kommt, hängt ebenfalls von der individuellen Konfiguration ab.

dedlfix.

[Karl Heinz]

Die Domäne kann dafür nichts. Die hat mit Protokollen nichts am Hut. Die Webserver-Konfiguration legt fest, ob er HTTP- und/oder HTTPS-Requests behandelt und was er dabei jeweils ausliefert. Wenn das eine oder andere nicht unterstützt wird, gibts entsprechende Fehlermeldungen. Welche da im einzelnen kommt, hängt ebenfalls von der individuellen Konfiguration ab.

Nun gibt es ja weder bei http noch bei https Fehlermeldungen.

Bedeutet das, dass sowohl http als auch https vom Webserver unterstützt wird?

Falls ja, welchen Sinn macht das?

Wenn man schon https verwendet, dann sollte man es doch gründsätzlich verwenden sprich http nichtmehr unterstützen oder?

In der Praxis wird https häufig nur im Checkout-Prozess, wenn sensible Daten übertragen werden, verwendet. Das ist doch eigentlich die beste Lösung oder?

[dedlfix]

Tach!

Nun gibt es ja weder bei http noch bei https Fehlermeldungen. Bedeutet das, dass sowohl http als auch https vom Webserver unterstützt wird?

Muss ja, wenn der in beiden Fällen was ausliefert.

Falls ja, welchen Sinn macht das?

Wenn man schon https verwendet, dann sollte man es doch gründsätzlich verwenden sprich http nichtmehr unterstützen oder?

Einen technischen Grund, generell nur HTTPS zu verwenden, kenne ich nicht. Es ist eher eine politische und/oder, wenn es von Konzernen vorangetrieben wird, eine wirtschaftliche Entscheidung, generell auf HTTPS zu setzen.

Etwas erbsenzählend: generell nicht unterstützen geht auch nicht, weil viele einfach nur die Adresse ohne http:// oder https:// eingeben und dann erstmal vom Browser zum http:// geschickt werden. Zumindest eine Umleitung auf https:// sollte da noch zu finden sein.

In der Praxis wird https häufig nur im Checkout-Prozess, wenn sensible Daten übertragen werden, verwendet. Das ist doch eigentlich die beste Lösung oder?

Wie man es nimmt. Die wichtigsten sensiblen Daten werden im Checkout-Prozess übertragen. Das Stöbern im Katalog ist nicht zwangsläufig schützenswert. Obwohl es auch da Situationen gibt, die Außenstehende nichts angehen sollen. Aber am Ende lauschen die, die das machen wollen, eben an einem der beiden Enden mit, wenn es einfacher ist, den Server oder den Rechner des Anwenders zu öffnen als die verschlüsselte Übertragung.

dedlfix.

[Mitleser]

Einen technischen Grund, generell nur HTTPS zu verwenden, kenne ich nicht. Es ist eher eine politische und/oder, wenn es von Konzernen vorangetrieben wird, eine wirtschaftliche Entscheidung, generell auf HTTPS zu setzen.

Ein technischer Grund wäre: es reduziert die Komplexität. Wenn ich innerhalb eines Projekts stumpf auf "https://example.org/ressource_xyz" oder "/ressource_xyz" verlinken kann, ist das etwas einfacher und robuster, als stets beachten zu müssen, ob ich jetzt auf "http" oder "https" gehen möchte.

Noch einer: vor einigen Jahren hat https auf dem Webserver noch einen relevanten Overhead erzeugt. Der ist mittlerweile zu vernachlässigen.

Ein weiterer, wichtiger Grund ist Google. Neben z.B. Ladezeiten ist https mittlerweile ein Ranking-Kriterium geworden.

[dedlfix]

Tach!

Einen technischen Grund, generell nur HTTPS zu verwenden, kenne ich nicht. Es ist eher eine politische und/oder, wenn es von Konzernen vorangetrieben wird, eine wirtschaftliche Entscheidung, generell auf HTTPS zu setzen.

Ein technischer Grund wäre: es reduziert die Komplexität. Wenn ich innerhalb eines Projekts stumpf auf "https://example.org/ressource_xyz" oder "/ressource_xyz" verlinken kann, ist das etwas einfacher und robuster, als stets beachten zu müssen, ob ich jetzt auf "http" oder "https" gehen möchte.

Dieselbe Begründung könntest du auch für http:// statt https:// anführen. Es gibt aber für deinen Fall mit relativen Verweisen (zuzüglich Serverumleitungen falls das Protokoll nicht stimmt) andere Möglichkeiten, als ständig die komplette URL anzugeben. Du nennst hier eher eine organisatorische Befindlichkeit statt einer technisch begründeten Notwendigkeit.

Ein weiterer, wichtiger Grund ist Google. Neben z.B. Ladezeiten ist https mittlerweile ein Ranking-Kriterium geworden.

Der ist auch nicht technisch begründet sondern in den Bereich politisch/wirtschaftlich einzuordnen.

dedlfix.

[Mitleser]

Du nennst hier eher eine organisatorische Befindlichkeit statt einer technisch begründeten Notwendigkeit.

Ich sehe das durchaus als technischen "Grund", kann man natürlich auch als "organisatorische Befindlichkeit" sehen. Wortklauberei, IMHO. "technisch begründete Notwendigkeit" hast Du im Nachgang in den Raum geworfen, das ist natürlich nicht gegeben, stimmt.

Ein weiterer, wichtiger Grund ist Google. Neben z.B. Ladezeiten ist https mittlerweile ein Ranking-Kriterium geworden.

Der ist auch nicht technisch begründet sondern in den Bereich politisch/wirtschaftlich einzuordnen.

Die Tatsache, dass das der Overhead mittlerweile vernachlässigbar ist, hat ja schon irgendwie auch so ein wenig mit Technik zu tun.

[dedlfix]

Tach!

Du nennst hier eher eine organisatorische Befindlichkeit statt einer technisch begründeten Notwendigkeit.

Ich sehe das durchaus als technischen "Grund", kann man natürlich auch als "organisatorische Befindlichkeit" sehen. Wortklauberei, IMHO. "technisch begründete Notwendigkeit" hast Du im Nachgang in den Raum geworfen, das ist natürlich nicht gegeben, stimmt.

Ich sehe das nicht als Wortklauberei, vielmehr vermute ich hier eine Differenz zwischen deiner und meiner Auffassung der Begrifflichkeit "technischer Grund". Für mich ist das etwas, das man nicht umgehen kann, weil es sonst nicht mehr funktioniert. Bei der von dir erwähnte Verlinkung hat man aber sehr wohl eine ganzen Reihe von Möglichkeiten, sie anders zu gestalten, ohne an eine Grenze zu stoßen.

Vielleicht wird das an einem anderen Beispiel deutlicher. Es gibt ja diverse Klammernsetzungsstile (oder auch Coding-Style-Regeln allgemein) und in der Regel ist es der eigenen Befindlichkeit geschuldet, welchen man davon bevorzugt einsetzt. Vielleicht hat der eine gegenüber dem anderen den Vorteil der leichteren Kopierbarkeit von Code-Blöcken, aber das ist keine technische Einschränkung, denn der Code funktioniert mit beiden Stilen. Es ist nur eine organisatorische Einschränkung, die einen beim Bearbeiten des Codes betrifft. Man könnte den Stil ja auch ändern und hätte dann dieses Problem nicht mehr.

Dasselbe trifft in deinem Link-Beispiel zu. Du könntest die Art und Weise, wie du Links setzt, ändern oder auch das dir selbst auferlegte Prinzip aufgeben und stattdessen situationsabhängig immer wieder erneut nachdenken und entscheiden. Weil du diese Wahlmöglichkeit hast, bestimmt nicht die Technik deine Arbeitsweise, sondern du selbst.

Ich möchte das jetzt nicht als Angriff gewertet wissen. Ich sehe vielmehr, dass das zutiefst menschlich ist, dass der innere Schweinehund immer wieder versucht, sich das Leben bequem(er) zu machen und sich deshalb einfache, möglichst in allen Situationen anwendbare Prinzipien ausdenkt, an die man sich ohne groß nachzudenken halten kann. Und das ist ja auch nicht generell verkehrt. Es gibt genügend andere Baustellen im Leben, die wichtiger sind als so mancher Kleinkram. Allerdings leidet wegen dieser Prinzipien mitunter die Qualität, vor allem dann, wenn das Prinzip nicht wirklich zur konkreten Situation passt.

dedlfix.

[Mitleser]

Ich sehe das nicht als Wortklauberei, vielmehr vermute ich hier eine Differenz zwischen deiner und meiner Auffassung der Begrifflichkeit "technischer Grund" [...]

OK. Ich kann Deiner Argumentation folgen, da ist was dran. Aber nochmal konkret zu der Fragestellung: inwiefern leidet denn die Qualität, wenn ich einfach stumpf zum DocumentRoot, bzw. auf https verlinke? Ist das nicht viel mehr Qualitätssicherung, weil man damit den potentiellen Fehler umgeht, dass schützenswerte Inhalte versehentlich unverschlüsselt übertragen werden?

Es ist doch beispielsweise nicht allzuweit hergeholt, dass ein formals unkritisches Formular auf einmal ein kritisches Feld verpasst bekommt und dabei übersehen wird, dass das Formular noch nicht auf https verweist.

[JürgenB]

Hallo,

ich verstehe die Intentionen, die hinter "man soll generell htps verwenden" stehen, aber ich sehe auch ein Problem:

Nicht jeder ist bereit, ein (teures) allgemein anerkanntes Zertifikat einzusetzen. Das hat dann aber zur Folge, das Besucher mit einer Warnung begrüßt werden. Wenn ich z.B. mit meinem alten Windows7-Smartphone die selfthtml-Seiten besuche, wird mir jedes mal vom Besuch abgeraten. Das alte Ding will das Zertifikat einfach nicht dauerhaft akzeptieren. Aber auch das Zertifikat, dass mein Hoster per default anbietet, wird nicht als vertrauenswürdig eingestuft.

Gruß Jürgen

[Christian Kruse]

Hallo JürgenB,

Nicht jeder ist bereit, ein (teures) allgemein anerkanntes Zertifikat einzusetzen.

Es gibt seit Jahren StartSSL, die Zertifikate für einzelne Domains <del>umsonst</del><ins>kostenfrei</ins> ausstellen. Und ab dem 3. Dezember gibt es auch Let's Encrypt, die auch Zertifikate <del>umsonst</del><ins>kostenfrei</ins> ausstellen.

Man muss schon lange keine selbst signierten Zertifikate mehr verwenden. SELFHTML hat für seine Zertifikate auch nichts bezahlt :-)

LG,
CK

[JürgenB]

Hallo Christian,

Nicht jeder ist bereit, ein (teures) allgemein anerkanntes Zertifikat einzusetzen.

Es gibt seit Jahren StartSSL, die Zertifikate für einzelne Domains <del>umsonst</del><ins>kostenfrei</ins> ausstellen. Und ab dem 3. Dezember gibt es auch Let's Encrypt, die auch Zertifikate <del>umsonst</del><ins>kostenfrei</ins> ausstellen.

ich weiß. Aber werden diese Zertifikate denn automatisch von den Browsern akzeptiert? Oder kommt da auch wieder die Warnung vor einem unsicheren Zertifikat?

Man muss schon lange keine selbst signierten Zertifikate mehr verwenden. SELFHTML hat für seine Zertifikate auch nichts bezahlt :-)

und eben vor diesem warnt mich mein altes Smartphone.

Gruß Jürgen

[Christian Kruse]

Hallo JürgenB,

ich weiß. Aber werden diese Zertifikate denn automatisch von den Browsern akzeptiert? Oder kommt da auch wieder die Warnung vor einem unsicheren Zertifikat?

StartSSL ist seit Jahren in den Browsern und Let's Encrypt wird cross-signed von einer CA, die seit Jahren in den Browsern ist.

Man muss schon lange keine selbst signierten Zertifikate mehr verwenden. SELFHTML hat für seine Zertifikate auch nichts bezahlt :-)

und eben vor diesem warnt mich mein altes Smartphone.

Das liegt aber an deinem alten Smartphone und daran, dass ich alle alten Ciphers abgeschaltet habe, nicht am Cert ;-)

LG,
CK

[JürgenB]

Hallo Christian,

Nicht jeder ist bereit, ein (teures) allgemein anerkanntes Zertifikat einzusetzen.

Es gibt seit Jahren StartSSL, die Zertifikate für einzelne Domains <del>umsonst</del><ins>kostenfrei</ins> ausstellen. Und ab dem 3. Dezember gibt es auch Let's Encrypt, die auch Zertifikate <del>umsonst</del><ins>kostenfrei</ins> ausstellen.

ich habe gerade mal bei meinem Provider angefragt, der nimmt für das Einbinden fremder Zertifikate einmalig 50€, für seine eigenen Zertifikate nimmt er ab 2€ pro Monat. Also nicht wirklich kostenfrei.

Ich vermute, ohne Zugang zur Serverkonfiguration, also auf .htaccess-Niveau, kann ich kein Zertifikat installieren.

Gruß Jürgen

[Christian Kruse]

Hallo JürgenB,

ich habe gerade mal bei meinem Provider angefragt, der nimmt für das Einbinden fremder Zertifikate einmalig 50€, für seine eigenen Zertifikate nimmt er ab 2€ pro Monat. Also nicht wirklich kostenfrei.

Hehe, nicht schlecht dafür, dass der Provider quasi keinen Aufwand hat.

Ich vermute, ohne Zugang zur Serverkonfiguration, also auf .htaccess-Niveau, kann ich kein Zertifikat installieren.

Das ist richtig.

LG,
CK

[Matthias Apsel]

Hallo Christian Kruse,

Ich vermute, ohne Zugang zur Serverkonfiguration, also auf .htaccess-Niveau, kann ich kein Zertifikat installieren.

Das ist richtig.

Gibt es eine möglichst allgemeingültige Anleitung, die sich auch für unser wiki anpassen lässt?

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@JürgenB

ich verstehe die Intentionen, die hinter "man soll generell htps verwenden" stehen

Ich glaube, eine wurde hier noch gar nicht angesprochen: Wenn unsensible Daten unverschlüsselt übertragen werden, weiß ein Angreifer, auf welche Daten er sich konzentrieren wird. Wenn hingegen alles verschlüsselt wird, muss er erstmal die Nadel im Heuhaufen finden.

LLAP 🖖

[dedlfix]

Tach!

Aber nochmal konkret zu der Fragestellung: inwiefern leidet denn die Qualität, wenn ich einfach stumpf zum DocumentRoot, bzw. auf https verlinke? Ist das nicht viel mehr Qualitätssicherung, weil man damit den potentiellen Fehler umgeht, dass schützenswerte Inhalte versehentlich unverschlüsselt übertragen werden?

Die Aussage zur Qualität war allgemein gehalten, nicht konkret auf den Fall bezogen. Die konkrete Frage vermag ich nicht in Bezug auf dein konkretes Projekt zu beantworten, weil ich dies nicht kenne. Aber ich versuche mal eine allgemeingültige Antwort, wohlwissend, dass ich diese bei besonderem Grund in konkreten Fällen auch nicht stur durchsetzen würde. Man holt sich mehr Probleme ins Haus, wenn man vollständige URLs inklusive Domainnamen verwendet. Man kann so zumindest schlechter auf einem nicht-produktiven System mit abweichender URL die Anwendung entwickeln oder testen. Ganz zu schweigen davon, dass man im Entwicklungssystem vielleicht vorwiegend mit http statt -s arbeiten möchte, weil beispielsweise sonst die Browser immer über das selbst ausgestellte Zertifikat jammern. (Kann man umgehen, aber das ist eine andere Baustelle.) Das sind Gründe, die stark für relative URLs sprechen. Die Angst, am Ende ungesicherte Verbindungen zu haben, braucht man nicht zu haben. Man kann den produktiven Webserver so einrichten, dass er alle http-Verbindungen auf https weiterleitet.

Es ist doch beispielsweise nicht allzuweit hergeholt, dass ein formals unkritisches Formular auf einmal ein kritisches Feld verpasst bekommt und dabei übersehen wird, dass das Formular noch nicht auf https verweist.

Wenn es relativ verweist ist das zusammen mit der Webserverkonfiguration kein Problem. Der erste GET-Aufruf kommt mit http daher und wird auf https weitergeleitet, anschließend wird das Formular relativ zu dieser https-Adresse abgesendet. Alles ist gut.

Ich hätte eher Bedenken, dass das Vollständige-URL-Prinzip an einigen Stellen übersehen worden sein könnte. Wenn dann nicht der Webserver umleitet, hast du trotz deines gut gemeinten Prinzips eine Lücke.

dedlfix.

[pl]

hi,

Noch einer: vor einigen Jahren hat https auf dem Webserver noch einen relevanten Overhead erzeugt. Der ist mittlerweile zu vernachlässigen.

Der Overhead ist immernoch derselbe. Am Client übrigens auch. Flinke HW vertuscht das nur.

[Mitleser]

Noch einer: vor einigen Jahren hat https auf dem Webserver noch einen relevanten Overhead erzeugt. Der ist mittlerweile zu vernachlässigen.

Der Overhead ist immernoch derselbe. Am Client übrigens auch. Flinke HW vertuscht das nur.

Ich gehe stark davon aus, dass Du bereits eine deutlich überlegene Alternative entwickelt hast und bald hier im Forum vorstellen wirst.

[Der Martin]

Hi,

Noch einer: vor einigen Jahren hat https auf dem Webserver noch einen relevanten Overhead erzeugt. Der ist mittlerweile zu vernachlässigen.

Der Overhead ist immernoch derselbe. Am Client übrigens auch. Flinke HW vertuscht das nur.

Ich gehe stark davon aus, dass Du bereits eine deutlich überlegene Alternative entwickelt hast und bald hier im Forum vorstellen wirst.

hihi, und die Musterimplementierung wird ganz bestimmt in Perl sein. :-)

So long,
 Martin

[pl]

Noch einer: vor einigen Jahren hat https auf dem Webserver noch einen relevanten Overhead erzeugt. Der ist mittlerweile zu vernachlässigen.

Der Overhead ist immernoch derselbe. Am Client übrigens auch. Flinke HW vertuscht das nur.

Ich gehe stark davon aus, dass Du bereits eine deutlich überlegene Alternative entwickelt hast und bald hier im Forum vorstellen wirst.

Aber nicht, wenn ich das dann hier zwanzigmal erklären muss.

[Karl Heinz]

Die Domäne kann dafür nichts. Die hat mit Protokollen nichts am Hut. Die Webserver-Konfiguration legt fest, ob er HTTP- und/oder HTTPS-Requests behandelt und was er dabei jeweils ausliefert. Wenn das eine oder andere nicht unterstützt wird, gibts entsprechende Fehlermeldungen. Welche da im einzelnen kommt, hängt ebenfalls von der individuellen Konfiguration ab.

Angenommen sowohl HTTP als auch HTTPS werden untersützt und ich möchte meine Webeseite in der Google Search-Console hinterlegen um Daten zusammeln:

https://support.google.com/webmasters/answer/6258314?hl=de&ref_topic=3309469

Muss ich dann vorne den URL mit dem Präfix http oder mit dem Präfix https hinzufügen?

[Der Martin]

Moin,

Angenommen sowohl HTTP als auch HTTPS werden untersützt und ich möchte meine Webeseite in der Google Search-Console hinterlegen um Daten zusammeln:

https://support.google.com/webmasters/answer/6258314?hl=de&ref_topic=3309469

Muss ich dann vorne den URL mit dem Präfix http oder mit dem Präfix https hinzufügen?

das hängt von dir bzw. deinen Wünschen ab. Wenn du bevorzugt verschlüsselte Verbindungen möchtest, trägst du hier natürlich direkt die HTTPS-Adresse ein.

Dann solltest du aber trotzdem dafür sorgen, dass alle URLs auch mit unverschlüsseltem HTTP erreichbar sind - und wenn's nur in Form einer Umleitung auf die entsprechende HTTPS-URL ist.

So long,
 Martin

[Karl Heinz]

Nochmal zusammengefasst mit Bitte um Bestätigung bzw. eventuelle Korrektur :-)

• aktuell wird sowohl http als auch https unterstützt (das erkenne ich zum einen daran, dass weder bei http noch bei https eine Fehlermeldung im Browser kommt und zum anderen das bei http nicht auf https umgeleitet wird bzw. das bei https nicht auf http umgeleitet wird).

• um in der jetzigen Situation für alle Requests (sowohl http als auch https) Daten in der Search-Console sammeln zu können müsste ich zum einen http und zum anderen https in der Search-Console hinterlegen.

• weil ich die Daten für http und https allerdings nicht in zwei verschiedenen Web-Propertys, bezogen auf die Seach-Console, sammeln möchte wäre es klüger entweder nur http oder https zu unterstützen.

• Wird nur eines der beiden Protokolle unterstützt möchte ich ja trodzem erreichen, dass die Nutzer bei der Eingabe des anderen Protokolls keine Fehlermeldung vom Browser erhalten. Aus diesem Grund leite ich bei der Eingabe des nicht unterstützten Protokols einfach auf das unterstütze um. Wird z.B. nur http unterstützt und gibt jemand https ein so leite ich per 301 auf http um.

• Was sollte ich denn für die Seite verwenden? Nur http, nur https oder eine Kombination aus beidem (z.B. für den Checkout https und für die restlichen Seiten http)?

• Angenommen ich verwende für manche Seiten http für manche https und für wieder andere http und https. Damit mir dann, bezogen auf die Search-Console, keine Informationen verloren gehen bin ich doch dann eigentlich gezwungen sowohl http als auch https in der Search-Consol zu hinterlegen oder?

[Jörg Reinholz]

Moin!

Wird z.B. nur http unterstützt und gibt jemand https ein so leite ich per 301 auf http um.

Äh nein. Um das tun zu können müsste https bereits unterstützt werden. Ist das nicht der Fall kommt schon keine Verbindung zu Stande.

• Ohne weiteres würde der Browser bei https den Standardport 443 auswählen. Dort lauscht aber nichts, wenn https nicht konfiguriert ist.
• Gibt der Benutzer jetzt https://example.com:80/ ein (und also den Port vor), dann geht das dennoch nicht, weil der Browser dann eine verschlüsselte Verbindung will und anderes nicht mal in Erwägung zieht.

Jörg Reinholz

[Karl Heinz]

Hallo,

grundsätzlich kann man den Web-Server ja für folgende vier Varianten konfigurieren:

1. Für alle Seiten wird ausschließlich http unterstützt (bei der Eingabe von https im Browser gibt es eine Fehlermeldung)

2. Für alle Seiten wird ausschließlich https unterstützt (bei der Eingabe von http im Browser gibt es eine Fehlermeldung)

3. Für alle Seiten wird sowohl http als auch https unterstützt

4. Für mache Seiten wird nur http unterstützt (Startseite, Kategorie Seite usw.) für andere Seiten nur https (Seiten im Checkout-Prozess, da hier sensible Daten wie z.B. die Bankverbindung übertragen werden)

Welche der vier Lösungsvarianten wäre denn zum heutigen Zeitpunkt die ideale Lösung? Grundsätzlich tendiere ich zu Variante 2, damit würden die Daten dann grundsätzlich verschlüsselt übertragen. Sicherlich ist die Verschlüsselung eine zusätzliche Performance-Last. Meines Erachtens ist die Last bei dem heutigen schnellen Internet allerdings zu vernachlässigen.

[dedlfix]

Tach!

1. Für alle Seiten wird ausschließlich http unterstützt (bei der Eingabe von https im Browser gibt es eine Fehlermeldung)

2. Für alle Seiten wird ausschließlich https unterstützt (bei der Eingabe von http im Browser gibt es eine Fehlermeldung)

Zum Zusatz in Klammern gibt es mindestens noch die Alternative, dass man statt der Fehlermeldung eine Umleitung zum Browser schickt.

3. Für alle Seiten wird sowohl http als auch https unterstützt

Zumindest der Apache wird so konfiguriert, dass das zwei verschiedene VHosts sind. Da könnten auch zwei völlig verschiede Inhalte präsentiert werden. Ob das praktikabel ist, steht auf einem anderen Blatt.

4. Für mache Seiten wird nur http unterstütz (Startseite, Kategorie Seite usw.) für andere Seiten nur https (Seiten im Checkout-Prozess, da hier sensible Daten wie z.B. die Bankverbindung übertragen werden)

Es wird eher so sein, dass beide VHosts auf dasselbe Verzeichnis zeigen und erst zum Checkout-Prozess zwingend umgeschaltet wird. Vorher könnte man zu Fuß das s ergänzen und bekäme die gesamte Site verschlüsselt. Es ergibt allgemein wenig Sinn, zum Beispiel eine Shop-Software so aufzuteilen, dass die Teile in unterschiedlichen VHosts abgehandelt werden.

Welche der vier Lösungsvarianten wäre denn zum heutigen Zeitpunkt die ideale Lösung? Grundsätzlich tendiere ich zu Variante 2, damit würden die Daten dann grundsätzlich verschlüsselt übertragen.

Grundsätzlich hab ich da auch grad kein Gegenargument, wenn statt deiner Klammerbemerkung die von mir genannte Alternative zum Einsatz kommt. Im konkreten Fall kann man jedoch auch anders entscheiden, wenn andere Begründungen und Notwendigkeiten ins Spiel kommen.

Sicherlich ist die Verschlüsselung eine zusätzliche Performance-Last. Meines Erachtens ist die Last bei dem heutigen schnellen Internet allerdings zu vernachlässigen.

Immer, wenn ich Systeme mit Websites überwache, langweilt sich die CPU. Die Serverseite sollte dabei weniger ein Problem darstellen. Das wäre eher auf schwachbrüstigen mobilen Clients zu suchen.

dedlfix.

[Karl Heinz]

Aus der Praxis kenne ich eine ganze Menge Online-Shops die https nur im Checkout-Prozess verwenden, auf den restlichen Seiten hingegen http.

Ich verstehe nicht so richtig den Beweggrund dahinter, grundsätzlich hätte man doch dann gleich alles auf https umstellen können, sowohl den Checkout-Prozess als auch die restlichen Seiten.

Habt ihr eine Begründung dafür, warum das in der Praxis häufig so gemacht wird (https nur im Checkout-Prozess und nicht auf allen Seiten)?

[Christian Kruse]

Hallo Karl,

Habt ihr eine Begründung dafür, warum das in der Praxis häufig so gemacht wird (https nur im Checkout-Prozess und nicht auf allen Seiten)?

Das ist ein Vorgehen aus der Vergangenheit. Man hat lange Zeit gar kein HTTPS verwendet; irgendwann hat man das dann nachgerüstet und dabei halt nur das nötigste gemacht, zumals damals[tm] HTTPS noch teuer war. Manche haben das bis heute bei behalten und machen das immer noch so, manche haben einfach nie wieder was daran geändert. Heute gibt es keinen sinnvollen Grund mehr, dass man das nur noch für den Checkout-Prozess macht.

LG,
CK

[Karl Heinz]

Heute gibt es keinen sinnvollen Grund mehr, dass man das nur noch für den Checkout-Prozess macht.

Warum wird denn hier im Forum für die Mobile Variante noch http genutzt und nicht stattdessen https?

Habe es mit meinem Samsung Galaxy Note III getestet.

[dedlfix]

Tach!

Warum wird denn hier im Forum für die Mobile Variante noch http genutzt und nicht stattdessen https?

Es gibt kein mobiles Extra-Netz und es gibt keine mobile Variante dieses Forums. Es ist alles eins.

Habe es mit meinem Samsung Galaxy Note III getestet.

Das kann daran liegen, dass dein verwendeter Browser nicht mehr auf dem aktuellen Stand ist, was Verschlüsslungstechnik angeht und deshalb keine Verschlüsslung ausgehandelt werden kann. Probier mal einen aktuelleren Browser.

Nachtrag: Diese Theorie passt nicht, siehe Antwort von CK.

dedlfix.

[Christian Kruse]

Hallo Karl,

Heute gibt es keinen sinnvollen Grund mehr, dass man das nur noch für den Checkout-Prozess macht.

Warum wird denn hier im Forum für die Mobile Variante noch http genutzt und nicht stattdessen https?

Wird nicht, da musst du geschielt haben oder da hat sich jemand in deine Leitung geschlichen. Ich mache einen 301-Redirect auf die HTTPS-Variante:

➜ ckruse@vali ~  % curl -I http://forum.selfhtml.org/
HTTP/1.1 301 Moved Permanently
Server: nginx/1.6.2
Date: Mon, 23 Nov 2015 07:42:42 GMT
Content-Type: text/html
Content-Length: 184
Connection: keep-alive
Location: https://forum.selfhtml.org/

➜ ckruse@vali ~  %

Du kannst das Forum nicht mit HTTP nutzen. Ausserdem sende ich einen STS-Header:

➜ ckruse@vali ~  % curl -I https://forum.selfhtml.org/
[...]
Strict-Transport-Security: max-age=31536000
[...]
➜ ckruse@vali ~  %

Dein Browser sollte also, sobald er einmal die HTTPS-Ressource abgerufen hat, automatisch auf HTTPS wechseln und sich weigern HTTP mit dem Foren-Server zu sprechen.

LG,
CK

[Karl Heinz]

Wie du im Screenshot unten erkennen kannst tritt dieses Phänomen nur bei Google Chrome nicht beim Firefox.

Zunächst dachte ich das durchgestrichene https bedeutet das https nicht unterstützt wird.

Nun weiß ich es besser mich würde aber trotzdem interessieren warum https bei Google Chrome durchgestrichen dargestellt wird?

[Christian Kruse]

Hallo Karl,

Nun weiß ich es besser mich würde aber trotzdem interessieren warum https bei Google Chrome durchgestrichen dargestellt wird?

Das weiss ich nicht; wenn ich raten müsste, würde ich sagen, dass deine Chrome-Version ein grundsätzliches Problem hat mit dem Zertifikat. Meine Chrome-Version zeigt ein grünes HTTPS:

Oder du hast eine externe Ressource eingebunden (vielleicht ein externes Stylesheet oder ein externes JS?), die via HTTP angefordert werden muss; in dem Fall hättest du ein mixed content ausgelöst.

LG,
CK

[Karl Heinz]

Google Chrome deinstalliert wieder neu installiert und schon wird alles korrekt angezeigt. Problem gelöst!

[dedlfix]

Tach!

Wie du im Screenshot unten erkennen kannst tritt dieses Phänomen nur bei Google Chrome nicht beim Firefox.

Abgesehen davon, dass du das Problem schon gelöst hast, ...

Zunächst dachte ich das durchgestrichene https bedeutet das https nicht unterstützt wird.

Dann gäbe es eine browserinterne Fehlermeldung. Wenn der Browser https nicht kann, kann er auch keine Inhalte darüber holen und darstellen.

Nun weiß ich es besser mich würde aber trotzdem interessieren warum https bei Google Chrome durchgestrichen dargestellt wird?

Diese Information kann man dem Text des Screenshots entnehmen. Zum einen ist das erste Icon gelb und nicht grün. Und zum anderen wird im zweiten Absatz etwas genannt, was nicht ganz ok ist. In der Zertifikatskette steckt eins mit altem und nicht mehr sicheren Signaturalgorithmus. Und da sagt dir dann der Browser mit dem Durchstreichen, dass das nicht wirklich sicher und damit kein gescheites https ist.

Zertifikatskette kann man auch mit Vertrauenskette übersetzen. Die Browser bringen eine Reihe von Zertifikaten mit, die generell als vertrauenswürdig eingestuft sind. Diese kommen von Zertifizierungsunternehmen aus aller Welt. Ob ich denen allen trauen würde, kann ich nicht beantworten, die Browser tun es jedenfalls. Mit diesen Zertifikaten sind weitere Zertifikate signiert/unterschrieben, woraufhin diese Zertifikate ebenfalls als vertrauenswürdig angesehen werden. Das kann man beliebig oft wiederholen und am Ende der Kette steht das Zertifikat für eine Website, das mit einem der Vorgänger signiert wurde. Vorausgesetzt es gibt in dieser Kette keine Lücke, dann denkt sich der Browser, dass das schon alles seine Richtigkeit hat und macht die grüne Lampe an.

Wenn ich nun ein selbst signiertes Zertifikat in meinen Webserver lade, oder eins, das von einer kleinen Organisation signiert wurde, deren Zertifikat es nicht in die Browser geschafft hat, dann geht auch großes Geschrei im Browser los. Ich müsste erst mein Root-Zertifikat oder das des Webservers zum Vertrauenswürdige-Zertifikate-Speicher der Browser hinzufügen, dass das Gejammer aufhört und ich auch ein grünes Licht bekomme.

dedlfix.