Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Please migrate to SHA-256-based fingerprints for certfp #442

tomoshizuki opened this Issue Jan 25, 2015 · 7 comments


None yet
7 participants

SHA-1 is long-known to have at least theoretically weaknesses and is classified as deprecated by the NIST(page 13). Prominent examples of software vendors like Microsoft, Google and Mozilla have issued correspondig statements on their own, while Google and Mozilla on their part are following the lead by implenting warnings or more severe actions for SHA-1-based certificate signatures, depending on the expiration dates.

For now the Atheme IRC Services only support SHA-1-based signatures for certfp. Please also implement certfp for SHA-256 fingerprints.

As I assume it wouldn't be always the user-friendliest approach to make a hard transition to SHA-256 it should at least be possible to give services Ops the possibility to configure Atheme for a signature algorithms of their choice or even better to configure Atheme to accept SHA-1 as well as SHA-256 simultaneously.

Mikaela commented Jan 25, 2015

If I recall correctly this is not happening because of backwards compatibility or current configs getting broken, but I am not sure was this said by Atheme or inspircd developer and where.


aaronmdjones commented Jan 25, 2015

Atheme is fingerprint algorithm agnostic. It does not know anything about the client certificate except its fingerprint, and that's only because the IRCd tells it what the fingerprint is. If you want SHA-256 CERTFP, you must modify the IRCd.

An example: https://github.com/aaronmdjones/charybdis-mordor/commit/5b67b22b536e18

Note that this will probably void your support.

@Mikaela Mikaela referenced this issue in inspircd/inspircd Jan 25, 2015


Default certfp to SHA-256 #972


jillest commented Jan 25, 2015

I think this is a valid atheme issue, but not for the fingerprint algorithm but for the transition mechanism. For example, ircd could send both SHA1 and SHA256 fingerprints and services could upgrade users transparently.

Alternatively, ircd could send SHA256 fingerprints for "new" certificates and SHA1 fingerprints for "old" ones. This would also enforce replacing all user certificates over some period of time.


kaniini commented Jan 25, 2015

A better solution would be to not use CertFP because it indirectly encourages use of the X.509 system, which is broken by design. Atheme supplies signature-based authentication schemes since 7.1 which do not use X.509.

Unless a patch is supplied, this is not something that much resources are going to be put towards, sorry.

tl;dr: use ECDSA-CHALLENGE family of SASL mechanisms if you really care about security that much.

@kaniini kaniini added this to the post-atheme milestone Feb 9, 2015

@kaniini Can you explain why CertFP is broken?


kaniini commented Dec 21, 2016

in relation to irc, it is because the fingerprint is relayed by the irc server to services and thus services cannot prove that the fingerprint is really legitimate. further fingerprints are only usable with a single account while challenge-response schemes (via sasl) can support multiple accounts


ilbelkyr commented Sep 8, 2017

As per @aaronmdjones above, SHA-256 is supported in that Atheme simply uses the fingerprint supplied by the ircd. The issue of transition is valid, but as far as I am aware, no ircd has a protocol to supply multiple fingerprints; if/when there is one, please feel free to reopen this issue so we can look into the possibilities this allows and implement suitable behaviour.

@ilbelkyr ilbelkyr closed this Sep 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment