Follow @Openwall on Twitter for new release announcements and other news
[<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

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.