DSTC: DNS-based Strict TLS Configurations

TL;DR

This paper introduces a DNS-based mechanism allowing TLS servers to advertise support for the latest protocols and strong ciphersuites, enabling clients to enforce stricter security policies with minimal overhead.

Contribution

It proposes a novel DNS-based approach for servers to advertise TLS configurations, improving security without sacrificing backward compatibility.

Findings

Feasible implementation with minimal overhead

Most top websites can benefit from the mechanism

Enhanced security enforcement for clients

Abstract

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.