HTTPS-WordPress高级管理手册-果果开发

HTTPS 是一种加密通信协议——本质上，它是一种更安全的方式浏览网络，因为您会在浏览器和 Web 服务器之间获得一个专用通道。这就是为什么大多数主要网站都使用它的原因。

如果某个网站使用了 HTTPS，您将在地址栏中看到一个小锁图标，如下面的截图所示：

显示“安全网站”锁图标的截图

以下是您可能希望在自己的网站上使用 HTTPS 的最常见原因：

更快。 人们可能会认为 HTTPS 会使您的网站变慢，因为加密和解密所有数据需要一些时间。但是，许多 HTTP 的效率改进只有在您使用 HTTPS 时才可用。因此，HTTPS 实际上会使您的网站对几乎所有访客都更快。

信任。 用户发现更容易信任安全网站。虽然他们不一定知道他们的流量是加密的，但他们知道小锁图标意味着该网站关心他们的隐私。技术人员会知道，位于您的计算机和 Web 服务器之间的任何服务器都无法查看来回流动的信息，也无法更改这些信息。

支付安全。 如果您在网站上销售任何东西，用户希望知道他们的支付信息是安全的。HTTPS 和小锁确保他们的信息安全地传输到 Web 服务器。

搜索引擎优化。 许多搜索引擎会对不使用 HTTPS 的网站施加惩罚，从而使它们更难在搜索结果中达到最佳位置。

您的好名声。 您是否注意到一些网站在其地址旁边有“不安全”字样？

当您的 Web 浏览器希望您知道某个网站未使用 HTTPS 时会发生这种情况。浏览器希望您（正确地！）认为那些懒得使用 HTTPS（在许多情况下是免费的）的网站所有者不值得您花时间，更不用说花钱了。

反过来，您也不希望浏览器建议您可能是那种不诚实的网站所有者之一。

当安装并可供 Web 服务器使用的 TLS/SSL 证书可用时，WordPress 完全兼容 HTTPS。强烈建议支持 HTTPS，以帮助维护 WordPress 登录和网站访客的安全性。

通过 HTTPS 进行管理

为了轻松启用（并强制）WordPress 通过 SSL 进行管理，您可以在网站的 wp-config.php 文件中定义两个常量。仅在插件文件中定义这些常量是不够的；它们必须在您的 wp-config.php 文件中定义。在将这些常量设置为 true 之前，您还必须已经在服务器上配置了 SSL，并配置了用于安全服务器的（虚拟）主机。

注意： FORCE_SSL_LOGIN 已在版本 4.0 中弃用。请使用 FORCE_SSL_ADMIN。

强制 HTTPS 登录和 HTTPS 管理访问

可以在 wp-config.php 文件中将常量 FORCE_SSL_ADMIN 设置为 true，以强制所有登录和所有管理会话通过 SSL 进行。

示例

define( 'FORCE_SSL_ADMIN', true );

使用反向代理

如果 WordPress 托管在提供 SSL 的反向代理后面，但其本身在没有 SSL 的情况下托管，这些选项最初会将任何请求发送到无限重定向循环中。为避免这种情况，您可以配置 WordPress 以识别 HTTP_X_FORWARDED_PROTO 标头（假设您已正确配置反向代理以设置该标头）。

示例

define( 'FORCE_SSL_ADMIN', true );
// 在某些配置中 HTTP_X_FORWARDED_PROTO 可能包含 
// 逗号分隔的列表，例如 http,https
// 因此检查 https 是否存在
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
    $_SERVER['HTTPS'] = 'on';

注意

当您使用代理传递重定向时，您会将请求传输到网络中的主机，但不传输与其相关的标头。然而，WordPress 需要某些标头才能执行一些重定向。为了传输它们，您需要向您的重定向添加一些行。

例如，对于 Nginx，您需要有以下行：

location / {
    proxy_pass http://your_host_name:your_port;
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_redirect off;
}

像 $variable 这样的变量由反向代理自动管理。

更多信息

本文的其余部分作为信息，以防您使用的是旧版本的 WordPress（理想情况下您不应该使用）或您的 SSL 设置略有不同（即您的 SSL 证书是针对不同的域）。

有时，您希望整个 wp-admin 使用 https 协议在安全连接上运行。从概念上讲，该过程的工作原理如下：

