New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
tomoshizuki opened this Issue Jan 25, 2015 · 7 comments

Comments

Projects
None yet
7 participants
@tomoshizuki

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

This comment has been minimized.

Show comment
Hide comment
@Mikaela

Mikaela 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.

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

This comment has been minimized.

Show comment
Hide comment
@aaronmdjones

aaronmdjones Jan 25, 2015

Member

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.

Member

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.

@jillest

This comment has been minimized.

Show comment
Hide comment
@jillest

jillest Jan 25, 2015

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@kaniini

kaniini Jan 25, 2015

Contributor

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.

Contributor

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

@DemiMarie

This comment has been minimized.

Show comment
Hide comment
@DemiMarie

DemiMarie Dec 21, 2016

@kaniini Can you explain why CertFP is broken?

@kaniini Can you explain why CertFP is broken?

@kaniini

This comment has been minimized.

Show comment
Hide comment
@kaniini

kaniini Dec 21, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@ilbelkyr

ilbelkyr Sep 8, 2017

Member

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.

Member

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