Administración sobre SSL

Para habilitar fácilmente (y hacer cumplir) la administración de WordPress a través de SSL, hay dos constantes que puede definir en el archivo wp-config.php de tu sitio. No es suficiente definir estas constantes en un archivo de plugin; deben estar definidos en tu archivo wp-config.php. También debes tener SSL configurado en el servidor y un host (virtual) configurado para el servidor seguro antes de que tu sitio funcione correctamente con estas constantes configuradas como verdaderas.

Nota: FORCE_SSL_LOGIN quedó obsoleto en la versión 4.0. Utiliza FORCE_SSL_ADMIN.

Para forzar inicios de sesión SSL y acceso de administrador SSL

La constante FORCE_SSL_ADMIN se puede establecer en true en el archivo wp-config.php para forzar que todos los inicios de sesión y todas las sesiones de administración se realicen a través de SSL.

Ejemplo

define('FORCE_SSL_ADMIN', true);

Usar un proxy inverso

Si WordPress está alojado detrás de un proxy inverso que proporciona SSL, pero está alojado sin SSL, estas opciones enviarán inicialmente cualquier solicitud a un ciclo de redireccionamiento infinito. Para evitar esto, puedes configurar WordPress para que reconozca el encabezado HTTP_X_FORWARDED_PROTO (suponiendo que hayas configurado correctamente el proxy inverso para establecer ese encabezado).

Ejemplo

define('FORCE_SSL_ADMIN', true);
// in some setups HTTP_X_FORWARDED_PROTO might contain 
// a comma-separated list e.g. http,https
// so check for https existence
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';

Más información

El resto de este artículo sirve como información en caso de que estés utilizando una versión anterior de WordPress (¡que, idealmente, no deberías!) O tu configuración de SSL sea algo diferente (es decir, tu certificado SSL es para un dominio diferente).

A veces, deseas que todo tu wp-admin se ejecute a través de una conexión segura utilizando el protocolo https. Conceptualmente, el procedimiento funciona así:

1. Configura dos hosts virtuales con la misma URL (la URL del blog), uno seguro y el otro no.
2. En el host virtual seguro, configura una regla de reescritura que envíe todo el tráfico que no sea de wp-admin al sitio inseguro.
3. En el host virtual inseguro, configura una regla de reescritura que envíe todo el tráfico a wp-admin al host seguro.
4. Coloque un filtro (a través de un plugin) que filtre los enlaces en wp-admin para que una vez activados, los enlaces administrativos se reescriban para usar https y que edite las cookies para que funcionen solo en conexiones cifradas.

La siguiente guía es para WordPress 1.5 y Apache que ejecutan mod_rewrite, utilizando reglas de reescritura en httpd.conf (a diferencia de los archivos .htaccess) pero podría modificarse fácilmente para adaptarse a otros escenarios de hosting.

Hosts virtuales

Necesitas un host (virtual) configurado para el servidor seguro además del sitio no seguro. En este ejemplo, el host virtual seguro usa el mismo DocumentRoot que el host inseguro. Hipotéticamente, podrías usar un host con un nombre diferente, como wpadmin.mysite.com y vincular la raíz del documento al directorio wpadmin.

Pídele a tu ISP que configure un host virtual seguro para ti o, si tienes acceso administrativo, configura el suyo. Ten en cuenta que no puedes utilizar un host virtual basado en nombres para identificar diferentes servidores SSL.

Reescribe las reglas para el anfitrión inseguro

En la sección .htaccess o host virtual en httpd.conf para tu host inseguro, agrega esta regla de reescritura para ir automáticamente al host seguro cuando navegues a http://mysite.com/wp-admin/ o http://mysite.com/wp-login.php

Esto debería ir por encima del bloque principal de reescritura de wordpress.

  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
  RewriteCond %{HTTPS} !=on [NC]
  RewriteRule ^/?(wp-admin/|wp-login\.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

Si estás utilizando reglas de reescritura de enlaces permanentes, esta línea debe ir antes RewriteRule ^.*$ - [S=40].

Una idea importante en este bloque es usar THE_REQUEST, que garantiza que solo se reescriban las solicitudes http reales y no las solicitudes de archivos directos locales, como un include o fopen.

Reescribir reglas para host seguro (opcional)

Estas reglas de reescritura son opcionales. Inhabilitan el acceso al sitio público a través de una conexión segura. Si deseas permanecer conectado a la parte pública de tu sitio usando el plugin a continuación, no debes agregar estas reglas, ya que el plugin deshabilita la cookie en conexiones no cifradas.

El host virtual seguro debe tener dos reglas de reescritura en un archivo .htaccess o en la declaración del host virtual (consulta Uso de enlaces permanentes para obtener más información sobre la reescritura):

   RewriteRule !^/wp-admin/(.*) - [C]
   RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]

