Web Site Security

Generating and installing an SSL Certificate using the Web Host Manager interface is easy.  The steps are:

1. Click on “Generate an SSL Certificate and Signing Request”
2. Fill in the text boxes with the appropriate information and click on “Create”
3. Use cut and paste to copy the CSR, (Certificate Signing Request)
4. Purchase your certificate and then use the CSR to complete the order in our billing system.
5. Once you have your certificate, click on, “Install an SSL Certificate on a Domain”

Important notes:

• If you want your certificate to work on both www.YourDomain.com and YourDomain.com, use the www version when generating a signing request.
• If you want a certificate for a specific sub-domain (such as forum.YourDomain.com or store.YourDomain.com) you need to generate a CSR for that sub-domain.  If you have a large number of sub-domains to secure, consider a wildcard certificate.
• As of this writing, cPanel makes outdated assumptions about additional certificates which may be required.  These certificates are called a “CA bundle”.  They are included when your certificate is sent to you.   The last box on the certificate installation screen shows the CA bundle as optional.  Don’t leave the box empty.  Fill it in with your CA bundle certificates.

You can order an SSL certificate from us here.  Select the type certificate you want from the category drop-down.

To the uninitiated, using cPanel to generate and install an SSL certificate will seem complicated.  It’s actually rather simple.

Generate a new private key:

1. Log in to cPanel and click on the SSL/TLS icon.
2. Click on, “Generate, view, upload, or delete your private keys.”
3. Leave the size set to 2,048; put your domain name in the description if you wish
4. Click on “Generate”
5. At the bottom, click on “Return to SSL Manger”

Generate a new certificate signing request based on the new key.  The “CSR” acronym stands for “Certificate Signing Request”:

1. Click on, “Generate, view, or delete SSL certificate signing requests.”
2. In the Key text box, select the key you just generated
3. Fill in the Domains text box with your domain name.  Be sure to use the www prefix, www.YourDomain.com
4. Fill in the rest of the text boxes which have an “*” next to them.  These are required.  The rest are optional.
5. DO NOT fill in the Passphrase box!  With our SSL providers it is not needed and can cause complications.
6. Click on “Generate”
7. Click on “Return to SSL Manager”

Now that you have the CSR, it’s time to order the certificate.   Go to our ordering system, select and purchase your certificate.  A new service will be created in your account which you then configure using your new CSR.  Logged in to your billing account:

1. Click on “Services” at the top followed by “My Services”
2. To the right of your certificate service, click on, “View Details”
3. Click on, “View Certificate Details” and then, “Configure Certificate”
4. In the web server drop down box, select “Apache +ModSSL”
5. Use cut and paste to put your new CSR in the box below that.
6. Make sure you see “—–BEGIN CERTIFICATE REQUEST—–” and “—–END CERTIFICATE REQUEST—–“
7. The rest of the boxes will self populate and you can ignore or change them as you wish.
8. Click on “Click to Continue”
9. Select where you want the confirmation email to be sent.  Be sure before continuing that you have access the the selected address.  An error here will cause delays.
10. Follow the instructions in the confirmation email once you receive it.

Your new SSL certificate will be emailed to you when the confirmation process is complete.  For domain validated certificates this will be a matter of minutes.  Extended validation certificates require manual review at the certificate vendor which can take a day or more and often includes a phone call from the vendor.

Now back in cPanel, follow these steps:

1.  In the SSL/TLS manager in cPanel, click on, “Generate, view, upload, or delete SSL certificates.”
2. You want “Upload a new Certificate”.  Paste your new certificate into the box, “Paste the certificate into the following text box:”
3. Click on “Save” and return to the SSL/TLS manager
4. Click on, “Manage SSL Sites”
5. In the box labeled, “Domain” – select the domain and click on, “Auto Fill by Domain”
6. Click on “Install Certificate”

That’s it!  Your site is now ready to use your new certificate.

If you wish, we will do all of this for you except for the confirmation in some cases.  During your certificate purchase, select the SSL Certificate installation option if you would like to take advantage of this.

To have your entire site use your new certificate, create or edit /public_html/.htaccess so that it contains this:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Previously we talked about why you and your site visitors should have a strong preference for secure sites.   Here we will address which certificate you should choose.

It’s all about establishing trust.  The decision is subjective.  Evaluate who your visitors are, why they are at your site and what you want them to do. If your objective is publish a blog while showing people that you respect and value their privacy, the least expensive certificate will do just fine.  If you are trying to sell products worth hundreds of dollars using credit cards, convincing people that your site can be trusted is both more important and more difficult.

It’s worth noting that in more advanced hosting setups, using a certificate will make a site load faster. There is a relatively new protocol which requires a secure connection, SPDY – pronounced “speedy”. It can improve page load times by as much as 30%. Also, Google rewards secure sites with slightly higher page rankings.

Be aware that attitudes are changing.  Frequent news about the latest hacked site or company is gradually making people more cautious.

