Protecting a Better Internet

When a client connects on TCP port 80 to a webserver, one of the first thing it sends is a line that tells the server what website it wants. This line looks like this:
HOST: www.csoandy.com
This tells the webserver which configuration to use, and how to present content to the end-user. This effectively abstracts TCP and IP issues, and lets websites and webservers interact at the discretion of the owner. The designed user of HTTP is the administrator, who may need to host dozens of websites on a smaller number of systems.

Secure Socket Layer (SSL) and its successor, Transport Layer Security (TLS), on the other hand, were designed for exactly the opposite user. The designed user of HTTPS is the paranoid security academic, who doesn't even want to tell a server the hostname it is looking for (the fact that you were willing to tell a DNS server is immaterial). In essence, SSL requires that any server IP address can have only one website on it. When a client connects to a webserver on port 443, the first thing it expects is for the server to provide a signed certificate, that matches the hostname that the client has not yet sent. So if you connect to www.csoandy.com via SSL, you'll note you get back a different certificate: one for a248.e.akamai.net. This is expected -- nothing on this hostname requires encryption. Similarly, for Akamai customers that are delivering whole-site content via Akamai on hostnames CNAMEd to Akamai's edgesuite.net domain, attempts to access these sites via SSL will result in a certificate for a248.e.akamai.net being returned. (Aside: customers use our SSL Object Caching service to deliver objects on the a248.e.akamai.net hostname; customers who want SSL on their own hostnames use our WAA and DSA-Secure services).

The designs of HTTP and HTTPS are diametrically opposed, and the SSL piece of the design creates horrendous scaling problems. The server you're reading this from serves over 150,000 different websites. Those sites are actually loadbalanced across around 1600 different clusters of servers. For each website to have an SSL certificate on this network, we'd need to consume around 250 million IP addresses - or 5.75% of the IPv4 space. That's a big chunk of the 9% left as of today. Note that there isn't a strong demand to put most sites on SSL; this is just elucidating why, even if there were demand, the sheer number of websites today makes this infeasible.

Fortunately, there are paths to a solution.

Wildcard certificates
For servers that only serve hostnames in one domain, a wildcard certificate can help. If, for instance, in addition to www.csoandy.com, I had store.csoandy.com, pictures.csoandy.com, and catalog.csoandy.com, instead of needing four certificates (across those 1800 locations!), I could use a certificate for *.csoandy.com, which would match all four domains, as well as future growth of hostnames.

You're still limited; a wildcard can only match one field, so a certificate for *.csoandy.com wouldn't work on a site named comments.apps.csoandy.com. Also, many security practitioners, operating from principles of least privilege, frown on wildcard certificates, as they can be used even for unanticipated sites in a domain.

Subject Alternate Name (SAN) certificates
A slightly more recent variety of certificate are the SAN certificates. In addition to the hostname listed in the certificate, an additional field lets you specify a list of valid hostnames for that certificate (If you look closely, the a248.e.akamai.net certificate on this host has a SAN field set, which includes both a248.e.akamai.net and *.akamaihd.net). This permits a server to have multiple, disparate hostnames on one interface.

On the downside, you still only have one certificate, which is going to get larger and larger the more hostnames you have (which hurts performance). It also ties all of those hostnames into one list, which may present brand and security issues to some enterprises.

Server Name Indication (SNI)
The long term solution is a feature for TLS called Server Name Indication (SNI). This extension calls for the client to, as part of the initial handshake, indicate to the server the name of the site it is looking for. This will permit a server to select the appropriate one from its set of SSL certificates, and present that.

Unfortunately, SNI only provides benefit when everyone supports it. Currently, a handful of systems don't support SNI, most notably Windows XP and IIS. And those two major components are significant: XP accounts for 55-60% of the browser market, and IIS looks to be around 24%. So it'll be a while until SNI is ready for primetime.

Posted by Andy Ellis at 9:25 AM | Permalink

Last week, I spent some time with Bill Brenner (CSO Magazine) discussing DDoS attacks, and some insight into attacks over the last ten years. He put our discussion into a podcast.

Posted by Andy Ellis at 10:24 AM | Permalink

