CA alternatives [mysterious magical discussion]

[sugarpuff]

at the request of a mod, I'm forking a conversation into a new thread to avoid derailing the parent thread.

Convergence for Namecoin will soon support using an nmcontrol instance that isn't running on the default host/port. This basically does what you're talking about. It should be emphasized that this should only be used with servers that you trust with the technical capacity to hijack, censor, and surveil all of your Firefox .bit traffic.

Sorry, don't think I understand, could you clarify what you mean by "what you're talking about"? How is changing the port what I'm talking about?

Run an nmcontrol instance on a non-localhost server which you trust, and enter its host/port in the Convergence for Namecoin settings. How is that not what you were talking about?

Ah I understand now. Yes, this is similar to what I'm talking about, but not identical.

My interest is in avoiding novel client software as much as possible, and that includes browser extensions. I agree that there is a possible necessity at this present time (hopefully not in the future) for a browser extension. It may be necessary for preventing scary warnings.

One possible method to avoid mandating an extension would be to utilize that wonderful "feature" in the existing PKI system whereby browsers trust a bunch of CAs, and simply obtain one of their private keys (through legal means) and use it to manufacture certs on behalf of authenticated .bit domains (and possibly others). This might not be realistic though, and is certainly not meant as any sort of long-term solution (the goal is to get rid of CAs, after all).

Chrome users simply cannot obtain good security/privacy due to problems with Chrome and Google. This is not something that I can fix. As a result, I don't have much interest in working on Chrome. If someone else wants to implement something like Convergence for Namecoin on Chrome, they're welcome to do so, but they'll be wasting their time in the sense of achieving strong security/privacy.

I'm not aware of any reason why they can't get good security/privacy (feel free to enlighten me).

My personal goal is to replace the CA/PKI system with something infinitely superior, and to protect as many internet users as possible (without discrimination). Would you be interested in collaborating? If so, do you have a GPG key somewhere?

[phelix: title edited]

[biolizard89]

at the request of a mod, I'm forking a conversation into a new thread to avoid derailing the parent thread.

<snip>

Ah I understand now. Yes, this is similar to what I'm talking about, but not identical.

My interest is in avoiding novel client software as much as possible, and that includes browser extensions. I agree that there is a possible necessity at this present time (hopefully not in the future) for a browser extension. It may be necessary for preventing scary warnings.

One possible method to avoid mandating an extension would be to utilize that wonderful "feature" in the existing PKI system whereby browsers trust a bunch of CAs, and simply obtain one of their private keys (through legal means) and use it to manufacture certs on behalf of authenticated .bit domains (and possibly others). This might not be realistic though, and is certainly not meant as any sort of long-term solution (the goal is to get rid of CAs, after all).

Chrome users simply cannot obtain good security/privacy due to problems with Chrome and Google. This is not something that I can fix. As a result, I don't have much interest in working on Chrome. If someone else wants to implement something like Convergence for Namecoin on Chrome, they're welcome to do so, but they'll be wasting their time in the sense of achieving strong security/privacy.

I'm not aware of any reason why they can't get good security/privacy (feel free to enlighten me).

My personal goal is to replace the CA/PKI system with something infinitely superior, and to protect as many internet users as possible (without discrimination). Would you be interested in collaborating? If so, do you have a GPG key somewhere?

It is unlikely that you will be able to replace CA's and get acceptable security without some kind of client software. Using a trusted CA key is what Convergence does, with the condition that the CA key is generated on your computer, so no third party can generate fraudulent certs. If we used an existing CA cert, that CA, and everyone who possesses that CA's keys, would be able to hijack all .bit websites... which would be really bad. Consider that the CA system itself required client software support.

