为什么不全部使用 HTTPS 呢？
如果我正在设置服务器并且拥有 SSL 证书，为什么我不对整个网站使用 HTTPS 而只是用于购买/登录？我认为加密整个网站并完全保护用户会更有意义。它将防止诸如决定必须保护什么之类的问题，因为一切都会受到保护，而且这对用户来说并不是真正的不便。
如果我已经在网站的一部分中使用 HTTPS，为什么我不想在整个网站中使用它呢？
这是一个相关问题：为什么 https 只用于登录？ ，但答案并不令人满意。答案假设您无法将 https 应用到整个网站。
If I was setting up a server, and had the SSL certificate(s), why wouldn't I use HTTPS for the entire site instead of just for purchases/logins? I would think it would make more sense just to encrypt the entire site, and protect the user entirely. It would prevent problems such as deciding what has to be secured because everything would be, and it's not really an inconvenience to the user.
If I was already using an HTTPS for part of the site, why wouldn't I want to use it for the entire site?
This is a related question: Why is https only used for login?, but the answers are not satisfactory. The answers assume you've not been able to apply https to the entire site.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
除了其他原因（尤其是与性能相关）之外，使用 HTTPS 时，每个 IP 地址* 只能托管一个域。
单个服务器可以支持 HTTP 中的多个域，因为 Server HTTP 标头让服务器知道要响应哪个域。
对于 HTTPS，服务器必须在初始 TLS 握手期间（在 HTTP 启动之前）向客户端提供其证书。这意味着服务器标头尚未发送，因此服务器无法知道正在请求哪个域以及哪个证书（www.foo.com 或 www.bar.com） ）来回应。
*脚注：从技术上讲，如果您将多个域托管在不同的端口上，则可以托管多个域，但这通常不是一个选择。如果您的 SSL 证书具有通配符，您还可以托管多个域。例如，您可以使用证书 * .example.com 托管 foo.example.com 和 bar.example.com
In addition to the other reasons (especially performance related) you can only host a single domain per IP address* when using HTTPS.
A single server can support multiple domains in HTTP because the Server HTTP header lets the server know which domain to respond with.
With HTTPS, the server must offer its certificate to the client during the initial TLS handshake (which is before HTTP starts). This means that the Server header hasn't been sent yet so there is no way for the server to know which domain is being requested and which certificate (www.foo.com, or www.bar.com) to respond with.
*Footnote: Technically, you can host multiple domains if you host them on different ports, but that is generally not an option. You can also host multiple domains if your SSL certificate is has a wild-card. For example, you could host both foo.example.com and bar.example.com with the certificate * .example.com
我可以想到几个原因。
I can think of a couple reasons.
SSL/TLS 的使用频率还不够。 整个会话必须使用 HTTPS，任何时候都不能通过 HTTP 发送会话 ID。如果您仅使用 https 进行登录，那么您显然违反了 OWASP 前 10 名2010“A3：失效的身份验证和会话管理”。
SSL/TLS isn't used nearly often enough. HTTPS must be used for the entire session, at no point can a Session ID be sent over HTTP. If you are only useing https for logging in then you are in clear violation of The OWASP top 10 for 2010 "A3: Broken Authentication and Session Management".
为什么不通过挂号邮件将所有普通邮件装在防篡改的不透明信封中发送？邮局的专人始终会亲自保管该邮件，因此您可以非常确定没有人会窥探您的邮件。显然，答案是，虽然有些邮件值得花钱，但大多数邮件却不值得。我不在乎是否有人读到我的“很高兴你出狱了！”给乔叔叔的明信片。
加密不是免费的，也并不总是有帮助。
如果会话（例如购物、银行业务等）最终将使用 HTTPS，则没有充分的理由不尽早将整个会话设置为 HTTPS。
我的观点是，只有在不可避免的情况下才应使用 HTTPS，因为需要保护请求或响应免受中间窥探。举个例子，看看雅虎！主页。即使您已登录，您的大部分交互也将通过 HTTP 进行。您通过 HTTPS 进行身份验证并获取证明您身份的 cookie，因此您不需要 HTTPS 来阅读新闻报道。
Why not send every snail-mail post in a tamper-proof opaque envelope by Registered Mail? Someone from the Post Office would always have personal custody of it, so you could be pretty sure that no one is snooping on your mail. Obviously, the answer is that while some mail is worth the expense, most mail isn't. I don't care if anyone reads my "Glad you got out of jail!" postcard to Uncle Joe.
Encryption isn't free, and it doesn't always help.
If a session (such as shopping, banking, etc.) is going to wind up using HTTPS, there's no good reason not to make the whole session HTTPS as early as possible.
My opinion is that HTTPS should be used only when unavoidably necessary, either because the request or the response needs to be safeguarded from intermediate snooping. As an example, go look at the Yahoo! homepage. Even though you're logged in, most of your interaction will be over HTTP. You authenticate over HTTPS and get cookies that prove your identity, so you don't need HTTPS to read news stories.
除了系统负载之外，最大的原因是它破坏了基于名称的虚拟主机。使用 SSL，它就是一个站点 - 一个 IP 地址。这是相当昂贵的，而且更难管理。
The biggest reason, beyond system load, is that it breaks name-based virtual hosting. With SSL, it's one site - one IP address. This is pretty expensive, as well as harder to administer.
对于高延迟链接，初始 TLS 握手需要额外的往返来验证证书链（包括发送任何中间证书）、就密码套件达成一致并建立会话。一旦建立了会话，后续请求就可以利用会话缓存来减少往返次数，但即使在这种最佳情况下，往返次数仍然多于正常 HTTP 连接所需的次数。即使加密操作是免费的，往返也不是免费的，并且在较慢的网络链接上可能会非常明显，尤其是在站点不利用 http 管道的情况下。对于网络连接良好的宽带用户来说，这不是问题。如果您开展国际业务，需要 https 很容易导致明显的延迟。
还有其他考虑因素，例如会话状态的服务器维护可能需要更多的内存，当然还有数据加密操作。任何小型站点实际上都不必担心给定的服务器功能与当今硬件的成本。任何大型站点都可以轻松负担得起 CPU/w AES 卸载或附加卡来提供类似的功能。
随着时间的推移以及硬件和网络功能的改进，所有这些问题都变得越来越不成问题。在大多数情况下，我怀疑今天是否有任何明显的差异。
可能存在操作方面的考虑，例如对 https 流量的管理限制（想想中间内容过滤器等），可能还有一些公司或政府法规。一些企业环境需要在外围进行数据解密，以防止信息泄露……干扰热点和类似的基于 Web 的访问系统，这些系统无法在 https 事务中注入消息。归根结底，在我看来，不默认使用 https 的原因可能很小。
For high latency links the initial TLS handshake requires additional round trips to validate the certificate chain (including sending any intermediate certificates), agree on cipher suites and establish a session. Once a session is established subsequent requests may utilize session caching to reduce the number of round trips but even in this best case there is still more round trips than a normal HTTP connection requires. Even if encryption operations were free round trips are not and can be quite noticable over slower network links especially if the site does not leverage http pipelining. For broadband users within a well connected segment of the network this is not an issue. If you do business internationally requring https can easily cause noticable delays.
There are additional considerations such as server maintenance of session state requiring potentially significantly more memory and of course data encryption operations. Any small sites practically need not worry about either given server capability vs cost of todays hardware. Any large site would easily be able to afford CPU /w AES offload or add-on cards to provide similar functionality.
All of these issues are becoming more and more of a non-issue as time marches on and the capabilities of hardware and the network improve. In most cases I doubt there is any tangable difference today.
There may be operational considerations such as administrative restrictions on https traffic (think intermediate content filters..et al) possibly some corporate or governmental regulations. Some corporate environment require data decryption at the perimeter to prevent information leakage ... interference with hotspot and similiar web based access systems not capable of injecting messages in https transactions. At the end of the day in my view reasons for not going https by default are likely to be quite small.
https 比普通的 http 更需要资源。
它对服务器和客户端都有更多的要求。
https is more resource-hungry than the normal http.
It demands more from both the servers and the clients.
如果整个会话都被加密，那么您将无法在代理级别（例如 ISP）上对静态资源（例如图像和 js）使用缓存。
If whole session is encrypted then you won't be able to use caching for static resources like images and js on proxy level eg ISP.
您应该在任何地方使用 HTTPS，但是您将失去以下内容：
由于 BREACH 和 CRIME 攻击，您绝对不应该使用 SSL 压缩或基于 SSL 的 HTTP 压缩。因此，如果您的响应包含会话或 csrf 标识符，则不会进行压缩。您可以通过将静态资源（图像、js、css）放在无 cookie 的域中并在那里使用压缩来缓解这种情况。您还可以使用 HTML 缩小。
一个 SSL 证书，一个 IP 地址，除非使用 SNI，这不适用于所有浏览器（旧版 Android、黑莓 6 等）。
一个 SSL
您不应在网页上托管任何不通过 SSL 传输的外部内容。
当浏览器转到 HTTP 页面时，您会丢失出站 HTTP Referer 标头，这对您来说可能是问题，也可能不是问题。
You should use HTTPS everywhere, but you will lose the following:
You should definitely not use SSL Compression or HTTP Compression over SSL, due to BREACH and CRIME attacks. So no compression if your response contains session or csrf identifiers. You can mitigate this by putting your static resources (images, js, css) on a cookie-less domain, and use compression there. You can also use HTML minification.
One SSL cert, one IP address, unless using SNI, which doesn't work on all browsers (old android, blackberry 6, etc).
You shouldn't host any external content on your pages that don't come over SSL.
You lose the outbound HTTP Referer header when browser goes to an HTTP page, which may or may not be a problem for you.
嗯，显而易见的原因是性能：所有数据在传输之前都必须由服务器加密，然后由客户端在收到时解密，如果没有敏感数据，这会浪费时间。它还可能会影响您网站的缓存量。
如果所有地址都使用
https://而不是熟悉的http://，最终用户也可能会感到困惑。另请参阅此答案：为什么不呢包含 js 文件时始终使用 https？
Well, the obvious reason is performance: all of the data will have to be encrypted by the server before transmission and then decrypted by the client upon receipt, which is a waste of time if there's no sensitive data. It may also affect how much of your site is cached.
It's also potentially confusing for end users if all the addresses use
https://rather than the familiarhttp://. Also, see this answer:Why not always use https when including a js file?
https 要求服务器对客户端请求和响应进行加密和解密。如果服务器为大量客户端提供服务，那么性能影响将会增加。这就是为什么大多数当前的 https 实现仅限于密码身份验证。但随着计算能力的增强，这种情况可能会改变，毕竟 Gmail 整个网站都使用 SSL。
https requires the server to encrypt and decrypt client requests and responses. The performance impact will add up if the server is serving lots of clients. That's why most current implementations of https is limited to password authentication only. But with increasing computing power this may change, after all Gmail is using SSL for the entire site.
除了 WhirlWind 的响应之外，您还应该考虑 SSL 证书的成本和适用性、访问问题（客户端可能无法通过 SSL 端口进行通信，但有可能）等。
使用 SSL 并不能保证安全毯。这种类型的保护需要内置到应用程序的体系结构中，而不是试图依赖某种灵丹妙药。
In addition to WhirlWind's response, you should consider the cost and applicability of SSL certificates, access issues (it's possible, though unlikely, that a client may not be able to communicate via the SSL port), etc.
Using SSL isn't a guaranteed blanket of security. This type of protection needs to be built into the architecture of the application, rather than trying to rely on some magic bullet.
有人告诉我，在我们公司的一个项目中，他们发现 SSL 消息占用的带宽明显多于普通消息。我相信有人告诉我这是惊人的 12 倍数据。我自己还没有验证过这一点，听起来很高，但如果每个页面都添加了某种标题，并且大多数页面都有少量内容，那可能不会太遥远。
也就是说，在 http 和 https 之间来回切换并跟踪哪些页面的麻烦对我来说似乎太费力了。我只尝试过建立一个混合它们的网站，但当我们被复杂的事情绊倒时，我们最终放弃了这个计划，比如由 Javascript 创建的弹出窗口附加了错误的协议之类的事情。我们最终只是让整个网站使用 https 来减少麻烦。我想在简单的情况下，你只有一个需要保护的登录屏幕和支付屏幕，而且它们都是简单的页面，混合搭配并不是什么大问题。
我不会太担心客户端解密的负担。通常，客户端等待数据通过网络传输的时间会比处理数据的时间多得多。在用户经常拥有千兆位/秒的互联网连接之前，客户端处理能力可能相当无关紧要。服务器加密页面所需的 CPU 功率是另一个问题。很可能存在无法跟上数百或数千用户的问题。
I was told that on one project at our company, they found that the bandwidth taken up by SSL messages was significantly more than for plain messages. I believe someone told me it was an astounding 12 times as much data. I have not verified this myself and it sounds very high, but if there is some sort of header added to each page and most pages have a small amount of content, that may not be so far out.
That said, the hassle of going back and forth between http and https and keeping track of which pages are which seems like too much effort to me. I only once tried to build a site that mixed them and we ended up abandoning the plan when we got tripped up by complex things like pop-up windows created by Javascript getting the wrong protocol attached to them and that sort of thing. We ended up just making the whole site https as less trouble. I guess in simple cases where you just have a login screen and a payment screen that need to be protected and they're simple pages, it wouldn't be a big deal to mix-and-match.
I wouldn't worry much about the burden on the client to decrypt. Normally the client is going to be spending a lot more time waiting for data to come over the wire than it takes to process it. Until users routinely have gigabit/sec internet connections, client processing power is probably pretty irrelevant. The CPU power requried by the server to encrypt pages is a different issue. There might well be issues of it not being able to keep up with hundreds or thousands of users.
另一个小点（也许有人可以验证），如果用户在表单项（例如文本框）中键入数据，然后由于某种原因刷新页面或服务器崩溃一秒钟，则用户输入的数据将丢失HTTPS 但使用 HTTP 保留。
注意：我不确定这是否是特定于浏览器的，但我的 Firefox 浏览器肯定会发生这种情况。
One other small point (maybe someone can verify), If a user types data into a form item such as a text box and then for some reason refreshes the page or the server crashes out for a second, the data the user entered is lost using HTTPS but is preserved using HTTP.
Note: I'm not sure if this is browser specific but it certainly happens with my Firefox browser.
带有 IIS 8.0 的 Windows Server 2012 现在提供 SNI，即服务器名称指示，它允许 IIS 中的多个 SSL Web 应用程序托管在一个 IP 地址上。
windows Server 2012 with IIS 8.0 now offers SNI which is Server Name Indication which allows multiple SSL Web Applications in IIS to be hosted on one IP Address.