LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityA ".secure" top-level domainOn May 10, Ars Technica reported on a new proposal to create a .secure top-level domain (TLD) that would enforce deployment of encryption and security protocols on all sites and scrutinize all registrants to verify their identity. The idea is being floated by the company that wants to be the registrar and manager of the TLD, however, and regardless of how noble its intentions may be, it still needs to make a strong case for how a domain-bound solution improves on existing security practices. The initial proposal and initial reactionsThe proposal comes from Alex Stamos of research firm iSec Partners, and would appoint Artemis Internet as the gatekeeper of .secure. Artemis would require registered domains to encrypt all web and email traffic (except for HTTP redirects funneling connections towards the appropriate TLS-encrypted site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam prevention. In addition, Artemis would employ a rigorous screening process to verify registrants' identities (including reviewing articles of incorporation and human interviews), and routinely conduct security scans of registered sites. The venture has $9.6 million (US) in funding provided by Artemis' parent company NCC Group, a UK-based IT security firm. The Artemis site says ".secure is not a category or destination. It is an expression of the user's intent to use the Internet safely," but so far offers few additional implementation details. After a number of Ars Technica readers expressed their skepticism in the comment thread, though, Stamos responded to several questions on the site (although, ironically, we have no way to verify that the poster is Stamos). Several commenters expressed doubt that the lofty goal of enforcing strong encryption and strictly-verified identities was practical on a large scale, while others argued that the proposed rules for registrants offer nothing that secure sites cannot already do today — thus making the special domain unnecessary. To the latter charge, Stamos replied that the goal was to automatically make secure choices whenever the user entered a .secure URL, rather than rely on the user to verify the security of a connection upon visiting a site:
The basic goal of .Secure is to invert the security user
experience when using the Internet. Right now you type somesite.com,
and then you are expected to look for user interface clues and even
dive into details (depending on your expected adversary) to determine
whether you got there safely. And if things go slightly wrong, you
are prompted to make a decision based upon your understanding of
discrete mathematics and the X.509v3 spec.
A reader who goes by VideoGameTech argued that even with a strict security policy enforced on the actual .secure sites, users would still be vulnerable to attacks like DNS hijacking and URL-obfuscation through email spam. Stamos responded that requiring DNSSEC would protect users against DNS hijacking, and that other measures would make spam attacks less likely, saying:
We continue to recommend that legitimate emails like this do
not contain clickable links, and that mail/spam providers continue to
improve their detection of URL/text mismatch. That being said, we'll
be attacking the spam problem in the From: field aggressively with
required DKIM and SMTP TLS with a real certificate.
PolicyStamos also added that Artemis was drafting a proposal called the Domain Policy Framework (DPF), which would allow a domain to specify a security policy to be stored in DNS TXT records that browsers and other client applications could securely retrieve over DNSSEC. He later posted an initial specification of DPF to his blog. The specification itself is hosted at Scribd.com; a PDF version can be downloaded from the Scribd page. The proposed DPF specification enumerates 15 separate security entries, broken up into "network and identity," "email," and "WWW" sections. They cover basic requirements like whether a domain requires DNSSEC and/or TLS, plus details like expected email signature algorithms, plus general identity information. Artemis has also started a project it calls the Domain Policy Working Group to create DPF, although at the moment it does not list any other members. The group's site does state that its intention is to submit DPF to the Internet Engineering Task Force (IETF) RFC process, and to create supporting standards. Yet another CA?Some commenters at Ars Technica and on our own story felt that the proposal boiled down to little more than Artemis vowing to be a certificate authority (CA) that actually acted responsibly — which so many CAs seem to have trouble doing. It would also appear that the .secure domain would require that only the Artemis CA be allowed to sign site certificates for the TLD or else a subverted CA could start issuing bogus .secure certificates. That, of course, means that subverting Artemis itself could lead to the same problem On the other hand, it is at least true that running an entire TLD securely would be more visible to the end user than would running a flawless CA. Consider, for comparison's sake, the Extended Validation (EV) SSL certificate concept. EV certificates were supposed to bolster security by inflicting a rigorous, fraud-proof identity verification process on all applicants. The trouble was that, as the Wall Street Journal reported, most users failed to notice the difference in their browser's UI. Barring any other improvements, if Artemis managed to cultivate a good reputation for running .secure, it would be easier for a casual user to spot the TLD than to dig into the the certificate chain-of-trust for another site. Speaking of previous enhanced-security efforts, the .secure TLD was floated as an idea in 2011 as well, under greatly differing circumstances. Back then it was the US government proposing a heavily-fortified subset of the Internet to live in .secure. That proposal had different components, including ongoing monitoring with intrusion detection and prevention software. But Chris Palmer of the Electronic Frontier Foundation (EFF) responded by critiquing the core notion that better identity verification would provide a security for users: But what does “authentication” mean on the
internet? People often (implicitly) take it to mean something like
“Through this web browser I am talking to the true Wells Fargo Bank,
and Wells knows that I am the true Chris Palmer.” However, when one
computer presents credentials (such as a username and password pair or
a cryptographic certificate) to another, the link between software
data structure and real-world entity (like a person or a business) is
weak. It is no stronger than the person’s or business’ ability to
ensure that the computers on both ends are operating correctly and are
not compromised, and that the channel between them is secure against
network threats. From painful experience we know that our operating
systems suffer from numerous design and implementation flaws, and that
malware and system hacks are all-too-prevalent.
[...]
For economic reasons (such as Metcalfe’s Law and economies of scale),
networks tend to converge, not diverge. (We will probably use the same
computers (and wires!) to connect to the real internet as to the
.secure internet.)
Echoing that sentiment, Ars Technica reader Mark Havel asked whether Artemis' .secure proposal would come with any guarantees that security patches would be quickly and routinely applied to all servers on .secure sites. Others pointed out that for end users, the only difference between a .secure site and a site in another TLD would be if Artemis offered liability protection against attacks. As reader Fuzzmz said, "Yes, I can visit a .secure domain with a bit more peace of mind, but if something goes haywire then I'm left in the same place as I was if it happened on a .com domain." There is also the question of whether a hardened .secure domain would attract a larger share of attackers than would the same sites hosted at .com or other TLDs. Some commenters suggested that cracking a .secure site would be an attractive achievement for fame-seekers. On a separate note, if the .secure TLD did successfully become associated with higher security in end users' minds, it would consequently make a more appealing target. In short, there is not much in the .secure proposal from Artemis that a server could not implement today (DPF, which is not limited to .secure, necessarily, depends on browser adoption). But even with a secure connection to a fully-patched server, it is up to the human being in front of the screen to pick out all manner of security attacks, from phishing spam to URL obfuscation, and that human being still relies heavily on the browser to expose and communicate threats in an understandable manner. Without question, the principles that the Artemis site hails as critical — verification, security, and enforcement — are vital to creating a secure web and email environment. But the company still needs to make a stronger case for how tying those principles to a particular TLD improves things over the status quo for the human/browser combination, not to mention why that responsibility should rest with a private, commercial enterprise.
Brief items Security quotes of the week
Consider disabling SELinux and auditing. We recommend to leave SELinux on, for security reasons, but truth be told you can save 100ms of your boot if you disable it. Use selinux=0 on the kernel cmdline.
-- Lennart Poettering
I operate a ~10k botnet using a ZeuS software I modified myself, including
IRC, DDoS and bitcoin mining (13GH/s - 20GH/s atm). Everything operating
tru TOR hidden service so no feds will take my servers down. (Don't worry,
traffic intensive stuff is not tru TOR and the bots work as relays too,
enchancing your TOR experience!)
-- "throwaway236236"
in a reddit "Ask me anything"
When I got to the orthopedist’s office a few days later, I gave the receptionist the CD, which she promptly read into the medical records computer and returned to me. It occurred to me that the risk taken in reading a CD or other media from an unknown source is pretty substantial, something we’ve known in the security world for decades but has not filtered well into other fields. On the other hand, every time I’m on a conference program committee I open PDFs from people I may never have heard of, so it’s not as if I’m immune from this risk myself.
-- Jeremy Epstein
When I got home, I read the CD on my Mac laptop, and discovered that it has an autorun.INF file to start the application that reads the x-ray data files. I don’t know whether the doctor’s office disables AutoRun on their computers; undoubtedly some doctors do and others don’t. And even if the doctors’ computers have disabled AutoRun and don’t use the software on the CD to view the test results, how secure are they against data-driven attacks, such as we saw a number of years ago against JPEG files in browsers?
My own private Internet: .secure TLD floated as bad-guy-free zone (Ars Technica)Dan Goodin at Ars Technica reports on iSec Partners, a company proposing to make .secure into a heavily-vetted high security domain. "Sites that wanted to be a part of this exclusive domain would have to undergo rigorous screening to verify their identity. Physical addresses, trademark registrations, articles of incorporation, and other legal documents would be reviewed by human beings. Upon approval, applicants would receive two-factor authentication hardware to register online. They would also be required to meet a minimum set of security practices, including end-to-end encryption of virtually all Web and e-mail traffic."
New vulnerabilities bind-dyndb-ldap: denial of service
chromium: multiple vulnerabilities
connman: code execution
coreutils: command injection
ffmpeg: multiple vulnerabilities
gridengine: privilege escalation
grub2: insecure permissions in bootloader configuration
kernel: multiple vulnerabilities
kernel: unfiltered netdev rio_ioctl access by users
libjakarta-poi-java: denial of service
libsoup: insecure SSL handling
mysql-cluster: multiple unspecified vulnerabilities
openssl: denial of service
postgresql-pgpool: multiple vulnerabilities
roundcubemail: multiple vulnerabilities
taglib: denial of service
wordpress: multiple vulnerabilities
wordpress: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||