Is there any reason not to serve https content on

问题:

I currently have image content being served on a domain that is only accessible over https. What is the downside of serving an image with an https path on a page accessed over http? Are there any caching considerations? I'm using an HttpRuntime.Cache object to store the absolute image path, which is retrieved from a database.

• I assume there is no benefit to using protocol-relative URLs if the image is only accessible over https?

• Is there a compelling reason why I should set up a separate virtual directory to also serve the image content over http?

回答1:

• If the content served over HTTPS within the HTTP page isn't particularly sensitive and could equally be served over HTTP, there is no downside (perhaps some performance issues, not necessarily much, and lack of caching, depending on how your server is configured: you can cache some HTTPS content).

• If the content server over HTTPS is sufficiently sensitive to motivate the usage of HTTPS, this is really bad practice.

  Checking that HTTPS is used and used correctly is solely the responsibility of the client and its user (this is why automatic redirections from HTTP to HTTPS are only partly useful, for example). Although some of it has to do with the technicalities of certificate verification, a lot of the security offered by HTTPS comes from the fact that the user:

  1. expects to be using HTTPS (otherwise they could easily be downgraded),
  2. is able to verify the validity of the certificate: green/blue bar, corresponding to the host name on which they expect to be.

  The first point can be addressed by HTTP Strict Transport Security, from a technical point of view.

  The second needs used interaction. If you go to your bank's website, it must not only be a site with a valid certificate, but you should also check that it's indeed the domain name of your bank, for example.

  Embedding HTTPS content in an HTTP page defeats this, since the user can't check which site is being used, and that HTTPS is used at all in fact. To some extent, embedding HTTPS content from a third party in an HTTPS page also presents this problem (this is one of the problems with 3-D Secure, which may well be served using HTTPS, but using an iframe doesn't make which site is actually used visible.)