Twitter had its name servers "stolen". Would DNSSEC have helped protect them? To be brief, no. But looking at why not will help understand the limitations of DNSSEC. It helps to start with the basics of DNS, and DNSSEC.

DNS is broken down into zones. A zone is a hierarchical collections of names, roughly grouped by the periods in the hostname -- e.g., www.csoandy.com exists under three zones: . (the root zone), .com, and .csoandy.com. Each zone has a set of servers that are authoritative when answering queries in that zone, and can delegate responsibility for a subsidiary zone to a different set of servers.

With DNSSEC, each zone has a set of keys used to sign answers in the zone; the zone signing key, which signs the records, and the key signing key, which signs the zone signing key. You learn the key signing key for a zone when receiving a delegation; the delegating server adds a special record informing you of the key for the zone they're passing you to.

Looking at the incident, it appears that a compromised Twitter employee email account was used to reset an administrative account login with their registrar, and then that account was used to change the delegation for twitter.com. Had Twitter been using DNSSEC, Twitter would have needed to provide the public half of their key signing key to their registrar. Odds are, that would be in the same interface that was used to redirect twitter.com. An adversary would have been able to alter the DNSSEC delegation just as easily as they altered the zone delegation.

DNSSEC has a lot of strengths, but it isn't a magic bullet for all of the weaknesses in the DNS infrastructure.

Posted by Andy Ellis at 9:24 AM | Permalink

An important piece of risk assessment is understanding your adversaries. Often, this can degenerate into an assumption of perfect adversaries. Yet when we think about risk, understanding that our adversaries have different capabilities is critical to formulating reasonable security frameworks. Nowhere is this more true than in the streaming media space.

Brian Sniffen (a colleague at Akamai) recently presented a paper at FAST exploring ways of considering different adversaries, especially in the context of different business models. He presents some interesting concepts worth exploring if you're in the space:

• Defense in breadth: The concept of using different security techniques to protect distinct attack surfaces, specifically looking at defeating how a specific adversary type is prone to conduct attacks.
• Tag-limited adversaries: An extension to the Dolev-Yao adversary (a perfect adversary who sits inline on a communication stream), the tag-limited adversary may only have knowledge, capabilities, or desire to conduct attacks within a limited vocabulary.

His paper is also a good primer on thinking about streaming threat models.

Posted by Andy Ellis at 9:09 AM | Permalink

Virtual patching, for those new to the term, is the practice of adding a rule to a Web Application Firewall (WAF) to filter out traffic that could exploit a known vulnerability in a protected application. This has triggered debate in the security community -- is this a good thing? Why would a developer fix the vulnerability if it is mitigated?

First off, Virtual Patching is, in fact, a good thing. The development turnaround time for a WAF rule is almost certainly shorter than the development cycle for the backend application, so this shortens your mitigation window. That shouldn't really be a topic of debate.

The interesting debate, then, is how we manage the underlying vulnerability. One school of thought argues that the WAF is only a stopgap, and developers should fix the vulnerability because that's the right thing to do. Another school's argument is a bit more complex. Don't fix the vulnerability. Fix the entire class of vulnerabilities.

If you have a vulnerability in a webapp, odds are that it's a symptom of a greater category of vulnerability. That CSRF bug on one page likely reflects a design flaw in not making GET requests nullipotent, or not using some form of session request management. Given the urgency of an open vulnerability, the developers will likely focus on fixing the tactical issue. Virtually patch the tactical vulnerability, and focus on the flaw in the foundation. It'll take longer to fix, but it'll be worth it in the long run.

Posted by Andy Ellis at 11:16 AM | Permalink

We are used to measuring the efficiency of DDoS attacks in ratios of bits-per-second. An attacker wants to consume many bits-per-second for each of his own bits-per-second that he uses. He would rather send one packet to generate a storm than have to send the storm himself. We can extend this efficiency measurement to other attacks. Let's use the name "flits per second" (for fully-loaded bits) for this more general measurement of cost and pain: sending or receiving one bit-per-second costs one flit-per-second. Doing enough computation to have an opportunity cost of one bit-per-second has a cost of one flit-per-second. Enough disk access to forestall one bit-per-second costs one flit-per-second. Now we can talk about the flit capacity of the attacker and defender, and about the ratio between flits consumed on each side during an attack.

