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
