TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why not DANE in browsers

30 pointsby Nimiover 10 years ago

3 comments

jasetover 10 years ago
Previous discussion <a href="https://news.ycombinator.com/item?id=8908880" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8908880</a>
nlyover 10 years ago
Neither HPKP nor HSTS deal with the issue of a-man-in-the-middle doing a downgrade attack against clients who are visiting a site for the very first time (which can be encouraged through phishing). There are only three ways to deal with this that I can think of:<p>1) Deprecate insecure HTTP. Literally get all the browsers to agree on a deadline X years out and then drop support for it entirely. HSTS would become irrelevant. I hold little hope of this ever happening, even in a HTTP&#x2F;2 world. See IPv6<p>2) Keep increasing the size of the trusted, preloaded list of HTTPS enabled sites shipping with browsers: Neither the implementation nor the process to manage the list scales. It&#x27;s just crappy all-round.<p>3) Standardise some SRV records for web protocols in the DNS so browsers can efficiently determine what is supported: Requires DNSSEC to prevent downgrade attacks.<p>Of these, #3 seems to me to be most practical. With regard to DNSSEC issues I would give these counterpoints:<p>* DNSSEC could and should be augmented to support ECC, obliterating the concerns with regard to large records and weak RSA key lengths.<p>* Browsers (or your OS&#x27;s dnscache process) can cache DNS responses from most of the chain. If the ZSK hasn&#x27;t been rolled over for a particular domain then I don&#x27;t see the need to reverify it again on each request. It&#x27;s not like revocation really works in HTTPS today anyway, so you probably aren&#x27;t going to bother to check upstream for NSEC records on each request. Or just recheck upstream once a day. I don&#x27;t really know, but I&#x27;m sure these latency issues can be minimized. Googles obsession with latency is how we ended up with the barf that is HTTP&#x2F;2 rather than something that actually improves websec in the first place.<p>Another thing I don&#x27;t often see people mention about HSKP and HSTS, regardless of whether they can be used as &quot;supercookies&quot;, is that they create a more-or-less permanent shadow browser history on your machine. This alone is borderline show-stopper afaiac
评论 #8912452 未加载
评论 #8912149 未加载
评论 #8912193 未加载
mike-cardwellover 10 years ago
I agree with his comments on HPKP. I looked in to adding HPKP headers to a couple of my sites, and figured out how to do it, but I&#x27;m nervous about enabling it. It seems far too easy to make a mistake and lock people out of being able to visit your site. The trouble is, if you make a mistake, they&#x27;re not locked out until you get around to fixing it. They&#x27;re locked out until the expiry date which you set in the HPKP headers, which could be months away.<p>We lack the proper tools to make this safe.
评论 #8912082 未加载
评论 #8912063 未加载