uncompiled.com

One core tenet of demilitarized zone (DMZ) design is to segregate network devices, systems, services and applications based on risk. Because of this, it’s crucial to carefully plan and design a DMZ because it may not be easy to fix major flaws in the DMZ’s design once it’s live. Here, Knowledge Center contributor Michael Hamelin explains how to design a secure DMZ for your enterprise.

We have come a long way when it comes to DMZs (demilitarized zones). It’s no longer a question of if your organization needs a DMZ, but rather, it’s now a question of how you should design one.

In computer security, a DMZ is a physical or logical subnetwork that contains and exposes an organization’s external services to a larger, untrusted network—usually the Internet. The original DMZ designs included a simple network separated from the internal network, where everything that needed access to the Internet was placed.

Today, there are as many DMZ designs as there are vehicles on the road. You have industrial trucks designed to simply transport goods as cheaply as possible. You have economy cars designed to save money. And you have exquisite Italian sports cars that are sure to make your friends jealous (and fast enough that you always arrive with plenty of extra time for a nice cup of espresso). DMZ designs are a lot like cars: there are many varieties which go by a lot of different names but they all serve the same purpose.

There are hundreds of names that we use for networks today but, essentially, there are internal networks, external networks and DMZs. They may be called partner nets, vendor zones, internal DMZs or security zones. But the reality is that they are all DMZs with a mix of ownership devices, connectivity and risk levels.

Goals of DMZ design

If you ask ten network architects about how to design a DMZ, they’ll come back with ten different answers. While variety is the spice of life, as an industry we should have some generally accepted practices of DMZ design.

One of the core tenets of DMZ design is to segregate devices, systems, services and applications based on risk. The goal is to isolate risk, so if something goes bad and the Web server is hacked, it is essential to know what other devices the hacker would have easy access to. Beyond segregation by risk, four other common design approaches are separation by operating system, data classification schemes, trust levels or business unit.

If you look at recent audit and compliance requirements, you’ll see that they include a growing number of specific technical design requirements. In some of the new requirements, we find the mandate to keep the Web and application tier separated from databases—a very good idea. We also see the move back to single purpose servers; for example, your Web server cannot also be your DNS server.

Four levels of DMZ design

Let’s break DMZ design into four levels, with Level 1 being the simplest design and subsequent levels providing more segmented security.

When we want to build a basic DMZ, we start with a single segment of the firewall. Let’s call this Level 1 in our DMZ design book. This design is fine if you have a few servers that need Internet access. But if you do any e-commerce transactions, you have already outgrown this design.

Many people make the mistake of keeping this design, placing the Web and application servers in the DMZ and the databases on the internal network. This is no longer acceptable. As database attacks become more targeted, the risk of having the database on the internal network requires a more sophisticated design.

Level 2 DMZ designs

A Level 2 DMZ would consist of multiple DMZ networks off of the firewall. This design is a substantial improvement over a Level 1 design. It allows traffic rules to be written between each DMZ for control and segregation. A good start is having separate DMZs for Web and application servers, databases, authentication services, VPNs, partner connections, e-mail and mobile services. This is very feasible today; most firewalls can easily handle tens of interfaces and multiple VLANs on each interface.

Level 3 DMZ designs

One problem often seen in Level 2 DMZ designs is that overly permissive firewall rules can lead to devices getting Internet access that should never have it. One way to rectify that is to use two firewalls. This design, which we’ll call Level 3, is built with an external firewall and an internal firewall. The DMZ is placed between the firewalls based on access restrictions. Inbound Internet access is allowed into the external DMZ via the external firewall—never directly routed to devices placed in the internal DMZ on the internal firewall. The internal network can talk to the internal DMZ but not the external DMZ.

This Level 3 DMZ design effectively separates Internet-connected devices and the services they require using just two firewalls with their own policies. Most security teams quickly understand the rule base design between externally accessible and internally accessible DMZs. The temptation is to create rules allowing inbound access from the DMZs to the internal network. This should never be allowed. All the services that are needed should be moved into DMZs so that internal networks are never exposed.

This restriction is often violated. A lack of coordination or communication between IT groups, the rush to deploy new applications, network complexity and other factors result in organizations building critical services on their internal networks.

Level 4 DMZ designs

Level 4 DMZ designs are where things start getting more complicated. A Level 4 scenario would most likely include deploying multiple firewall pairs in parallel along your border rail, and spreading your DMZs out among them, segregated by your choice of metrics. Most people choose to separate the firewalls into business or functional groups, while others like to separate them by trust levels.

