Change TOFU storage method #173

After some discussions on IRC with xq, I've realized the issue with the Bombadillo TOFU system. There should be a mailing list post soon on it.

The main issue outlined was that when a site updates their cert before the expiry date, Bombadillo will say there's an error, because the hash doesn't match. A better way might be to just store the cert public key, and see if it matches.

This also avoids an attack where an attacker waits for a site's cert to reach the expiry date, then the next time Bob visits the site with Bombadillo, the attacker does a MITM and has Bob's browser store the attacker's cert hash in his database.

After some discussions on IRC with `xq`, I've realized the issue with the Bombadillo TOFU system. There should be a mailing list post soon on it. The main issue outlined was that when a site updates their cert before the expiry date, Bombadillo will say there's an error, because the hash doesn't match. A better way might be to just store the cert public key, and see if it matches. This also avoids an attack where an attacker waits for a site's cert to reach the expiry date, then the next time Bob visits the site with Bombadillo, the attacker does a MITM and has Bob's browser store the attacker's cert hash in his database.

See https://lists.orbitalfox.eu/archives/gemini/2020/001604.html for more info.

Hmmm... I'll think on this and look into it a bit more as I am not sure what goes into using the cert public key.

I'm still mulling over the future of my involvement, and to a degree Bombadillo's involvement, with the gemini protocol. These sorts of security issues are things I just straight up do not care about in the context for which I use gopher/gemini/etc... I know a lot of people do, so I think the path forward I would be willing to take on this issues is that I am not interested in coding it. However, I would certainly be open to pull requests from anyone that wanted to code it up.

I do think that for the most part the existing implementation works alright for the time being and aprt of me wants to wait and see how this takes shape on the mailing list as well.

Another factor in not being too excited about doing this, for me, is that of the last few releases I would say a solid 90% of the work was done for gemini alone... a protocol that should not have such an overlarge amount of code added. I really would like to focus on usability issues that do not relate to just one protocol (out of the seven protocols currently supported) but instead support the client on the whole.

Hmmm... I'll think on this and look into it a bit more as I am not sure what goes into using the cert public key. I'm still mulling over the future of my involvement, and to a degree Bombadillo's involvement, with the gemini protocol. These sorts of security issues are things I just straight up do not care about in the context for which I use gopher/gemini/etc... I know a lot of people do, so I think the path forward I would be willing to take on this issues is that I am not interested in coding it. However, I would certainly be open to pull requests from anyone that wanted to code it up. I do think that for the most part the existing implementation works alright for the time being and aprt of me wants to wait and see how this takes shape on the mailing list as well. Another factor in not being too excited about doing this, for me, is that of the last few releases I would say a solid 90% of the work was done for gemini alone... a protocol that should not have such an overlarge amount of code added. I really would like to focus on usability issues that do not relate to just one protocol (out of the seven protocols currently supported) but instead support the client on the whole.

After more conversations about TOFU on the list, I don't think this makes sense anymore. Storing cert hash and expiry is a good way to do it in my opinion, as many sites may change their cert keys when renewing. This is what Amfora does currently.

It is not perfectly secure, but combined with the Bombadillo purge command, it should be fine. As Solderpunk pointed out, TOFU doesn't need to be perfect.

After more conversations about TOFU on the list, I don't think this makes sense anymore. Storing cert hash and expiry is a good way to do it in my opinion, as many sites may change their cert keys when renewing. This is what Amfora does currently. It is not perfectly secure, but combined with the Bombadillo `purge` command, it should be fine. As Solderpunk pointed out, TOFU doesn't need to be perfect.

One thing I am going to change in Amfora is storing the port number as well as the domain. That way you could host different services and certs on different ports.

I might also switch to storing the hash of cert.RawSubjectPublicKeyInfo instead of cert.Raw.

These changes were informed by this report, which Solderpunk just shared on the mailing list. He said he intends to make a TOFU guideline document, so there's no harm in waiting of course.

One thing I am going to change in Amfora is storing the port number as well as the domain. That way you could host different services and certs on different ports. I might also switch to storing the hash of `cert.RawSubjectPublicKeyInfo` instead of `cert.Raw`. These changes were informed by [this report](https://rp.delaat.net/2012-2013/p56/report.pdf), which Solderpunk just shared on the mailing list. He said he intends to make a TOFU guideline document, so there's no harm in waiting of course.

I think I will wait, but will likely update this once official guidelines are settled on. I think it would be could to have some kind of consensus or standard around the level of security provided by TOFU implementations. Otherwise it is hard for people using clients to know what to expect. For the time being I will keep things as they are (and maybe start a branch working toward this if I get time), with the plan of updating in the not distant future. Storing the port is a simple enough thing to do and I agree it will make things much more robust if people do start different services on various ports.

I will keep this issue open to that effect and comment when this starts to get worked on. If you happen to notice that document come out and happen to be on the Bombadillo tildegit and want to send a little nudge in the form of the link it would be appreciated (but no worries either way).

I think I will wait, but will likely update this once official guidelines are settled on. I think it would be could to have some kind of consensus or standard around the level of security provided by TOFU implementations. Otherwise it is hard for people using clients to know what to expect. For the time being I will keep things as they are (and maybe start a branch working toward this if I get time), with the plan of updating in the not distant future. Storing the port is a simple enough thing to do and I agree it will make things much more robust if people do start different services on various ports. I will keep this issue open to that effect and comment when this starts to get worked on. If you happen to notice that document come out and happen to be on the Bombadillo tildegit and want to send a little nudge in the form of the link it would be appreciated (but no worries either way).

Sounds good, I'll stay abreast of any updates on the mailing list.

Labels Milestones

Change TOFU storage method #173