Drupal Hosting mit ssl
HTTPS ist ein Protokoll, das HTTP verschlüsselt Anfragen und die Antworten. Dies stellt sicher, dass, wenn jemand kann das Netzwerk zwischen Ihrem Computer kompromittieren und dem Server, von dem Sie anfordern, würden sie nicht in der Lage sein, in hören oder mit den Kommunikations zu manipulieren.
Wenn Sie eine Website über HTTPS besuchen, sieht die URL wie folgt aus: https://drupal.org/user/login. Wenn Sie eine Website über Ebene (unverschlüsselt) HTTP besuchen, sieht es wie folgt aus: drupal.org/user/login.
Warum ist es wichtig, dass Sie (und wann)
HTTPS wird typischerweise in Situationen verwendet, in denen ein Benutzer vertrauliche Informationen auf eine Webseite und das Abfangen dieser Informationen wäre ein Problem senden würde. Üblicherweise umfassen diese Informationen:
- Kreditkarten
- Sensitive Cookies wie PHP Session-Cookies
- Passwörter und Benutzernamen
- Identifizierbare Informationen (Sozialversicherungsnummer, Staat-ID-Nummern, etc.)
- vertraulicher Inhalt
Vor allem in Situationen, in denen Sie als Administrator, Ihr Drupal Passwort Senden oder das FTP-Passwort für Ihren Server, sollten Sie HTTPS verwenden, wann immer möglich, das Risiko einer Beeinträchtigung Ihre Website zu reduzieren.
HTTPS kann auch Lauscher von der Beschaffung Ihrer authentifizierten Sitzungsschlüssel, verhindern, die ein Cookie von Ihrem Browser mit jeder Anforderung an die Website gesendet wird, und dessen Verwendung Sie ausgeben. Zum Beispiel kann ein Angreifer den administrativen Zugriff auf die Website gewinnen, wenn Sie ein Site-Administrator Zugriff auf die Website über HTTP statt HTTPS sind. Dies wird als Session-Hijacking bekannt und können mit Tools wie Firesheep erreicht werden.
Sicherheit ist ein Gleichgewicht. Serving HTTPS-Verkehr kostet mehr Ressourcen als HTTP-Anforderungen (sowohl für den Server und Web-Browser) und aus diesem Grund möchten Sie vielleicht gemischt verwenden, HTTP / HTTPS, wo der Eigentümer der Website entscheiden können, welche Seiten oder Benutzer sollten HTTPS verwenden.
Wie HTTPS-Unterstützung in Drupal ermöglichen
- Ein Zertifikat bekommen. Viele Hosting-Anbieter setzen diese sich für Sie - entweder automatisch oder für eine Gebühr. Sie können auch Certificate frei ist, automatisiert und öffnen Authority verwenden Lassen Sie uns verschüsselt. Wenn Sie eine Test-Site sichern möchten, können Sie stattdessen ein selbst signiertes Zertifikat generieren.
- Konfigurieren Sie Ihren Web-Server. Einige nützliche Links:
- Apache Anweisungen.
- nginx Anweisungen
- Ubuntu Anweisung
Die Chancen stehen gut, kann Ihr Webhoster für Sie tun, wenn Sie Shared Hosting oder Managed verwenden.
Hinweis: Clean URLs Wenn Sie mit Apache für HTTP und HTTPS:
Sie werden wahrscheinlich zwei verschiedene Virtual Eimer haben.
- Ein Eimer für den Port 80 http
- Ein Eimer für Port: 443 https
Jede dieser Virtualcontainer oder Eimern erfordern, dass eine bestimmte Apache Direktive in ihnen hinzugefügt werden, wenn Sie mit Hilfe des sauberen URLs. Dies liegt daran, Drupal extensive Nutzung von .htaccess und mod_rewrite machen freundliche URLs zu bieten.
Stellen Sie sicher, dass sie innerhalb der Richtlinie haben, die ein Kind unter dem Virtualhost Container: Siehe Apache Dokumentation für AllowOverride
Dies bedeutet, dass Ihre .htaccess hat Vorrang, und dass die Apache-Konfiguration ermöglicht es zu laufen, wie Sie für Drupal erwarten.
Fehlerbehebung:
Wenn Sie HTTPS aktiviert und es funktioniert nur auf der Homepage und Ihre Sub-Links gebrochen sind, ist es, weil die Virtualhost: 443 Eimer benötigt AllowOverride All aktiviert, so können URLs während in HTTPS-Modus neu geschrieben werden.
Auf Drupal 7, möchten, wenn Sie im gemischten Modus HTTPS und HTTP-Sitzungen unterstützen, eröffnen sites / default / settings.php und $ conf [ 'https'] = true ;. Dadurch können Sie die gleiche Sitzung über beiden HTTP und HTTPS - aber mit zwei Cookies, wo der HTTPS-Cookie wird HTTPS nur geschickt. Sie müssen beigetragen Module verwenden, wie securepages etwas Nützliches mit diesem Modus zu tun, wie Formulare über HTTPS einreichen. Während Ihr HTTP-Cookie für alle üblichen Angriffe immer noch anfällig. Ein entführte unsicheres Session-Cookie kann nur verwendet werden, authentifizierten Zugriff auf die HTTP-Site zu erhalten, und es wird nicht auf der HTTPS-Site gültig sein. Ob dies ein Problem ist oder nicht, hängt von den Anforderungen Ihrer Website und die verschiedenen Modulkonfigurationen. Zum Beispiel werden gesetzt, wenn alle Formulare durch HTTPS und Ihre Besucher gehen können die gleichen Informationen sehen wie eingeloggte Benutzer, ist dies kein Problem.
Beachten Sie, dass in Drupal 8, Mixed-Mode-Unterstützung hat # 2342593 entfernt: Entfernen gemischte SSL-Unterstützung von Kern.
Für eine noch bessere Sicherheit, die alle authentifizierten Datenverkehr über HTTPS senden und HTTP für anonyme Sitzungen verwenden. Auf Drupal 8, Secure Login-Modul installieren, die Warnungen mit gemischten Inhalten löst. Auf Drupal 7, lassen $ conf [ 'https'] auf dem Standardwert (FALSCH) und Secure Login installieren. Drupal 7 und 8 automatisch die session.cookie_secure PHP-Konfiguration auf HTTPS-Sites aktivieren, die bewirkt, dass SSL-nur sichere Session-Cookies an den Browser ausgegeben werden. Auf Drupal 6 finden Sie unter Module 443 Session und Secure Login beigetragen.
Für bestmögliche Sicherheit, richten Sie Ihre Website nur HTTPS zu verwenden und auf alle HTTP-Anfragen mit einer Umleitung auf Ihre HTTPS-Site antworten. Drupal 7 ist $ conf [ 'https'] kann auf den Standardwert (FALSCH) auf pure-HTTPS-Sites gelassen werden. Selbst dann ist HTTPS anfällig für Man-in-the-Middle-Angriffe, wenn die Verbindung als eine HTTP-Verbindung beginnt, bevor zu HTTPS umgeleitet werden. Verwenden Sie das HSTS Modul oder Security Kit-Modul. oder die Strict-Transport-Sicherheits-Header in Ihrem Webserver festgelegt, und fügen Sie Ihre Domäne an den Browser HSTS Preload-Liste. zu verhindern, dass Benutzer zu helfen, die Website ohne HTTPS aus erreichbar.
Sie können den gesamten Verkehr von example.com und www.example.com zu https://example.com umleiten möchten. Sie können dies tun, indem Sie den Code unten auf Ihre Server-Konfigurationsdatei hinzufügen, das heißt die Virtual Definitionen:
Die Verwendung von RewriteRule wäre angebracht, wenn Sie den Zugriff auf die Hauptserver-Konfigurationsdatei nicht haben, und sind verpflichtet, anstatt diese Aufgabe in einer .htaccess-Datei auszuführen:
Es gibt bestehende Kommentare in .htaccess, die erklären, wie example.com zu www.example.com umleiten (und umgekehrt), aber dieser Code hier leitet diese beiden zu https://example.com.
bjdeliduka kommentiert 27. 2015 Februar um 21:25 Uhr
Da das Thema sagt. die Joys.
Ein Kunde von mir hat zahlreiche Kunden mit Drupal 7 Standorten. Wir bewegen uns alle von ihnen hinter CloudFlare (www.cloudflare.com) wir sie frei SSL-Zertifikate, Web-Caching bieten und DDoS-Schutz / Milderung. Wir haben dann die Server-Firewall nur Verbindungen von der CF-Caches zu akzeptieren und stellen Sie sicher, dass die tatsächliche HTTP-Server nicht in DNS aufgeführt ist (Client / Browser sollte auf die CF-Servern verbinden, die dann Seiten von den tatsächlichen Server holen wird). Die Drupal Server (Apache 2.4 auf CentOS) auch SSL verwenden, um die Verbindung zwischen CF und dem Server zu verschlüsseln (könnte auch alles halten aus Klartext)
Während die oben sieht und fühlt sich wie eine große Lösung, die alle Verbindungen zu versichern sind verschlüsselt wir ein Problem mit einigen Seiten gestoßen, die IFRAMES haben, die verschlüsselten Inhalte zu laden. (Web-Browser werfen einen Fehler, wenn dies der Fall ist und oft weigern, den Inhalt ohne Eingreifen des Benutzers zu laden).
Optionen enthielten 1) ein Proxy-Einrichtung und die unsicheren Inhalte zu verschlüsseln. Während technisch möglich, es dem Benutzer den Eindruck gibt, ist die Sitzung zu sichern, während einige der Inhalte im Klartext ist (wenn auch nicht zum / vom Client). 2), um den Inhalt fallen, bis er über eine sichere Verbindung zur Verfügung steht (Client / Kunde hat wie diese Option nicht) 3) Kraft-Seiten, die diese Inhalte enthalten sein, unverschlüsselt (http) Verbindungen, während der Rest der Website verschlüsselt ist.
Wir entschieden uns für die Option 3.
Die Standorte waren zuvor konfigurierten Verbindungen auf https umgeleitet wird unter Verwendung einer Rewrite-Regel in der .htaccess-Datei (wahrscheinlich diese in die vhost Konfigurationsdateien aus Leistungsgründen bewegen, aber nur, wenn wir auf Sperren die .htaccess-Dateien einigen können) als solche jeden http Verbindung wird eine HTTPS-Verbindung.
Normalerweise könnte ein RewriteRule in Form erstellt werden:
Verbindungen zu der Seite mit dem unsicheren iframe zu fangen. (Passend umschreiben HTTP und HTTPS nicht-matching)
versuchen, dies mit dem sauberen URL aktiviert ist und Sie nie die unverschlüsselte Seite bekommen, weil jede Seite Anfrage an Drupal legte einen letzten Durchgang durch den Rewrite-Engine auf /index.php tut.
Ich bin mir nicht sicher über den genauen Grund aber secure_pages wurde keine gangbare Option in Betracht gezogen.
Das Endergebnis ist eine Serie Lösung von 13 RewriteRule / RewriteCond Linien, die effektiv die secure_pages Modul zum Zwingen alle außer einigen wenigen ausgewählten (1 oder mehr), Seiten HTTPS-Verbindungen ersetzen können.
/ Streaming-Seite und die Root-Seite der Website sind HTTP der Rest der Seite ist HTTPS. Zusätzliche Seiten können durch Hinzufügen von zusätzlich Leuten unter der / Streaming-Seite Linie von HTTPS ausgeschlossen werden folgende es ist Format.
Die einzige bekannte Seite dieses Code beeinflusst, ist, dass die Bearbeitung unverschlüsselte Seiten ist komplizierter als der admin_menu auf den unverschlüsselten Seiten fällt. Version 1.1 beinhaltet ein Verfahren zur Deaktivierung der http Seite von einem Kunden-Browser (was in den Browser-Fehler, dass die Entwickler beschäftigen wird je nach Bedarf, während die Seiten bearbeiten) Ich werde auch eine ausführlichere Anweisungen dazu in .htaccess-Dateien setzen und Entfernen unerwünschten / nicht benötigten Code für Dinge wie www. Abstreifen (oder pre-pending) usw.
selinav kommentiert 25. April 2017 um 09:51 Uhr
Bairnsfather kommentiert 26. April 2017 um 17:29 Uhr
Ich bin sehr zufrieden mit https://www.drupal.org/project/securepages für eine lange Zeit. Laden Sie einfach die Konfigurationsseite und setzen einen Stern auf dem Gebiet, für die Seiten, die Sie gesichert wollen, das heißt alle. Ich denke, die Warnung an der Spitze der Projektseite ist abgestanden; Ich habe das Modul ohne Flecken oder zu modifizieren meine .htaccess in den letzten paar 7.x Versionen verwendet. Überprüfen Sie Ihre settings.php und stellen Sie sicher, dass die base_url Variable enthält https, nicht http.
[Bearbeiten] Aber bitte nehmen Sie dies nicht als das letzte Wort über die derzeit beste Methode der gesamten Datenverkehr zu https dieser Tage zu umleiten. Basierend auf den letzten Lesung, so scheint es HSTS ist, wo die Dinge vorangegangen werden.
Bairnsfather kommentiert 9. Mai 2017 um 17:30 Uhr
Hier ist, was ich habe, dass für D7 scheint zu funktionieren D8 (insbesondere ab 7,54 8.3.1 auf Apache 2.4.5 mit PHP 5.6.30) mit dem Lager .htaccess-Datei nur mit den Änderungen, die nachstehend erwähnt. Vereinfacht ausgedrückt, wird die Strenge-Transport-Sicherheitskontrolle nicht von Anfang an Datenverkehr von http auf https umgeleitet werden. (Diese Linie ist nicht auf HTTP-Anfragen gesehen und älterer Browser versteht es nicht.) So das Interesse an der Umleitung mit einer RewriteRule; lässt jedoch, dass die Möglichkeit eines MITM Angriff öffnen. Aber die Hoffnung ist, mit DNSSEC und einem modernen Browser, den HSTS versteht, in weniger als eine Sekunde Ihr Browser (für max-age Sekunden) auf nur Anfrage https Ressourcen erinnern, auch wenn Ihre Website oder eine andere Website hat ein HTTP-Link / Mittel auf es. Mit anderen Worten, sobald Ihre modernen Web-Browser lädt eine Seite über https von Ihrer Website erfährt der Browser sollte es streng sein und nur https-Anfragen machen, auch wenn es eine Ressource oder einen Link Angabe http trifft.
Erstens, stellen Sie sicher, dass Sie Ihren Server über https zur Verfügung haben und Ihr Zertifikat enthält alle Subdomains Sie verwenden. Max-Alter ist in Sekunden, passen Sie es für Ihre Bedürfnisse, und sicher sein, lesen (mindestens) https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security (RFC Link weiter unten.)
Unterhalb der Linien:
Dann legen Sie ein # vor den drei Linien unter ihnen auszukommen; es gilt nicht mehr, da wir nur den gesamten Verkehr auf https gezwungen. Die folgenden Zeilen sind bereits in der .htaccess-Datei und nur unter dem, was Sie klebte in.
Beachten Sie auch die HSTS Modul https://www.drupal.org/project/hsts hat Versionen für D7 D8. Das ist gut, wenn man auf mehreren Systemen laufen und nicht alle Domains ein Zertifikat.
Sie können Dinge testen, indem Sie Ihre Terminal-Anwendung öffnen und -I Ihre Domäne auf verschiedene Weise kräuseln den Header zu inspizieren.
In Verbindung stehende Artikel
2013.07.23 01.22 EST Danke für die Frage! Ja, können Sie ein Shared SSL-Zertifikat verwenden. Das Shared SSL-Zertifikat ist voreingestellt, so dass es keine Konfiguration auf der Serverseite durchgeführt. Bitte...
In Wordpress, können Sie Inhalte auf Ihrer Website entweder als ein „post“ oder eine „Seite“ setzen. Wenn Sie einen regelmäßigen Blog-Eintrag zu schreiben, schreiben Sie einen Beitrag. Beiträge, in einem Standard-Setup, erscheinen in umgekehrter ...
Hinweis: Extra besonderen Dank geht an Doug Vann für Motivation bietet schließlich diese Blog-Post zu schreiben! Früh im Jahr 2016, wenn der Such-API und Solr bezogene Module für Drupal 8 in frühen Alpha waren ...
Einführung Einer Implementierung einer effektiven Suche ist eine der schwierigsten Aufgaben in der Entwicklung, aber es ist auch ein Schlüssel zum Erfolg von vielen Websites und Anwendungen. Eine schnelle Suche und ...
Ich erstelle eine Website-Archiv, das Benutzern erlaubt, auf verschiedene Arten von Medieninhalten wie Video, Audio, Bilder, Dokumente und Texte hochladen. Ich mag es für die Benutzer einfach machen ...