Best practices dictate building separate firewall stacks based on Service Level Agreements (SLAs) and data classification. This creates a situation where there is an entirely separate firewall stack for PCI, separate firewalls for user services (such as Web browsing, FTP, e-mail, patching, etc.) and separate firewall stacks for business services. Consider business services placed in DMZs by SLA: 90 percent, 98 percent and 99.9 percent make for three good goals. Designing DMZs by SLA can streamline DMZ management and reduce business disruptions.

Conclusion

In closing, it’s imperative to place as much rigor as possible into the planning and design process. Assume that once the DMZ is live, it may not be so easy to fix major flaws in the design. Internal due diligence can be used as a way to establish strong lines of communication with other stakeholders—whether they are other IT folks, business owners, partners or managers. It can raise your profile within your company as a thoughtful risk manager and strategic thinker. And, perhaps most important, it will invite feedback outside your frame of reference. If one conversation with one person has a significant impact on DMZ design, wouldn’t you want to have that conversation before you design it?

Source

For 12% of CIOs, hearing complaints from employees over IT security measures — specifically, limits on their access to certain types of websites or networks while using the office network — is a common occurrence. Meanwhile, 29% of CIOs say such gripes are at least “somewhat common.”

The numbers come from a survey of more than CIOs, selected randomly from companies in the United States with 100 or more employees, conducted by staffing firm Robert Half Technology.

“There will always be employees who feel IT security policies are too restrictive,” said John Reed, executive director of Robert Half Technology, in a statement. “But in most situations, robust information security measures are necessary to protect sensitive data and an organization’s network integrity from increasingly sophisticated threats.”

On the other hand, said Reed, if too many people are complaining, then maybe it’s time to reevaluate whether an organization’s security policies have come down on the wrong side of the security-versus-productivity equation.

Rather than worrying whether their security policies are too restrictive, however, many organizations have a more fundamental problem: they lack any security policies, or else mechanisms for automatically enforcing those policies.

The result in either case is the same: employees often take their chances, ignoring any rules that they think are slowing them down, such as social networking restrictions or file transfer rules. According to numerous studies, when it comes to flouting security policies, IT personnel can be amongst the worst offenders.

But if corporate security or web access rules are cramping your style and making it harder to do your job, Reed recommends speaking up. “Some policies may simply be outdated and no longer make sense,” he said. “Asking someone in your organization’s IT department why access is restricted is often one of the quickest ways to resolve an issue.”

If policies aren’t judged to be outdated, he suggests talking up the business reasons for why they should change. “If employees can’t access a client’s website or a professional networking site that can generate business, it will probably be an easy case to make,” he said.

Source

There’s a tremendous buzz today about cloud computing, but before outsourcing your critical business systems to the cloud let’s review some security concerns.

The most critical business applications deal with corporate HR, finance, credit card, and other sensitive data. If any of this information is compromised lawsuits may ensue and your corporate brand is tarnished. This is a nightmare that could lead to customers avoiding purchasing your products or services. How can cloud computing effectively protect sensitive data?

There are three areas that need to be addressed to effectively push your applications into the cloud:

Let’s start with defense in depth.

First, put sensitive data in a second tier of firewall segments behind the main corporate firewalls. This second-tier firewall and corresponding network shields sensitive applications and their data from being easily accessed if the Web-facing firewalls are breached. For example, let’s look at grocery stores. It would be wise to deploy at least four firewall/network segments: one for HR data, one for financial data, one for credit card PCI (Payment Card Industry) data, and one for services that the other segments share. The segment containing services that are shared could contain common support services such as network and systems management, encryption and PKI functions, access control services, and security event management functions.

Another architectural implementation that protects corporations from internal data theft is the creation of a Tunneling Access Protocol. The Tunnel Access Protocol is an access control function that forces all administrators to log information before they perform administration on segment systems. Hence, all administrative access is tracked, discouraging internal theft of information

The second area that needs addressing is the analysis needed to determine successful migration of the application to behind the cloud’s second-tier firewalls. I recommend starting with the application design document first. It gives you a big-picture understanding of which business need the application performs, what middleware is used, what databases are used, and what protocols it uses. It also often contains the logical architecture.