There are 2 important visual cues to your site visitor that they are at a secure site: a site seal and a green address bar.  Also, in Google Chrome you may see a green padlock.  Other browsers generally give some indication you are at a secure site, but it’s less obvious.

Site Seals

Virtually all certificate purchases include a site seal to display on your web site.

The more recognizable the seal, the more it will engender some degree of trust. But you need to weigh this against cost. The Norton / Symantic seal comes with certificates which cost $500 and more.  The Comodo Positive SSL seal comes with a $9 certificate.

The Green Bar

If you go to Deerfield Hosting, you will notice that the company name is written in the address bar in green.  Deerfield Hosting uses an extended validation certificate.   The certificate authority (CA) took additional steps to verify the identity of Deerfield Hosting, Inc.  They are willing to be held accountable for certifying that deerfieldhosting.com is run by Deerfield Hosting, Inc. up to a liability limit of $500,000.  The liability limit for the certificate on this site is $10,000.    All the CA did before issuing the certificate used here is make sure that the domain name registration is controlled by the same people who were trying to buy the certificate.

Attributes of authority signed SSL certificates

1. Validation – How the CA checked up on the company or individual who ordered the certificate.
   • Domain Validated – verify that the domain is owned by the person or entity ordering the certificate
   • Organization Validation – verify domain ownership and that supplied company information is accurate (but no green bar)
   • Extended Validation – verify domain ownership and that supplied company information is accurate

   The benefit of extended validation is the company name in green in the address bar, signaling that the identity has been more rigorously established.

2. Number of Domain Names – The certificate may work for one site or more than one.
   • Single site: generally example.com and www.example.com, but might be others like store.example.com
   • Wildcard: a single certificate which works with sub-domains of a single domain. For example, blog.example.com, store.example.com, www.example.com
   • Multiple Domains: a single certificate which works with domains which (in general) have the same ownership. For example, deerfieldhosting.com and deerfieldhosting.net
3. Warranty – CA liability limit. Ranges from none to $1.75 Million.  Note that this is NOT in any sense insurance.  Many sources imply or incorrectly state that it is.

Anyone can create a certificate and self sign it.  This will work fine for encryption, but web browsers will pop up a warning to let you know that no identity validation is in place.  When a site does not need to provide identity assurance because no visitors are total strangers, a self signed certificate is adequate.  On the other hand, few people fully understand the warning.  Not having to bother with explanations may be worth the low cost of a basic certificate.

The encryption provided by any brand or type of certificate is as good as any other brand or type.  While it is possible to generate a too weak certificate, no vendor will provide you with a certificate which is too weak.

In modern browsers, the certificate is only used to establish identity and begin a secure session.  The browser and the server together decide how to go about encrypting the session and then generate new keys to use it.  At this point the work of the certificate is complete and it’s no longer a part of the encryption process. What we are talking about is called perfect forward secrecy. Every session getting encrypted separately.  This is up to the browser and the web server configuration, not the certificate.

As an aside, you can test the safety of supposedly secure sites at SSL Labs. You may be surprised as I was to discover that your online banking pages get low marks.  Until I complained, my bank was getting an F.

 Recommendations

• Selling products and taking credit cards – Get the green bar with an extended validation certificate.  Your visitor to customer conversion rate will justify this unless your volume is very low.
• Selling products using Paypal – If you can afford it, get the green bar.  It will improve sales on most sites more than enough to pay for itself.
• Multiple Domains or Sub Domains – Do the math.  Break even on cost with a wildcard certificate is about 10 sub domains.
• Warranty – This is only relevant if money is changing hands or the site relates to that in important ways.  Organization validated certificates get you a better warranty, but for slightly more money you get the green bar.
• Informational or Promotional Sites– Showing your visitors that you respect their privacy and getting the rankings boost is almost certainly worth the cost of a basic certificate

Most people have no idea that their personal information is being leaked all over the place when they use the Internet.  If your initial reaction is that you don’t care because you have nothing to hide, it’s time to re-evaluate that position.  Someone who gets possession of your personal information can ruin your reputation and steal your identity.  If you don’t want to live through that nightmare, you need to take steps to avoid it.  More is leaking than you know and and more can be done with it than you think.

It’s not just criminals that should be a concern.  For example, Verizon engages in some questionable practices and is far from alone.

Do you have “block third party cookies” turned on in you browser? If not, turn it on! Are you using a browser not capable of that?  Stop using it!

It should be abundantly clear by now that it’s not a good idea to blindly trust the security provided by most companies.  It seems that every week there are revelations about a new security breach, costing the loss of personal information from thousands and sometimes millions of people.

Bigness does not in any way imply a company is on top of security.  It’s more likely to mean the opposite because as size increases, security becomes more complex.  Neither is it reasonable to assume that companies which would suffer huge losses from a security breach are on top of it.  It’s a moving target and staying on top if it is difficult.