La primera regla excluye el directorio wp-admin de la siguiente regla, que desvía el tráfico del sitio seguro al sitio inseguro, para mantener las cosas agradables y fluidas para tu audiencia.

Configuración de URI de WordPress

Para que algunos plugins funcionen, y por otras razones, es posible que desees configurar la URI de WordPress en las opciones para reflejar el protocolo https haciendo esta configuración https://mysite.com. La dirección de tu blog no debería cambiar.

Ejemplo de Stanzas de configuración

NOTA: La siguiente configuración no es 100% compatible con WordPress 2.8+, WordPress 2.8 usa algunos archivos de la carpeta wp-includes. La redirección que introduce el primer conjunto de reglas de reescritura puede generar advertencias de seguridad para algunos usuarios. Consulta https://core.trac.wordpress.org/ticket/10079 para obtener más información.

<VirtualHost nnn.nnn.nnn.nnn:443>
        ServerName www.mysite.com

        SSLEngine On
        SSLCertificateFile    /etc/apache2/ssl/thissite.crt
        SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

        DocumentRoot /var/www/mysite

        <IfModule mod_rewrite.c>
                RewriteEngine On
                RewriteRule !^/wp-(admin|includes)/(.*) - [C]
                RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
        </IfModule>
        ...
</VirtualHost>

# Insecure site
<VirtualHost *>
        ServerName www.mysite.com

        DocumentRoot /var/www/ii/mysite

        <Directory /var/www/ii/mysite >
                <IfModule mod_rewrite.c>
                        RewriteEngine On
                        RewriteBase /
                        RewriteCond %{REQUEST_FILENAME} -f [OR]
                        RewriteCond %{REQUEST_FILENAME} -d
                        RewriteRule ^wp-admin/(.*) https://www.mysite.com/wp-admin/$1 [C]
                        RewriteRule ^.*$ - [S=40]
                        RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
                        ...
                </IfModule>
         </Directory>
         ...
</VirtualHost>

Reescribir para inicio de sesión y registro

Probablemente sea una buena idea utilizar SSL para inicios de sesión y registros de usuarios. Considera el siguiente sustituto RewriteRules.

Inseguro

RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]

Seguro

RewriteRule !^/wp-(admin|login|register)(.*) - [C]

Reescritura para sitios que se ejecutan en el puerto 443 o el puerto 80

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# For a site running on port 443 or else (http over ssl)
RewriteCond %{SERVER_PORT}  !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ http://%{SERVER_NAME}/$1 [L]

# For a site running on port 80 (http)
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]

RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>

Resumen

Este método no corrige algunos riesgos de seguridad inherentes en WordPress, ni lo protege contra ataques de intermediarios u otros riesgos que pueden paralizar las conexiones seguras.

Sin embargo, esto debería hacer que sea mucho más difícil para una persona malintencionada robar tus cookies y/o encabezados de autenticación y usarlos para hacerse pasar por ti y obtener acceso a wp-admin. También oculta la capacidad de rastrear tu contenido, lo que podría ser importante para los blogs legales que pueden tener borradores de documentos que necesitan una protección estricta.

Verificación

En el servidor del autor, los registros indican que tanto las solicitudes GET como las POST son a través de SSL y que todo el tráfico hacia wp-admin en el host inseguro se está transfiriendo al host seguro.

Ejemplo de línea de registro POST:

[Thu Apr 28 09:34:33 2005] 



 Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] "POST /wp-admin/post.php HTTP/1.1" 302 - "https://foo.com/wp-admin/post.php?acti
on=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

Más pruebas, preferiblemente con un rastreador de paquetes y algunas herramientas de análisis de red, ayudarían a confirmar.

Limitaciones

El autor asume (pero no lo ha verificado) que si el usuario ha almacenado cookies/le ha dicho a su navegador que recuerde las contraseñas (no basado en campos de formulario, pero si usa cierto mecanismo de autenticación externo) y visita http://www.mysite.com/wp-admin/, esos paquetes se envían sin cifrar y los encabezados de cookie/auth podrían ser interceptados. Por lo tanto, para garantizar la máxima seguridad, el usuario debe usar explícitamente el host https o iniciar sesión siempre al comienzo de nuevas sesiones.