It is important to focus on all the systems the application interacts with. Your security team will have a variety of information collected about the application: what data is sensitive, how and what tools are used to encrypt the data, and penetration testing results if it is a Web-facing application. Also, I recommend creating a protocol diagram showing all servers and their IP addresses, the protocols being used, and the protocol (TCP or UDP) ports being used. This network view specifically shows which servers need to talk to each other and what protocols (ports) they will use to do it. It is not necessary to include switches, routers and other network infrastructure components because the protocols/ports just ride over them. If the protocol diagram is thorough, it should be a simple step to create the firewall rules. Firewall rules are made up of source and destination IP (Internet Protocol) addresses, protocol used, and ports that ride on top of those protocols.

Lastly, I recommend a thorough collection of system and application metadata. The need to port your application well requires this work. Plus, if you have a disaster, business interruption or want to pull your application from the cloud — you need this data. System information exists per firewall/network segment. All applications share the same system data such as the same firewall, routers, switches, encryption algorithm (if used for all applications in a segment), and storage subsystem. System metadata includes vendor, model, software release and version, and other system-wide configuration data. Application data is similar but it addresses load balancers, encryption method, middleware, database, server hardware and operating system, and services, protocols, and ports that ride on top of those systems. Application metadata includes vendor, model, software release and version, and other application configuration data.

The next debate is where this metadata should be contained. I recommend containing this information in a hierarchy in a LDAP repository. I would create two tiers in the directory: one called Segment System for each of the four segments in the example above, and lastly one called Application for all applications within a given segment. This ordering enables a systematic collection of all metadata so that sensitive cloud applications can quickly be deployed. And, most importantly, it enables a quick deployment of the application and/or segment into a cloud.

In summary, migrating critical cloud applications involves putting data behind a second tier of firewalls. Common services exist in one of the segments that can be shared by all segmented applications. Applications should be in separate segments based upon the type of data that is being protected such as credit card data, finance data and HR data, and services that are shared. A variety of documentation should be created and/or reviewed to make sure that the porting of applications behind the second-tier ‘deep theater’ defense firewalls goes well. This collected metadata is from a hierarchy of two layers: common system per segment and different applications within each segment. I recommend the metadata be saved in a directory where it can be easily retrieved.

Source

Michigan CIO Ken Theis on state’s implementation of Einstein 2 intrusion detection system.

The numbers are staggering: the intrusion detection system Einstein 2 blocked 195,000 e-mail and spam messages as well 25,000 web defacements, 12,000 scanning, 18,000 Internet browser compromise and 17,000 intrusion prevention systems attempts. That for just one state and for just one day.

Michigan early this year became the first state to implement the Einstein 2 created by the federal Department of Homeland Security. What’s as important as blocking intrusions is the ability of the state to use Einstein to analyze the threat to its IT network, Ken Theis, director of Michigan Office of Technology and state chief information officer, said in an the second of a two-part interview with GovInfoSecurity.com.

“What Einstein has taught us is that even if you think you’re good, there are always opportunities to get a lot better, and I think Einstein has taken us up a couple of notches because it’s really providing us with a vision into a whole other level of threats that current processes in our current systems aren’t capable,” Theis said.

In the interview, conducted by GovInfoSecurity.com’s Eric Chabrow, Theis also discusses a framework Michigan has adopted to implement cloud computing in which the state, not cloud providers, prescribe the client-vendor relationship.

Source

In our continuing series of groundbreaking tests of cloud computing services, we take a look at what enterprises can expect if they decide to entrust data to a cloud storage provider.

We found that cloud storage lives up to its advance billing in two key areas: cloud storage can be fast and the pay-as-you-go model can be a real cost saver. We also found that security could be an issue for enterprise shops, and the formulas for trying to predict overall costs can be complex.

The services that we tested were Amazon S3, Rackspace’s CloudFiles, Egnyte’s On Demand File Server, Nasuni Cloud Storage, and Nirvanix’s Storage Delivery Network.

Amazon, Rackspace and Nirvanix represent the containerized/object-oriented model. Egnyte embodies the file/folder metaphor, while Nasuni offers a different twist – it’s a front-end that simplifies cloud storage for enterprise customers and connects to other cloud storage vendors on the back end.

To test cloud-based storage, we accessed the cloud vendor’s site through their supplied APIs, where applicable. We moved data either from virtual machines in our cabinet at n|Frame in Indianapolis at 100Mbps, or from our lab connected via standard Comcast broadband.

We pounded each site with a variety of file sizes ranging from 500KB to 1GB. We also tested in two periods, daytime and nighttime, to see if Internet congestion played a role in cloud storage performance.