From a defensive efficiency perspective, we have two axes to play with: first, reducing the flit-to-bit ratio of an attack, by designing optimal ways of handling traffic; and second, increasing the relative client cost to produce an attack.

To reduce the flitcost, consider the history of SYN floods. SYN floods work by sending only the first packet in the three way TCP handshake; the victim computer keeps track of the half-open connection after sending its response, and waits for the attacker's followup. That doesn't come; for the cost of a single SYN packet, the attacker gets to consume a sparse resource (half-open connections) for some period of time. The total amount of traffic needed historically was pretty minimal, until SYN cookies came along. Now, instead of using the sparse resource, targets use a little bit of CPU to generate a cryptographic message, embed it in their response, and proceed apace. What was a very effective attack has become rather ineffective; against most systems, a SYN flood has a lower flit-to-bit ratio than more advanced application layer attacks.

The other axis is more interesting, and shows why SYN floods are still prevalent even today: they're cheap to produce. They don't consume a lot of cycles on the attacking systems, and don't require interesting logic or protocol awareness. The fewer resources an attacker can consume, the more likely their attack will go unnoticed by the owners of the compromised hosts used in the attack (Case in point: look at how fast Slammer remediation happened. Why? ISPs were knocked offline by having infected systems inside). Many attack programs effectively reduce to "while (1) {attack}". If the attack is making an HTTP request, filtering the request will often generate a higher rate of requests, without changing the attacker's costs. If this higher rate has the same effect on you that the lower rate did, you didn't buy anything in your remediation. You might have been better off responding more slowly, than not at all.

In the general case, this leads us to two solution sets. Traffic filtering is the set of technologies designed to make handling attacks more efficient; either by handling the attack further out in an infrastructure, classifying it as malicious for a cheaper cost than processing it, or making processing cheaper.

Capacity increases, on the other hand, are normally expensive, and they're a risky gamble. If you increase far in excess of attacks you ever see, you've wasted money. On the other hand, if you increase by not quite enough, you're still going to be impacted by an event (and now, of course, you'll be criticized for wasting money that didn't help). Obligatory vendor pitch: this is where a shared cloud infrastructure, like a CDN, comes into play. Infrastructures that measure normal usage in terabits per second have a significantly different tolerance for attack capacity planning than most normal users.

Posted by Andy Ellis at 5:10 PM | Permalink

The nervousness around H1N1 has pretty much permeated every aspect of our lives. Remember a year or two ago, the hysteria around hand sanitizers and alcohol poisoning? Gone; in its place, we have dispensers in buildings everywhere. That's the power of the fear of H1N1.

Another place is in schooling. Not too long ago, if your kid got sick, school policy was "keep them home if they have a fever or are vomiting." Sanely, this migrated to "keep them home for 24 hours after a fever." Now, however, it is "48 hours fever-free with no medications." Some schools/daycares have added "and no symptoms either," which is moderately impractical for the kids who get a three-week long lingering cough.

This affects us in the workplace. If an employee has a small child and they don't have a stay-at-home caregiver, expect that they're going to miss more time than in prior years; and that the employee actually will be stressed about this (heck, anyone trapped at home with a no-longer-sick child on a school-day is going to end up pretty stressed). Also, you may want to suggest that employees with sick children stay at home even if they aren't the primary caregiver, just to minimize workplace infections.

Key to this is a sane telework plan. Like most things, this comes down to People, Process, and Technology.

People: Do the employee and manager have a good rapport, such that working remotely does not lead to communications failures? Can the employee work without direct management? Can the employee balance the needs of daytime home-life with work?

Process: Do you have understood ways for the employee's status to be communicated? Do other employees know how to reach them? How many hours do you expect when an employee is "working from home"?

Technology: What telework capabilities do you have? (VOIP phones in the home? VTC setups?) What about remote collaboration? (A wiki, IM, ticketing system or just email?) Do your employees have enough bandwidth at home to telework? Do you have enough in your office to support them?

