然后为端口80上我域中的所有流量设置重定向，以将其重定向到端口443。
话说来，我所有的
http://example.com流量现在都已重定向到页面的相应https://example.com版本。重定向是在Apache Virtual Hosts文件中完成的，类似于以下内容...
RewriteEngine on
ReWriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/ [NC,R,L]
我的问题是，使用SSL是否有任何弊端？
由于这不是301重定向，我会因切换而失去搜索引擎中的链接汁/排名到
https吗？感谢您的帮助。我一直想在服务器上设置SSL，只是为了进行此操作，我最终决定今晚进行操作。到目前为止，它似乎运行良好，但是我不确定在每个页面上使用它是否是一个好主意。我的网站不是电子商务网站，并且不处理敏感数据；它主要是为了外观和安装它的学习乐趣。 ...
#1 楼
[R]标志本身就是302重定向（Moved Temporarily）。如果您确实希望有人使用您网站的HTTPS版本（提示：您这样做），那么您应该使用[R=301]进行永久重定向：RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/ [NC,R=301,L]
301可以保留您所有的google-fu和来之不易的网页排名都保持不变。确保启用了mod_rewrite：a2enmod rewrite
要回答您的确切问题：
将http重定向到https是否不好？
没有很好。
评论
感谢您提供的信息，我的老板告诉我他仅在网站的某些页面上运行https的原因是，它使用大量的服务器资源来在每个页面上运行它。您是否对此有所了解，或者这是真的吗？
–JasonDavis
2014年1月28日下午2:00
@jasondavis仅当您不花几分钟来对其进行优化时。
–迈克尔·汉普顿
2014年1月28日在2:03
“它使用大量服务器资源来在每个页面上运行它。”现代CPU具有加密加速功能，使SSL几乎免费。不用担心开销。
–亚当·戴维斯（Adam Davis）
2014年1月28日下午4:24
@AdamDavis加密算法可能很轻巧，但握手开销仍然存在。同样，HTTPS可以防止HTTP代理缓存您的内容。在大多数情况下，HTTPS的开销很小且值得，但请过分泛化。
– 200_success
2014年1月28日在7:22
它会杀死共享缓存，这对于某些站点的使用模式很有用，并且通常保护不大（人们可以知道您访问了站点，但没有了解所做的工作是否重要？这是唯一有用的SSL情况）。 SSL在每种资源上的主要优势不是您需要“保护”例如人们看着“关于我们”，但是在必要的情况下您不能滑倒并不能使用它。
–琼·汉娜（Jon Hanna）
2014年1月28日在11:02
#2 楼
尽管我支持仅SSL站点的想法，但我要说的一个缺点是开销取决于站点设计。我的意思是，例如，如果您要在img标签中投放大量单独的图片，则可能会导致您的网站运行缓慢。我建议任何使用仅SSL服务器的人以确保它们可以在以下服务器上正常工作。如果您自己指定域名，请检查整个网站的内部链接，并确保它们都使用HTTPS。在链接中，这样就不会引起自己的重定向。
将
<meta property="og:url"更新为使用域的https版本。如果再次使用
<base href=，则更新为使用HTTPS。如果安装SPDY协议，
请确保在可能的情况下使用CSS Image Sprites，以减少请求数量。
更新站点地图以指示https状态，以便蜘蛛逐渐了解此更改。
更改搜索引擎偏好设置，例如Google网站管理员工具更喜欢HTTPS
，如果可能的话，可以将任何静态媒体卸载到HTTPS CDN服务器上。
如果解决了以上问题，那么我怀疑您会遇到很多问题。
评论
SPDY是一个很好的建议；甚至还有一个模块向Apache 2.x添加了SPDY支持。
–花al
2014年1月28日，下午2:25
使用“ //yourserver.com/some-uri”而不是“ yourserver.com/some-uri”解决了问题（1），因为浏览器将根据加载页面的模式来选择适当的模式（http或https） 。
– MauganRa
2014年1月28日上午8:21
@MauganRa当然，除非，例如，它是从http文章页面到https登录页面的链接。
–Mołot
2014年1月28日上午11:01
Google会通过Referer标头查看某人正在访问的URL。例如，此网站使用Google CDN中的jQuery，并且每次我重新加载该网站时，我的浏览器都会向Google发送请求。因此，Referer标头也发送到Google，该标头设置为该站点的URL。因此，Google可以跟踪我在IP地址不变的情况下访问的网站（如果在这段时间内使用Google服务，Google也可以将此信息与我的Google帐户关联）。
–斯蒂芬·库拉（Stephan Kulla）
2014年1月28日下午16:31
对于1）我只是搜索并在MySQL数据库中将http替换为https ...我正在使用WordPress，因此它非常容易更新数百个链接
–JasonDavis
2014年1月29日在18:13
#3 楼
我已经设置了https，那么您应该在网站的任何地方使用它。您将避免出现混合内容问题的风险，如果您拥有所需的工具，为什么不确保整个站点的安全呢？关于从http重定向到https的答案并不那么简单。
重定向将使您的用户更加轻松，他们只需输入whatsite.com并重定向到https。
但是。如果用户有时处于不安全的网络上（或与Troy Hunt及其菠萝接近）怎么办？然后，用户将出于旧习惯而请求http://whateversite.com。那是http。这可以妥协。重定向可能指向https://whateversite.com.some.infrastructure.long.strange.url.hacker.org。对于普通用户来说，它看起来很合法。但是流量可以被拦截。
所以我们在这里有两个相互竞争的要求：人性化和安全。幸运的是，有一种称为HSTS标头的补救措施。使用它可以启用重定向。浏览器将移至安全站点，但是由于HSTS标头也使它记住了。当用户键入位于该不安全网络上的whatsite.com时，浏览器将立即转到https，而不会跳过通过HTTP进行的重定向。除非您处理非常敏感的数据，否则我认为对于大多数站点而言，这是安全性和可用性之间的合理平衡。 （当我最近设置一个处理病历的应用程序时，我使用了所有https，而没有重定向）。不幸的是，Internet Explorer不支持HSTS（源），因此，如果您的目标受众主要是使用IE，并且数据敏感，则可能要禁用重定向。
因此，如果您不以IE用户为目标，继续并使用重定向，但还要启用HSTS标头。
评论
更多的人也需要注意这一点。另一件事是，人们认为它们是安全的，因为端点是HTTPS，而忽略了GET或POST中发送到页面的所有信息都是纯文本的事实。
–Velox
2014年1月28日在12:07
@Velox-我认为“人们认为它们是安全的，因为端点是HTTPS，而忽略了GETs或POSTs中发送到页面的所有信息都是纯文本的事实”的含义是非常准确的。尽管存在一些陷阱，但在通过HTTPS进行传输期间，GET查询参数不会明显传播。例如，请参阅：stackoverflow.com/questions/323200/…POST负载也受到保护，同时也不容易受到日志记录和引用标头的影响。
–louboutin编码
2014年1月28日在19:53
@codingoutloud这就是我的观点。通过HTTPS对它们进行加密，但是在对HTTP页面的初始请求中未对它们进行加密。
–Velox
2014年1月28日在20:24
@Velox-如果整个站点都重定向到HTTPS，则不太可能在启动HTTPS之前发送任何GET参数（此后所有内容都将保留在HTTPS中）。仍然有一个初始请求将发送cookie，可以通过HSTS对其进行补救...以及一个很小的SSLStrip攻击窗口，它可能会被JavaScript击败，但这本身就是一场军备竞赛。
– Briilliand
2014年1月29日，下午2:21
@Brilliand公平点，但是安全性方面的弱点会使整个事情变得脆弱。永远值得考虑。
–Velox
2014年1月29日在8:32
#4 楼
这样做没有任何问题，实际上，这是最佳做法（适用于应通过安全连接提供服务的网站）。实际上，您正在执行的操作与我正在使用的配置非常相似：<VirtualHost 10.2.3.40:80>
ServerAdmin me@example.com
ServerName secure.example.com
RedirectMatch 301 (.*) https://secure.example.com
</VirtualHost>
# Insert 10.2.3.40:443 virtual host here :)
301状态代码表示永久重定向，指示有能力的客户端使用用于将来连接的安全URL（例如，更新书签）。如果您仅通过TLS / SSL提供网站服务，则建议您再启用一条指令，以启用HTTP严格传输安全性）在您的安全虚拟主机中：
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=1234; includeSubdomains"
</IfModule>
此标头指示有能力的客户端（我相信这些天大多数都是这样），它们只能将HTTPS与提供的域（
secure.example.com，在此情况下）持续下一个1234秒。 ; includeSubdomains部分是可选的，它指示该指令不仅适用于当前域，还适用于其下的任何域（例如alpha.secure.example.com）。请注意，只有通过SSL / TLS连接提供服务时，浏览器才会接受HSTS标头！我的目标是至少获得A-评分（由于缺乏对椭圆曲线密码的支持，Apache 2.2无法获得更高的评分）。评论
我应该添加，发送标头Strict-Transport-Security：max-age = 0将否定所有先前的指令；像往常一样，必须通过HTTPS发送才能被接受，但是如果您决定还需要在域上使用HTTP，则这是取消事务的便捷方法。
–花al
2014年1月28日在6:20
#5 楼
哇 ！将HTTP重定向到HTTPS是一件非常好的事情，我看不到有任何缺点。请确保您的客户端具有正确的CA，以避免有关浏览器中证书的非用户友好警告。
此外，您已经设置了Apache重定向到HTTPS的方式。
#6 楼
将http重定向到https是否不好？
不，一点也不。实际上，这是一件好事！
关于重定向：
通过完全消除重写，可以提高效率。这是我在类似情况下的配置...
<VirtualHost *:80>
ServerName domainname.com
<IfModule mod_alias.c>
Redirect permanent / https://domainname.com/
</IfModule>
</VirtualHost>
#7 楼
HTTPS并非万无一失。当然，通常强制使用HTTPS是一件好事。
它可以防止普通罪犯对您的用户造成不良影响。
但是请记住要检查一下SSL设置（例如SSLCiphers设置）。
请禁用RC4加密，SSLv2和SSLv3协议。
此外，您还应该确定系统的密码系统库是否支持TLS1.2（这是您想要的东西；））
打开SSL，它是好东西。
评论
熵不会耗尽（至少在您防御地球攻击者而不是伏都教的时候）。要么从不足的熵开始，要么无法做任何需要随机性的工作，要么从足够的熵开始，并且无论生成多少随机性，都保持足够的熵。
–吉尔斯'所以-不再是邪恶的'
2014年1月28日在11:23
不好意思Linux上有很多操作都坚持硬件派生的强熵，而不是基于PRNG的可能足够好的熵，并且如果池深度很低，这些操作确实会阻塞。在Linux系统上，最有可能从足够的熵开始，但是过度使用会耗尽池，从而导致某些操作阻塞。
– MadHatter
2014年4月19日在10:48
#8 楼
就我个人而言，我全都希望使用SSL来保护Web上的连接安全，但是我觉得这里遗漏了所有其他答案，这是因为并非所有支持HTTP连接的设备和软件都可以使用SSL，因此，如果他们不支持，我会考虑为用户提供某种避免它的方法。在某些国家/地区，加密技术是非法的，也有可能不允许人们访问您的网站。我会考虑添加一个带有链接的未加密登录页面，以强制使用该网站的不安全版本，但是除非用户明确选择按照您所说的那样做，然后将其转发到HTTPS版本。评论
解决方案的问题是，即使将HTTP登陆页面正确分隔，也要使其具有一个纯净的HTTP登录页面，否则该页面将无法操作。即，没有任何实际保证可以将网站的HTTPS版本的链接完整地传递给访问者。
–Håkan Lindqvist
16年2月24日在7:27
#9 楼
以下是一些常见的笔触问题：MITM / SSLSTRIP：这是一个很大的警告。如果要通过HTTPS服务站点，请在该站点上禁用HTTP。否则，您将使用户容易受到包括SSLSTRIP在内的各种中间人攻击，该攻击将拦截请求并通过HTTP悄悄地为他们提供服务，从而将自己的恶意软件脚本插入流中。如果用户没有注意到，那么他们会认为自己的会话在实际上不是安全的时候是安全的。公共站点，您只是毫不客气地禁用了HTTP，您可能会失去很多访问者。如果站点无法使用HTTP加载，他们甚至不会尝试使用HTTPS。
如果站点需要安全登录，则整个用户会话均应受到保护。不要通过HTTPS进行身份验证，然后将用户重定向回HTTP。如果再次这样做，您将使用户容易受到MITM攻击。目前，身份验证的标准方法是进行一次身份验证，然后来回传递身份验证令牌（在cookie中）。但是，如果您通过HTTPS进行身份验证，然后重定向到HTTP，则中间人可以拦截该cookie并使用该站点，就好像它们是您的身份验证用户一样，绕过您的安全性。
实际上，HTTPS的“性能”问题仅限于创建新连接所涉及的握手。尽您所能，以最大程度地减少来自URL的多个HTTPS连接的需求，那么您将遥遥领先。坦率地说，即使您通过HTTP提供内容，也是如此。如果您读过SPDY，您将意识到它所做的一切都旨在尝试通过单个连接从单个URL提供所有内容。是的，使用HTTPS会影响缓存。但是，无论如何，如今有多少网站只是静态的可缓存内容？使用Web服务器上的缓存来最大限度地减少冗余数据库查询，一次又一次地检索未更改的数据，并防止不必要的频繁执行昂贵的代码路径，您可能会付出更多的努力。
评论
您可以实际解决sslstrip的问题是使用HSTS（最好是预先加载HSTS设置）。在这方面，无论您是否接受通过纯HTTP发出的请求实际上都无关紧要，即使您仅接受HTTPS请求，MITM仍可以通过纯HTTP应答（可能代理到您的HTTPS站点）。
–Håkan Lindqvist
16年2月24日在7:10
@HåkanLindqvist我真的赢得了你的反对票？在不通过HTTPS进行身份验证然后在会话的其余部分切换到HTTP方面，我是否给出了不好的建议或好的建议？我是否就HTTPS性能神话提供了不好的建议？另外，如果客户端最初尝试使用HTTPS连接，则MITM无法在不触发浏览器警报的情况下进行拦截和响应，因为除非证书被盗或伪造成功，否则证书将不匹配。另一方面，如果站点接受HTTP连接，则侦听会更容易。无论哪种方式，HTTPS都会提高标准。
– Craig
16-2-25的1:40
..当然，我完全同意使用HSTS。
– Craig
16-2-25的1:40
我的答案问题是列表中的第一项声称解决sslstrip，而实际上却没有解决（说神话）。在我的初始评论中，我试图得出的结论是，如果您拥有活动的MITM（首先是sslstrip所需要的），从客户端的角度来看，攻击者实质上可以是“站点”。是由攻击者决定他们是否要接受来自客户端的纯HTTP连接，在这方面您的实际Web服务器的行为不会影响攻击者可以或将做的事情。
–Håkan Lindqvist
16-2-25在7:44
@HåkanLindqvist除了访问者有意尝试连接HTTPS之外，除非攻击者设法窃取了服务器证书或以某种方式成功伪造了证书，否则攻击者无法在浏览器中不抛出标志就无法满足该请求。以便将连接切换到HTTP。 HTTPS仍然提高了标准。当然，如果访问者通过HTTP进行初始连接尝试，则所有选择都将完全无效。
– Craig
16-2-25在15:41
#10 楼
重定向到HTTPS很好，但是我读过它还取决于您如何组织重定向。按照安全性此答案中的建议，制作专用的虚拟主机将传入的HTTP请求重定向到HTTPS连接。 .com-听起来很聪明，将关闭一些其他安全威胁。 Apache中的配置如下所示：
# Virtual host for rerouting
<VirtualHost *:80>
ServerName www.example.com
Redirect permanent / https://www.example.com/
</VirtualHost>
# Virtual host for secure hosting on https
<VirtualHost *:443>
ServerName www.example.com
SSLEngine on
Header set Strict-Transport-Security "max-age=8640000;includeSubdomains"
...site settings...
</VirtualHost>
#11 楼
从技术上讲，这不是您的原始问题的答案，但是，如果您在所有位置使用Google Chrome扩展程序HTTPSEverywhere（我确定其他浏览器上也有类似的扩展程序），则该扩展程序会自动将HTTP站点重定向到HTTPS站点。我已经使用了一段时间了，而且我没有任何问题（除了速度下降以外，但我还没有进行测试）。 HTTPSEeverywhere可以通过服务器端的某些规则进行更改，但是由于我在该领域没有做太多事情，因此我不确定确切的细节。回到您的实际问题您使用HTTPSEverywhere之类的东西时，使用纯HTTP的动机甚至更少，尽管我认为很难在需要时设置正确的规则。
#12 楼
通过HTTP进行HTTPS的唯一技术缺点是，与普通HTTP相比，处理HTTPS请求在计算上要昂贵得多。但是，考虑到大多数现代服务器都具有强大的CPU，通常这种影响可以忽略不计。极高的流量水平，此时无论如何您都不太可能使用负载均衡器
随着SPDY等协议的出现，这些协议要求SSL / TLS起作用，这实际上抵消了上述计算开销，因为关于多个请求的性能改进，以及总体上更快地将资产提供给客户端。
评论
HTTPS性能的问题在于，建立新连接的成本更高，因为涉及的往返次数更多，并且非对称加密/解密比对称加密/解密要昂贵得多。一旦连接握手建立了共享的对称加密密钥，则正在进行的开销实际上是无关紧要的（很小）。如果阅读SPDY，您会发现它做的所有花哨的东西的目的实质上是通过单个连接为URL提供所有内容，从而减轻了连接握手的开销。
– Craig
2014年4月19日在10:26
评论
[WTF-我无法添加答案（尽管我似乎有足够的代表）。]我的答案（部分地）是有时是错误的。考虑在通过HTTP的GET中传递COOKIE或API密钥。如果您的站点将HTTP请求重定向到HTTPS请求，则这些调用将起作用，但COOKIE或API密钥将以明文形式传输。有些API会关闭HTTP，这是一种更可靠的方法-根本没有HTTP，因此除非使用HTTPS，否则您甚至无法使其正常工作。例如：stripe.com/docs/api/lang=php#authentication中的“所有API请求都必须通过HTTPS进行。通过纯HTTP的调用将失败”
@codingoutloud-替代方法是整个过程都通过HTTP进行，而根本没有HTTPS。怎么样了？
@BenCrowell，这是因为俘虏的门户网站看起来非常像sslstrip样式的重定向攻击（它们都是中间人请求劫持），因此支持HSTS的浏览器会同时阻止这两个。
请注意，使用https意味着您包括的所有内容也应为https或可能不会加载-例如，使用src =“：//example.com/jquery.js”加载jquery-注意缺少http或https，因此浏览器会加载合适的一个。我经历了一场噩梦，试图通过API（通过https加载）生成的http链接来正确加载一些嵌入式Amazon东西-这意味着它们直到我找到未记录的参数来切换https链接后才能正常工作
杰森您的更新应该是一个新问题，可能是网站管理员提出的，因为它与您的原始问题（技术上）无关。但是您的样式表可能来自不安全的域。