Perimeter
Guest Blog // Selected Security Content Provided By Sophos
What's This?
5/24/2012
08:53 AM
Dark Reading
Dark Reading
Security Insights
Connect Directly
RSS
E-Mail
50%
50%

What A Secure Top-Level Domain Can And Can't Do

Is the .secure domain a better mousetrap, or does it lead only to the same dead end?

As Ralph Waldo Emerson once surmised, "Build a better mousetrap and the world will beat a path to your door."

Maybe so. Then again, maybe no.

I have to say I was equally intrigued and amused by the recent news announced by Artemis introducing a new top-level domain (TLD) that folds in security for Internet member sites from inception.

As reported on Decrypted.com, to become a secure "member" in this club you would first submit your organization for screening. In turn, the screening process would confirm you are who you say you are by verifying things like articles of incorporation, trademarks, site address, IP address, and so on. Once you pass this level of screening, you would be supplied with hardware that supports two-factor authentication and registers this at the location for the edge of your network.

Additionally, this membership process would require all data and Web traffic be encrypted end-to-end. Mail traffic would require use of the OTLS (opportunistic transport layer security), which encrypts data before it’s transmitted to the destination server.

For its part, Artemis will continue to scan all the sites with the .secure extension to ensure they are not and have not been compromised in any way. If a compromise is detected (for example, infection by malware), then it is removed from the so-called "walled garden" until it cleaned up. Repeat offenders would be permanently removed.

As reported by Kelly Jackson Higgins here on Dark Reading, Artemis CTO John Stamos believes incremental security, such as a .secure domain, has value.

"Effortless security is our tagline. Right now, when you go to .com, you have to look for five different visual clues to figure what’s going on security-wise," Stamos says. "If you type .secure, you're telling the server or organization that you want to communicate with that you want to be safe and expect them to be as safe as possible. All of that security stuff is taken care of for you."

For his part Stamos doesn't see every .com as a potential customer; instead, he expects financial institutions and other security-sensitive businesses to adopt the new domain for their pages that handle transactions, for example, or sensitive data. "We're not trying to tell people to throw away your .com, but if you are a bank that runs hundreds of websites for users who do billion-dollar transactions, that site could go to the .secure domain," he says.

As you'd expect, this announcement is drawing skepticism from many quarters.

That includes Constantine von Hoffman. In his column on CIO.com, called "Why the New .Secure Domain Idea is a Dud," he draws an inference between personal and corporate responsibility and why neither party in an exchange of data can completely abdicate their respective responsibilities:

"Just as in the physical world, I am responsible for getting myself to the bank securely. I don't run around with money popping out of my pockets, and I don't use random Internet connections to connect to banking sites. That's my responsibility. Just like it's my responsibility to know if I live in a place where my doors need to be locked or I can leave my car keys in the ignition at night. Users should be able to take some parts of online security for granted, but other parts are--and should be--the user's responsibility."

From a technical perspective, there's the complaint voiced by independent researcher Moxie Marlinspike, who concludes that the .secure plan won't solve an underlying problem that arises from putting trust for digital data and services into the hands of commercial entities subject to the whims of various governments, which are notorious for their lax security practices.

"If we sign up to trust the organizations who manage that infrastructure, we're signing up to trust them forever; without any opportunity to change our minds in the future, and without any incentives for them to continue warranting our trust," Marlinspike says.

So where do I come in on this one?

Well, .secure has some good features, and the principles behind its founding appear sound, but it looks, at least from my reading of what has been said so far, that its primary aim is to reduce phishing and hijacking. The measures they suggest (DNSSEC zone signing and TLS for all HTTP) are designed to reassure the end user that:

1) They are communicating with the correct website.

2) Their communications are not being eavesdropped.

These are great precautions against phishing attacks, but what they do not ensure is that the site itself has not been hacked. Some of these measures are things that sites with sensitive information are already doing. In fact, even the most recalcitrant Web security administrators should have learned from FireSheep that sensitive traffic must be encrypted.

The .secure system will apparently scan .secure sites for vulnerabilities and hosted malware with SLAs to fix anything found, but that is not the same as being truly safe.

As Stamos himself says on his Unhandled Exception blog's FAQ, "I'll say it right now: a server running a .Secure site will get hacked. A web app hosted under .Secure will get hacked. Software, like humans, is fallible and we would be foolish to expect or promise perfection with even the best implemented and tested controls."

Moreover (and not being a hacker myself but knowing something about the mindset), I can't help thinking that a .secure domain is the metaphorical equivalent of waving the proverbial red flag in front of a bull’s eyes.

In fact, one of the questions on Stamos' blog asks, "Won't .Secure just attract hackers looking to make a point?" To which Stamos retorts, "Any organization for whom .Secure makes sense is already a target. Their level of adversity currently ranges from small-time criminals and amateurs looking to make a name for themselves up to nation-state actors and dedicated, professional white-hat researchers. It is possible that LocalBookShop Inc. would face additional scrutiny due to a .Secure domain, but attacker quality is not going to differ greatly between payments.globobank.com and payments.globobank.secure."

There's also the sheer marketing effort required to evangelize the .secure domain. In fact, my concern with .secure would be that the average user will not be aware of the subtleties behind it and will assume that .secure means secure. While it certainly raises the bar a little (although only a little because many of the institutions to whom .secure is marketed already take such precautions), it's not the same as a secure gated Internet.

In other words, Artemis has presented a better mousetrap, but the bait it's using to attract members, ultimately, may not be palatable to either the (member) mouse or the (online) company that's trying to trap it.

Brian Royer, a security subject matter expert, Sophos U.S., is partnering with SophosLabs to research and report on the latest trends in malware, Web threats, endpoint and data protection, mobile security, cloud computing and data center virtualization.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-0334
Published: 2014-10-31
Bundler before 1.7, when multiple top-level source lines are used, allows remote attackers to install arbitrary gems by creating a gem with the same name as another gem in a different source.

CVE-2014-2334
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2335
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2336
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 and FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2334 and CVE-2014-2335.

CVE-2014-3366
Published: 2014-10-31
SQL injection vulnerability in the administrative web interface in Cisco Unified Communications Manager allows remote authenticated users to execute arbitrary SQL commands via a crafted response, aka Bug ID CSCup88089.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.