authenticating users and encrypting transmissions

@bjn2104:

I have a situation that I would like to know people's opinions on. I want to set up a section of my website (at this point running on apache 1.3, which is running on Slackware 10.0) so that it can only be viewed and used by a few specific people, and all packets between those users and the web server should be as unreadable to outside observers as possible. I have been researching the best way to do this, but have had trouble piecing together a complete solution. IPsec? SSL? What do you think the best way to do this is, and do you have any links that could help with implementation? Thank you.

Configure your web server to support SSL, and then put that section of the site behind the secure server. Use passsword authentication for those pages.

With SSL and password authentication:

• All traffic is encrypted using strong encryption and will completely unreadable by anyone sniffing the packets

• Only authenticated users will be able to read any of the web pages

I think this meets all your requirements.

It's been a while since I've done any web server configuration so I can't help you with the specific details of your server. But to answer your broader question, SSL and password authentication will satisfy your requirements.

bji,

Thank you for your reply, but from what I understand (and please correct me if I am wrong) if only using SSL it is impossible to authenticate packets, even if they are encrypted. This means that though they are unreadable to outsiders, they could have originated from anywhere, meaning that I cannot be sure that only the users I have authorized are viewing my encypted information. One of the upsides of IPsec, from what I have read, is that packets are both encrypted and signed by some sort of authenticating key/checksum. Please let me know what you think.

IPSec is overkill.

1) Apache+SSL

2) Make users login with un/pw to that section

3)

> Deny from All

Allow from ip.goes.right.here

Allow from another.ip.goes.here

…

in an .htaccess file.

Correctly implemented SSL prevents anyone other than your authenticated users from reading your data. The packets could not have originated from anywhere - they have to be encrypted with the keys agreed when the SSL session was established. The vulnerability you were thinking of is probably a man-in the-middle (MITM) attack, where the attacker tricks your users into logging in to his spoof of your site and grabs the encryption keys, enabling him to read and alter communications in both directions.

IPSec makes MITM more difficult but is indeed overkill unless you're working for the feds or Colombian drug barons.

Thank you everyone, I will look into SSL

For a highly secure web server I have used client & server side certificates in the past. That would allow clients to use a certificate (private key/public key pair) instead of a username & password to authenticate, or it could be used alongside traditional username & password logins for extra security.

Untitled9,

That sounds like a great idea, using public/private keys and username/passwords involves something the user has and something the user knows, upping the probability that it is actually the expected user. And from what I understand, that is how the ssh protocal works. But what I am having a hard time understanding is how you would implement private/public key security for users logging into a website?