Secure SSL Session from losing itself into unsecure http

Question

I've seen some implementations of HTTPS SSL and, as a visitor, forced to rely to a lot of those. What would a secure implementation look like and where can one expect problems? I expect the installer to understand what should be done by implementing the SSL itself.

The question come of the fact that some https sites suddenly forget that you are using https. Such problem appear after a submitted form, a silenced error message (i.e. you got a blank template page and press back button).

When establish a new or porting a established site into HTTPS, how do you deal with some facts, like

1. You probably into mixed mode if you forgot some reference to old http:// (which seem to apply even on the biggest web sites that have streams, different servers, user-uploaded content). Are there more complicated descisions like parse the ip adress and "accept http on some traffic / ip sources"?

2. Force visitors into HTTPS. There may be hundred of thousands of links from outside, to the page that you don't want to shutdown with a complete closing of the HTTP entry. Or would you?

3. Probably not least, how do you avoid try/cached/throwed Error and such unexpected (or not studied) actions, port your users into HTTP mode?

This question can appear language specific, but I'm sure the security point of view is enough visible. The most simple scenario should be just close down the http entry, but how applicable are that - if you want current entries to remain (but redirected)?

Answer 1

Basic rules for SSL protection for a website

How would a secure implementations look like and where can one expect problems?

These rules are intended to provide SSL protection, that is protection against an opponent that can intercept and alter packets.

Subcomponents

You probably into mixed mode in some scenarios

If, in a HTTPS page, you load any script, or CSS resource in plain http, that nullifies the SSL benefit (not just reduce).

As a rule, in a HTTPS page, load every subcomponents (frames, scripts, styles, images) over HTTPS, from trustworthy hosts.

Cookies

A particularly unfortunate mistake is to forget to make all cookies "secure". If you forget to mark all security relevant cookies with this attribute, it nullifies the SSL security. (Obviously a login/session cookie is security sensitive.)

As you want your website to be entirely over HTTPS, mark all cookies "secure".

One problem is that even "secure" cookies can be replaced by cookies HTTP non-secure cookies! What makes it even worse is that the browser will not even tell you if the cookie came from HTTP or HTTPS!

You can assume that a secure cookie cannot be read by an opponent. But you cannot assume that a cookie sent by a browser over HTTPS is the secure cookie you sent previously.

Whole site SSL protection

By providing content over HTTPS not just for some "sensitive" pages, but for the whole site, you will train users to only use your site over HTTPS which is quite good for security.

In order for users to be able to enter an HTTP URL, you will certainly do an HTTP redirect from HTTP to HTTPS, so that the only non-encrypted HTTP traffic is a HTTP redirect (in the usual, no attack, case).

The problem here is that if users get used to type the HTTP URL, and they might fail to check every time that they are properly redirected to the corresponding HTTPS site: an attacker that can intercept and modify packets can alter the HTTP request to redirect to another misleading HTTPS site, or just assume that the user doesn't usually doesn't detect the HTTP/HTTPS difference: this is a good reason to use HSTS.

Other website security principles

The SSL cryptographic protection is an essential part of website security, especially to protect the secrecy of passwords. But it isn't the end of the security requirements that are specific to websites.

Just as a reminder, some other essential security principles:

Safe handling of untrusted data

When taking user input and outputting it in web page, you must apply proper escaping to avoid XSS vulnerabilities. For this, you must understand that different parts of the HTML page have different syntax (normal HTML, attribute value, URL have completely different syntaxes) and thus need different escaping.

As in any other program taking external untrusted input, you must properly validate every input, and store and output it in a way that does not misbehaved if an unusual character is present (see: SQL injection).

Verification of authorisation on the web

You cannot only rely on cookies (or HTTP authentication) to validate that a specific order from a HTTP client is authorised: doing so would expose your website to a CSS attack from another website if the user browse both websites in the same browser.

My view of secure design

The problem with website security is often caused either by not understanding the different specific requirements of these web protocols, or by securing all but one "entry point".

Before you even to design a "secure" website, you should understand all these requirements; then you should apply them in a systematic way. Your design should be simple, regular, understandable, and easy to audit.

The best style is one where you just cannot forget to apply to escape text that is going to be interpreted as HTML/HTML attribute/SQL/SQL "regexp"/shell commands/shell regexp. The best approach, when possible, is to prevent variable data that is not intended to be interpreted as HTML/HTML attribute/SQL/SQL "wildcard expr"/shell commands/shell regexp to appear in such context that it requires escaping: avoiding need to escape is safer because you cannot forget to escape things.

I know that I am drifting off topic here... so I will stop now. I just wanted to it clear that HTTP security doesn't stop at "100 % over SSL".

Answer 2

let me try to answer that for you:

1. Do not use mixed mode. Disbale port 80 completly (or configure port 80, so it forwards http://yourdomain.ext and http://yourdomain.ext/ to https://yourdomain.ext/, nothing else; for any other request, show a 404
2. Now you prefer usability and page ranks over security. you may want to think about that
3. just don't host any thing on port 80, port 443 should host the app, not port 80

EDIT 1: It seems a fact that most applications get designed with no security in mind (or want to reduce cost and plan to add security later). Then something terrible happens and the decision makers start screaming:" We want SECURITY, NOW, but we do not want to spoil our customers with error messages." Well, this is not going to happen, if you want to try to make your system as secure as possible.

Look around here on IT Security, there are a lot of topics related to switching from HTTP to HTTPS, why not thinking about HTTPS only mode right from the beginning? It is actually funny: Already the first versions of IE and Netscape Navigator warn the the users about the danger of submitting POSTS to HTTP pages. All browsers still do with the little check box ticked saying "Do not bother me about it again!".