Monthly Archives: January 2009

Creating SSL Certificates for Secure HTTP

2 Replies

ssl_padlockThe use of Secure HTTP (or HTTPS) is essential to avoid getting my browser communication hijacked, or hacked.  For savvy web users, browsing a site with HTTPS is a must to protect login and other private information.  As a Web Application administrator, the way to accomplish this is to use the Secure Socket Layer (SSL) library in combination with an Apache web server.

The widely used SSL library is by OpenSSL.  It’s constantly updated, and it’s freely available.  I use it because it also compiles well on Linux and Solaris operating systems.   The source code is portable and has been tested in many flavors of Unix.  Windows install is available also.  Compiling the source code is as straight forward as running the “configure” script and run “make”.  The default install for OpenSSL is usually in /usr/local/ssl directory.

Once installed, the first step is to create a Key Pair:

/usr/local/ssl/bin/openssl genrsa -des3 -rand <anyfile1>:<anyfile2>:<anyfile3> -out www.website.com.key 1024

  • The anyfile1, anyfile2, or anyfile3 can be any file in the system.  There has to be at least one file specified.
  • Specifying a pass phrase is required in this case.  But for convenience, I might opt to do it without specifying a password.  To disable the password prompt, remove the “-des3” option.

Next create a Certificate Signing Request:

/usr/local/ssl/bin/openssl req -new -sha256 -key www.website.com.key -out www.website.com.csr

Fill in the requested information.  At the end of the questionnaire, a “challenge password” is usually not required.

Updated September 10, 2014: Due to SHA-1 weakness, it’s imperative to let the intermediate cert provider generate a cert without SHA-1 encryption.  Hence the -sha256 option when generating the CSR.

Submit the CSR to a CA such as Thawte or Verisign.  After payment is processed, they will send an email with directions how to get the certificate file.  It might require cut and paste of the cert code into a file, usually with  a .crt or .cert suffix (such as www.website.com.crt).

For development or QA environments, where a valid signed certificate is not required, I can create a self-signing one.  To create a “fake” (aka Snake Oil) certificate, use the following:

/usr/local/ssl/bin/openssl x509 -req -days 999 -in www.website.com.csr -signkey www.website.com.key -out www.website.com.cert

Both the cert and key files are required for the web server.  I’ll cover Apache web server installation in the next post.

Got Hacked?

3 Replies

Green Lock (via Flickr)The talk around Twitter right now is the phishing scam via Direct Message, as reported by many including Read Write Web, Mashable, and Chris Pirillo.  The victims include Twitter accounts for Barack Obama, Fox News, Britney Spears, and Rick Sanchez of CNN.   Getting their Twitter account hacked is a potential public relations nightmare.  The bait was a simple message to direct recipients to a fake Twitter login page, and enters their Twitter passwords.  Unsuspecting users went ahead and entered their information.  A similar trick was done in e-mail for the longest time using pages that looked like E-Bay, PayPal, or a banking site.

I get similar complaints with the websites that I maintain.  What can server administrators do to figure out who’s behind these attacks?   Here are the steps I take:

  1. Ask the business or customer when the suspecting hack happened.  Find out the exact date and time, if possible.
  2. Comb through the web server logs to find the IP addresses of the hackers using the date and time range reported by user.  For example, in Apache HTTPD, the file is normally called “access_log”.
  3. Most hackers try multiple times, in quick successions.   In this case, running through web logs through an analyzer like Webalizer or Awstats will reveal the IP address with the most hits, within a specified time range.
  4. Find out who the IP belongs to using tools like dig or nslookup.
  5. Report the offending IP address to the Internet Service Provider (ISP) as indicated by the lookup tool.  It can be done via email to postmaster@<isp.name> or abuse@<isp.name>.
  6. Depending on the severity, a fax or a phone call to the ISP may be required.  This is usually done when the hacking continues and there’s no indication of the ISP intervention to stop it.
  7. Start using the web server IP filtering features to blacklist the offending IPs.  For example, in Apache it can be done via Deny directive for doc-root in httpd.conf or .htaccess file.
  8. For known hackers’ IP addresses, make it permanent by blacklisting them in the firewall or router level.

Users do get complacent with their username/password.  They type (or even share!) passwords to others without thinking twice.  With more and more sites requiring a login, it’s easy to forget about checking the legitimacy of the page presented on the web browser.  Proactively, the web applications need to be modified to prevent login hacking such as:

  • Using Secure Socket Layer (SSL)   With SSL, most phishing sites will not bother with it because of the cost involved.  If logins are not done securely, users need to be extra careful.
  • Using OpenID, the open standards user login.  A site needs to be registered with OpenID to be able to use this service.  This removes the guesswork if the site is legitimate or not.

Hopefully the word is out for both users and web developers, to do whatever is required to secure login passwords.

Image Credit: Ashenzil