设置两个具有相同 URL（博客 URL）的虚拟主机，一个安全，另一个不安全。
在安全的虚拟主机上，设置一个重写规则，将所有非 wp-admin 流量发送到不安全的网站。
在不安全的虚拟主机上，设置一个重写规则，将所有 wp-admin 流量发送到安全的主机。
通过插件添加一个过滤器，过滤 wp-admin 中的链接，以便一旦激活，管理链接就被重写为使用 https，并且编辑 cookie 仅在加密连接上工作。

以下指南适用于在 httpd.conf 中使用重写规则的 WordPress 1.5 和 Apache（而不是 .htaccess 文件），但可以轻松修改以适应其他托管场景。

虚拟主机

除了不安全的网站外，您还需要为安全服务器配置一个（虚拟）主机。在本示例中，安全虚拟主机使用与不安全主机相同的 DocumentRoot。理论上，您可以使用具有不同名称的主机，例如 wpadmin.mysite.com，并将文档根目录链接到 wpadmin 目录。

请要求您的 ISP 为您设置一个安全的虚拟主机，或者如果您有管理权限，请自行设置。请注意您不能使用基于名称的虚拟主机来识别不同的 SSL 服务器。

不安全主机的重写规则

在不安全主机的 .htaccess 或 httpd.conf 中的虚拟主机部分中，添加此重写规则，以便当您浏览到 https://example.com/wp-admin/ 或 https://example.com/wp-login.php 时自动转到安全主机。

这应该放在主要的 WordPress 重写块之上。

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

如果您使用永久链接重写规则，此行必须位于 RewriteRule ^.*$ - [S=40] 之前。

此块中的一个重要思想是使用 THE_REQUEST，它确保仅重写实际的 HTTP 请求，而不是本地直接文件请求，如 include 或 fopen。

安全主机的重写规则（可选）

这些重写规则是可选的。它们禁用通过安全连接访问公共网站。如果您希望使用下面的插件保持登录到站点的公共部分，您必须不添加这些规则，因为该插件会在未加密的连接上禁用 cookie。

安全虚拟主机应该在 .htaccess 文件或虚拟主机声明中有两个重写规则（有关重写的更多信息，请参阅使用永久链接）：

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

第一条规则将 wp-admin 目录排除在下一条规则之外，后者将流量从安全网站重定向到不安全的网站，以使您的观众保持顺畅。

设置 WordPress URI

为了使某些插件工作以及其他原因，您可能希望将您的 WordPress URI 设置为反映 https 协议，将此设置设置为 https://example.com。您的博客地址不应更改。

示例配置段

注意：下面的配置与 WordPress 2.8+ 不完全兼容，WordPress 2.8 使用 wp-includes 文件夹中的一些文件。第一组 Rewrite 规则引入的重定向可能会为某些用户引发安全警告。有关更多信息，请参阅 #10079。

<VirtualHost nnn.nnn.nnn.nnn:443>
    ServerName www.example.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 ^/(.*) https://www.example.com/$1 [QSA,L]
    </IfModule>

</VirtualHost>

不安全网站

<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.example.com/wp-admin/$1 [C]
            RewriteRule ^.*$ - [S=40]
            RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]

        </IfModule>
    </Directory>

</VirtualHost>

重定向登录和注册

对于用户登录和注册，最好利用 SSL 进行加密。请考虑以下替代的重写规则。

不安全

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

安全

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

为运行在 443 端口或 80 端口的站点进行重定向

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

# 对于运行在 443 端口或其他端口（SSL 上的 HTTP）的站点
RewriteCond %{SERVER_PORT} !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [L]

# 对于运行在 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>

摘要

此方法并未修复 WordPress 中固有的某些安全风险，也无法保护您免受中间人攻击或其他可能破坏安全连接的风险。

然而，这应该使恶意人员窃取您的 Cookie 和/或身份验证标头并冒充您以访问 wp-admin 的难度大大增加。它还会混淆嗅探您内容的能力，这对于可能需要严格保护文档草稿的法律博客来说可能很重要。

验证

在作者的服务器上，日志表明 GET 和 POST 请求均通过 SSL 进行，并且所有对不安全主机上 wp-admin 的流量都被重定向到安全主机。

示例 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?action=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

更多的测试，最好使用数据包嗅探器和一些硬核的网络分析工具，将有助于确认。

局限性

作者假设（但未检查）如果用户存储了 Cookie 或指示浏览器记住密码（不是基于表单字段，而是如果使用某些外部身份验证机制），并且访问 https://www.example.com/wp-admin/，这些数据包将以明文发送，Cookie 和身份验证标头可能会被拦截。因此，为了确保最大安全性，用户应明确使用 HTTPS 主机或在新的会话开始时始终登录。