It's going to happen to you -- you just need a little prep. And most of that prep? You can typeset it to hand to your auditors; it's a big piece of your DRP.

Posted by Andy Ellis at 11:51 AM | Permalink

I've become an amateur hairdresser in the past couple of years, thanks to my three year old (I suspect that, had I been unwilling to do so, her hair would be quite short right now). Along the way, I've realized that I know as much about hairdressing as I do about many of the disciplines InfoSec touches.

For those of you who've never braided hair, let's try a little manual experiment. Go get three strings. Tie them together at one end to a fixed object: maybe a railing. Now braid them: holding them extended, switch the middle and right one; then the (new) middle and left one. Repeat, each time making sure the middle one goes under the outer one. Do this a couple of times, until you're comfortable with it.

You now know as much about hairstyling as you probably know about some of the more esoteric security disciplines: executive extraction, availability analysis, crypto design, or fault isolation in Byzantine networks. You haven't had to deal with snarls, or working with multiple different hair types, or tried a French braid. Similarly, you may never have designed a communications protocol, or walked a perimeter, or managed IDS sensors on the other end of an intercontinental straw.

Yet every day, as infosec professionals, we are compelled to guide other professionals in how to do their jobs. My advice: be a bit humble. As smart and clever as we think we are, the professionals we deal with are smarter in their own disciplines.

Posted by Andy Ellis at 8:30 PM | Permalink

I disagree with this:

It's time to show most passwords in clear text as users type them. Providing feedback and visualizing the system's status have always been among the most basic usability principles. Showing undifferentiated bullets while users enter complex codes definitely fails to comply.

Most websites (and many other applications) mask passwords as users type them, and thereby theoretically prevent miscreants from looking over users' shoulders. Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn't even protect fully against snoopers.

More importantly, there's usually nobody looking over your shoulder when you log in to a website. It's just you, sitting all alone in your office, suffering reduced usability to protect against a non-issue.

Even though Bruce Schneier agrees with it:

Shoulder surfing isn't very common, and cleartext passwords greatly reduces errors. It has long annoyed me when I can't see what I type: in Windows logins, in PGP, and so on.

Ignoring the issue of security controls enforced differently in browsers for type password versus type text, the arguments in favor of unmasking fail to address several issues:

