Solved

private SSL useage

Posted on 2003-12-06
9
634 Views
Last Modified: 2010-04-11
Hi Experts,

I'd like to setup a server at home that contains things like my address book, how do i secure comunication with it via SSL without having to purchase a credential from a company ( like thawte ) that in fact verifies who I am. As i only intend to use it privately I do not need any company to verify me. is there any way tp use SSL without the comerce corupting the internet?

Regards,
Fouad
0
Comment
Question by:FouadDaniels
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
9 Comments
 
LVL 5

Expert Comment

by:arjanh
ID: 9887864
You can self-sign your certificates, e.g. as described here:
http://slacksite.com/apache/certificate.html
You can off course set a longer expiry period...
0
 
LVL 18

Expert Comment

by:chicagoan
ID: 9888352
http://www.cacert.org/ issues free certs

http://www.shininglightpro.com/search.php?searchname=Win32+OpenSSL for windows

note you should have a host name registered first
0
 
LVL 10

Expert Comment

by:KingHollis
ID: 9891575
If your server at home is genuinely a Windows 2000 or greater server, you can install certificate services from Add/Remove programs and create your own certs.
0
Threat Trends for MSPs to Watch

See the findings.
Despite its humble beginnings, phishing has come a long way since those first crudely constructed emails. Today, phishing sites can appear and disappear in the length of a coffee break, and it takes more than a little know-how to keep your clients secure.

 
LVL 51

Expert Comment

by:ahoffmann
ID: 9891699
simply install your own CA, see http://www.openssl.org/
0
 
LVL 4

Expert Comment

by:MobileOakAI
ID: 9893309
OpenSSL - I think we have a winner
0
 
LVL 1

Accepted Solution

by:
chrish4321 earned 500 total points
ID: 9893378
There are a couple of ways to securely communicate with your server at home.  One of the most flexible is to set it up with a self signed SSL certificate.  Since you don't need the public to securly access your site, you are right that you do not need your certificate signed by a standard public CA.  See http://slacksite.com/apache/certificate.html for details on doing this.  

However, if your certificate is not signed by a trusted authority, then each time you access your site, you will be presented with a warning that no trusted path exists to your certificate.  You can choose to ignore this warning, but you run the risk of a man in the middle attack -- i.e., someone hijacks your connection to your server, passing your requests and the responses from the server along (possibly unchanged, but note that he could inject any false or misleading information he wanted), but standing in between and evesdroping on your transactions.  

This is a risk because by accepting an untrusted certificate, you don't actually know that you're encrypting and verifying your transactions with _your_ server's public key.  You could be encrypting to the attacker's public key, sending your information to him, where he decrypts it, reads it, corrupts it or otherwise compromises is, then reencrypts it with your server's key and sends it the rest of the way to your server.  

There are a few solutions.  Since you don't want to pay for a public CA's signature, which gains its security because the CA's certificate is built in to most browsers by default, you'll have to establish trust between your two machines.  

The simplest and most cumbersome method is to verify your certificate's fingerprint or thumbprint each time you use it.  When your browser tells you that the certificate isn't trusted, choose to view the certificate's details.  Depending on your browser, there are two hashes that you might see -- they're called finger or thumb prints.  Compare these to the values you get by computing the finger/thumbprints while sitting at your server, and if they match, it's ok to accept the certificate.  

See http://www-zeuthen.desy.de/computing/projects/security/SSL/ssl_commands.html for a list of common SSL commands, including for getting fingerprints.  

Once you've done this, you can choose to "install" the certificate -- that way, your browser remembers the certificate and you won't have to check the fingerprint each time you use the site.  

With this solution, you can then consistently and safely use your work computer to access your home page.  However, you'll have to check the fingerprint again for each computer you use to access the site.  

If you plan to run several sites this way, you can setup your own unofficial CA, install that CA's certificate in your browsers, then sign your server certificates with your CA's key.  This is essentially the same technique, but allows you to expand more readily.  See http://tirian.magd.ox.ac.uk/~nick/openssl-certs/ca.shtml for information on this.  

However, in my experience, messing about with SSL causes headaches.  I _do_ run one of my servers this way, but it's annoying.  SSL has the great advantage of allowing websites with certificates signed by the public CAs to communicate securely with millions of people, but SSL is tricky to learn and use, and can easily be messed up.  Also, checking the fingerprints of non-publically-signed certificates is tedious, and skipping the check since it's such a bother can lead to security risks.  

