New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 119 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Oct 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Feature

Blocking:
issue 480920

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Implement DNSSEC verification

Reported by harvi...@gmail.com, Aug 1 2010

Issue description

Hello,
i think it would be usefull to start implementing DNSSEC validation. there are libraries for this. For example: libval from http://dnssec-tools.org/ and minimalistic libldns from http://www.nlnetlabs.nl/projects/ldns/ (which i can really suggest to you).

Thank you.
 
Labels: -Restrict-View-SecurityTeam -Security -Pri-0 -Type-Bug -Area-Undefined Type-Feature Area-Internals Internals-Network
Status: Untriaged
This issue template is for reporting security bugs, not making feature requests. In the future please use the following template for feature requests:

http://code.google.com/p/chromium/issues/entry?template=New%20Feature

Eric, Wan-Teh, I don't see an open request for this yet. Not that there's any rush, but is this on anyone's radar?

Comment 2 by harvi...@gmail.com, Aug 2 2010

Well. i've made (and attached) simple DNSSEC validator plugin for chromium, but it's in early stage of development but it works somehow. Only thing it does is showing red icon on fraudent sites and yellow on every other site (trusted and non-signed). it uses external binary of program called drill (from ldns or libldns package), which is launched with npexec plugin (NPAPI which enables you to call system() call from javascript) right now it's synchronous and therefore very slow. i want to implement following things in future (if i will found it usefull):

TODO:
* multiple DNSSEC lookups at the time (asynchronous or multithreaded NPAPI plugin).
* block user from using sites with fraudent DNS records (not only showing icons)
* distinguish between non-signed and secure domains (parse drill output or patch drill)
* compile NPAPI plugin for Windows, Linux64 and MacOS. Currently i have only .so for 32bit Linux, but it should build as it is without any code changes.
* pack static drill binary and root-zone key to plugin
* plugin configuration page (change drill binary path or root-zone certificate, whitelist domains)
chromium-drill-dnssec-validator.zip
196 KB Download

Comment 3 by wtc@chromium.org, Aug 2 2010

Labels: Mstone-X
Status: Available

Comment 4 by agl@chromium.org, Aug 2 2010

We are considering our position with respect to DNSSEC. DNSSEC validation of A records and the like isn't useful and doesn't warrant any UI indication. DNSSEC validation of certificates may, but it would be premature to submit patches for that at this time.

Cheers

AGL

Comment 5 by ulevi...@gmail.com, Oct 28 2010

Could you clarify what you mean by "DNSSEC validation of A records and the like isn't useful and doesn't warrant any UI indication?"

Comment 6 by agl@chromium.org, Oct 28 2010

I mean that, even if we are sure that "www.example.com A 1.2.3.4", that doesn't get us anything. We could make a connection to 1.2.3.4 but that connection can be hijacked. We need a fingerprint of a public key etc in order to trust the identity of a server.

Comment 7 by ulevi...@gmail.com, Oct 28 2010

Adam -- Thanks for responding, what you mentioni is very true, which means you still require SSL for valid identification.  That said, I think there are some folks who believe that DNSSEC validated responses might include application-specific data to help with this and look more like:

www.example.com A 1.2.3.4
www.example.com NONCE asd8ujk3h4ad89

And then an unsecured 1.2.3.4 connection might have a X-Nonce: asd8ujk3h4ad89 header or similar.  Thus identity is established, even if not the connection is not encrypted.[1]

The same model can be applied to SSH fingerprints handed back over DNS, etc (SSH FP DNS qtype).

In this case, using DNSSEC as a substitute for SSL (indicating "secure" or "not secure" or similar) is not accurate for the reasons you mentioned though additional affirmations for non-encrypted connections become possible.

What I think is true is that without application-level support for DNSSEC validation responses, DNSSEC will never gain traction.  Applications that can not differentiate between a non-response and a non-validating response will not be very user-friendly.

1: This may be foolish, as the bar to encrypt TCP/IP streams today is very low and will only get lower.  My point is that there are DNSSEC supporters who want to see this, which requires applications to do their own resolution and have the logic to handle DNSSEC validated responses and their associated additional records.

Comment 8 by agl@chromium.org, Oct 28 2010