• What class of attackers are completely foiled by password masking? What is the exposure presented by these people? (Think: someone that happens to glance at your screen as they've interrupted you midlogin)
• What is the additional level of likelihood of detection of someone trying to watch your fingers touchtype vs. someone simply reading off a screen?
• What is the additional level of risk presented by a persistent display of the password vs. an ephemeral display of each keystroke as it is typed?
• What is the additional attack surface presented by having the password sent back from a network application, rather than a one-way transmission?
• How much of the uncommonality of shoulder surfing is due to user awareness of password protection needs, as communicated to them at every login?

All that aside, the correct answer is to reduce our dependency on passwords, both through SSO technologies, and through use of certificate and ephemeral authentication schemes.

Posted by Andy Ellis at 8:45 AM | Permalink

I have a bluetooth handsfree device, which occasionally gets into an annoying error mode, where my phone thinks the device is connected, and the device disagrees. Modifications to the phone's state - turning bluetooth on or off, powercycling - have no effect. The only apparent cure is to turn the bluetooth device off, and then back on again.

Unfortunately, it's the embedded handsfree system in my car. So I have to turn off the car, and then turn it back on again. My mother has the same problem - this seems to be a defect in the Toyota/Lexus integration. So if you're behind me when I pull out of the garage, and I turn the car off and on at the first red light, you'll know why.

Posted by Andy Ellis at 7:28 PM | Permalink

Bruce Schneier opines on NIST's proposed non-use of encryption as sanitization:

Encryption is not a generally accepted means of sanitization. The increasing power of computers decreases the time needed to crack cipher text and therefore the inability to recover the encrypted data can not be assured.

I have to admit that this doesn't make any sense to me. If the encryption is done properly, and if the key is properly chosen, then erasing the key -- and all copies -- is equivalent to erasing the files. And if you're using full-disk encryption, then erasing the key is equivalent to sanitizing the drive. For that not to be true means that the encryption program isn't secure.

While NIST has removed the paragraph, functionally, they are correct. Bruce has too many qualifications, and missed some more - if there were no implementation bugs in your crypto, if your key was properly generated, if you didn't escrow the key for DR someplace where it didn't get removed, if there are no known-plaintext or chosen-plaintext attacks against your encryption algorithm within the life of your hard drive... just a few too many ifs.

By all means, encrypt the hard drive - it's a great practice, especially in the event your hard drive is lost. But absolutely sanitize it if you also have the opportunity.

Posted by Andy Ellis at 6:46 AM | Permalink

Zipcar just showed up in the new parking garage at work. Interesting to note that they've now added the Scions (xA and XB), Element, and Matrix to their line-up.

I assume that means they're seeing demand for more cargo space, which seems to me to be the big gap for people who rely on public transportation.

Posted by Andy Ellis at 4:14 PM | Permalink

Invisibility gets closer.

It's a cool concept. But once the price comes down, this is one of those potentially disruptive technologies (it reminds me a lot of Shield, by Poul Anderson). I think there are some scary uses, and some cool uses:

In the scary category:

• concealed guns
• concealed bombs
• traffic hazards. People drop bricks off overpasses - what about a cloaked piece of furniture?

In the cool category:

• Urban renewal - what if, instead of creating a hole in space that one looked through, you offshifted light, so that light appeared to go over the object? Imagine a downtown parking garage, with landscaping on the top. From the side, it appeared to be - just a park. Because just making the garage invisibile is ugly - you end up with strange sightlines and perspectives. But making it actually disappear? We could have saved a lot of money on the Big Dig.


• Architectural features - imagine a building where every other floor is invisible. Or where the pillars aren't there.


• Privacy umbrella - have your own portable changing station at the beach! Of course, I could see some uses for this that might best fit in the scary category, come to think of it....

Posted by Andy Ellis at 7:26 PM | Permalink

Noam Eppel at Vivica asserts that Information Security is a total failure:

Today we have forth and fifth generation firewalls, behavior-based anti-malware software, host and network intrusion detection systems, intrusion prevention system, one-time password tokens, automatic vulnerability scanners, personal firewalls, etc., all working to keep us secure. Is this keeping us secure? According to USA Today, 2005 was the worst year ever for security breaches of computer systems. The US Treasury Department's Office of Technical Assistance estimates cybercrime proceeds in 2004 were $105 billion, greater than those of illegal drug sales. According to the recently released 2005 FBI/CSI Computer Crime and Security Survey, nearly nine out of 10 U.S. businesses suffered from a computer virus, spyware or other online attack in 2004 or 2005 despite widespread use of security software. According to the FBI, every day 27,000 have their identities stolen.

Noam's article is a good read if you think the Internet is safe. But a lot of folks disagree with his conclusion, and I side with them. Noam's article is just a litany of all the doom and gloom statistics out there - like the ones you see on Slide 2 of every security vendor's pitch.

Posted by Andy Ellis at 5:43 PM | Permalink

Driving in to work this morning, I discovered a wonderful failure mode of an alerting system. My car has a weight sensor in the passenger seat; if it detects a possible passenger in the seat, without a safety belt in use, it alerts you.

Now, our other car has had this, and it's just a little red light on the dash. But this car starts an audible dinging alarm, which then goes to a very fast audible alarm. I'm not sure if it will turn itself off, as I moved my backpack quickly from the passenger seat to the floor. But what was my first thought?

Man, I've got to disable that alarm.

Continue reading "False positives" »

Posted by Andy Ellis at 9:46 AM | Permalink

We just bought a new car, and it has headlights that turn to the left or the right when the steering wheel has turned in that direction. It's a pretty neat feature, although I discovered an interesting "attack" you can do with it, even unintentionally. The distance the steering wheel needs to turn to trigger the auto-adjust happens to be the curvature of the onramp from Storrow Drive to 93 North. So if you happen to be behind someone, and the steering wheel has any jitter in it (not that, you know, you'd jitter it intentionally), your headlamps will wash back and forth across the inside of their car.

As if being followed by a tall car wasn't already painful enough.

Posted by Andy Ellis at 8:15 AM | Permalink