Drupal hosting con SSL

HTTPS es un protocolo que cifra las peticiones HTTP y sus respuestas. Esto asegura que si alguien fuera capaz de poner en peligro la red entre el ordenador y el servidor al que está solicitando a, no serían capaces de escuchar o manipular las comunicaciones.

Cuando se visita un sitio web a través de HTTPS, la URL tiene el siguiente aspecto: https://drupal.org/user/login. Cuando se visita un sitio a través de HTTP plano (sin cifrar), que se ve así: drupal.org/user/login.

¿Por qué es importante para usted (y cuándo)

HTTPS se utiliza normalmente en situaciones en las que un usuario podría enviar información confidencial a un sitio web y la intercepción de esa información sería un problema. Comúnmente, esta información incluye:

Tarjetas de crédito
Galletas sensibles, como las cookies de sesión de PHP
Los nombres de usuario y contraseñas
información de identificación (número de seguro social, números de identificación del estado, etc.)
contenido confidencial

Especialmente en situaciones en las que, como administrador, está enviando su contraseña Drupal o la contraseña FTP de su servidor, debe utilizar HTTPS siempre que sea posible para reducir el riesgo de comprometer su sitio web.

HTTPS también pueden prevenir los fisgones de la obtención de la clave de sesión autenticada, que es una cookie enviada desde su navegador con cada solicitud al sitio, y usarlo para hacerse pasar por ti. Por ejemplo, un atacante puede obtener acceso administrativo al sitio si usted es un administrador del sitio acceder al sitio a través de HTTP en lugar de HTTPS. Esto se conoce como secuestro de sesión y se puede lograr con herramientas como Firesheep.

La seguridad es un equilibrio. Sirviendo HTTPS costes de tráfico más recursos que las peticiones HTTP (tanto para el buscador de servidores y web) y debido a esto es posible que desee utilizar mixta HTTP / HTTPS en el que el propietario del sitio puede decidir qué páginas o los usuarios deben utilizar HTTPS.

Cómo habilitar la compatibilidad con HTTPS en Drupal

Obtener un certificado. Muchos proveedores de alojamiento establecen estas arriba para usted - ya sea de forma automática o por una tarifa. También puede utilizar Cifrar Vamos que es gratuito, automatizado, y abrir la autoridad de certificación. Si desea proteger un sitio de prueba, en su lugar podría generar un certificado autofirmado.
Configure su servidor web. Algunos enlaces útiles:
instrucciones de Apache.
instrucciones Nginx
de instrucciones Ubuntu

Es probable que su proveedor de alojamiento puede hacer esto por usted si está utilizando o la gestión de alojamiento compartido.

Nota: las URL limpias Si está utilizando Apache HTTP y HTTPS:

Es probable que tenga dos cubos VirtualHost diferentes.

Un cubo para el puerto: 80 http
Un cubo para el puerto: 443 https

Cada uno de estos contenedores VirtualHost o cubos requieren que una directiva específica de Apache que añadir dentro de ellos si usted está utilizando URLs limpias. Esto se debe a Drupal hace un amplio uso de .htaccess y mod_rewrite para proporcionar URLs amigables.

Drupal hosting con sitio SSL a través de HTTP en vez

Asegúrese de que tiene lo siguiente dentro de la Directiva, que es un niño bajo el contenedor VirtualHost: Véase la documentación de Apache para AllowOverride

Esto significa que su .htaccess tiene prioridad y que la configuración de Apache permitirá que se ejecute como se puede esperar para Drupal.

Solución de problemas:
Si habilitó HTTPS y que sólo funciona en la página y sus enlaces sub está roto, es porque el VirtualHost: 443 balde necesita AllowOverride All habilitado para direcciones URL se pueden reescribir en el modo HTTPS.

En Drupal 7, si quieres apoyar de modo mixto HTTPS y las sesiones HTTP, abre sites / default / settings.php y añadir $ conf [ 'https'] = true ;. Esto le permite utilizar la misma sesión sobre HTTP y HTTPS - pero con dos galletas en la cookie HTTPS se envía a través de HTTPS. Usted tendrá que utilizar módulos de terceros como securepages hacer algo útil con este modo, al igual que la presentación de formularios a través de HTTPS. Mientras que su cookie de HTTP sigue siendo vulnerable a los ataques de los habituales. Una cookie de sesión insegura secuestrado sólo se puede utilizar para obtener acceso autenticado al sitio HTTP, y no será válida en el sitio HTTPS. Si esto es un problema o no depende de las necesidades de su sitio y las diversas configuraciones de módulos. Por ejemplo, si todas formas se fijan para ir a través de HTTPS y sus visitantes pueden ver la misma información que los usuarios registrados, esto no es un problema.

