All kinds of redesigns are possible. I’d like the problem defined first – anything based on needing to protect against SHA256 collisions is (to be be bluntly honest) so far out in tinfoil hat land that I’m just not interested…
How about this though… Currently the CN is always “syncthing”, but we don’t verify that. We could verify that, and then we’re officially up to par with regular x509 certificate verification. The configuration could contain a certificateName setting per node. By default it would be blank or syncthing, and that’s pretty much the current behavior. An advanced user could generate a certificate with a CN of their choosing (using other tools, or some new -generate flag to syncthing) and set the certificateName option on the other nodes to match.
The verification mechanism on connect then becomes
- Calculate the node ID based on the presented certificate, verify this against configuration as we do currently.
- Check the certificate CN against the
certificateNameoption for the node we found in step one, or the stringsyncthingif it’s unset.
That sounds great! It should also prevent birthday attacks since we would actually need to match something on the inside.
Implemented in https://github.com/calmh/syncthing/commit/ea4524024ab61e28c28a2b130efd94fe91566da7. No GUI support so far for setting certificate names, I could write up a guide for using your own certificates though.
Looks awesome. That’s exactly what I was looking for. Is this being backported into the v0.8.x line or are all new features being added to v0.9?
v0.9 only. There should be a real release there in a week or so.
(If I end up doing another v0.8 release for some reason I can include it, but I don’t think it warrants a release on its own)