HTTPS encrypts the connection between the client and the server, so, login pages and all backend/control panel pages should be HTTPS.

Reason being, someone between the client and the server can sniff the traffic. If it is HTTPS it will be encrypted; if not, plain as day. Hence the reason why login pages usually redirect you over to a HTTPS login page, when you login you don't want to send your username and password pair to the server in plaintext!

What's funny is people often still send their email creds to their email server without being encrypted either...

Your whole site should not use HTTPS unless all of the data or functionality on that site were sensitive. Pretty simple rule of thumb: public facing pages use HTTP and login pages + anything behind use HTTPS.

Total noob question, but I'll ask it anyway: is there any coding that has to be done to do HTTPS, or is it as simple as linking to the same page with https in the front?

I also feel that I should point out: Putting forms behind SSL does not absolve you of secure coding guidelines! SSL does not influence whether or not your webapp is vulnerable to traditional injection and logic flaw attacks.

While that is true, the OP said he was interested in learning more beyond just SQL injection etc...

Which brings me to your second subject: logic flaw. That is probably the most common security flaw than anything else. It is been made worse by the fact that most "web developers" don't actually understand logic nor the full implications of structured programming.

It is compounded by a lack of understanding system fundamentals too; it's quite common amongst developers I have met to not know why "0123" comes out as "83" in any scripting language built atop C (Python and PHP are popular examples). (Hint for those that don't know: C interprets integer literals with a leading zero as an Octal number).

haha. this is so true. i have no doubts the biggest problems we'll face with early product iterations are our own bugs rather than malicious third parties :-)

we'll do the best we can to get both fronts up to snuff before the general public gets a stab at us.

You need to have an SSL certificate, and your webserver has to have the appropriate modules and such installed and accept requets on port 443.

There's server configuration, but not "coding" as traditionally defined.

One thing to remember is that some browsers will complain if your HTTPS page loads other files (css, js, etc.) over HTTP. Be sure to do some testing in that regard.

I highly recommend the Slicehost articles. They've been indispensable for me and there are some good ones on SSL/HTTPS server setup:

http://articles.slicehost.com/tags/ssl

good reminder. i've used slicehost to help setup servers before, even though i happen to use linode (early recommendation from a friend who got me into web dev to begin with). i really like the slicehost community.

One would typically serve media and static content via HTTP because of performance, and probably more importantly, easier caching architecture as it's impossible to cache TLS'ed content outside the web server.

You might want to serve some personally-identifiable or sensitive data via HTTPS if you have the the resources. At the very least, you should authenticate via HTTPS which is what a lot of services do.

thanks for all the advice.

i've chosen to make the entire site HTTPS and redirect HTTP to HTTPS. the reason being that performance doesn't seem to take a big hit, and while things like caching and moving to multiple servers will be harder, if we get to that point then re-writing some of this code will be fine (whereas it is not fine now when we just want to get some user testing done).

i'm using django. the move for some pages to be accessed via https means accounting for redirects more intelligently. eg, {% url login %} should produce https://... while {% url static_page %} should produce http://... there is a django snippet for middlewhere that allows one to provide a SSL flag.

still...if one is visiting https://mysite.com/A and then moves to https://mysite.com/B, then won't the browser alert them to the move? it should, but that provides the wrong viewing experience... i guess, once a user logs in, the rest of their visit to the site should be over https, even the static pages that non-logged in users view over http?

alternatively, i care less about the users that log in and more that the API used by my Firefox extension to communicate with my server is conducted over HTTPS. that's where i started, but once i made that https it was a slippery slope for the rest of the site :-)