One major problem with Chrome is that its developers simply don't appear to care about privacy. For example, Chrome's default configuration sends a copy of every address you type in to Google for indexing. This was a contributing factor to people having their bitcoins stolen from Instawallet (although it's a dumb idea anyway to use a bank to store bitcoins). The other problem is more general: Google is known to cooperate with the NSA when asked (e.g. PRISM); if the NSA asks for a backdoor, it is likely that Google will comply with the request.

Long-term plans for Convergence for Namecoin include making it not rely on Firefox, so you could download this hypothetical modified Convergence for Namecoin and use it with any application that supports HTTP/HTTPS/SOCKS proxies. Right now I have funding available for other features but not this feature, so it's on the back burner... but definitely is in the plans.

I would prefer to be contacted via this forum. If something is sensitive, I'm okay with TorChat.

[sugarpuff]

It is unlikely that you will be able to replace CA's and get acceptable security without some kind of client software. Using a trusted CA key is what Convergence does, with the condition that the CA key is generated on your computer, so no third party can generate fraudulent certs. If we used an existing CA cert, that CA, and everyone who possesses that CA's keys, would be able to hijack all .bit websites... which would be really bad. Consider that the CA system itself required client software support.

Yes, that's a good point. I thought there might be a way to have a two-step verification (use CA to stop the warning, and use something else to actually verify), but that's unlikely to be worth the trouble, it would be better to do something else instead.

One major problem with Chrome is that its developers simply don't appear to care about privacy. For example, Chrome's default configuration sends a copy of every address you type in to Google for indexing. This was a contributing factor to people having their bitcoins stolen from Instawallet (although it's a dumb idea anyway to use a bank to store bitcoins). The other problem is more general: Google is known to cooperate with the NSA when asked (e.g. PRISM); if the NSA asks for a backdoor, it is likely that Google will comply with the request.

Long-term plans for Convergence for Namecoin include making it not rely on Firefox, so you could download this hypothetical modified Convergence for Namecoin and use it with any application that supports HTTP/HTTPS/SOCKS proxies. Right now I have funding available for other features but not this feature, so it's on the back burner... but definitely is in the plans.

I agree that that would be useful in terms of preventing browser warnings when visiting https://www.something.bit.

I am presently working on a project that's somewhat different, and doesn't rely on HTTPS for security. I'm working on securing existing web apps, and for this I need a slightly modified DNS server that can talk to the blockchain. Communication with the DNS server does not need to be encrypted, although that's an optional feature that can later be added via whatever means. I'm not concerned about meta data leakage, because with the apps I'm trying to secure it's simply not possible to prevent that. I would, however, like to provide end-to-end encryption where it did not exist before.

To this effect, I will need a slightly modified DNS server. What do you think about that? Should I fork Bind? I want it to also function perfectly well as a regular DNS server for standard domains (in addition to supporting .bit and .id). (existing solutions created by the community are sufficient, i think, provided configured correctly).

I would prefer to be contacted via this forum. If something is sensitive, I'm okay with TorChat.

I think TorChat is a bit overkill, and I'm OK with communicating over this form. The project is not "sensitive", I just think the forum is a bit too slow for detailed discussion and brainstorming.

Does this project sound like something you'd be interested in discussing in greater depth? And if so, do you prefer email, or XMPP?

[sugarpuff]

I just realized I left some important details out. It's not clear why a custom DNS server is necessary (as opposed to using one of the existing solutions as-is, like nmcsocks). edit: on second thought, I don't think it's necessary to modify code beyond what's already been done. It just needs a small amount of customization to the configuration, I think.

It'd be nice to if we can bestow stronger security guarantees to online communication than those provided by HTTPS, and even Convergence-type HTTPS. HTTPS solutions don't offer PFS and other desirable protections. Too many people have been imprisoned, tortured, or killed for victim-less crimes by governments eavesdropping on their communications.

To protect web apps, and the folks using them, it's necessary to query the blockchain over HTTP or HTTPS, and to be able to trust the response. You can't do that with pure DNS.

[sugarpuff]

*edit.

[biolizard89]

I just realized I left some important details out. It's not clear why a custom DNS server is necessary (as opposed to using one of the existing solutions as-is, like nmcsocks). edit: on second thought, I don't think it's necessary to modify code beyond what's already been done. It just needs a small amount of customization to the configuration, I think.

It'd be nice to if we can bestow stronger security guarantees to online communication than those provided by HTTPS, and even Convergence-type HTTPS. HTTPS solutions don't offer PFS and other desirable protections. Too many people have been imprisoned, tortured, or killed for victim-less crimes by governments eavesdropping on their communications.

To protect web apps, and the folks using them, it's necessary to query the blockchain over HTTP or HTTPS, and to be able to trust the response. You can't do that with pure DNS.

I don't claim to be an expert on this, but I'm under the impression that TLS (and therefore HTTPS) has optional support for forward secrecy, which some major websites (e.g. Google, and if I'm not mistaken even dot-bit.bit) support. There's some information about this at https://community.qualys.com/blogs/secu ... rd-secrecy .

It *might* be possible to have an option in Convergence which warns the user when forward secrecy is not supported by a website (or other crappy TLS configuration). Would this be a useful feature if it's possible?

For querying the blockchain, the *only* way to trust the response is to use namecoind (or nmcontrol with namecoind). I *think* namecoind supports HTTPS for its API; I don't believe nmcontrol does, but it would probably be easy for the nmcontrol devs to add that. In the meantime an SSH tunnel should be sufficient. If you don't want to use namecoind, wait for a secure lite client (I suspect that will be coming soon after the rumored libcoin rebase).

[sugarpuff]

I don't claim to be an expert on this, but I'm under the impression that TLS (and therefore HTTPS) has optional support for forward secrecy, which some major websites (e.g. Google, and if I'm not mistaken even dot-bit.bit) support. There's some information about this at https://community.qualys.com/blogs/secu ... rd-secrecy.

Ah yes, how silly of me to forget about this.

Indeed, PFS is supported by some TLS implementations, but, there's a but.

Have a look at this wonderful netcraft article about the sad PFS situation with HTTPS today.

There are two three important things to note about PFS and HTTPS:

1. Support is needed on the server and client, and today only a small percent of websites sporting HTTPS results in a connection with PFS.
2. Even if they all supported HTTPS with PFS, it wouldn't matter! Why? Because PFS only protects the data whilst enroute to the server (and away from it). Once it reaches the server, the security is completely undermined because companies will store it in the clear in their databases (or encrypted, but the companies hold the keys, which effectively amounts to plain-text).
3. HTTPS + PFS does not (I don't think) protect against active MITM attacks involving compromised CA certs.

End-to-end encryption, therefore, is the only reliable solution, and HTTPS does not offer that.

It *might* be possible to have an option in Convergence which warns the user when forward secrecy is not supported by a website (or other crappy TLS configuration). Would this be a useful feature if it's possible?

The article I linked to above actually links to browser extensions that do precisely that.

For querying the blockchain, the *only* way to trust the response is to use namecoind (or nmcontrol with namecoind). I *think* namecoind supports HTTPS for its API; I don't believe nmcontrol does, but it would probably be easy for the nmcontrol devs to add that. In the meantime an SSH tunnel should be sufficient. If you don't want to use namecoind, wait for a secure lite client (I suspect that will be coming soon after the rumored libcoin rebase).

Yes, I think we're on the same page there. namecoind does not have to be running on the local machine though. It can be running remotely. The connection (and server) just needs to be trustworthy.

[sugarpuff]

*edit to above post: added a third issue with HTTPS + PFS.

[domob]

There are two three important things to note about PFS and HTTPS:

1. Support is needed on the server and client, and today only a small percent of websites sporting HTTPS results in a connection with PFS.
2. Even if they all supported HTTPS with PFS, it wouldn't matter! Why? Because PFS only protects the data whilst enroute to the server (and away from it). Once it reaches the server, the security is completely undermined because companies will store it in the clear in their databases (or encrypted, but the companies hold the keys, which effectively amounts to plain-text).
3. HTTPS + PFS does not (I don't think) protect against active MITM attacks involving compromised CA certs.

End-to-end encryption, therefore, is the only reliable solution, and HTTPS does not offer that.

Can you please elaborate, why you don't consider HTTPS / TLS to be "end-to-end encryption"? After all, when I visit a website, the "other end" is the website's server. It must always have the ability read the cleartext, and thus your second point is IMHO something which simply can't be avoided with any system. How would it be different if we used another encryption system?

[pmc]

1. 3. HTTPS + PFS does not (I don't think) protect against active MITM attacks involving compromised CA certs.

End-to-end encryption, therefore, is the only reliable solution, and HTTPS does not offer that.

Can you please elaborate, why you don't consider HTTPS / TLS to be "end-to-end encryption"? How would it be different if we used another encryption system?

The problem is not one of encryption but of authentication. Once you have authenticated the other side you can set up a secure encrypted channel with PFS.

A compromised CA enables a MITM to authenticate himself as the target domain, and thereby break into the communication. The only way around this is to get rid of CAs.

A slightly better alternative to CAs is DANE/DNSSEC. The problem here is, of course, that you have to trust the DNS root keys, your TLD's keys and your own DNS operator...