Overall, performance was strong, although it was also somewhat random and unpredictable. Generally speaking we did get faster uploads and downloads at night, when Internet congestion is lower. And we found that download speeds were considerably slower than upload speeds for all the vendors tested.

Rackspace delivered the best overall performance, with an average speed 2.57Mbps for uploads and roughly 650Kbps for downloads. But all of the vendors delivered impressive performance.

Nirvanix delivered an average upload speed of 1.3Mbps and Egnyte topped 1Mbps. Amazon had the lowest average upload speed at 835Kbps, but also the highest download speed at 773Kbps, giving it the best balance between upload and download speeds.

Security concerns
Those desiring comfortable high security may be disappointed. While all of the vendors we tested provided link encryption, data encryption was glossed over by the container providers. We wanted to see port scrambling, and IP address access control lists, but these were missing across the board. Admittance control would, for some thinkers, break the cloud model by creating an extranet relationship between a subscriber and the cloud storage area, but we’d feel happier if there were greater admittance control by IP address. At press time, Amazon announced such IP address admittance control, along with HTTP_Referrer control (URL-based admittance), but we were unable to examine it at deadline.

Source

Developers of the 14 semifinalist algorithms for the new SHA-3 Secure Hash Algorithm standard will have a chance to defend their work next week at the second NIST candidate conference, being held at the University of California, Santa Barbara.

“We’re creating a record” on which to base selection of four to six finalists, expected to be named by the end of the year, said Bill Burr, manager of the Cryptographic Technology Group a the National Institute of Standards and Technology. “All in all we’ve got quite a bit of performance data. At this point we have a surprising amount of data on hardware implementation on all 14 candidates.”

Final selection of a new standard hashing algorithm for government is expected by early 2012, although that date could slip if additional analysis is needed, Burr said.

A hashing algorithm is a cryptographic formula for generating a unique, fixed-length numerical digest—or hash—of a message. Because the contents of the message cannot be derived from the hash and because the hash is to a high degree of probability unique for each message, it can be used to securely confirm that a document has not been altered. It also can be used to effectively sign an electronic document and link the signature to the contents.

SHA-3 will augment and eventually replace those algorithms now specified in Federal Information Processing Standard 180-2. The standard now includes SHA-1 as well as SHA-224, SHA-256, SHA-384 and SHA-512, collectively known as SHA-2. The standards undergo regular reviews and the decision was made to open a competition for SHA-3 in 2007 after weaknesses had been discovered in the currently approved algorithms.

Sixty-four algorithms were submitted to NIST in 2008, of which 51 were met minimum criteria for acceptance in the competition. The cryptographic community spent the next year hammering at the candidates, looking for flaws and weaknesses and 14 algorithms advanced to the second round in July 2009. The 14 second-round candidates are BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD and Skein. Candidate algorithms are available online, and NIST has published a status report on the first round of the competition.

Next week’s conference will give the entrants a chance to address the results of analysis and testing over the past year. The conference is being held in conjunction with this week’s overlapping CRYPTO 2010 conference and the workshops on Cryptographic Hardware and Embedded Systems, being held by the International Association for Cryptologic Research at Santa Barbara.

Harnessing the collective brainpower of the cryptographic community to identify strengths and weaknesses of possible hash algorithms is the idea behind the competition. This is the third cryptographic competition conducted by NIST to select a standard algorithm. The first, to select the Digital Encryption Standard in the 1970s, drew just two submissions, only one of which was seriously considered. In the 1990s the competition for the DES replacement, the Advanced Encryption Standard, drew about 15 submissions.

With 14 semifinalists to hear from, the conference schedule will be tight, with each presenter having only about 15 minutes to address results of analysis over the past year and present an argument for moving to the final round. After a second year of testing and analysis by the crypto community, a final candidate conference is expected to be held in the winter of 2012.

Even when the field has been narrowed to about five finalists, doing an analysis of cryptographic tools that are expected to remain in the federal toolkit for years to come takes considerable time and effort, Burr said, and there have been calls to slow down the process and extend it beyond the current 2012 end point.

“I’m not inclined to do that, but I’m open to arguments,” Burr said.

The timeline for selection will depend in part on developments in cryptography and in attacks against existing standards, he said. NIST might have some additional breathing space in selecting a new standard algorithm because there has been little progress toward breaking SHA-2.

“There was a lot of fear about how much progress there would be in attacking SHA-2,” Burr said, but hackers to not appear to be focusing on that. “SHA-2 is falling, although more slowly than we thought.”

Source

