6 ms·

DNSChain 0.5 released, brings full HTTPS support, Openname Resolver API and more

77 points by DonPellegrino 12y ago

higherpurpose 12y ago
> Automatically generates 4096-bit HTTPS key/certificate pair for you Will this be a problem for low-end phones? Why not ECC certificates?
- itistoday2 12y ago
  > Will this be a problem for low-end phones? Why not ECC certificates? That's a great suggestion, thank you. I chose to use RSA because it has excellent browser support and I don't know how good the browser support for ECC is. If anyone has any useful links/info on this I'd appreciate it very much. Note that you can of course generate and use whatever sort of key/cert pair you'd like.
  - agwa 12y ago
    https://www.ssllabs.com/ssltest/clients.html https://www.ssllabs.com/ssltest/clients.html is a good resource. For reference, the clients listed there that don't support ECDSA are: Android 2.3.7, IE 6 / XP, IE 8 / XP, Java 6u45, and OpenSSL 0.9.8y.
  - mnordhoff 12y ago
    I believe CloudFlare's free "Universal SSL" uses ECDSA. Support isn't, um, universal, but it seems to be widespread enough among modern clients.
    - ryan-c 12y ago
      Clients supporting ECDSA certificates advertise it via a TLS extension - some server software can actually serve up a RSA or ECDSA certificate depending on what the client claims to support.
e12e 12y ago
Is there a clear readme on dnschain somewhere? I looked at the github repo, but still don't quite get what actual benefits it brings over running one's own dns server? Using the public server obviously still leaks metadata (who looks up what when) - not that such metadata isn't rather obvious anyway by observing traffic between ips. How is it any better than cacert? Because you pin the trust to your own ca? What stops you from doing that now (how is the trust different with dnschain?).
- itistoday2 12y ago
  > I looked at the github repo, but still don't quite get what actual benefits it brings over running one's own dns server? A traditional DNS server does not give you access to blockchain-based domains. Blockchain TLDs (like .bit) can be MITM-proofed. DNSChain also lets you communicate with blockchains over a MITM-proof HTTPS connection: https://github.com/okTurtles/dnschain/blob/master/docs/What-is-it.md https://github.com/okTurtles/dnschain/blob/master/docs/What-... > not that such metadata isn't rather obvious anyway by observing traffic between ips. Tor is your best option if you want complete anonymity. DNSChain does have a planned feature called Unblock, which is effectively a DNS-based proxy that hides metadata as it travels between client and DNSChain, but if you want the best anonymity you should still use Tor. DNSChain is a secure PKI solution (alternative to X.509), the primary purpose of which is to securely and simply distribute public keys, as that's what provides protection from MITM attacks. > How is it any better than cacert? Because you pin the trust to your own ca? What stops you from doing that now (how is the trust different with dnschain?). CACert is a CA. You can certainly design your software to only trust certificates from one CA, but that is only useful in special-purpose situations, it's not going to work for general purpose browsing. In X.509, everyone on the Internet is forced to trust the weakest link, and security decreases for everyone with the more CAs there are. The opposite is true with DNSChain-based PKI, where the more independent servers that are queried, the more certain you can be of the authenticity of the response. If you completely trust a particular DNSChain server, then it's the only server you need to query.
  - e12e 12y ago
    Thank you for a concise and clear response! > If you completely trust a particular DNSChain server, then it's the only server you need to query. I guess this is the part that is still unclear to me: How is this different from a curated list of pinned certs coupled with a ca cert store that holds only my own ca cert? How can/why should I trust a dnschain server to validate google.com? Because there is ample evidence in the blockchain that others have been tricked by/trusted a particular key/cert for google.com?

77 points by DonPellegrino 12y ago

> Automatically generates 4096-bit HTTPS key/certificate pair for you Will this be a problem for low-end phones? Why not ECC certificates?

itistoday2 12y ago
> Will this be a problem for low-end phones? Why not ECC certificates? That's a great suggestion, thank you. I chose to use RSA because it has excellent browser support and I don't know how good the browser support for ECC is. If anyone has any useful links/info on this I'd appreciate it very much. Note that you can of course generate and use whatever sort of key/cert pair you'd like.
- agwa 12y ago
  https://www.ssllabs.com/ssltest/clients.html https://www.ssllabs.com/ssltest/clients.html is a good resource. For reference, the clients listed there that don't support ECDSA are: Android 2.3.7, IE 6 / XP, IE 8 / XP, Java 6u45, and OpenSSL 0.9.8y.
- mnordhoff 12y ago
  I believe CloudFlare's free "Universal SSL" uses ECDSA. Support isn't, um, universal, but it seems to be widespread enough among modern clients.
  - ryan-c 12y ago
    Clients supporting ECDSA certificates advertise it via a TLS extension - some server software can actually serve up a RSA or ECDSA certificate depending on what the client claims to support.

e12e 12y ago

Is there a clear readme on dnschain somewhere? I looked at the github repo, but still don't quite get what actual benefits it brings over running one's own dns server? Using the public server obviously still leaks metadata (who looks up what when) - not that such metadata isn't rather obvious anyway by observing traffic between ips. How is it any better than cacert? Because you pin the trust to your own ca? What stops you from doing that now (how is the trust different with dnschain?).

itistoday2 12y ago
> I looked at the github repo, but still don't quite get what actual benefits it brings over running one's own dns server? A traditional DNS server does not give you access to blockchain-based domains. Blockchain TLDs (like .bit) can be MITM-proofed. DNSChain also lets you communicate with blockchains over a MITM-proof HTTPS connection: https://github.com/okTurtles/dnschain/blob/master/docs/What-is-it.md https://github.com/okTurtles/dnschain/blob/master/docs/What-... > not that such metadata isn't rather obvious anyway by observing traffic between ips. Tor is your best option if you want complete anonymity. DNSChain does have a planned feature called Unblock, which is effectively a DNS-based proxy that hides metadata as it travels between client and DNSChain, but if you want the best anonymity you should still use Tor. DNSChain is a secure PKI solution (alternative to X.509), the primary purpose of which is to securely and simply distribute public keys, as that's what provides protection from MITM attacks. > How is it any better than cacert? Because you pin the trust to your own ca? What stops you from doing that now (how is the trust different with dnschain?). CACert is a CA. You can certainly design your software to only trust certificates from one CA, but that is only useful in special-purpose situations, it's not going to work for general purpose browsing. In X.509, everyone on the Internet is forced to trust the weakest link, and security decreases for everyone with the more CAs there are. The opposite is true with DNSChain-based PKI, where the more independent servers that are queried, the more certain you can be of the authenticity of the response. If you completely trust a particular DNSChain server, then it's the only server you need to query.
- e12e 12y ago
  Thank you for a concise and clear response! > If you completely trust a particular DNSChain server, then it's the only server you need to query. I guess this is the part that is still unclear to me: How is this different from a curated list of pinned certs coupled with a ca cert store that holds only my own ca cert? How can/why should I trust a dnschain server to validate google.com? Because there is ample evidence in the blockchain that others have been tricked by/trusted a particular key/cert for google.com?