Some months ago I tested the banking online pages at my bank.  They got an F.  This is one of the largest banks in the United States and they got an F.  When I called them, they arrogantly and vehemently denied any problem.  3 days later I tested them again and they got an A.  Obviously, someone had to wake them up.

Testing sites you use which need to be secure can be done at: SSL Labs.  You will be surprised at the vulnerabilities in common sites.  Try www.walmart.com at that site.

The things to think about are:

1. Authentication – Is who I am talking to the same as who I think I am talking to?  This was the problem at my bank.  The site was open to impersonation with a vulnerability called cross site scripting.
2. Data Integrity – Is what I am seeing correct?  Has it been tampered with?  When I submit information in a form, is the same information being recorded at the other end?
3. Encryption – Can anyone eavesdrop on the conversation?

This is expanded upon in a video from Google:

 

One big take way from that is that the problem is not the leakage of specific information.  It’s the leakage of patterns of behavior.  That may seem ephemeral, but coupled with tiny bits of specific information it can turn you into a ripe target.  As the general public becomes more aware, preference for sites using https is increasing.  This is a good thing.

Last August, Google announced that sites using encryption would get a boost in search rankings in a blog post titled HTTPS as a Ranking Signal.  Anyone running a web site should be running a secured site.  The tiny expense is well worth the benefits.

We are responsible for more than 30,000 user logins on computers which had been susceptible to the Heartbleed bug.  As you may imagine, that means we have been watching very carefully for signs of trouble.  So far, we have found no evidence of any compromise.  What this does not mean is that complacency is acceptable.

Media reports have in some cases flatly stated that this bug allows an attacker to compromise any server with the bug.  That is, to gain access to the server at the administrator level.  This is almost total nonsense.  As you will see from what follows, the problem is entirely limited to data flows.  It’s true that if an administrator happened to log in while an attacker was running an exploit, there is a slight chance that his login name and password were captured.  On our systems I can say unequivocally that this never happened.  We use a two factor encryption system.   The second part was exposed to the bug, but the first part was never in jeopardy.

As an aside, this bug has created a much needed uproar in the security community.   I checked the online banking system I use.  I found that while it was never susceptible to the heartbleed bug, it was susceptible to man in the middle attacks.  That is nearly as serious!  I suggest you check and complain at any secure sites you need to use.  Here is a way to check:

Website Security Test

Just put the subject website name in the box.

Very few of our users have followed our advice and changed their passwords.  If you are one of them, please do so.  It’s true that media reports have been overblown and the probability that your account has been affected is low.  None the less, this is NOT something to ignore.

We have more information now about this bug, how it works, what it would take to compromise a server and what it would take to compromise any individual account.  It’s not nearly as bad as first reported. 

It’s a buffer overflow vulnerability.  When a program starts up, it allocates memory to hold what it needs to do its work.  In the case of openssl (the program with the bug) as it services requests it allocates and frees memory to temporarily hold the information flowing in and out.  When a request has completed, the pointer to this memory is discarded.  The problem is that whatever was in that area is still there.  The bug allows an attacker to request and get what was left over from the last request which used that memory area.

Memory is allocated on what’s called the heap, from the bottom up.  When openssl starts up, the first thing it does is load public and private keys into the heap.  This means the private keys are in the lowest part of memory.  Following is a diagram of subsequent memory allocations:

The client machine is allowed to check with the server periodically to see if the encrypted connection is still intact.  This is called a heartbeat.  The client sends the server a test packet and the server sends it back as verification.  The bug is that the server fails to sanity check the packet size which is provided in the first few bytes of the request, “length” in the diagram.  It returns a memory area as large as whatever the client put there.  If it’s bigger than what was sent, material left over from the last request is sent.  If that happens to contain something sensitive, we have a serious problem.

Initially it was reported that the attacker could gain access to the keys to the kingdom, the server private encryption keys.  Security experts, with an abundance of caution, are unwilling to flatly state that it is impossible for an attacker to get these keys, but that appears to be the case.  The keys are located in the lowest portion of memory which is never freed and reused.  Using an assortment of scenarios, literally hundreds of millions of attempts have been made to get the keys.  None has yet succeeded.

UPDATE: Although the process is difficult, it has now been proven that it was possible to obtain the server keys.

Again, the likelihood that your passwords have been compromised by this particular bug is very low.  Our servers were updated and new security certificates issued within 3 hours of the announcement. 

However, recent security studies have been done on the source of the bot net (robot network) problem.   A bot net is a group of compromised computers being controlled remotely by someone other than the owner.  They are used in concert or individually to attack other computers.  The studies have provided good evidence that about 37% of computers connected to the Internet with broadband connections are participating in bot net activity.  This means there is roughly a 1 in 3 chance that your computer is one of them.  If it is, you can bet your passwords are out there.  If you have been complacent about security, you really need to check for this.