More than 80% of security administrators think that Web 2.0 applications — social networking tools, widgets, instant messaging programs, and their ilk — are undermining enterprise security. Furthermore, one in five think that employees rarely or never consider the consequences to corporate security of engaging in such activities as downloading applications from the Internet, streaming video, or using peer-to-peer file-sharing sites.

Those results come from a new survey of more than 2,100 IT security administrators in the United States, United Kingdom, France, Japan, and Australia. The survey was conducted by the Ponemon Institute and sponsored by Check Point Software Technologies.

“Our research finds security can be seen as an afterthought for corporate users of Web 2.0 applications; the growing number and sophistication of security threats, coupled with the proliferation of online and easily downloadable tools, is exacerbating the challenges of protecting sensitive information,” said Larry Ponemon, chairman and founder of the Ponemon Institute, in a statement.

The survey also found that nearly half of security managers think that minimizing Web 2.0 risks is an urgent priority. According to respondents, the top threats posed by Web 2.0 applications are, in order, poor workplace productivity, malware, data loss, and viruses.

But so far, spending on Web 2.0 security technology lags. “While this is an issue that must be addressed through strategic investment in technology and awareness, our research also shows that most IT administrators do not believe their organizations have sufficient resources dedicated to securing critical web applications,” according to Ponemon.

On a related note, Check Point Monday announced its forthcoming release of Application Control Software Blade, which can control and manage the use of Web 2.0 applications in the enterprise. The product will use the Check Point AppWiki, which catalogs more than 50,000 Web 2.0 widgets and more than 4,500 Internet applications, including social networking, instant messaging, and media streaming tools. The tool can be centrally managed — together with other Check Point “software blades” — from a single Check Point console, and will also integrate with any of the company’s security gateways, such as UTM-1 or Power-1.

Check Point plans to release the Application Control Software Blade by the end of the year.

Source

The UK’s Cyber Security Challenge has announced the winner of its prologue crypto puzzle, as well as the solution – for anyone still struggling to find an answer.

Successful code crackers had to solve a three-stage puzzle of increasing complexity. The task tested basic cryptoanalysis skills, as well as the ability to apply lateral thinking and “read between the lines” to figure out how to proceed from one stage of the puzzle to the next. The first stage involved recognising that the initial ciphertext took the form of a .jpg image, encoded in the base64 system. This .jpg image cartoon contained a binary string on its border, encoded using a simple substitution cipher.

Having solved that stage of the puzzle, would-be codebreakers recovered a message inviting them to visit a specified website. The third phase of the challenge was based on making sense of a bitshift operation applied to a string hosted on this site.

More than 1000 contestants submitted responses to the puzzle with 152 hitting on the right answer. Winner Paul Mutton cracked the code before anyone else and wins a season ticket for Bletchley Park and a personal tour of the refurbished WWII-era Colossus code-breaking computer.

Cyber Security Challenge said it planned to run another code-cracking puzzle at an unspecified time over the coming months, following the success and obvious interest generated by its initial brain teaser.

The cipher challenge was essentially a bit of fun designed to publicise the wider ambitions of the UK’s Cyber Security Challenge, which aims to hunt for would-be information security experts and stimulate interest in the topic. The scheme, launched on Monday, aims to address a looming skills shortage by inspiring under-graduates and teenagers to consider a career in cybersecurity.

More than 30 prizes will be awarded during the competition, including internships at net security companies and university bursaries. The scheme has the support of private security firms such as Sophos and Qinetiq, as well as the UK government.

Source

Cyber terrorists have a number of ways to mount a major cyber attack on U.S. Internet infrastructure due to the general instability of its base, the director of the agency in charge of protecting the federal government’s IT network said Wednesday.

“With decades of IT infrastructure built to support changing technologies, there is little ability to baseline the entire infrastructure within the United States,” said Randy Vickers, director of the United States Computer Emergency Readiness Team (US-CERT), in an interview Wednesday. “This variety of platforms and applications provides many possible vectors by which to attack infrastructure.”

Vickers is scheduled to join other IT leaders from government agencies for a panel to discuss the threat of cyber war and how to deter it at the Black Hat security conference in Las Vegas on Thursday.

US-CERT is a division of the Department of Homeland Security (DHS) responsible for responding to and defending against cyber attacks for the federal government’s IT infrastructure. It also is in charge of sharing information and collaborating with state and local governments as well as the private sector to protect critical infrastructure in the U.S.