Tenga en cuenta que en Drupal 8, el soporte de modo mixto se ha eliminado # 2342593: Retire el soporte SSL mixta del núcleo.

Para una mejor seguridad, enviar todo el tráfico autenticado a través de HTTPS y HTTP para utilizar sesiones anónimas. En Drupal 8, instalar el módulo de Conexión Segura que resuelve las advertencias de contenido mixto. En Drupal 7, deje $ conf [ 'https'] con el valor predeterminado (FALSO) e instalar Secure Login. Drupal 7 y 8 permiten automáticamente la configuración session.cookie_secure PHP en sitios HTTPS, lo que hace SSL sólo las cookies de sesión segura que se emitirán en el navegador. En Drupal 6, véanse los módulos 443 de sesión y Secure Login contribuido.

Para mayor seguridad posible, configurar su sitio para utilizar solamente HTTPS y responder a todas las peticiones HTTP con una redirección a su sitio HTTPS. de Drupal 7 $ conf [ 'https'] puede dejarse en su valor predeterminado (FALSO) en los sitios puros-HTTPS. Incluso entonces, HTTPS es vulnerable a ataques man-in-the-middle si la conexión se inicia como una conexión HTTP antes de ser redirigido a HTTPS. Utilice el módulo o módulo HSTS kit de seguridad. o establecer la cabecera-Transporte-estrictos de seguridad en su servidor web, y añadir su dominio a la lista de precarga HSTS navegador. para ayudar a evitar que los usuarios accedan al sitio sin HTTPS.

Es posible que desee volver a dirigir todo el tráfico de example.com y www.example.com a https://example.com. Esto se puede hacer añadiendo el siguiente código a su archivo de configuración del servidor, es decir, las definiciones VirtualHost:

El uso de RewriteRule sería apropiado si usted no tiene acceso al archivo de configuración del servidor principal, y está obligado a realizar esta tarea en un archivo .htaccess en su lugar:

Hay comentarios existentes en .htaccess que explican cómo redirigir example.com a www.example.com (y viceversa), pero este código aquí redirige tanto de aquellos a https://example.com.

bjdeliduka comentó 27 de de febrero de 2015 a las 21:25

Como dice el tema. Las alegrías.

Un cliente mío tiene numerosos clientes con Drupal 7 sitios. Nos estamos moviendo todos ellos detrás de CloudFlare (www.cloudflare.com) que ofrecen Certificados SSL Gratuitos, almacenamiento en caché web, y DDoS protección / mitigación. A continuación, los servidores Firewall para aceptar solamente conexiones desde el CF cachés y asegurarse de que el servidor HTTP real no aparece en DNS (cliente / navegadores deben conectarse a los servidores de CF que a su vez a buscar páginas en el servidor real). El Drupal servidor (Apache 2.4 en CentOS) también utilizan SSL para cifrar la conexión entre CF y el servidor (como bien podría mantener todo fuera de texto plano)

Mientras que las miradas anteriores y se siente como una gran solución para asegurar que todas las conexiones están cifrados nos encontramos con un problema con algunas páginas que tienen Representado que cargan contenido cifrado. (Navegadores web emiten un error cuando esto ocurre y con frecuencia se niegan a cargar el contenido sin intervención del usuario).

Las opciones incluían 1) la creación de un proxy y cifrar el contenido no seguro. Aunque técnicamente es posible que le da al usuario la impresión de la sesión es segura, mientras que algunos de los contenidos es en texto plano (aunque no a / desde el cliente). 2) dejar caer el contenido hasta que esté disponible a través de una conexión segura (cliente / cliente no le gustaba esta opción) 3) páginas de fuerza que contienen estos contenidos sean conexiones sin cifrar (http), mientras que el resto del sitio está encriptada.

Elegimos la opción 3.

Los sitios habían sido previamente configurados para redirigir las conexiones a https utilizando una regla de reescritura en el archivo .htaccess (probablemente mover éstos en los archivos de configuración de host virtual por razones de rendimiento, pero sólo si nos ponemos de acuerdo sobre cómo desactivar los archivos .htaccess) Por lo tanto cada http la conexión se convierte en una conexión HTTPS.

Normalmente, un RewriteRule se podría crear en la forma:

