TOPIC: DEFENDING YOUR NETWORK
TOP TEN WAYS TO DEFEND YOUR
NETWORK AGAINST THE LATEST
SSL EXPLOITS
Staying on top of the latest web exploits is a job in itself, but that responsibility usually falls on a network admin who has countless other
responsibilities, too. This article discusses many recent SSL-related exploits, explaining them in real-world terminology (and baseball analogies)
and offering some simple steps you can immediately take to protect your network.
1: STANDARDIZE ON HTTPS
In a “Man-in-the-Middle” (MITM) attack, an attacker intercepts
communications between a website and its visitor. Once the
attacker has convinced the two parties that they are talking
directly to each other, it becomes possible to alter the data in
transit and manipulate the exchange for the attacker’s benefit.
Hypertext Transfer Protocol Secure (HTTPS) is a ubiquitous
protocol for secure communication over the web, allowing
you to layer HTTP on top of the SSL/TLS protocol. Securing the
connection provides protection against MITM attacks, because
HTTPS can encrypt not only the data exchanged during the
secure session but also the URL request, query parameters,
headers, and cookies. This heightened security makes HTTPS
especially suited for high-risk interaction such as e-commerce
transactions and communications over unencrypted Wi-Fi
networks.
In practice, even if a site is largely configured to use HTTPS,
across-the-board implementation is necessary to close all
potential attack vectors. In home security, locking your front
door is a great first step, and it may deter some potential
burglars. But if you leave a small bathroom window on the
second floor unlocked, you run the risk of a small burglar with
a tall ladder taking advantage of that. And once the burglar is
in the house, it doesn’t matter how he got in — the potential
for damage is the same. Similarly, loading unsecured scripts or
cookies, using HTTP on a login or landing page, and switching
between secure and unsecure pages on a given site all open
the door to exploitation by a clever hacker.
Thanks to advances such as HTTPS support for Google’s SPDY
protocol to reduce page load latency, previous concerns about
SSL/TLS slowing website performance have been laid to rest.
SSL Pulse reports that currently less than 20% of the Internet’s
most popular websites have a secure implementation of
HTTPS, leaving a large majority of the web vulnerable to MITM
attacks. Make sure your site isn’t on the wrong side of that
statistic.
2: USE STRICT TRANSPORT SECURITY
WHENEVER POSSIBLE
In step 1, you set up your server to serve all pages via HTTPS.
The next step is to implement HTTP Strict Transport Security
TOPIC: DEFENDING YOUR NETWORK
(HSTS), a web security policy whereby web servers inform web
browsers that they should only interact with the server using
HTTPS-protected connections. This is necessary because a
browser has no way to know whether a plain HTTP response
from a website is due to a failure to implement SSL/TLS security,
or the result of a malicious hack. An SSL-Stripping Man-in-theMiddle attack relies on converting a secure HTTPS connection
into a plain HTTP connection and thereby compromising the
subsequent data exchange.
Another benefit HSTS provides is aiding in safeguarding
your site’s cookie-based login credentials that are otherwise
exposed to attackers sniffing your site.
The HSTS header on your website tells visiting browsers
that they should only use SSL/TLS connections for the
specified period of time (e.g., “Strict-Transport-Security: maxage=2592000” tells the browser to use only HTTPS for the
next 2,592,000 seconds, or 30 days). Because an attacker can
theoretically strip out the HSTS header on someone’s first
visit to a site, some browsers consult a list of all HSTS-enabled
sites. These lists are not comprehensive, slightly limiting the
protection afforded by HSTS, but it is still a useful layer of
security. (Going back to our home security analogy from step
1, you wouldn’t refuse to lock your front door just because you
knew the lock on the upstairs bathroom window was broken.)
if we don’t fully understand it. “Undecillion” is not a word we
are familiar with. When numbers get that big, people start
expressing them in scientific notation, and our brains translate
it to “a lot.” If the number in superscript is large enough, we
may translate it to “a whole lot.”
So one point is that 128-bit encryption provides roughly “a
whole lot” of distinct keys. The second, more important, point
is that gains in key complexity are exponential, which means
you get a lot of bang for your bit-buck. Computers are getting
faster and smarter, and even the outlandish 340 undecillion
number is expected to eventually become susceptible to
exhaustive key searches, more commonly known as “brute
force attacks.” So let’s say, hypothetically, that eventually
computers get to where they can crack a 128-bit key in one
second. That does not mean they would be able to crack a 256bit key in two seconds, or even two minutes or two hundred
years. No, if it took one second to crack a 128-bit key, it would
take roughly 10 nonillion years — that’s 10 with 30 zeroes after
it — to crack a 256-bit key.
The takeaway for this section: computers are much closer than
we ever thought they would get to cracking 128-bit encryption,
but 256-bit encryption is significantly more complex and
unsusceptible to brute force attacks.
4: USE httpONLY COOKIES
3: 256-BIT ENCRYPTION
Here’s an interesting math lesson (well, interesting if you’re
the kind of person who reads white papers about network
vulnerabilities): simple logic tells you that a 256-bit encryption
key is twice as secure as a 128-bit key. Or, more specifically,
that there are twice as many distinct keys in 256 bits as there
are in 128 bits. In this case, though, logic would be wrong,
and we’d have to turn to math for the answer. Because the
numbers we’re dealing with are impossibly large, let’s use
some smaller numbers to demonstrate the principle.
Let’s look at the difference between 4-bit keys and 8-bit keys.
With four bits, each one containing either a 1 or a 0, there are
16 distinct keys. (Specifically: 0000, 0001, 0010, 0100, 1000,
0011, 0110, 1100, 0101, 1010, 1001, 0111, 1011, 1101, 1110,
and 1111.) When you go to eight bits, you don’t double the
number of distinct keys — you square it. Eight-bit encryption
gives us 256 distinct keys, 16 times as many as 4-bit encryption.
If we double again from 8-bit to 16-bit, we go from 256 keys
to 65,536.
What is the point of this math lesson? There are a few points.
One is that 128-bit encryption provides an enormous number
of distinct keys — roughly 340 undecillion, or 340 with 36
zeroes after it. Compare that to the roughly 1,000,000,000,000
distinct keys in 40 bits. Years ago, 40-bit keys were commonly
used to encrypt data, because people thought (and rightly so)
that one trillion was a huge number of keys. We probably don’t
really comprehend how many one trillion is, but just realize
that you would have to earn one million dollars a year for one
million years to earn one trillion dollars. So yes, one trillion keys
is a lot, but “trillion” is a number we are familiar with, even
Imagine two friends, Tom and Bill. They have a great friendship
and trust each other completely. There’s a third person, Al,
who is jealous of this friendship and wants to cause some
problems. So Al steals Tom’s cell phone and sends Bill a text
message asking a sensitive question. Because Bill trusts Tom
and thinks he is interacting with Tom, he answers the question
openly and honestly. Al then uses this information in all sorts
of nefarious ways, which does severe damage to Tom and Bill.
Sadly, what we’ve just described is not the plot of an upcoming
super-intense action movie starring Channing Tatum and
Kiefer Sutherland (with Clint Howard as Al). No, it is a realworld analogy for Cross-Site Scripting (XSS), where an attacker
exploits established trust between a browser and a website.
One of the underlying security mechanisms on the web is the
premise of “same-origin policy,” meaning that after trust is
established with a website, permission is granted by that site
to access resources on a client computer. XSS is a common
security vulnerability that seeks to steal session cookies by
injecting compromised content into the stream of data coming
from the website, disguised as coming from the “same origin.”
This code injection gives the attacker access to information
that is being shared in the connection and compromises
the interaction. Using JavaScript or other scripts, malicious
code can steal additional data from the client computer or
otherwise wreak havoc. While XSS itself isn’t new, it continues
to evolve and mutate as a viable attack vector.
The solution is HttpOnly, first introduced in Microsoft Internet
Explorer 6 in 2002. HttpOnly is a flag included in a Set-Cookie
HTTP response header that prevents the cookie from being
accessed through a client-side script. All current versions of
TOPIC: DEFENDING YOUR NETWORK
suite, because a) the opposing team knows that if the coach
gives a sign, something is going on, and they have a chance
to guess what it is; and b) once the coach touches the bill of
his cap and the batter bunts, the opposing team now knows
that the bill of the cap is the bunt sign.
modern browsers support HttpOnly, so using the HttpOnly
flag when creating a cookie protects you from XSS even if your
code is vulnerable.
5: DISABLE TLS COMPRESSION (AND “TAKE A
BITE OUT OF CRIME”)
•
In a more complex “cipher suite,” the coach gives a sign
every time, but most of them are meaningless. It’s only if he
touches the bill of his cap, for example, that a bunt is being
called for. Touching his belt buckle is a decoy sign that means
nothing. This eliminates the first problem of the opposing
team knowing something is up every time the coach gives
a sign, but it doesn’t address the second issue of reverse
engineering signs.
•
In a “cipher suite” much more like what coaches actually
use, there is some sort of “indicator” given before a sign.
So touching the bill of the cap may be the bunt sign, but it
is meaningless unless the indicator sign is given first. For
example, if the indicator is touching the belt buckle, then a
touch of the bill cap means nothing, but a touch of the belt
buckle followed by a touch of the bill cap means to bunt. To
make things more complex, teams will sometimes throw in
other wrinkles: the coach has to give the indicator twice, or
the third sign given after the indicator is the actual sign, etc.
A combination of those two examples would mean that if the
coach did indicator-decoy-bunt-decoy-steal-indicator-stealbunt-steal-decoy-bunt, the sign would be “steal” because
that was the third sign given after the second instance of
the indicator. This “cipher suite” makes it much harder for
opponents to decrypt the signs — enough so that they don’t
bother trying. The key is that the coach and his players know
some information that the opponents don’t — the algorithm,
if you will.
The Transport Layer Security (TLS) protocol, the successor to
the SSL protocol, includes a feature that can compress the
data being exchanged between server and browser in order
to reduce the bandwidth and latency issues that occasionally
occur when encrypting and decrypting large amounts of data.
CRIME (“Compression Ratio Info-leak Made Easy”) is a potential
exploit targeting cookies over connections using the HTTPS
and SPDY protocols that employ TLS data compression. An
attacker can recover the content of secret authentication
cookies and subsequently hijack an authenticated web session.
The vulnerability is caused by a combination of plaintext
injection and data leakage because of the compression. In
essence, the hacker compares the size of the ciphertext
sent by the browser while goading the browser into making
several connections to the site. By careful examination of each
exchange the attacker can deduce parts of the encrypted
communication and compromise the session.
The way to prevent CRIME is to disable TLS compression using
the protocol negotiation features of TLS, either on the website
server or in the browser (or, ideally, both). Most browsers have
taken steps to mitigate the danger of this exploit, but site
admins should ensure the security of their visitors by disabling
the compression option altogether. The speed benefits of TLS
compression do not justify the risk of exploitation, just as the
speed benefits of driving your car 150 mph (241 km/h) do not
justify the risk of accident.
6: DISABLE WEAK CIPHER SUITES
A cipher suite uses a specific combination of authentication,
encryption, and algorithms to negotiate the security settings
for a SSL/TLS network connection. More specifically, each
cipher suite defines a key exchange algorithm, a bulk encryption
algorithm, a message authentication code algorithm, and a
pseudorandom function. When a TLS handshake occurs to
establish a web connection, the client sends a list of the cipher
suites that it supports in order of preference. The server
selects a cipher suite from the list for its response and the
subsequent exchange.
Here’s a real-world analogy for cipher suites: picture the thirdbase coach for a baseball team giving signs to his team. A
batter and any base runners will look to the coach for signs
telling them to bunt, hit-and-run, steal a base, etc. There are a
few ways the coach could go about giving these signs — we’ll
call them “cipher suites” for ease of analogy:
•
One “cipher suite” is that if there is no play being put on, the
coach gives no sign. If calling for a bunt, he gives the bunt
sign (e.g., touching the bill of the cap). This is a weak cipher
Just as with baseball signs, there are actual cipher suites that
are weak, and there are some that are strong. In 2011, security
researchers developed a theoretical attack called BEAST
(“Browser Exploit Against SSL/TLS”) that uses a Java applet to
violate same-origin policy constraints and decrypt an HTTPS
session between a browser and an e-commerce website.
Browser vendors responded by addressing holes exploited by
this attack in their latest versions. The best way that site admins
can mitigate the danger from BEAST is to disable all weak
cipher suites that are being recognized by their site, relying
on the RC4 cipher by default. For more information on weak
cipher suites, and how DigiCert’s free Certificate Inspector can
help you identify where you have weak cipher suites enabled in
your network, go to http://www.digicert.com/cert-inspectorvulnerabilities.htm#weak_cipher_suites_h3.
7: UPDATE YOUR SERVERS TO SUPPORT
SECURE RENEGOTIATION
The SSL/TLS protocol has a useful feature called session
renegotiation. This feature allows a client and server to
use an existing connection to negotiate new parameters,
generate new keys, and so forth, during the session. The fact
TOPIC: DEFENDING YOUR NETWORK
that renegotiation is not directly associated with the channel
creates a vulnerability that allows a third party to intercept
and manipulate the data being passed between the client and
the server — a classic Man-in-the-Middle attack. HTTP, SMTP,
IMAP, and other protocols that rely on SSL/TLS can all be
subsequently exploited. The attack initiates a renegotiation
between the MITM and the server while the client is operating
under the assumption that the connection is still in the initial
negotiation stage.
This vulnerability led to the creation of a specific exploit
known as the TLS Renegotiation Man-In-The-Middle attack
(TLS Renego MITM, which is easier to write but not much
easier to say). Many system manufacturers have released
patches to fix this issue, which was first discovered in 2009.
However, a large percentage of sites (including prominent
e-commerce websites) have still not installed the necessary
patches, leaving themselves open to this attack. Not only
are these sites vulnerable, but they are likely to encounter
connectivity issues — which cause revenue-generation issues
— in the future as they fall farther out of industry compliance.
The way to protect against TLS Renego MITM is to make
sure your servers support secure renegotiation. All of your
servers should also be running current versions of the SSL/
TLS protocol. Because it is currently impossible for the client
browser to know if a given server is still using the obsolete
versions of SSL/TLS, it becomes incumbent on server admins
to provide adequate protection for this attack surface. An
alternative is to disable renegotiations altogether.
8: CHECK YOUR SITE USING A WEB SERVER
TESTER
Once you have optimized your site you still have one important
step — running an SSL installation diagnostics tool, such as
the DigiCert’s free Certificate Inspector. A good SSL test will
examine installed certificates, protocol support, key exchange,
and cipher strength. It can examine your SSL configuration
and prescribe further steps to take to improve your overall
security and eliminate attack surfaces. These tests should be
run on a frequent basis to ensure that no settings have been
inadvertently changed, and that ongoing updates to your site
haven’t broken important safeguards.
To use another baseball analogy, every once in a while there
will be news of a pitcher who changed teams and subsequently
learned that he had been “tipping his pitches.” A team will pick
up on the fact that, for example, when he is going to throw his
changeup, the webbing of his glove will flare a bit as he presses
the ball deep into his palm before pitching. So from then on,
that team knows when they are going to get a changeup,
which drastically improves their chances of hitting it. It’s not
until the pitcher goes to a new team that has figured out his
“tips” that his new pitching coach will tell him about them.
In the same way, it is important to get information from a
trusted third party about any pitches you might be tipping on
your server. You do everything you can to make sure you are
secure, and then let DigiCert’s tool take a look and doublecheck your work.
9: STAY CURRENT WITH THIRD-PARTY
SECURITY UPDATES
Every network is full of third-party software fulfilling critical
functions. If something isn’t “broken” the tendency is not to fix
it, leading to many organizations with extremely old versions
of software running in their network. This can create serious
holes in an otherwise well-protected environment.
Attackers are routinely sniffing your network for attack
surfaces left exposed by outdated software, in many cases
stumbling upon vulnerabilities as they conduct scans across
the entire face of the web. A poorly managed network can
easily be vulnerable to dozens of potential exploits.
The one sure way to prevent exploits via third party software is
to exercise extreme prejudice when testing and installing new
software. If a piece of software isn’t critically important, simply
uninstall it. Once a given program has outlived its usefulness,
get rid of it. Programs that you decide to keep need to be
monitored as part of a regular maintenance schedule. Patch
management software and version management systems can
also provide important reminders when you fall behind on
your updates.
10: CONDUCT YOUR OWN PENETRATION
TESTS
Because web applications running on your site often bypass
your firewall, SSL encryption, and other security measures to
tie straight in to your most mission-critical processes and data,
it is imperative to also conduct penetration tests (pentests)
inside your network.
A vulnerability scanner run from inside your network
can reveal many vulnerabilities that are not immediately
detected by an external scan. You need to pressure test the
connections between your servers and the scripts running on
them to discover weak points and potential buffer overflow
issues. If you are concerned about possibly disrupting
production servers and important e-commerce engines, you
can sometimes pentest development environments without
compromising the smooth functioning and integrity of your
day-to-day operations.
Cleaning up the software running on your network, especially
insecure web applications, not only is important for auditing
purposes, but can save you from experiencing a catastrophic
attack in the very heart of your IT operations.
PICKING THE RIGHT SSL VENDOR
(HINT: IT’S DIGICERT)
The Certificate Authority (CA) that you select will impact the
ease-of-use, speed of issuance, uptime, OCSP/CRL latency, and
TOPIC: DEFENDING YOUR NETWORK
a variety of features that make your network more secure and
simple to manage. At DigiCert®, we understand that most of
our customers are not SSL experts, because managing their
organizations’ certificates is just a small part of their jobs. With
DigiCert, you don’t have to be an expert — between our online
tutorials and instructions and immediate access to our awardwinning technical support team via email, chat, or telephone,
you have access to experts whenever you need it.
DigiCert has been providing SSL Certificates and SSL
management tools for over a decade. We assisted in creating
the Extended Validation Certificate and worked with Microsoft
to develop and promote the use of Subject Alternate Names
in SSL Certificates. Unlike other CAs who offer dozens or
even hundreds of products unrelated to SSL, we started our
business on a core of authentication and encryption and have
built it out from there. This focused energy results in better
products and unmatched support.
In addition to DigiCert’s award-winning in-house technical
support team, we also have some of the fastest certificate
issuance times out of any CA — with EV certificates typically
issued in a matter of hours and standard certificates in less
than 20 minutes! And when you call us on the phone, a real
person will answer, and that person will be able to help you
with your issue. No phone queues, not outsourced support, no
endless transfers where you have to explain the same issue to
six different people. Just real, great support. Experience the
“DigiCert difference” for yourself by calling 1-855-800-3444 or
visiting www.digicert.com.
About DigiCert, Inc.
DigiCert is a premier online trust provider of enterprise
security solutions with an emphasis on authentication, PKI,
and high- assurance digital certificates. Headquartered in Lehi,
Utah, DigiCert is trusted by a continually growing clientele
of more than 80,000 of the world’s leading government,
finance, education, and Fortune 500® organizations. DigiCert
has been recognized with dozens of awards for providing
enhanced customer value, premium customer support and
market growth leadership. For the latest DigiCert news and
updates, visit digicert.com, like DigiCert on Facebook® or
follow Twitter® handle @digicert.
©2014 DigiCert, Inc. All rights reserved. DigiCert is a registered trademark of DigiCert, Inc. in the USA and elsewhere. [v0113]