Vickers said that critical infrastructure is not likely to become less prone to attacks anytime soon. He cited ongoing changes in the IT landscape — such as cloud computing and an increasingly mobile workforce — as conditions that only open up infrastructure to more threats.

“The environment is only going to increase in complexity, and as more threat capabilities are developed the risk to our information infrastructure that we are so heavily dependent upon also increases,” he said.

To achieve its goal to keep an eye on federal networks, the DHS is currently deploying an intrusion-detection and security system called EINSTEIN 2, Vickers said. The system is currently operational at 12 of 19 federal agencies, providing US-CERT with, on average, visibility into more than 278,000 indicators of potentially malicious activity per month, he said.

EINSTEIN 2 should be fully deployed at the federal government by the end of the year, after which the DHS will take security to the next level with EINSTEIN 3, Vickers said.

EINSTEIN 3, developed by the National Security Agency, is the third phase of the Comprehensive National Cybersecurity Initiative (CNCI), and will provide intrusion prevention on top of EINSTEIN 2′s intrusion-detection capability, he said. The first phase of the system — EINSTEIN 1 — is currently in deployment as system that gathers information about network traffic.

US-CERT first revealed details about EINSTEIN 3 in March. At the time, the DHS said the system will do real-time, deep packet inspection and make decisions based on threats by examining network traffic at the edge of federal agency networks.

This activity will redirect agency Internet traffic to DHS cybersecurity systems, which will determine which traffic might be associated with cyber threats and how to respond, they said. The DHS worked with a commercial Internet service provider to do a test deployment of EINSTEIN 3 earlier this year. Vickers said these types of private-public partnerships will continue as the federal government continues to work to secure its network infrastructure against cyber attacks.

“At the end of the day, the architecture for the dot-gov’s cyber perimeter defense will be hybrid of government and private technologies,” he said.

Source

LAS VEGAS–A security researcher has found a slew of fundamental problems with the way that modern browsers are designed and built, leading to serious questions about the security of these applications and the way that they handle SSL sessions.

The research, done by Robert Hansen of SecTheory, shows that browsers such as Firefox, Internet Explorer and Chrome have a number of architectural problems that can essentially negate the security that SSL is meant to provide for sensitive Web transactions. The techniques that Hansen has developed, which he demonstrated at the Black Hat conference here Thursday, give an attacker the ability to do any number of nasty things to a target machine, including forcing the download of an executable file, overwriting the URL field in the browser and overwrite secure HTTPS cookies with non-secure cookies.

In all, Hansen found 24 problems before he decided to stop looking. “I had basically had to stop the research because there were just too many issues. I didn’t have time to deal with anymore,” Hansen said.

A big part of the problem, Hansen said in an interview, is that browsers don’t enforce policies that would isolate the tabs in an open browser from one another. This allows an attacker who can control one of the tabs, say a normal non-SSL session, to also affect content in the other tabs, even if they’re using SSL. Hansen identified several techniques that enable him to watch an SSL-protected session and glean a lot of information about what the user is doing, based on timing certain parts of the Web session and knowing how long it takes for part of a site to load. He also can tell whether a user is logged in on a given site and use a specific technique to log the user out so he can then watch the login operation and steal the credentials.

“When you look at it, what does SSL really offer? What this means is that for the average user, against a determined adversary, there really is no protection,” said Hansen, who presented his findings at the Black Hat conference here Thursday. “People give SSL and TLS a lot of credit, when it shouldn’t have any at all.”

SSL is the main transport security used by millions of Web sites to protect data being sent from browsers to Web servers. It’s been shown to be vulnerable to a number of different attacks, including several man-in-the-middle attacks, which could be used in conjunction with some of Hansen’s techniques to completely compromise a supposedly secure Web session.

“The most important thing is that if an attacker can map out the domain ahead of time, he can get a really good feel for how the site is built,” Hansen said. “If there’s a side channel, I can force them to precache some of the content on the page so that I don’t see that again when they reload the page. Then, the only thing you’re seeing are the things that are interesting to the attacker. You can map out the user’s flow around the site and the attacker can force the user to make an SSL connection to them so they can tell which SSL and HTTP headers are being sent in which direction. It’s about narrowing down the number of bytes that are interesting.”

As troubling as the problems that Hansen found are, he emphasized that they don’t mean that the sky is falling.

“You still need to be a man in the middle first and there are probably easier ways to attack people once you are, but there are a lot of issues here,” he said. “If there was better jitter and padding in SSL, a lof of this wouldn’t even be possible.”

Source