TLS validation of server cert for .bit [$129]

[JeremyRand]

At the moment there is no good option for validation of server certs for .bit websites.

Requirements for this ticket to be closed:

1. Certificates are checked against the blockchain using a locally running NMControl. (Could be indirectly, e.g. via a DNS server powered by NMControl.)
2. Uses TLS part of d/ spec that has achieved consensus among developers.
3. Cert check is done during TLS handshake, i.e. if it leaks HTTP cookies it does not qualify.
4. No intercepting proxies; we don't want to be the next Lenovo.
5. No stupid/unstable hacks. The definition of stupid/unstable hacks is intentionally vague, but shared library override hooks (e.g. LD_PRELOAD) are definitely stupid/unstable hacks.
6. Works in latest version (latest ESR counts as latest version) of at least one significant browser. (If there is a question of which browsers are significant, talk to us first.)
7. Must work with self-signed certificates.
8. Must reject certificates that don't match the blockchain, even if the certificate is signed by a trusted CA.
9. Design must pass review by Namecoin devs. We suggest talking to us before beginning work.
10. These criteria might be revised in the future. Talk to us in advance to avoid any misunderstandings.

Addendum 2016 Feb 20: Requirement 1 is amended; you may use ncdns instead of NMControl if you like. --Jeremy

--- There is a **[$129 open bounty](https://www.bountysource.com/issues/26334512-tls-validation-of-server-cert-for-bit?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github).

[ryancdotorg]

You should clarify that these requirements are for Firefox. Most other applications cannot be supported without either intercepting proxies or code injection (which is nowhere near as unstable as you seem to think it is).

[JeremyRand]

@ryancdotorg Yes, these requirements are primarily aimed at Firefox, but if someone can find a way to do it with another browser while meeting the requirements, then that is fine too.

[JeremyRand]

Note: @hlandau and I have a partially working prototype of this. It should work fine in current Firefox, though might break in 12-18 months when Firefox wipes out their XPCOM API.

[JeremyRand]

@ryancdotorg the Cert-Shim documentation says that it uses unstable data structures in the TLS libraries that it interacts with, and so may break between different versions of the TLS library. That's what I mean by unstable.

[ryancdotorg]

Cert-Shim documentation says that it uses unstable data structures in the TLS libraries that it interacts with, and so may break between different versions of the TLS library.

It's messing with stuff that isn't part of the exposed API and therefore is subject to change without notice by the developers of that library. That doesn't mean it is likely to change. This is less of an issue on e.g. Debian since the TLS libraries are mostly fixed and security stuff is normally backported.

As I have said before, the solution to this problem will suck. It's a matter of figuring out what sucks the least.

[JeremyRand]

@ryancdotorg Well, if a browser adopted DANE, a solution wouldn't suck. The current Firefox extension I'm working on doesn't suck (though it might suck in a year depending on whether Mozilla is favorable to us). For the general case of software that has no interest in giving us usable API's, then yes, the solution will suck. Also note that shared library injection is much more difficult on Windows than on Linux.

[JeremyRand]

FYI, the mitmproxy guys have added certificate validation. So while we're talking about suboptimal solutions, someone might want to recheck how good their TLS security settings are. I still wouldn't really be happy about using an intercepting proxy though, if we can avoid it.

[hlandau]

Please keep in mind that a solution should support TLSA records received from a DNSSEC-enabled nameserver securely delegated to from d/. All we really need is DANE support.

Also note that shared library injection is much more difficult on Windows than on Linux.

That's a curious thing to say. Sure, there's no LD_PRELOAD, but when you have functions like CreateRemoteThread, Read/WriteProcessMemory and CreateProcess CREATE_SUSPENDED, or, god forbid, AppInit, who needs them? Libraries like EasyHook make this easy.

[JeremyRand]

Please keep in mind that a solution should support TLSA records received from a DNSSEC-enabled nameserver securely delegated to from d/. All we really need is DANE support.

It would also be nice to support Perspectives notaries, since a lot of ICANN domains don't support DNSSEC yet.

That's a curious thing to say. Sure, there's no LD_PRELOAD, but when you have functions like CreateRemoteThread, Read/WriteProcessMemory and CreateProcess CREATE_SUSPENDED, or, god forbid, AppInit, who needs them? Libraries like EasyHook make this easy.

Last time I read up on Windows hooking, there were substantially more ways that you could accidentally crash the hooked process compared to Linux LD_PRELOAD. Am I out of date?

[JeremyRand]

EasyHook appears to require the Microsoft compiler. Is there any way to hook Windows programs that can be cross-compiled from Linux?

[hlandau]

If you're looking for an easy way to replace system calls, there is no way to do that which is as safe as LD_PRELOAD, as far as I'm aware. EasyHook works nicely, though, and is probably the closest to stable you'll get.

You could always just distribute EasyHook as a known-good DLL. I don't think it changes often.

[JeremyRand]

@hlandau Other things being equal, I'd really prefer that we stick to things that can be built reproducibly. Doing so decreases our exposure to speculation about backdoors, and keeps users safer. mitmproxy can probably be built reproducibly for Windows since it's Python and @josephbisch has been working on reproducible Python builds. EasyHook looks really really hard to build reproducibly. Of course, other things aren't equal in this case.

[josephbisch]

Note that creating an exe file from Linux for Windows with Python embedded in the exe is an entirely different challenge than just building from Linux for Windows and then expecting the user to install Python manually. The goal with Armory is to have a single exe (like there currently exists) to allow uses to just double-click and have it just work. But the current py2exe solution is Windows only, so we are going with pyqtdeploy. We are literally building everything (Python, PyQt, Twisted, etc) that the user would otherwise have to install and embedding it into the exe using pyqtdeploy.

The problem seems to be with the Python ssl module, but Armory runs fine when modules that depend on the ssl module are removed from the list of imports. Not very practical to use though, being that the ssl module won't import.

So depending on the goal here, it may currently be possible to get something reproducible, but if you want an all-in-one exe, that isn't possible (currently at least).

[JeremyRand]

To recap the discussion from IRC yesterday, it appears that even Tor has not figured out how to get Python to build reproducibly for Windows. The Tor Browser Bundle just grabs python.msi from the Python download server. So... mitmproxy is quite probably not any more reproducible than EasyHook. There is a Go intercepting proxy, https://github.com/elazarl/goproxy , but I have no idea how safe it is. Also https://github.com/kr/mitm .

[JeremyRand]

Any objections to modifying the criteria for this bounty to allow ncdns-based solutions to claim the bounty, in addition to NMControl-based solutions? The fact that Go's x.509 library is written entirely in Go makes handling certificates substantially easier and less error-prone than dealing with PyOpenSSL (which is a thin wrapper around OpenSSL). Also, Go's DNS library supports DNSSEC, while Python's DNS libraries do not.

Full disclosure: my draft code uses ncdns and the Go x.509 and DNS libraries.

[JeremyRand]

Bumping my previous comment, as I'd like to make sure that my code qualifies for the bounty before I spend more time on it. Any objections to permitting ncdns-based solutions? @ryancdotorg @hlandau @josephbisch @domob1812 @phelixbtc @cassiniNMC

[josephbisch]

No objection from me.

[phelixbtc]

Is ncdns anywhere near release ready? E.g. is there an installation instruction, does it have a Windows installer?

[JeremyRand]

@phelixbtc Last I checked, Windows installation instructions are reasonably easy to follow, although I haven't yet tried to set up DNSSEC support. (That's mainly because I didn't need it rather than it being inherently difficult.) It doesn't yet have an installer script, but there's not much to install since it's just the ncdns.exe file and a config file.

[JeremyRand]

@phelixbtc Are there any objections?

[JeremyRand]

Just wanted to mention that I have a proof of concept working with Firefox on Fedora (and it's not using anything Linux-specific, so will probably work verbatim on Windows and OS X versions of Firefox). That's in addition to the previously existing code that works on Chrome on Windows. As with the Chrome/Windows code, the Firefox code works in a way that is only reasonably feasible with ncdns (because PyOpenSSL doesn't expose the right API's, and I have zero interest in forking OpenSSL or trying to implement my own parser/serializer).

The Firefox code is based on the previous unreleased extension which @hlandau and I made. Unfortunately Hugo's part of that code is unworkable because of Mozilla API changes made last year. So I had to completely rewrite it using a different API. All of this is going to break again when XPCOM is removed sometime in the future.

[JeremyRand]

@phelixbtc While I don't like doing stuff unilaterally, if I don't get a response from you within the next 72 hours, I will modify the bounty criteria to allow ncdns-based solutions. Everyone else whom I've talked to is okay with it, and you have not brought up any issues with it.

[JeremyRand]

Addendum has been added to the requirements.

[JeremyRand]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

Since this is potentially relevant to some implementation methods, should we require that revocation work properly? I.e. if a TLS cert which was valid for a .bit domain becomes invalid (because the value of the name changed), should this ticket (as a condition on being closed) require that that cert not be accepted?

My opinion is that this should be required (even though it's going to take me some extra time to implement properly). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCAAGBQJXSr8hAAoJEAHN/EbZ1y06upsQAKGRvOm2Q9uzOXSpnpb4zLgX 6eh5wTUqNoAuLXi8soFiAnjNTV5dVZgSJ5aq5eKaDPugQhkktq0Rkgo4Rr8KmutH Qx/uDq9uoTHfLsgH/D/mxPbDPO7Kexjikautw4u93orKrdSVpa/N9Bu9CqAUTos+ FWQFPbyCsZ3M07EgRLOvwq4F4wf0SwxYhJ0URYyOSGVO79bl0IIAXi4Cc/J5sEU0 L/Tu9gc2pYrNVhBDb3XO+a8SNI005feMOD9s2ZRa+6nQl6wGQINaMz41tuwgu4+I 4hFGq+zIxzIPwVzHGsNiLf7dRkOINa0VwQdgmAoSRrdN0LW7AQq9ieCLiMlBRUXU z4Yfcv6L/bWZ4QlCey258bPjSZc8SKHawQSJKEMAqbZx5I3mjApUx08doUFDADDv oQ11dbdIXwP0e2XTtTXcMMtezi5PeOwwI2yX90v5FUdqe2JYXdz32iD4FUVydAel Dbv650ZCvGZdhNpzw6jgf4WFoSGS2aSVe1oY26yh6lcznlnUCjgb6V9qreyGxgvh yn/HrXXMBnx5kF6Z+4rS9vlmTWnowu05tsOIE7LFsDZV6VEJBqWG+9aG2F18iVqo 5Q20nM1YETJI/jXTmFkREDT12AqnYCdb5TJcDNEGGYTljYdAhNhaALdrd0dxFeMf +/kmI+cn4AG07BCWyo8m =QnQ/ -----END PGP SIGNATURE-----

[JeremyRand]

Closing as fixed; the Chromium TLS support in current ncdns releases (by me) qualifies for the bounty.