para coger las conexiones a la página con el iframe inseguro. (Reescribir a juego para HTTP y no coincidente a https)

probar esto con URL limpia habilitado y nunca se tiene la página sin cifrar porque cada petición presentada a Drupal hace una pasada final a través del motor de reescritura de /index.php.

Estoy seguro de la razón exacta, pero secure_pages no se consideraron una opción viable.

La solución resultado final es una serie de líneas / RewriteCond 13 RewriteRule que pueden reemplazar efectivamente el módulo secure_pages por obligar a todos menos un (1 o más) páginas a conexiones https pocos elegidos.

/ Transmisión de la página y la página raíz del sitio HTTP son el resto del sitio es HTTPS. Páginas adicionales pueden ser excluidos de HTTPS mediante la adición de gustos adicionales bajo la línea / Online-Página siguiente su formato.

El único aspecto conocida afectar de este código es que la edición de páginas sin cifrar es más complicado que el admin_menu cae en las páginas sin encriptar. La versión 1.1 incluirá un método para deshabilitar el lado http clientes desde un navegador (que resulta en los errores de navegación que los desarrolladores podrán tratar como sea necesario durante la edición de las páginas) También a mirar un instrucciones más detalladas en poner esto en archivos .htaccess y la eliminación de código no deseado / no sean necesarios para las cosas como www. reextracción (o pre-pendiente) etc

selinav comentó 25 de de abril de 2017 a 09:51

Bairnsfather comentó 26 de de abril de 2017 a 17:29

He sido muy feliz con https://www.drupal.org/project/securepages durante mucho tiempo. Sólo tiene que cargar la página de configuración y poner un asterisco en el campo de las páginas que desea garantizado, es decir, todo. Creo que la advertencia en la parte superior de la página del proyecto es rancio; He utilizado el módulo sin parches o modificar mi .htaccess en los últimos comunicados de 7.x. Compruebe su settings.php y asegúrese de que la variable base_url contiene https y no http.

[Editar] Pero por favor no tome esto como la última palabra en la actualidad mejor método para redirigir todo el tráfico a https en estos días. En base a la lectura reciente, parece HSTS es dónde se dirigen las cosas.

Bairnsfather comentó 9 de mayo de 2017 a 17:30

Esto es lo que tenía que parece funcionar para D7 D8 (específicamente como de 7,54 8.3.1 en Apache con PHP 2.4.5 6.5.30) utilizando el archivo de .htaccess sólo con las modificaciones mencionadas a continuación. En términos simples, la línea de transporte y de seguridad estrictas, no volverá a dirigir inicialmente el tráfico de http a https. (Esa línea no se ve en las peticiones HTTP y navegadores antiguos no lo entienden.) Así, el interés por la redirección con un RewriteRule; Sin embargo, esto deja abierta la posibilidad de un ataque MITM. Pero la esperanza está con DNSSEC y un navegador moderno que entiende HSTS, en menos de un segundo su navegador recordará (por segundo max-age) a sólo recursos solicitud HTTPS, incluso si su sitio o en otro sitio tiene un enlace http / recurso de eso. En otras palabras, una vez que su navegador web moderno carga una página a través de https de su sitio, el navegador se entera de que debe ser estricta y sólo hacer peticiones HTTPS, incluso si se encuentra con un enlace http recurso o especifica.

En primer lugar, asegúrese de que tiene su servidor disponible a través de HTTPS y su certificado incluye todos los subdominios que utiliza. Max-age es en cuestión de segundos, personalizar según sus necesidades, y asegúrese de leer (al menos) https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security (enlace RFC abajo).

Por debajo de las líneas:

A continuación, poner una # delante de las tres líneas siguientes para comentar a cabo; que ya no se aplica ya que sólo forzados a todo el tráfico HTTPS. Las siguientes líneas ya están en el archivo .htaccess y justo por debajo de lo que ha pegado en.

También tenga en cuenta las https://www.drupal.org/project/hsts módulo HSTS tiene versiones para D7 D8. Lo cual es bueno si ejecuta varios sitios y no todos los dominios tienen un certificado.

Puede probar cosas mediante la apertura de la aplicación de terminal y el rizo -I su dominio de varias maneras para inspeccionar la cabecera.

¡Mira este video!

Choose Hosting

Top 3

Drupal hosting con SSL

¿Por qué es importante para usted (y cuándo)

Cómo habilitar la compatibilidad con HTTPS en Drupal

Nota: las URL limpias Si está utilizando Apache HTTP y HTTPS:

Artículos relacionados