Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Oct 2014 11:59:21 +0200
From: Hanno Böck <>
Subject: Re: attacking hsts through ntp

Am Fri, 17 Oct 2014 08:50:57 -0700
schrieb Tim <>:

> It seems to be a better place to put HSTS-like information is the DNS.

I hear this "we need to fix TLS/HTTPS with DNSSEC" a lot.

There are a couple of difficulties with that:
1. DNSSEC is currently mostly vapoware. At least since the kaminsky DNS
attacks (2008!) I'm hearing "DNSSEC is coming". The reality is: it's
not. Adoption is very rare today. This may change, but I don't see
anyone rushing to DNSSEC.
2. Even if DNSSEC would work: How exactly do you want a browser to
check dnssec records? Should it have its own dns server? Because right
now the usual setup is:
* Provider runs DNS server
* (sometimes) router is running a DNS server which is basically
  forwarding requests to the provider DNS
* Client has no own DNS, just queries router or provider DNS

Basically, the current situation doesn't really consider having DNSSEC
verified on the client. This could of course be fixed by either having
a local DNS resolver running or having the browsers ship their own DNS
resolver. However that's a rather huge change and it will likely have
some other implications (portal pages come to mind) - and I don't see
anybody working on this.

That said: I wouldn't entirely throw the idea away of using dnssec to
increase tls security. But it's not something we can do today or any
time soon.

Hanno Böck


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