Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add Cancel-Lock support in nnrpd and a secrets file
Implement Cancel-Lock support in nnrpd, based on RFC 8315 and libcanlock. Secrets are configured in a new inn-secrets.conf file. see #47
- Loading branch information
1 parent
6b10dbd
commit f25c972
Showing
38 changed files
with
1,425 additions
and
87 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4,6 +4,7 @@ | |
| ## line, to install for testing. | ||
|
|
||
| default-mta | ||
| libcanlock-dev | ||
| libdb5.3-dev | ||
| libgd-perl | ||
| libkrb5-dev | ||
|
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,166 @@ | ||
| =head1 NAME | ||
|
|
||
| inn-secrets.conf - Configuration data for InterNetNews secrets | ||
|
|
||
| =head1 DESCRIPTION | ||
|
|
||
| F<inn-secrets.conf> in I<pathetc> is a configuration file containing general | ||
| secrets used by INN. It was added in S<INN 2.7.0> for the implementation of | ||
| Cancel-Lock. The intent is that new secrets used by INN are added to that | ||
| file, and that all secrets currently stored in several other configuration | ||
| files eventually move to that file. | ||
|
|
||
| The F<inn-secrets.conf> file is not required. It currently only serves | ||
| the purpose of Cancel-Lock. If not present or empty, the Cancel-Lock | ||
| authentication system will just be deactivated for local posts. | ||
|
|
||
| This file is intended to be fairly static. Any changes made to it will | ||
| generally not affect any running programs until they restart. | ||
|
|
||
| Changes in Cancel-Lock secrets will be taken into account when new B<nnrpd> | ||
| processes are spawned (which happens each time a reader opens a new | ||
| connection). | ||
|
|
||
| Blank lines and lines starting with a number sign (C<#>) are ignored. | ||
| All other lines specify parameters, and are organized in groups. The general | ||
| form is: | ||
|
|
||
| <group> { | ||
| <parameter>: <value> | ||
| } | ||
|
|
||
| (Any amount of whitespace can be put after the colon and is optional.) If the | ||
| value contains embedded whitespace or any of the characters C<< []<>{}"\:; >>, | ||
| it must be enclosed in double quotes (""). A backslash (C<\>) can be used to | ||
| escape quotes and backslashes inside double quotes. <group> and <parameter> | ||
| are case-sensitive; C<cancels> is not the same as C<Cancels> or C<CANCELS>. | ||
| (F<inn-secrets.conf> groups and parameters are generally all in lowercase.) | ||
|
|
||
| The two parameters currently defined in this file have as their value a | ||
| list of strings, that is to say space-separated elements enclosed in square | ||
| brackets. Examples follow in the documentation. | ||
|
|
||
| =head1 PARAMETERS | ||
|
|
||
| =head2 Cancel-Lock secrets | ||
|
|
||
| These secrets are used for the Cancel-Lock authentication system described | ||
| in S<RFC 8315>. This mechanism permits verifying that the withdrawal of an | ||
| article is valid, that is to say the poster, posting agent, moderator, or | ||
| injecting agent that processed the original article has requested to withdraw | ||
| it via the use of a cancel control article or a Supersedes header field. | ||
|
|
||
| You'll need to build INN with version 3.3.0 or later of libcanlock | ||
| to embed Cancel-Lock support. This library is available at | ||
| L<https://micha.freeshell.org/libcanlock/>. The C<configure> script will | ||
| automatically enable Cancel-Lock support if it finds libcanlock; you may have | ||
| to specify the B<--with-canlock> option to help C<configure> find it. | ||
|
|
||
| The C<cancels> group is defined as follows: | ||
|
|
||
| cancels { | ||
| canlockadmin: [ "Cl4yniTtmlsR3nwVaM2erBQClVprEtLjd/UiqTErXjk=" ] | ||
| canlockuser: [ "tf+fY0Z7KNzYzF9uPo/qPrLKOPXIJLqejwqsV1nwOTRwGQ==" ] | ||
| } | ||
|
|
||
| If one of the I<canlockadmin> or I<canlockuser> parameters is not an empty | ||
| list, B<nnrpd> will add information to every posted article that will permit | ||
| other news servers to later ensure that an attempt to cancel or supersede the | ||
| article is not forged, and really originates from the authenticated original | ||
| sender or the administrator of the local server. | ||
|
|
||
| More concretely, for each secret in I<canlockadmin>, B<nnrpd> adds two | ||
| Base64-encoded hashes to a Cancel-Lock header field. These hashes are | ||
| based on the secret and the Message-ID of the article. If this field | ||
| already exists, it will just append the Base64-encoded hashes to its end. | ||
| One hash uses the SHA-1 algorithm (for interoperability reasons as not all | ||
| news software implement SHA-256), and the other hash uses the mandatory | ||
| SHA-256 algorithm per S<RFC 8315>. Besides, if the poster is authenticated, | ||
| B<nnrpd> will similarly add two Base64-encoded hashes for each secret in | ||
| I<canlockuser>. These hashes are based on the secret, the user name and the | ||
| Message-ID of the article. | ||
|
|
||
| When a cancel or supersede article is posted by an authenticated user, | ||
| B<nnrpd> will add to a Cancel-Key header field two pre-images for each secret | ||
| in I<canlockuser>. Other news servers can then hash one of these pre-images | ||
| with SHA-1 or SHA-256 algorithms (one is enough) and verify that the resulted | ||
| Base64-encoded hash is the same as the one present in the Cancel-Lock header | ||
| field of the original article. (Necessarily, the same authenticated user on | ||
| the same local server sent the original article.) When receiving articles | ||
| with a Cancel-Key header field (locally or from other peers), B<innd> applies | ||
| that check to verify the authenticity of the withdrawal before deciding to | ||
| honour it. | ||
|
|
||
| Naturally, no pre-images for each secret in I<canlockadmin> are added by | ||
| B<nnrpd>. As these pre-images are not based on a user name, only the news | ||
| administrator can generate them with a separate program (yet to write, and | ||
| that will be shipped with the final 2.7 release), and then inject the cancel | ||
| or supersede request with for instance B<inews>. The news administrator | ||
| is therefore capable to send authenticated withdrawal requests for articles | ||
| posted by all the users of his news server, be they authenticated or not. | ||
|
|
||
| After this (little) introduction to explain what Cancel-Lock is for, here are | ||
| the two relevant parameters: | ||
|
|
||
| =over 4 | ||
|
|
||
| =item I<canlockadmin> | ||
|
|
||
| This parameter expects a list of strings. It is unset by default (no admin | ||
| hashes will be generated). | ||
|
|
||
| If this parameter is not an empty list, each provided secret will be used to | ||
| generate admin hashes. | ||
|
|
||
| To maximize security, secrets should have a length of at least the output | ||
| size of the hash function used (32 octets for SHA-256). You can for instance | ||
| generate a strong secret based on 36 random octets with: | ||
|
|
||
| % openssl rand -base64 36 | ||
| Vs4zdggAHKEUtqs6dH5/oNGWwIVFPf2ZIngog6aE6cDMoyJF | ||
|
|
||
| and use it as follows: | ||
|
|
||
| canlockadmin: [ "Vs4zdggAHKEUtqs6dH5/oNGWwIVFPf2ZIngog6aE6cDMoyJF" ] | ||
|
|
||
| The purpose of providing several secrets is when you want to rotate secrets. | ||
| For instance, if your policy is to change secrets each year, you can use two | ||
| secrets during a transition period: | ||
|
|
||
| canlockadmin: [ "rH5L8geEzkNVvpAZQMJJcd4AYkpSkkx5S/4qewPDA/U=" | ||
| "eAaeyrQfjqQryhqrfwJOKezwf9GpL+xs+A9YfK9MMxE=" ] | ||
|
|
||
| Withdrawals of previously posted articles will still work with the old secret | ||
| (still added to the Cancel-Key header field). | ||
|
|
||
| As all posted articles will have a Cancel-Lock header field with the admin | ||
| secret, you should also set I<canlockuser> because otherwise posters may not | ||
| be able to withdraw their own articles (unless their posting agents generate | ||
| Cancel-Lock header fields themselves with their own secrets). | ||
|
|
||
| =item I<canlockuser> | ||
|
|
||
| This parameter expects a list of strings. It is unset by default (no hashes | ||
| will be generated for authenticated users). | ||
|
|
||
| If this parameter is not an empty list, each provided secret will be used to | ||
| generate hashes for authenticated users. | ||
|
|
||
| The same recommendation of more than 32 random octets applies, and the secrets | ||
| must not be the same as I<canlockadmin>. | ||
|
|
||
| You should also set I<canlockadmin> because you may otherwise not always | ||
| be able to cancel an article posted by an authenticated user (if you do not | ||
| manage to find out the user name). | ||
|
|
||
| =back | ||
|
|
||
| =head1 HISTORY | ||
|
|
||
| Documentation written by Julien Elie for InterNetNews. | ||
|
|
||
| =head1 SEE ALSO | ||
|
|
||
| nnrpd(8). | ||
|
|
||
| =cut |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.