The system we use for billing, support and client management had a major upgrade about a week ago, including an overhaul of the interface, with a very fresh new look. We've been waiting for this upgrade, to get it in place and make any adjustments necessary (reinstalling any customizations, etc), before wrapping our own new websites' design around it.
Things may look a little different as this process is completed, though the Client Portal should be completely functional. Please bear with us, as the shoemakers' children are finally getting some long overdue new shoes!
Monday, December 12, 2011
Wednesday, October 26, 2011
SSL Security and the BEAST
SSL has been in the news a lot lately. In fact it's become the Paris Hilton of the IT security world. There are two different security issues currently in the news, with some overlap between the two because they both involve the SSL protocol. There have been many sensationalized headlines, and some of the news articles are misleading at best.
I find a lot of articles dealing with Internet security don't do much more than attempt to scare the pants off the average user, without either explaining the true risks in plain English, and/or what the average user can do to prevent, avoid or mitigate the risks...which is what I'll attempt to do here.
SSL is a process of data encryption that works between your browser and the web server you're connecting to (either by viewing a secure web page or imputing personal information via a web form), encrypting the data as it travels across the Internet, so anyone who has the ability to access it wouldn't be able to read it. Here's an example of what one type of encrypted data (also known as "unreadable gibberish"), looks like:
Here's a good easy-to-read primer ("easy-to-read" and "cryptography" are rarely used in the same sentence!) on how encryption works, if you'd like to learn more.
To Website Owners: It needs to be stressed that these vulnerabilities are not in the SSL certificate itself, but in the way a particular server (where your website resides) is configured. At the end of this article there will be links to online tools so you can test your website to find out if you could be at risk.
On Oct. 25th a major news network reported a group of hackers known as The Hacker's Choice (THC) had just released a new DDoS tool capable of attacking and overloading SSL servers with ease, from a single computer. While the threat of a DDoS attack is hardly new (in fact any website online is susceptible to a DDoS attack), this type of attack has always required a network of computers (typically zombied - or infected) and loads of bandwidth. This tool makes it possible for a lone hacker on a standard DSL connection to launch an attack from a single laptop.
Many IT Security experts are calling this an overhyped threat, mainly because THCs' tool - in part - relies on SSL Renegotiation being enabled on the server, which any server admin who takes security seriously should have disabled two years ago when that vulnerability was first released.
Most security-minded web hosts' servers also have a firewall configured to ward off such an attack, though even major providers can fall victim if the attack is large enough. This is yet another reason to host your website with a company who takes security seriously. Any hosting company running a considerably out-dated version of Apache (or other core software) and no firewall doesn't meet that criteria. SSL Renegotiation is a real threat, and later in this article I'll tell you how to check to see if your website is at risk.
BEAST, which stands for "Browser Exploit Against SSL/TLS", exploits a weakness in the SSL protocol to decrypt secret cookies that are stored on your computer. The potential threat from a BEAST attack is being hotly debated in the IT Security industry, since it targets a long-documented vulnerability in some encryption algorithms that researchers have long believed were impractical to exploit. Or as one commenter on an article stated,
Which is not to say the threat shouldn't be taken seriously.
BEAST is a "proof of concept", which means it's been demonstrated to work but hasn't - as of this writing - been used for malicious means. Its' developers chose PayPal as their test target, citing "We chose PayPal because they do everything right when it comes to server-side SSL, and that is good to demonstrate the power of BEAST, which is a client-side SSL attack."
"Client-side" refers to your browser and your computer.
It's a type of man-in-the-middle attack, and it relies on a scenario that while possible, is unlikely. The attacker, who needs to be on the same network as the victim in order to gain any sort of access, decrypts SSL-protected Internet traffic by using Javascript to inject plain text code into the encrypted stream. The injection can be done through a malicious advertisement, an iFrame or malware which the user could pick up from visiting an infected web page.
The BEAST tool is purported to allow an attacker to intercept from the victims' computer TLS (secure) cookies, bits of text that identify users. TLS cookies are frequently used by websites to keep users logged in even after the user has closed the browser tab or window. In a variation of a "man in the middle" attack, the data (such as login details) is decrypted then changed by the attacker, re-encrypted then sent back to the victims' browser, which is tricked into sending the changed data to the server.
While this is a "client-side" attack, it relies on the SSL-enabled server having certain settings. BEAST attacks algorithms on the server that use a mode known as cipher block chaining (CBC), in which information from a previously encrypted block of data is used to encode the next block. AES and DES, two strong cryptographic algorithms used to secure network and Web traffic, both use CBC. The RC4 cipher does not.
George Notaras cites "The problem lies in the way that block ciphers are used in SSL/TLS. Block ciphers are generally operated in one of several modes that define how encrypted blocks are manipulated to ensure complete confidentiality. Cipher Block Chaining, or CBC mode, is used in SSL for all block ciphers, including AES and Triple-DES. The BEAST attack relies on a weakness in the way CBC mode is used in SSL and TLS. Non-CBC cipher suites, such as those using the RC4 stream encryption algorithm, are not vulnerable.
There have been several suggested mitigations that can be put into play from the perspective of the client, such as reorganizing the way the data is sent in the encrypted stream. Servers can protect themselves by requiring a non-CBC cipher suite. One such cipher suite is rc4-sha, which is widely supported by clients and servers."
On the server-side, RC4 ciphers are not vulnerable.
For both server-side and client-side, TLS versions 1.1 and 1.2 are not vulnerable.
SSL3.0 and TLS1.0 are the latest encryption versions that modern browsers and websites use. Browsers won't/don't upgrade their encryption because websites don't use TLS version 1.1 or 1.2, and websites (servers) don't use it because no browsers support it. It's a wake-up call for the industry, but changes like this rarely happen quickly. In the words of PhoneFactor upgrading the entire web to use TLS 1.1 or 1.2 would be a "massive" undertaking. Researchers have found that upgrading TLS is proving surprisingly difficult, mostly because almost every fix breaks widely used applications or technologies.
At one point Firefox developers recently considered disabling Java as a way of mitigating the risks (note that Java in NOT the same thing as Javascript, though Java applets are used to facilitate the attack), or at the very least recommending users "soft-block" Java (disabling the plugin, then only re-enabling it when needed by a website).
For the Web Hosting Company and/or Server Admin, the only REASONABLE and immediate work-around is to require RC4 ciphers.
Enter your domain name (click "Do not show the results on the boards" if you don't want your results made public), and several tests will be run on the server where your website is hosted. As the scores explain, the letter grade is more important than the individual test scores, assuming all scores are above 80 and green. PLEASE NOTE: Your hosting server can get an "A" and still be vulnerable to the BEAST attack.
The summary at the top of the page shows your websites' score in 4 tests:
Certificate is for the actual SSL certificate you've purchased.
Protocol Support, Key Exchange and Cipher Strength all have to do with how the server is set up, and only a Server Admin can correct any existing issues.
If this test shows your websites' server is vulnerable to the BEAST attack, I suggest contacting your hosting support and asking them to fix the issue. This test will also show whether weak ciphers are allowed (they shouldn't be, you'll see text in orange or red if weak ciphers are allowed) and confirm whether the server has SSL Renegotiation enabled (if you see green text for that test, you're safe). Use the publicly listed test results from other servers to compare between what your results are and what they should be. Again, talk to your hosting support if you have concerns.
I find a lot of articles dealing with Internet security don't do much more than attempt to scare the pants off the average user, without either explaining the true risks in plain English, and/or what the average user can do to prevent, avoid or mitigate the risks...which is what I'll attempt to do here.
What Is SSL?
SSL is a process of data encryption that works between your browser and the web server you're connecting to (either by viewing a secure web page or imputing personal information via a web form), encrypting the data as it travels across the Internet, so anyone who has the ability to access it wouldn't be able to read it. Here's an example of what one type of encrypted data (also known as "unreadable gibberish"), looks like:
Here's a good easy-to-read primer ("easy-to-read" and "cryptography" are rarely used in the same sentence!) on how encryption works, if you'd like to learn more.
To Website Owners: It needs to be stressed that these vulnerabilities are not in the SSL certificate itself, but in the way a particular server (where your website resides) is configured. At the end of this article there will be links to online tools so you can test your website to find out if you could be at risk.
THC DDoS Tool: A Threat To Websites and Servers
On Oct. 25th a major news network reported a group of hackers known as The Hacker's Choice (THC) had just released a new DDoS tool capable of attacking and overloading SSL servers with ease, from a single computer. While the threat of a DDoS attack is hardly new (in fact any website online is susceptible to a DDoS attack), this type of attack has always required a network of computers (typically zombied - or infected) and loads of bandwidth. This tool makes it possible for a lone hacker on a standard DSL connection to launch an attack from a single laptop.
According to the THC website
"Establishing a secure SSL connection requires 15x more processing power on the server than on the client. THC-SSL-DOS exploits this asymmetric property by overloading the server and knocking it off the Internet."
Many IT Security experts are calling this an overhyped threat, mainly because THCs' tool - in part - relies on SSL Renegotiation being enabled on the server, which any server admin who takes security seriously should have disabled two years ago when that vulnerability was first released.
Most HTTPS sites already have SSL Renegotation turned off, so they aren't vulnerable. Apache 2.2.14, IIS 7.0, and OpenSSL 0.9.8l and earlier all shipped with SSL Renegotiation enabled by default, making them potential targets. If the server is running more recent versions, SSL Renegotiation is disabled by default.
Most security-minded web hosts' servers also have a firewall configured to ward off such an attack, though even major providers can fall victim if the attack is large enough. This is yet another reason to host your website with a company who takes security seriously. Any hosting company running a considerably out-dated version of Apache (or other core software) and no firewall doesn't meet that criteria. SSL Renegotiation is a real threat, and later in this article I'll tell you how to check to see if your website is at risk.
BEAST: A Threat To Users, Websites and Servers
BEAST, which stands for "Browser Exploit Against SSL/TLS", exploits a weakness in the SSL protocol to decrypt secret cookies that are stored on your computer. The potential threat from a BEAST attack is being hotly debated in the IT Security industry, since it targets a long-documented vulnerability in some encryption algorithms that researchers have long believed were impractical to exploit. Or as one commenter on an article stated,
"This is a ridiculous amount of hype for a vulnerability that has been known for almost a decade."
Which is not to say the threat shouldn't be taken seriously.
BEAST is a "proof of concept", which means it's been demonstrated to work but hasn't - as of this writing - been used for malicious means. Its' developers chose PayPal as their test target, citing "We chose PayPal because they do everything right when it comes to server-side SSL, and that is good to demonstrate the power of BEAST, which is a client-side SSL attack."
"Client-side" refers to your browser and your computer.
It's a type of man-in-the-middle attack, and it relies on a scenario that while possible, is unlikely. The attacker, who needs to be on the same network as the victim in order to gain any sort of access, decrypts SSL-protected Internet traffic by using Javascript to inject plain text code into the encrypted stream. The injection can be done through a malicious advertisement, an iFrame or malware which the user could pick up from visiting an infected web page.
The BEAST tool is purported to allow an attacker to intercept from the victims' computer TLS (secure) cookies, bits of text that identify users. TLS cookies are frequently used by websites to keep users logged in even after the user has closed the browser tab or window. In a variation of a "man in the middle" attack, the data (such as login details) is decrypted then changed by the attacker, re-encrypted then sent back to the victims' browser, which is tricked into sending the changed data to the server.
The Sky Is Falling! The Sky Is Falling!...Or Maybe Not...
Quoting Patrick Lane of Comptia:
So why shouldn't you immediately panic? Well, the attack is difficult to carry out. For starters, the hacker must be on the same network as the victim, such as a broadband wireless network, to capture packets. Once packets have been captured, it takes approximately 10 minutes to decrypt the data.
While this is a "client-side" attack, it relies on the SSL-enabled server having certain settings. BEAST attacks algorithms on the server that use a mode known as cipher block chaining (CBC), in which information from a previously encrypted block of data is used to encode the next block. AES and DES, two strong cryptographic algorithms used to secure network and Web traffic, both use CBC. The RC4 cipher does not.
George Notaras cites "The problem lies in the way that block ciphers are used in SSL/TLS. Block ciphers are generally operated in one of several modes that define how encrypted blocks are manipulated to ensure complete confidentiality. Cipher Block Chaining, or CBC mode, is used in SSL for all block ciphers, including AES and Triple-DES. The BEAST attack relies on a weakness in the way CBC mode is used in SSL and TLS. Non-CBC cipher suites, such as those using the RC4 stream encryption algorithm, are not vulnerable.
There have been several suggested mitigations that can be put into play from the perspective of the client, such as reorganizing the way the data is sent in the encrypted stream. Servers can protect themselves by requiring a non-CBC cipher suite. One such cipher suite is rc4-sha, which is widely supported by clients and servers."
On the server-side, RC4 ciphers are not vulnerable.
For both server-side and client-side, TLS versions 1.1 and 1.2 are not vulnerable.
"So why don't all servers just require RC4 ciphers? Why don't websites and browsers upgrade to TLS1.1 and TLS1.2, which aren't vulnerable? Why hasn't this been fixed? Why don't you guys do something?"
The Chicken And The Egg
SSL3.0 and TLS1.0 are the latest encryption versions that modern browsers and websites use. Browsers won't/don't upgrade their encryption because websites don't use TLS version 1.1 or 1.2, and websites (servers) don't use it because no browsers support it. It's a wake-up call for the industry, but changes like this rarely happen quickly. In the words of PhoneFactor upgrading the entire web to use TLS 1.1 or 1.2 would be a "massive" undertaking. Researchers have found that upgrading TLS is proving surprisingly difficult, mostly because almost every fix breaks widely used applications or technologies.
At one point Firefox developers recently considered disabling Java as a way of mitigating the risks (note that Java in NOT the same thing as Javascript, though Java applets are used to facilitate the attack), or at the very least recommending users "soft-block" Java (disabling the plugin, then only re-enabling it when needed by a website).
Be aware that running older versions of Java makes you particularly vulnerable to this and other types of attacks. Always run the most current version of Java. Instructions for checking and upgrading are at the end of this article.
For the Web Hosting Company and/or Server Admin, the only REASONABLE and immediate work-around is to require RC4 ciphers.
What You Can Do AS A USER:
- Keep Your Browser Up-To-Date. Security patches are released for a reason. This also means not continuing to use an old, unsupported version of any browser, such as Firefox3 or Internet Explorer6.
- Upgrade Java. You can configure Java to automatically check for updates, or you can use this online tool to check your Java version.
Keeping old and unsupported versions of Java on your system presents a serious security risk. Java recommends uninstalling previous versions. We recommend using JavaRa, a free and very light-weight program. JavaRa is a simple tool that does a simple job: it removes old and redundant versions of the Java Runtime Environment (JRE).
Java Critical Updates and Security Alerts
RSS Feed For Java Critical Updates and Security Alerts
Java Public Vulnerability Advisory - Always Use Anti-Virus and Security Software. A good anti-virus (set to update it's definitions daily), anti-malware, trojan detection, and a firewall can save you from a large percentage of Internet threats. While anti-virus won't protect you from the attacks specified in this article, I always include it as a recommendation. It's something that should be a given, but I find a surprising number of users don't have any anti-virus installed.
- Secure Your Wireless Network. If hackers can't access your network, they can't capture your local traffic. Never use a public network, such as a free WiFi hotspot (AT&T, Starbucks) for any secure transactions unless scripting is disabled.
- [Optional] Disable Scripting In Your Browser. You can disable both Javascript and the Java in your browser. Beware: if you decide to disable Javascript, be ready for a seriously degraded Internet experience. You'll be surfing like it's 1999...
If you use Firefox install the NoScript extension, which allows you to set what sites are allowed to execute Javascript code. By only allowing the sites that are trusted, the potentially malicious code can be prevented from being installed on workstations.
Why did I mark this as optional?
Javascript is used extensively on the Internet, with an average os 15-20 different scripts (or content being imported from other sites using Javascript) on a page. Be prepared to spend a LOT of time going through the list of blocked sites and enabling. For those who have a computer with Vista on it, NoScript is much like that. Every time you try to do something, you need to enable a page.
Some blogs run as many as 36-72 scripts. You can click "Allow all this page" (you'll need to do this twice, as the extension allows the currently running scripts then refreshes the page, and typically new scripts are loaded into the page, which in turn have to be enabled/allowed), assuming you trust the website of the page you're on....but again, that brings us back to where we started. How will you know if the content from all the listed domains can be trusted? And unlike a missing multimedia plugin, you won't know what elements of a site you're missing.
Your mileage may vary, but I disabled NoScript after a day. Interesting that the blog article that recommends disabling Javascript as a mitigating measure is using blogging software that runs 36 different scripts.
What You Can Do AS A WEBSITE OWNER:
- Check Your Server To See If It's Vulnerable. It's simple and quick using the Qualys SSL Labs Server Test.
Enter your domain name (click "Do not show the results on the boards" if you don't want your results made public), and several tests will be run on the server where your website is hosted. As the scores explain, the letter grade is more important than the individual test scores, assuming all scores are above 80 and green. PLEASE NOTE: Your hosting server can get an "A" and still be vulnerable to the BEAST attack.
The summary at the top of the page shows your websites' score in 4 tests:
Certificate is for the actual SSL certificate you've purchased.
Protocol Support, Key Exchange and Cipher Strength all have to do with how the server is set up, and only a Server Admin can correct any existing issues.
If this test shows your websites' server is vulnerable to the BEAST attack, I suggest contacting your hosting support and asking them to fix the issue. This test will also show whether weak ciphers are allowed (they shouldn't be, you'll see text in orange or red if weak ciphers are allowed) and confirm whether the server has SSL Renegotiation enabled (if you see green text for that test, you're safe). Use the publicly listed test results from other servers to compare between what your results are and what they should be. Again, talk to your hosting support if you have concerns.
The sky isn't falling today...but it could tomorrow. Internet security isn't a destination, it's an ongoing and ever-changing process.
~ Mara Alexander
Hello World Web Design and Hosting
Tuesday, October 18, 2011
PayPal Subscriptions, Demystified
PayPal doesn't make it easy to see if you have a subscription set up with a company (like us!), and on top of that they've changed their interface and moved where you used to be able to find your subscriptions listed.
Since we've recently had a few instances of clients duplicating monthly payments by making a manual payment when there was already an automatic subscription in place (and I can't tell you how many times I've also done that very thing), a guide on how to find if you have an active PayPal subscription for us or anyone else seemed in order.
Log in to your PayPal account.
Click History.
Click the little down arrow next to More filters. You may need to adjust the dates shown (at the top) if it's not an active (current) subscription.
Choose Subscriptions and agreements from the drop-down menu.
Click Subscriptions in the sub-menu.
You can then view the details of a specific Subscription Creation by clicking Details in the Details column.
This page shows detailed information regarding your Subscription and Recurring Payments. On this page, you may change the funding source*, cancel your Subscription, or just verify it's active and the date it will be paid.
We've also added a section into our Hosting "Welcome" email, so you can make a note for your own records if you pay your hosting bill manually or by subscription.
We're happy to resend your welcome email upon request. If fact if you've been with us for many years (as most of our clients have been), it's not a bad idea to get a new copy, as we've recently combined the "Contact and Support Matrix" into the welcome email, as well as made other changes over the years.
If you pay by PayPal eCheck, please remember to set the subscription start date for 3-4 days prior to your due date, since eChecks take 3-4 days to clear, and your payment isn't considered by our billing system as "paid" until the funds are actually received. You know how picky bean counters are...
*If you want to change the credit card PayPal uses, add the new one first, then remove the old one. Otherwise any subscriptions that were set to be paid using the old credit card as a funding source will be canceled, and you'll need to recreate them.
If you happen to forget and make a duplicate payment to us, your account will show it as a credit (under "Account Statistics" when you first login to the Client Portal). We can apply it to another service, apply it to your next payment (which means you'd need to delete the subscription in PayPal and then remember to recreate it the following month), or issue a refund upon request.
Since we've recently had a few instances of clients duplicating monthly payments by making a manual payment when there was already an automatic subscription in place (and I can't tell you how many times I've also done that very thing), a guide on how to find if you have an active PayPal subscription for us or anyone else seemed in order.
Log in to your PayPal account.
Click History.
Click the little down arrow next to More filters. You may need to adjust the dates shown (at the top) if it's not an active (current) subscription.
Choose Subscriptions and agreements from the drop-down menu.
Click Subscriptions in the sub-menu.
You can then view the details of a specific Subscription Creation by clicking Details in the Details column.
This page shows detailed information regarding your Subscription and Recurring Payments. On this page, you may change the funding source*, cancel your Subscription, or just verify it's active and the date it will be paid.
We've also added a section into our Hosting "Welcome" email, so you can make a note for your own records if you pay your hosting bill manually or by subscription.
We're happy to resend your welcome email upon request. If fact if you've been with us for many years (as most of our clients have been), it's not a bad idea to get a new copy, as we've recently combined the "Contact and Support Matrix" into the welcome email, as well as made other changes over the years.
This will also be added to the FAQs (under Billing Procedures) for easier future referencing.
If you pay by PayPal eCheck, please remember to set the subscription start date for 3-4 days prior to your due date, since eChecks take 3-4 days to clear, and your payment isn't considered by our billing system as "paid" until the funds are actually received. You know how picky bean counters are...
*If you want to change the credit card PayPal uses, add the new one first, then remove the old one. Otherwise any subscriptions that were set to be paid using the old credit card as a funding source will be canceled, and you'll need to recreate them.
If you happen to forget and make a duplicate payment to us, your account will show it as a credit (under "Account Statistics" when you first login to the Client Portal). We can apply it to another service, apply it to your next payment (which means you'd need to delete the subscription in PayPal and then remember to recreate it the following month), or issue a refund upon request.
Thursday, October 6, 2011
Installatron Has A New Feature
The missing Installatron icon has been restored, and the new version of Installatron comes with a nifty new feature! They now have their own section in cPanel, titled "Installatron Web Applications", right underneath the "Software/Services" section.
This section displays any scripts you have installed through Installatron as well as some other, featured scripts available.
We hope you enjoy this new feature!
This section displays any scripts you have installed through Installatron as well as some other, featured scripts available.
We hope you enjoy this new feature!
Wednesday, October 5, 2011
Installatron Icon Missing
We're experiencing a minor issue with Installatron, after upgrading to their latest version, which included some new features. Installatron is still functional, but the icon is missing in cPanel. Where the icon should be (in the "Software/Services" section) you'll see the text link to Installatron.
Installatron support is working on this issue, hopefully it will be fixed today.
Installatron support is working on this issue, hopefully it will be fixed today.
Friday, September 23, 2011
Hello, New Auto-Installers!
Last December we reported that the Fantastico Auto-Installer would be phased out in favor of Installatron. While researching Auto-Installers (to make sure we give you the best one available) we also found Softaculous. Both Installatron and Softaculous were quietly added to your cPanel Software/Services section in February while we tested both in their installing capabilities, customer service, the variety of their scripts and so on.
You'll find both icons in the "Software/Services" section of your cPanel (at the very bottom, unless you've re-ordered the sections):
After offering Fantastico since 2005...
Fantastico took f-o-r-e-v-e-r to release new scripts, and was especially lagging in releasing new versions of scripts. When you're dealing with scripts such as WordPress, when updates should be available and applied within a matter of hours, a delay of weeks to sometimes months (Fantastico typically would release new scripts along with updated scripts in "batches", saving the updated scripts for the next batch of 5-10).
Fantasticos' admins maintained that they offer an auto-installer, not an auto-updater, and they do have a point. The problem is both that when a user installs something a certain way they expect to be able to update it in the same manner; and also that Fantastico would often make changes to a script (in order to install it through their auto-installer) that made it incompatible with using that scripts' own internal updater. All of this led to many outdated scripts in many hosting accounts, and many web hosts stopped offering Fantastico because of the security risks involved.
Installatron and Softaculous are a new breed.
Some key features of both, which we found impressive:
Just how many scripts are available?
It depends on which hosting plan you have. We painstakingly matched the scripts to each hosting plans' disk space and target user. We tried to chose some scripts from each applicable category, though obviously the eCommerce scripts will be exclusively for the Quasar (eCommerce) plan (our reseller plan, Omega, has all scripts available so they can provide them to their own customers).
Ceres (designed for very small businesses or personal sites) 61 scripts
Pegasus (designed for medium-sized businesses or small forums) 107 scripts
Orion (designed for businesses or active forums) 145 scripts
Voyager (designed with developers in mind) 200 scripts
Quasar (our eCommerce plan) 220 scripts
Omega (our Reseller plan) 220 scripts
So which auto-installer should you use?
Each has their own strengths and weaknesses, and each carries different scripts. I'll be honest, Installatron has come across as the stronger product and company overall, though Softaculous has been responsive to suggestions and issues we've had.
It was only in the past week that Softaculous offered a way for us hosts to offer certain scripts to certain hosting plans, commonly called an Access Control List...something that Fantastico has had for years and every other auto-installer has built-in from day one. Waiting for them to enable the ACL was why this official announcement was delayed until now. I've also personally noticed during testing a few issues with the installation process of some scripts (i.e.- scripts failed to install), as well as demos on their site not working, a lot of spam in the support forum, etc. The last thing we at Hello World Web need to do is offer something to our hosting clients that will only create more support requests for us and frustration for our users.
To their credit, the Softaculous admins do seem to be right on top of correcting these issues as fast as they can, and as long as there's positive moment on that front, we will continue to offer Softaculous as an auto-installer to our clients. What Softaculous has to offer over Installatron is a boat-load more scripts. While Installatron thoroughly and carefully tests each script they offer, Softaculous seems to "fast-track" new scripts (may be good, may be bad, it just depends on the script).
It will be a personal decision for you on which installer you prefer, as they each have very different interfaces with different options and information on the various scripts they offer. As it stands right now, if both installers carry the same script, preference will be given to Installatron.
Sometime it takes more than one-click to get it right.
One thing to note: You may see Softaculous (or another Auto-Installer, for that matter) bragging that they offer "one-click installs", as if that's a good thing. It's not always. The "clicks" that a user needs to do to install a script typically involve choices. The less clicks, the fewer choices or decisions you get to make about your install, which is not always a good thing. Your mileage may vary. While Installatron installs involve more clicks, they lead you through each screen and provide plenty of information-in-plain-English (as opposed to that geek-gobbledegook) so you can make sensible choices.
You may also notice we don't carry every script each of the auto-installers offer. Any script that is found to be abandonware, have known security issues, or lack any sort of user support we will not be offering. Be sure to check our FAQ on Application Auto-Installers for information on both auto-installers and a list of scripts we won't carry (and why). There will soon be a complete list on our website, listing every script available to each hosting plan.
Take our new Auto-Installers for a spin!
Enjoy yourself, poke around, and see what's available. Please be aware, however, that though we'll certainly help you when we can, we did not author/develop these scripts and can not offer support for them. During each script install you'll be given a link to that scripts' support forum. Please make note of it. If you find your script requires special server settings, we're happy to make those changes for you if it doesn't compromise security.
We're pleased to announce that we've decided to offer BOTH Auto-Installers and are included in all our shared hosting plans at no additional charge!
You'll find both icons in the "Software/Services" section of your cPanel (at the very bottom, unless you've re-ordered the sections):
After offering Fantastico since 2005...
Fantastico took f-o-r-e-v-e-r to release new scripts, and was especially lagging in releasing new versions of scripts. When you're dealing with scripts such as WordPress, when updates should be available and applied within a matter of hours, a delay of weeks to sometimes months (Fantastico typically would release new scripts along with updated scripts in "batches", saving the updated scripts for the next batch of 5-10).
Fantasticos' admins maintained that they offer an auto-installer, not an auto-updater, and they do have a point. The problem is both that when a user installs something a certain way they expect to be able to update it in the same manner; and also that Fantastico would often make changes to a script (in order to install it through their auto-installer) that made it incompatible with using that scripts' own internal updater. All of this led to many outdated scripts in many hosting accounts, and many web hosts stopped offering Fantastico because of the security risks involved.
Installatron and Softaculous are a new breed.
Some key features of both, which we found impressive:
- Updated scripts are released within hours, a day or two at most.
- When an update to a script you have installed is released, you get an emailed notification.
- Any existing/currently installed script (installed from another installer or manually) can be easily imported into either Installatron or Softaculous for ease of future management.
- Each carry an enormous catalog of available scripts in every category you can think of (and at least a few I'll bet you can't!):
Blogs, micro blogs, social networking, image galleries, polls and surveys, wikis, CMS and portals, forums, eCommerce, customer service, accounting, calendars, gaming, mailing lists, and many, MANY more! - Each is very responsive to our support requests.
Just how many scripts are available?
It depends on which hosting plan you have. We painstakingly matched the scripts to each hosting plans' disk space and target user. We tried to chose some scripts from each applicable category, though obviously the eCommerce scripts will be exclusively for the Quasar (eCommerce) plan (our reseller plan, Omega, has all scripts available so they can provide them to their own customers).
Ceres (designed for very small businesses or personal sites) 61 scripts
Pegasus (designed for medium-sized businesses or small forums) 107 scripts
Orion (designed for businesses or active forums) 145 scripts
Voyager (designed with developers in mind) 200 scripts
Quasar (our eCommerce plan) 220 scripts
Omega (our Reseller plan) 220 scripts
So which auto-installer should you use?
Each has their own strengths and weaknesses, and each carries different scripts. I'll be honest, Installatron has come across as the stronger product and company overall, though Softaculous has been responsive to suggestions and issues we've had.
It was only in the past week that Softaculous offered a way for us hosts to offer certain scripts to certain hosting plans, commonly called an Access Control List...something that Fantastico has had for years and every other auto-installer has built-in from day one. Waiting for them to enable the ACL was why this official announcement was delayed until now. I've also personally noticed during testing a few issues with the installation process of some scripts (i.e.- scripts failed to install), as well as demos on their site not working, a lot of spam in the support forum, etc. The last thing we at Hello World Web need to do is offer something to our hosting clients that will only create more support requests for us and frustration for our users.
To their credit, the Softaculous admins do seem to be right on top of correcting these issues as fast as they can, and as long as there's positive moment on that front, we will continue to offer Softaculous as an auto-installer to our clients. What Softaculous has to offer over Installatron is a boat-load more scripts. While Installatron thoroughly and carefully tests each script they offer, Softaculous seems to "fast-track" new scripts (may be good, may be bad, it just depends on the script).
It will be a personal decision for you on which installer you prefer, as they each have very different interfaces with different options and information on the various scripts they offer. As it stands right now, if both installers carry the same script, preference will be given to Installatron.
Sometime it takes more than one-click to get it right.
One thing to note: You may see Softaculous (or another Auto-Installer, for that matter) bragging that they offer "one-click installs", as if that's a good thing. It's not always. The "clicks" that a user needs to do to install a script typically involve choices. The less clicks, the fewer choices or decisions you get to make about your install, which is not always a good thing. Your mileage may vary. While Installatron installs involve more clicks, they lead you through each screen and provide plenty of information-in-plain-English (as opposed to that geek-gobbledegook) so you can make sensible choices.
You may also notice we don't carry every script each of the auto-installers offer. Any script that is found to be abandonware, have known security issues, or lack any sort of user support we will not be offering. Be sure to check our FAQ on Application Auto-Installers for information on both auto-installers and a list of scripts we won't carry (and why). There will soon be a complete list on our website, listing every script available to each hosting plan.
Take our new Auto-Installers for a spin!
Enjoy yourself, poke around, and see what's available. Please be aware, however, that though we'll certainly help you when we can, we did not author/develop these scripts and can not offer support for them. During each script install you'll be given a link to that scripts' support forum. Please make note of it. If you find your script requires special server settings, we're happy to make those changes for you if it doesn't compromise security.
Tuesday, September 20, 2011
Status is up even when the server is down
This afternoon we came across a nasty cPanel bug that caused Apache to fail to restart (while all other services: email, FTP, cPanel were up and continued to function). We were on it within 6 minutes and the issue was resolved within 20 minutes.
But what if you'd tried to access the server within that time? How would you know what was happening??? You're reading it right this moment. Our hosting status blog is hosted off-site and through the magic of secondary (back-up) DNS continues to keep you informed, even in the event of an actual emergency. Or in the event of a whole range of things you might want to know about.
Sometimes in the world of hosting, things happen fast. Issues can be created and fixed before we get a chance to blog about them. That's why there's Twitter. What? Are we asking you to sign up for yet another service, just to stay informed? No way!
Our Tweets are imported into the right-hand sidebar of our status blog, so you still only need to remember one place to check:
But wait, you say...what if I'm playing FarmVille on Facebook, and checking the status page is too much work? Never fear! We've got you covered there, too.
Simply head over to Our Facebook Page (You're a fan, right? RIGHT???) and click on either the News or the Twitter link:
Our blog posts from this very status blog, along with our Twitter statuses imported (there's even a nifty little "follow" button for you to click). If you're wondering why some of our Tweets start with [status] that's to allow anyone using an RSS Reader who may want to only receive our actual status tweets and filter out our otherwise equally high-quality tweets.
Through the magic of the Internet, you can even have the status tweets sent to your phone through SMS. Not like when I was a kid...and we have to carve our tweets on stone tablets, by hand. True story.
If all that isn't enough for you (man, tough crowd!) there are numerous RSS options on the blog (RSS Readers, subscription by email, carrier pigeon) so you can keep up with the latest. We've got lots of exciting new features rolling out in the next month or two, and you won't want to miss any of it!
But what if you'd tried to access the server within that time? How would you know what was happening??? You're reading it right this moment. Our hosting status blog is hosted off-site and through the magic of secondary (back-up) DNS continues to keep you informed, even in the event of an actual emergency. Or in the event of a whole range of things you might want to know about.
Sometimes in the world of hosting, things happen fast. Issues can be created and fixed before we get a chance to blog about them. That's why there's Twitter. What? Are we asking you to sign up for yet another service, just to stay informed? No way!
Our Tweets are imported into the right-hand sidebar of our status blog, so you still only need to remember one place to check:
But wait, you say...what if I'm playing FarmVille on Facebook, and checking the status page is too much work? Never fear! We've got you covered there, too.
Simply head over to Our Facebook Page (You're a fan, right? RIGHT???) and click on either the News or the Twitter link:
Our blog posts from this very status blog, along with our Twitter statuses imported (there's even a nifty little "follow" button for you to click). If you're wondering why some of our Tweets start with [status] that's to allow anyone using an RSS Reader who may want to only receive our actual status tweets and filter out our otherwise equally high-quality tweets.
Through the magic of the Internet, you can even have the status tweets sent to your phone through SMS. Not like when I was a kid...and we have to carve our tweets on stone tablets, by hand. True story.
 |  |
If all that isn't enough for you (man, tough crowd!) there are numerous RSS options on the blog (RSS Readers, subscription by email, carrier pigeon) so you can keep up with the latest. We've got lots of exciting new features rolling out in the next month or two, and you won't want to miss any of it!
Saturday, September 10, 2011
New SSL Certificate for the Apollo Server
A new SSL certificate was installed for all shared hosting and services (mail, FTP) on the Apollo server. Depending on the email client/software you use, you may need to re-accept the certificate for email, and/or also re-accept the certificate in your browser (or create a new exception).
This will need to be done any time a new certificate is installed or renewed (and in this case we changed from using Equifax to using GeoTrust certificates). The hostname will always be the same, only the validity dates change. The big, bad, scary warnings that your browser gives you, claiming "No valid site would ask you to do this" aren't technically true. Millions upon millions of websites use shared hosting.
They write these warnings to scare the crap out of people, because - in general - that's the only way people pay attention. The unfortunate part is these warnings are both overkill and technically untrue...and quite often the user clicks the red "X", closes their browser, unplugs their computer, hides under their desk...then calls me to complain the next day.
This is how shared hosting, and SSL encryption is *supposed* to work.
An SSL certificate can only be given to one hostname and one single IP. A shared hosting server contains many domains/accounts, all using the same IP. The shared hosting servers' SSL certificate that's used by all services (email, FTP, cPanel logins, etc) is assigned to the servers' hostname. Typically when you login to cPanel you use your own domain name, i.e. - yourdomain.com/cpanel (or yourdomain.com:2083).
What your browser (or email client) is alerting you to is that the domain name (our server) on the SSL certificate is different than the domain you're logging into (your domain on our server). That's all. They're trying to alert you in case you're not aware that the names are different. In this case, you *are* aware, and can verify that by viewing the certificate and verifying that the servers' hostname and our name are there on the certificate.
Many "discount hosting companies" use self-signed certificates, but we go the extra mile and provide high quality encryption for you, with a purchased SSL certificate from a recognized vendor (in this case GeoTrust).
If you have any questions about this please feel free to ask.
This will need to be done any time a new certificate is installed or renewed (and in this case we changed from using Equifax to using GeoTrust certificates). The hostname will always be the same, only the validity dates change. The big, bad, scary warnings that your browser gives you, claiming "No valid site would ask you to do this" aren't technically true. Millions upon millions of websites use shared hosting.
They write these warnings to scare the crap out of people, because - in general - that's the only way people pay attention. The unfortunate part is these warnings are both overkill and technically untrue...and quite often the user clicks the red "X", closes their browser, unplugs their computer, hides under their desk...then calls me to complain the next day.
This is how shared hosting, and SSL encryption is *supposed* to work.
An SSL certificate can only be given to one hostname and one single IP. A shared hosting server contains many domains/accounts, all using the same IP. The shared hosting servers' SSL certificate that's used by all services (email, FTP, cPanel logins, etc) is assigned to the servers' hostname. Typically when you login to cPanel you use your own domain name, i.e. - yourdomain.com/cpanel (or yourdomain.com:2083).
What your browser (or email client) is alerting you to is that the domain name (our server) on the SSL certificate is different than the domain you're logging into (your domain on our server). That's all. They're trying to alert you in case you're not aware that the names are different. In this case, you *are* aware, and can verify that by viewing the certificate and verifying that the servers' hostname and our name are there on the certificate.
Many "discount hosting companies" use self-signed certificates, but we go the extra mile and provide high quality encryption for you, with a purchased SSL certificate from a recognized vendor (in this case GeoTrust).
If you have any questions about this please feel free to ask.
Monday, June 20, 2011
cPanel 11.30
From cPanel:
We are pleased to announce the release of cPanel/WHM 11.30. cPanel and WHM version 11.30 marks a major milestone for cPanel product development. Throughout the last six months, we've made a number of progressive, under-the-hood changes, transforming how cPanel and WHM is developed, released, and updated.
This version includes:
• Over 600 maintenance and bug fixes
• Over 30 feature improvements and additions
• Over 150 product optimizations for performance and usability
For a full list of changes, please see our product change logs:
http://go.cpanel.net/changelog
We are pleased to announce the release of cPanel/WHM 11.30. cPanel and WHM version 11.30 marks a major milestone for cPanel product development. Throughout the last six months, we've made a number of progressive, under-the-hood changes, transforming how cPanel and WHM is developed, released, and updated.
This version includes:
• Over 600 maintenance and bug fixes
• Over 30 feature improvements and additions
• Over 150 product optimizations for performance and usability
For a full list of changes, please see our product change logs:
http://go.cpanel.net/changelog
Wednesday, May 4, 2011
Scheduled Server Migration
No mechanical device with moving parts lasts forever, and computer servers are no exception. We prefer to plan in advance for this and swap out hardware that's starting to show it's age long before any failure. This way the migration can be scheduled to be done at a time when traffic is typically at it's lowest.
That's us...keeping it fresh!
On Saturday, May 7, 2011 at 10pm EDT (GMT -4), we will begin migrations to a newly provisioned server. There will be some downtime while the accounts are migrated. We generally do not expect the downtime to exceed 15 minutes, but it is based on many variables and may (rarely) exceed 30-45 minutes. The data center will be actively monitoring all accounts for the duration of the migration.
That's us...keeping it fresh!
On Saturday, May 7, 2011 at 10pm EDT (GMT -4), we will begin migrations to a newly provisioned server. There will be some downtime while the accounts are migrated. We generally do not expect the downtime to exceed 15 minutes, but it is based on many variables and may (rarely) exceed 30-45 minutes. The data center will be actively monitoring all accounts for the duration of the migration.
Monday, March 28, 2011
Changes to phpMyAdmin Authentication
During recent upgrades to cPanel the way that a user authenticates when logging into phpMyAdmin from cPanel was substantially changed. The purpose is to allow for multiple types of authentication to phpMyAdmin, as the user's cPanel account does not necessarily have to have the same password for MySQL as it uses for system authentication.
From cPanel:
Because of this change, there's been a few instances of users having trouble accessing phpMyAdmin; specifically using the phpMyAdmin link from within cPanel, and instead of the phpMyAdmin interface opening as usual the user is presented with a phpMyAdmin login screen. By rights your system password (the same one used for logging into cPanel) should work, but in a few reported cases it doesn't. Typically this will happen if you've changed your cPanel password recently, and for some reason cPanel's internal system hasn't synced up the password change.
By far the easiest solution to this is to go back to cPanel and change your cPanel system password (cPanel -> Preferences -> Change Password):
Make sure to leave the box checked "Allow MySQL password change". Once the password change has processed, feel free to change your password back to what it was, again leaving the "Allow MySQL password change" box checked if you want phpMyAdmin to have the same password as cPanel (and FTP). As a reminder, it's good security practice to routinely change your password. cPanel has an integrated password generator that makes having a STRONG password very easy. Remember that when you change your cPanel system password this also changes your FTP password.
As always, if you have any questions, we're here to help!
A side note: our users may have noticed some recent interface/theme changes and new options being added. As soon as we're done implementing and testing all the new goodies (we've been working our butts off, there's a LOT!) announcements will be made in the upcoming newsletter...so watch for it!
From cPanel:
When phpMyAdmin loads, it will now attempt to get authentication data from multiple sources. It will validate the authentication data by attempting a mysql_connect() against the configured MySQL server for each source, until it finds the correct authentication information. The order of sources that it will attempt to load is:
1. The user's system password.
2. The user and password contained in ~/.my.cnf
3. If both of these fail, it will prompt for authentication with a login form.
As a result of this change, users should take note of the following:
* When invalidated session data exists, it is possible for phpMyAdmin to have problems authenticating. So, if the user notices abnormalities in phpMyAdmin, clearing browser session data should always be the first step in attempting to resolve the issue.
Because of this change, there's been a few instances of users having trouble accessing phpMyAdmin; specifically using the phpMyAdmin link from within cPanel, and instead of the phpMyAdmin interface opening as usual the user is presented with a phpMyAdmin login screen. By rights your system password (the same one used for logging into cPanel) should work, but in a few reported cases it doesn't. Typically this will happen if you've changed your cPanel password recently, and for some reason cPanel's internal system hasn't synced up the password change.
By far the easiest solution to this is to go back to cPanel and change your cPanel system password (cPanel -> Preferences -> Change Password):
Make sure to leave the box checked "Allow MySQL password change". Once the password change has processed, feel free to change your password back to what it was, again leaving the "Allow MySQL password change" box checked if you want phpMyAdmin to have the same password as cPanel (and FTP). As a reminder, it's good security practice to routinely change your password. cPanel has an integrated password generator that makes having a STRONG password very easy. Remember that when you change your cPanel system password this also changes your FTP password.
As always, if you have any questions, we're here to help!
A side note: our users may have noticed some recent interface/theme changes and new options being added. As soon as we're done implementing and testing all the new goodies (we've been working our butts off, there's a LOT!) announcements will be made in the upcoming newsletter...so watch for it!
Subscribe to:
Posts (Atom)