> And then an unsecured 1.2.3.4 connection might have a X-Nonce: asd8ujk3h4ad89 header or similar.  Thus identity is established.

I think you need to think about that sentence :)

It is vanishingly unlikely that there will ever be any UI indication about DNSSEC specifically. Users don't understand the current UI without adding any more to it.

What does seem likely is that DNS will be able able to do the following:

* Get the same UI as DV certificates for DNSSEC verified TLS connections.
* Allow sites to bind to a specific certificate or CA (DNSSEC is helpful but not required).
* Allow sites to indicate HTTPS only (DNSSEC is helpful but not required).

Comment 9 Deleted

Comment 10 by ulevi...@gmail.com, Oct 29 2010

Adam -- Okay.  That all sounds reasonable.  Thanks.

Comment 11 by Deleted ...@, Sep 4 2011

The other way around, DNSSEC does prevent DNS spoofing. And that, together with an SSL connection, solves 2/3 of the possible hacks, leaving only a hack CA plus connection/server hacking.
.nl TLD has implemented DNSSEC. Is the client-side checking being enabled in Chromium/Chrome soon? We would like to take advantage of this increased security.

Comment 13 by harvi...@gmail.com, May 15 2012

pieterde: you can use this plugin: https://labs.nic.cz/dnssec-validator/
@hsm "leaving only a hack CA plus connection/server hacking." Chrome has Google's certificates also hardcoded built-in, so they covered that one for Google too (that's how they found the Iran fake certificates from Diginotar).

@Harvi Yes, already using that! Thank you for the suggestion, though. Normal users wont be using a plugin, so I think this feature should be built-in.

Comment 15 by agl@chromium.org, May 15 2012

pieterdebruij: regarding DNSSEC in Chrome, there is http://www.imperialviolet.org/2011/06/16/dnssecchrome.html but there are no plans to do anything else (save to update DNSSEC stapling for DANE once the RFC is out). Please see my previous comments on this bug.

Comment 16 by thu...@gmail.com, Aug 31 2012

Comment 6:
> I mean that, even if we are sure that "www.example.com A 1.2.3.4", that doesn't get us anything. We could make a connection to 1.2.3.4 but that connection can be hijacked. We need a fingerprint of a public key etc in order to trust the identity of a server.

But if I do not use a validating stub resolver, then the attacker controlling the DNS server can just say "this website doesn't use HTTPS, and doesn't have a SSL certificate inside DNSSEC". And without a validating DNSSEC stub resolver, I would have no way to know whether that was true, or if I am being mislead to a false address.

So while I agree that the public key fingerprint is needed to have meaningful security, we also absolutely need the validating stub resolver.
DANE is finally out, see http://tools.ietf.org/html/rfc6698
Cc: rsleevi@chromium.org
agl had this CL https://codereview.chromium.org/11184027/, but I think it's not going to used (I think he's going to land it and revert it).
Project Member

Comment 19 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
It will be super-awesome if chromium will manage to get DANE support as technology-leading browser. DANE is really big step forwards for internet security...

Comment 21 by Deleted ...@, Oct 1 2014

Have there been any changes in the plans to include DNSSEC and DANE support in Chromium? It seems like this feature has been dead for a while now, given that DANE was standardized in RFC 6698 in 2012. It's been a few years and it seems like everybody has stalled in providing support for it.

I can't find a reference atm, but I believe that it was the ISC that said that some 45-50% of SSL certs used in the wild are self-signed; widespread support and deployment of DANE/DNSSEC would go a long way of providing security to the users of those 45-50% of SSL certs. I would love if Chrome would lead the world in providing production-quality client support for DNSSEC and DANE.
Labels: Restrict-AddIssueComment-EditIssue
Status: WontFix
Closing this out as WontFix, as there are no plans.

The ISC number is not accurate for what real world users experience, and is biased by crawls that have a number of experimental limits.

DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security.
DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism.

While not desiring to stifle discussion, we've continued to evaluate the security and usability benefits and costs of DNSSEC and DANE, and will continue to do so, but for now, this is neither something we plan to implement nor would support landing.
Blocking: chromium:480920

Sign in to add a comment