Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In doing some research regarding SSL, I came across this topic. One of the common suggestions was not to serve content over HTTP. What does that mean from a website development POV? Referencing things like stylesheets with a full https URL? Something else?

share|improve this question
You'll be safe following the same origin policy: – Henning Klevjer Nov 8 '12 at 15:16
up vote 5 down vote accepted

It means to always use the SSL layer when serving pages. Links don't need to be absolute, but traffic received on port 80 without SSL should be redirected to port 443 with SSL. The rest of the magic is in avoiding attacks where the user doesn't visit the SSL site first and the redirect is hijacked using something like SSLstrip. That is covered in this question: Options when defending against SSLstrip?

share|improve this answer
Hmmm... I think my options may be a bit limited from a development POV. Client wants a small e-commerce site, but can only afford a shared hosting solution at the moment. I can't go under the hood and disable pure HTTP access. Thankfully, further research shows I can enable HSTS programatically, so that's a plus. – Major Productions LLC Nov 8 '12 at 2:40
HSTS requires HTTPS and doesn't work on IE, only Firefox and Chrome. Also, even on shared hosting, SSL (HTTPS) is usually an option, just look around for different offers. – Matrix Nov 8 '12 at 8:32
@KevinM1 They can't afford a VPS for 15 dollars a month? – Polynomial Nov 8 '12 at 8:59
You can put in a 301 permanent redirect to the HTTPS site thereby disabling all HTTP access with a forced redirect? And in addition to what Matrix says, technically opera also supports HSTS and there is no harm in enabling it as long as everything on the domain is available over HTTPS and you are aware of the limitations. – ewanm89 Nov 8 '12 at 10:19
@Polynomial The client got scammed by her last developer/webmaster, so she's still trying to recover. I've been able to gain a portion of her trust by being straight with her (like I am with all my clients), but she's still very hesitant when it comes to expenses I suggest. I'm trying to meet her halfway. – Major Productions LLC Nov 8 '12 at 12:29

It means that all content and resources should be served over HTTPS (not HTTP). Local scripts, stylesheets, and images should be referenced with a URL that will ultimately load the resource over HTTPS, not HTTP.

One way to achieve this is to make sure that all URLs are absolute and fully qualified, and start with https:.

Alternatively, you can continue to use relative URLs, as long as you verify they will ultimately resolve to a https: URL.

For example, suppose you have a page Here are some examples of snippets that are OK / not OK to include in that page:

  • OK: <IMG SRC="">

  • OK: <IMG SRC="/pic.png">

  • OK: <IMG SRC="">

  • OK: <IMG SRC="//"> (this is a relative URL, which uses the same protocol as the containing page, but a different host)

  • Bad: <IMG SRC="">

  • OK: <IFRAME SRC="">

  • OK: <IFRAME SRC="">

  • OK: <SCRIPT SRC="">

  • OK: <LINK HREF="">

  • Bad: <SCRIPT SRC="">

  • Bad: <LINK HREF="">

  • Bad: <IFRAME SRC="">

I hope this makes sense.

share|improve this answer

I want to be able to encrypt certain things (like user passwords) but DO NOT WANT to enable any third party verification exploits (CAs have no idea about site content nor user wishes so so what exactly would they be able to verify?). It just opens up a huge security hole in browsers that could be exploited by a rogue CA, nor do I want WASTE resources encrypting PUBLIC content (that makes no sense).

Browser behavior is the problem … and we are still stuck with a mid-90's workaround was probably only intended to be temporary and the security hole opened up in browsers by it now is considered too high a price to pay for many of us.

I am getting very sick of the misinformation being bandied about everywhere regarding SSL and the endless attempts to sneak this exploit into software.

Until the third party verification exploits are removed from browser defaults SSL cannot be considered secure for website use, because the untrusted third party verification opens up a big gaping hole in those browsers that could potentially be abused to frighten your users away!

You get the same encryption with a self signed certificate, but browsers will tell users it is "insecure" - based not on anything on your site, nor anything the user asked for. No, it's just whether you paid someone for a certificate.

Now what would happen if a rogue or corrupt government or corporation took over a CA? (or even a corrupt employee working there)…

Think about it

… its a serious matter!

I've seen plenty of pretty dodgy scammy sites with "valid" certificates out there, and not yet in all these years ever seen those browser warnings happen on anything malicious (always just "expired", self signed, etc). It does not help anyone - people just buy certificates for the browser bling.

The actual encryption is no more or less secure than with a self signed certificate.

That could be abused.

share|improve this answer
The point of domain verified SSL certificates is to verify that you're talking to the owner of the domain, which prevents MitM. Protecting against scammers is out-of-scope. The CA corruption issue is a problem, but people work on countermeasures, such as Certificate Transparency, which increases the probability of a corrupted CA being detected and blacklisted. Extended validation certificates have a larger scope, they aim to validate the real life identity of the domain owner. – CodesInChaos Oct 25 '13 at 14:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.