Enabling Practical IPsec authentication for the Internet

On the Move to Meaningful Internet Systems 2006: OTM 2006 Workshops (First International Workshop on Information Security (IS'06), OTM Federated Conferences and workshops). Montpellier, Oct,/Nov. 2006There is a strong consensus about the need for IPsec, although its use is not widespread for end-to-end communications. One of the main reasons for this is the difficulty for authenticating two end-hosts that do not share a secret or do not rely on a common Certification Authority. In this paper we propose a modification to IKE to use reverse DNS and DNSSEC (named DNSSEC-to-IKE) to provide end-to-end authentication to Internet hosts that do not share any secret, without requiring the deployment of a new infrastructure. We perform a comparative analysis in terms of requirements, provided security and performance with state-of-the-art IKE authentication methods and with a recent proposal for IPv6 based on CGA. We conclude that DNSSEC-to-IKE enables the use of IPsec in a broad range of scenarios in which it was not applicable, at the price of offering slightly less security and incurring in higher performance costs.Universidad de Montpellier IIPublicad

DSTC: DNS-based Strict TLS Configurations

Most TLS clients such as modern web browsers enforce coarse-grained TLS security configurations. They support legacy versions of the protocol that have known design weaknesses, and weak ciphersuites that provide fewer security guarantees (e.g. non Forward-Secrecy), mainly to provide backward compatibility. This opens doors to downgrade attacks, as is the case of the POODLE attack [18], which exploits the client's silent fallback to downgrade the protocol version to exploit the legacy version's flaws. To achieve a better balance between security and backward compatibility, we propose a DNS-based mechanism that enables TLS servers to advertise their support for the latest version of the protocol and strong ciphersuites (that provide Forward-Secrecy and Authenticated-Encryption simultaneously). This enables clients to consider prior knowledge about the servers' TLS configurations to enforce a fine-grained TLS configurations policy. That is, the client enforces strict TLS configurations for connections going to the advertising servers, while enforcing default configurations for the rest of the connections. We implement and evaluate the proposed mechanism and show that it is feasible, and incurs minimal overhead. Furthermore, we conduct a TLS scan for the top 10,000 most visited websites globally, and show that most of the websites can benefit from our mechanism

BlockPKI: An Automated, Resilient, and Transparent Public-Key Infrastructure

This paper describes BlockPKI, a blockchain-based public-key infrastructure that enables an automated, resilient, and transparent issuance of digital certificates. Our goal is to address several shortcomings of the current TLS infrastructure and its proposed extensions. In particular, we aim at reducing the power of individual certification authorities and make their actions publicly visible and accountable, without introducing yet another trusted third party. To demonstrate the benefits and practicality of our system, we present evaluation results and describe our prototype implementation.Comment: Workshop on Blockchain and Sharing Economy Application

How Do Tor Users Interact With Onion Services?

Onion services are anonymous network services that are exposed over the Tor network. In contrast to conventional Internet services, onion services are private, generally not indexed by search engines, and use self-certifying domain names that are long and difficult for humans to read. In this paper, we study how people perceive, understand, and use onion services based on data from 17 semi-structured interviews and an online survey of 517 users. We find that users have an incomplete mental model of onion services, use these services for anonymity and have varying trust in onion services in general. Users also have difficulty discovering and tracking onion sites and authenticating them. Finally, users want technical improvements to onion services and better information on how to use them. Our findings suggest various improvements for the security and usability of Tor onion services, including ways to automatically detect phishing of onion services, more clear security indicators, and ways to manage onion domain names that are difficult to remember.Comment: Appeared in USENIX Security Symposium 201

Securing The Root: A Proposal For Distributing Signing Authority

Management of the Domain Name System (DNS) root zone file is a uniquely global policy problem. For the Internet to connect everyone, the root must be coordinated and compatible. While authority over the legacy root zone file has been contentious and divisive at times, everyone agrees that the Internet should be made more secure. A newly standardized protocol, DNS Security Extensions (DNSSEC), would make the Internet's infrastructure more secure. In order to fully implement DNSSEC, the procedures for managing the DNS root must be revised. Therein lies an opportunity. In revising the root zone management procedures, we can develop a new solution that diminishes the impact of the legacy monopoly held by the U.S. government and avoids another contentious debate over unilateral U.S. control. In this paper we describe the outlines of a new system for the management of a DNSSEC-enabled root. Our proposal distributes authority over securing the root, unlike another recently suggested method, while avoiding the risks and pitfalls of an intergovernmental power sharing scheme