Leider passt es in keinen anderen Bereich, daher hier her.
Eigentlich ist die Frage recht leicht: Ist es möglich, und wenn ja: Wie?, einen Web-Server so aufzusetzen dass dieser grundsätzlich nur auf TCP/443 für HTTPS läuft ohne dass ich trotzdem HTTP über TCP/80 freihalten muss nur um halt dem Browser zu sagen: Du sollst HTTPS nutzen? Ich frag nur aus dem Grund da es zwar mit DNS hier und da sicher schöne Möglichkeiten gibt Programmen die dies korrekt implementieren schon bei der Adressauflösung dies mitzuteilen, aber bei 0-8-15-Standard wird es eher mager aussehen.
Es geht mir eher weniger um “ich muss alles sicher haben” als mehr um die Frage ob es überhaupt geht.
Einen Großteil der Daten die über meinen Web-Server laufen würden (liegt aktuell breit) braucht auch keine Sicherung. Und dank einer guten JS-Lib mit passendem PHP-Code auf der anderen Seite kann man sogar ohne SSL schon gute Sicherung mit RSA2048 erreichen (das lastet dann aber den Browser schon gut aus und gerade auf langsamen Kisten brauchts gefühlt ewig), aber hier und da möchte man dann doch die eine oder andere Information zumindest halbwegs gesichert übers Netz ziehen.
Zur Software:
OS: openSUSE tumbleweed
Web: Apache 2.4.18
openSSL: 1.0.2e
Immer diese Rewriteanleitungen… ai ai ai. Geht mit RedirectPermanent einfacher ^^ Aber das ist nicht die Antwort auf die Frage, da ja dann Port 80 offen sein muss.
Dass der Browser https und damit standardmäßig Port 443 benutzen soll, dafür braucht man keinen offenen Port 80. In sofern ist die Frage eigentlich mit ja zu beantworten.
Entscheidend ist nämlich, dass die Webadresse mit [noparse]https://[/noparse] beginnt. Wenn der Nutzer eine unvollständige URL eingibt und das [noparse]https://[/noparse] weglässt, dann versuchen die mir bekannten Browser nur über http auf den Webserver zuzugreifen. Wenn man möchte, dass der Dienst auch dann erreichbar ist, kommt man um eine Umleitung nicht herum. Und insofern ist mogels Antwort auch nicht verkehrt, da das genau der Grund dafür ist, dass der Port 80 offen sein muss.
Falls man übrigens eine Umleitung definiert und eine nur über https erreichbare Webseite betreibt, bietet es sich an, auch noch einen HSTS-Header mitzuschicken. Danach verbindet der Browser sich nie wieder per http mit dem Server, selbst wenn man es explizit angibt.
Hmm, ungefähr solche Antworten hatte ich leider erwartet. Naja klar, das WWW baut halt auf HTTP und damit auf TCP/80 auf. Woher soll man sonst die Info “ne du, is nich, nutz HTTPS” bekommen wenn nicht über den nicht gesicherten Anschluss. Bzgl. HSTS: braucht auch wieder eine initiale Verbindung über ungesichertes HTTP, und auch nur dann wenn der Browser das mit macht. Ich hab z.B. meinen IE so eingestellt das er beim beenden des letzten Tabs und damit der oberen Kontroll-Instanz den Verlauf und damit auch z.B. HSTS löscht. So ist jede neue frische Session wie die erste. Greift also nicht. Zwar hat Google mit Chrome zwar HSTS-Listen im Sinne dass der Browser halt schon vorher weis dass er nur über HTTPS anfragen soll, und ich finds auch ne gute Idee, aber man müsste die Grundidee umdrehen: erst auf HTTPS/443 versuchen, und wenn die Verbindung fehlschlägt dann auf HTTP/80 - und erst dann, wenn auch das nicht geht, einen Fehler anzeigen. Komisch dass das noch keiner der Großen umgesetzt hat, wo wir doch mitlerweile Jahr 3 nach Snowden haben und alle nur noch SSL rufen.
Naja, dann wird es wie ursprünglich geplant genutzt: normaler Content ganz simpel über HTTP, und erst das was gesichert werden soll dann über HTTPS.
Dabei mal die Frage: Wie siehts eigentlich mit byte-welt.net aus? Dafür mal HTTPS geplant? Oder sicher das Login-Script mit hash/a-symetrisch ab? Und wie siehts mit dem Reg-Form für neue User aus?
… und dabei die Zugriffsgeschwindigkeit bei einer Vielzahl von Seiten spürbar reduzieren, weil zuerst ein in die Leere laufender Request ausgeführt wird.
Weshalb siehst du das als problematisch an? Für die Privatsphäre ist das Problem doch minimal - denn die IP-Adresse ist auf jeden Fall sichtbar. Egal ob SNI durch den Client verwendet wird oder nicht. Und je nachdem was für ein Server das ist, kann man den Domännennamen auch mittels Reverse-Lookup herausbekommen.
Wenn es für eine IP-Adresse mehrere Namen gibt oder der Reverse-Lookup nur einen nichtssagenden Hostnamen ergibt, bleiben einem immer noch Datenbanken, die zu den IP-Adressen passende Namen auflisten.
Auch wenn es ein wenig schon wieder über das Ziel hinausgeht ist der Einwand bzgl. der vermutlich deutlich spürbar steigenden Zugriffszeiten gerechtfertigt und ich muss zugeben daran bei meiner Aussage gar nicht gedacht zu haben. Natürlich gibts Probleme wenn default versucht wird HTTPS/443 zu laden wenn dort ggf. gar kein offener Port läuft. Und wie setzt man hier ein allgemeingültiges Timeout? 5/10 Sekunden? Und was macht man DDoS-Diensten wie CloudFlare (wobei ich die dort beschriebenen Lösungen für kompletten Müll halte : entweder gar kein SSL, nur zwischen CloudFlare und Server - aber von CloudFlare zu Client nicht mehr, dann als nächstes zwar auch SSL bis Client - aber mit CloudFlare als MITM, aber eine Option bzgl. richtigem end-to-end hab ich nicht gesehen (auch wenn beworben halt nicht garantierbar))?
Nun ja, aber bevor wir damit zu weit vom eigentlichen Topic abdriften (dazu ggf neuer Thread?) trotzdem Danke für den Input.
Da für mich die Frage geklärt ist und ich halt auf die bereits genannte Art und Weise (nur für wirklich nötige Dinge zusätzlich SSL bereitstellen - sonst normal ohne) werde ich hier erstmal SOLVED setzen.
Nah, ich muss, trotz das ich es eigentlich schon auf solved gesetzt hab, doch noch was hinzufügen:
Im Wiki-Artikel ist die von Google initiierte Seite [noparse]https://hstspreload.appspot.com/[/noparse] verlinkt. Diese stellt eine im Rahmen des Chromium-Projektes verfügbare Liste in der man seine Domain registrieren kann durch die dann der Browser schon vor dem initialen Handshake weis dass er die Seite via HTTPS aufzurufen hat.
Voraussetzung hierfür ist dass man ein Zertifikat benötigt welches sowohl für 501 als auch für domain.tld gültig ist, z.B. wie sie von StartSSL und ich vermute auch vom Projekt Let’s Encrypt ausgestellt werden. Auch muss der Server mit einem HTTP/200 antworten, Redirects werden erkannt und ausgefiltert.
Soweit ich es allerdings bisher verstanden habe muss diese Liste regelmäßig vom Browser-Hersteller via Updates nachgepflegt werden. Eigentlich der falsche Weg. Stattdessen sollte man die Implementierung so legen dass beim lookup eine Anfrage an einen zentralen Server gestellt wird um zu prüfen ob die Domain registriert ist. Würde einerseits den load auf den Server ablegen, würde aber auch die ständigen Updates vermeiden die verteilt werden müssen.
Naja, aktuell ist meine Domain, nach dem der erste Versuch auf Grund meines Zertifikates welches auf eine andere Sub-Domain als www ausgestellt war fehlgeschlagen ist, in der erneuten Prüfung. Mal gucken was draus wird.
btw: schön zu sehen dass auch Byte-Welt zumindest für das login nun auch SSL nutzt
Nachtrag:
Mitlerweile ist meine Domain cryptearth.de wohl zumindest bei Chrome im HSTS-preload gelandet. Durch eigentlich ganz andere Umstände bin ich auf die Idee gekommen nach eine cache-clear mal wieder zu testen was passiert, da mein Indianer sowohl ohne als auch mit TLS erreichbar ist. Ergebnis: Chrome baut sofort eine TLS-Verbindung zu TCP/443 auf.
Trotzdem finde ich diese Vorgehensweise immer noch falsch: Wenn man sich schon drauf verständigt eine gemeinsame Liste zu nutzen - warum fragt man diese dann nicht dynamisch ab sondern baut diese umständlich jeweils in die Browser und deren Updates ein? Es ist ja nicht so als dass Google, Mpzilla, M$ und Apple zusammen nicht genug Leistung hätten um solche Anfragen abzudecken.
Tolle Idee - wenn man lange genug wartet kommt man auch mit in die hall-of-lame - aber die Umsetzung ist so aktuell noch kompletter Schrott.
[QUOTE=Sen-Mithrarin]Nachtrag:
warum fragt man diese dann nicht dynamisch ab sondern baut diese umständlich jeweils in die Browser und deren Updates ein? Es ist ja nicht so als dass Google, Mpzilla, M$ und Apple zusammen nicht genug Leistung hätten um solche Anfragen abzudecken.
[/QUOTE]
Weil das halt schon ziemlich viel Traffic wäre. Und auch den first page load schnell mal herauszögert. Und privacy concerns. Du würdest damit dein komplettes Browsingverhalten offenlegen. Die selben Gründe, warum man OCSP Stapling nutzen sollte.
*** Edit ***
Einzig interessanter Zwischenweg wäre, dass sich die HSTS-preload Liste im Browser von selbst updaten kann, unabhängig von Browserupdates. So dass jede Version immer die aktuelle Liste hat.