Therefore, when the issue came up for me again, I decided to postpone the SSL technique until I had time to mess around with it, and instead used a combination of .htaccess files and SSH to securely tunnel to my site.  This interim solution worked so well that I still use it.  These directions are geared towards Apache with .htaccess files, but I'm sure you can adapt them to other servers.  

Here's what I mean:

1. Restrict access to the pages/directories you want to protect to "localhost" using .htaccess files.  Here's an example .htaccess file:

        <limit GET POST PUT>
        order deny,allow
        deny from all
        allow from 127.0.0.1
        </limit>

You can also do .htaccess Basic Authentication here, which should be pretty secure, since we're going to encrypt our sessions with the server.  See http://www.javascriptkit.com/howto/htaccess.shtml for an excellent .htaccess guide.  

2. I'm assuming you're using *NIX, but if not, you can still do this step by installing Cygwin on Windows and running an SSH daemon as a service.  I do it on XP, but it's a bit involved to set up.  Check out google for tips on that one.  You can also see below about running the web server and ssh daemon on different boxes.  

Now, if you have a *NIX system, odds are you're running sshd or can easily do so.  To connect to your machine, just tunnel a port from your local (work) machine to port 80 on your webserver.  Here's the command:

ssh -L 4321:localhost:80 user@yourserversaddress.com

You can also use putty or whatever SSH client you'd like to use.  If you use the ssh.com version, you can do all this through the GUI settings under Edit Profiles, on the Tunneling tab.
 
If this is your first time connecting to your server from any given machine, I strongly reccommend that you verify your server's (SSH) public key fingerprint against the fingerprint you got by running ssh-keygen -l (that's an L) on your server.  ssh-keygen -B may also be useful, since this gives "bubble-babble", which is how ssh.com's client presents fingerprints.  This is equivalent to checking your SSL certificate's fingerprint in terms of security ramifications.  Once the fingerprints match up, install the server's key.  

Assuming all this has worked out, you've now established a secure, encrypted tunnel between your work computer at port 4321 and your home server at port 80.  

3. To connect to the website, just point your browser at http://localhost:4321.  You've now got a secure link to your server, sans SSL or any special webserver settings.  Just be sure not to break the connection by using absolute URLs in links or anything...  This sounds bad, but you still would have had to make sure all your links pointed to the https:// version of your site if you were using SSL.  

So,
1. restrict access to localhost (i.e. your server)
2. tunnel to your server using SSH
3. access http://localhost:port

This is equivalent to SSL but for me it's cleaner and easier.  It separates the encryption from the quirky and "user friendly" web browsers, and should, if done right, be just as secure.  

One final thought.  If you don't want to or can't run sshd on the webserver, you can run it on a local machine on your home network.  Then just restrict access to the page to that machine on your LAN, and tunnel to the webserver through the LAN machine running sshd by using ssh -L 4321:yourwebserversLANaddress:80 user@yourSSHserverspublicinternetaddress.com.  This ought to be ok, since I assume no one's tapping into your LAN.... just don't do this if you use a wireless LAN, or if you bridge your LAN into your local cable provider's network.  

Good luck.  
0
 
LVL 18

Expert Comment

by:chicagoan
ID: 9893384
Two words:
VPN
0
 
LVL 1

Expert Comment

by:chrish4321
ID: 9898946
I think that's five words...
0
 

Author Comment

by:FouadDaniels
ID: 10631018
I appologise it took so long, thanks for your effort. it has helped me alot eventually.

Once more sorry that only now I came back on this subject.

Respect,

Fouad Daniels
0

Featured Post

The Eight Noble Truths of Backup and Recovery

How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A hard and fast method for reducing Active Directory Administrators members.
I was prompted to write this article after the recent World-Wide Ransomware outbreak. For years now, System Administrators around the world have used the excuse of "Waiting a Bit" before applying Security Patch Updates. This type of reasoning to me …
The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…
With Secure Portal Encryption, the recipient is sent a link to their email address directing them to the email laundry delivery page. From there, the recipient will be required to enter a user name and password to enter the page. Once the recipient …

752 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question