رازهای Cancel-Lock (Cancel-Lock secrets)

این رازها برای سامانه احراز اصالت Cancel-Lock که در RFC 8315 شرح داده شده است استفاده می‌شوند. این سازوکار امکان تأیید معتبر بودن پس‌گیری یا لغو یک مقاله را فراهم می‌کند؛ به این معنا که ارسال‌کننده، عامل ارسال، ناظر یا عامل تزریقی که مقاله اصلی را پردازش کرده است، از طریق استفاده از یک مقاله کنترلی لغو (cancel control article) یا فیلد سرآیند Supersedes درخواست پس‌گیری آن را داده باشد.

برای تعبیه پشتیبانی از Cancel-Lock، باید INN را با نسخه 3.3.0 یا جدیدتر کتابخانه libcanlock کامپایل کنید. این کتابخانه در نشانی https://micha.freeshell.org/libcanlock در دسترس است. اگر اسکریپت "configure" کتابخانه libcanlock را پیدا کند، پشتیبانی از Cancel-Lock را به‌طور خودکار فعال خواهد کرد؛ ممکن است لازم باشد گزینه --with-canlock را مشخص کنید تا به "configure" در پیدا کردن آن کمک نماید.

گروه "cancels" به شکل زیر تعریف می‌شود (شما طبیعتاً باید از گذرواژه‌هایی به غیر از موارد زیر استفاده کنید):

cancels {
    canlockadmin: [ "9kc3ZtAACpNZRGtmYiPlbfkDacqNwPbcEfzFodc5X48g" ]
    canlockuser:  [ "TSrg41qEbp6AyZuQoIIHo6sUzFkBLOocJYN3KsUVdgft" ]
}

اگر یکی از پارامترهای canlockadmin یا canlockuser یک فهرست خالی نباشد، nnrpd اطلاعاتی را به هر مقاله ارسال‌شده اضافه می‌کند که به سایر سرورهای خبری امکان می‌دهد تا بعداً مطمئن شوند تلاش برای لغو یا جایگزینی مقاله جعلی نبوده و واقعاً از فرستنده اصلی احراز اصالت‌شده یا مدیر سرور محلی سرچشمه می‌گیرد.

اگر کاربران شما به صورت فردی احراز اصالت نشده‌اند یا با یک IP ایستا و منحصربه‌فرد قابل شناسایی نیستند، نباید canlockuser را تنظیم کنید؛ زیرا در غیر این صورت هر فردی قادر خواهد بود مقالات هر شخص دیگری با همان هویت انتساب‌یافته را لغو کند. اگر همه یا تنها برخی از کاربران شما به صورت فردی احراز اصالت شده یا قابل شناسایی هستند، می‌توانید canlockuser را تنظیم کرده و اطمینان حاصل کنید که مقدار addcanlockuser در تمام گروه‌های دسترسی در readers.conf که بین چندین فرد مختلف با هویت یکسان به اشتراک گذاشته شده‌اند، روی "none" تنظیم شده باشد.

به طور مشخص‌تر، برای هر راز در canlockadmin، برنامه nnrpd دو هش کدگذاری‌شده با Base64 را به یک فیلد سرآیند Cancel-Lock اضافه می‌کند. این هش‌ها بر اساس راز و Message-ID مقاله ساخته می‌شوند. اگر این فیلد از قبل وجود داشته باشد، هش‌های کدگذاری‌شده با Base64 را به انتهای آن الحاق می‌کند. یک هش از الگوریتم SHA-1 استفاده می‌کند (به دلایل سازگاری، زیرا همه نرم‌افزارهای خبری SHA-256 را پیاده‌سازی نکرده‌اند) و هش دیگر طبق RFC 8315 از الگوریتم الزامی SHA-256 بهره می‌برد. علاوه بر این، nnrpd به طور مشابه دو هش کدگذاری‌شده با Base64 برای هر راز در canlockuser اضافه خواهد کرد؛ این هش‌ها بر اساس راز، هویت اختصاص‌یافته در readers.conf به اتصال یا IP ایستای آن (بسته به تنظیم addcanlockuser) و Message-ID مقاله هستند.

هنگامی که یک مقاله لغو یا جایگزینی توسط یک کاربر احراز اصالت‌شده ارسال می‌شود، nnrpd برای هر راز در canlockuser دو پیش‌تصویر (pre-image) به فیلد سرآیند Cancel-Key اضافه می‌کند. (به همین دلیل است که اگر canlockuser را تنظیم کرده‌اید، اهمیت دارد که مقدار addcanlockuser را در تمام گروه‌های دسترسی در readers.conf که متناظر با اشخاص منفرد نیستند روی "none" قرار دهید.) سایر سرورهای خبری سپس می‌توانند یکی از این پیش‌تصویرها را با الگوریتم‌های SHA-1 یا SHA-256 هش کنند (یکی کافی است) و تأیید کنند که هش کدگذاری‌شده با Base64 حاصل، با هش موجود در فیلد سرآیند Cancel-Lock مقاله اصلی یکسان است. (الزاماً، همان کاربر احراز اصالت‌شده در همان سرور محلی مقاله اصلی را ارسال کرده است.) هنگام دریافت مقالات دارای فیلد سرآیند Cancel-Key (به صورت محلی یا از سایر همتایان)، innd آن بررسی را برای اعتبارسنجی اصالت لغو پیش از تصمیم‌گیری درباره اعمال آن انجام می‌دهد.

طبیعتاً هیچ پیش‌تصویری برای رازهای موجود در canlockadmin توسط nnrpd اضافه نمی‌شود. از آنجا که این پیش‌تصویرها بر اساس نام کاربری نیستند، تنها مدیر سرور خبر می‌تواند آن‌ها را (با ابزار gencancel که همراه با INN عرضه می‌شود) تولید کند و سپس درخواست لغو یا جایگزینی را مثلاً با inews تزریق نماید. بنابراین مدیر سرور خبر قادر است درخواست‌های لغو احراز اصالت‌شده را برای مقالات ارسال‌شده توسط تمامی کاربران سرور خبری خود، چه احراز اصالت شده باشند و چه نشده باشند، ارسال کند.

پس از این مقدمه (کوتاه) برای توضیح کاربرد Cancel-Lock، دو پارامتر مربوطه در ادامه آمده است:

canlockadmin

این پارامتر فهرستی از رشته‌ها را می‌پذیرد. به طور پیش‌فرض تنظیم نشده است (هیچ هش مدیریتی تولید نخواهد شد).

اگر این پارامتر یک فهرست خالی نباشد، هر یک از رازهای ارائه‌شده برای تولید هش‌های مدیریتی به کار خواهند رفت.

برای به حداکثر رساندن امنیت، طول رازها باید حداقل به اندازه اندازه خروجی تابع هش مورد استفاده باشد (۳۲ بایت برای SHA-256). برای نمونه، می‌توانید با دستور زیر یک راز قوی بر پایه ۳۳ بایت تصادفی تولید کنید (به طوری که نویسه آخر به طور سیستماتیک "=" نباشد، همان‌طور که در کدگذاری Base64 برای ۳۲ بایت تصادفی رخ می‌دهد):

% openssl rand -base64 33
nfwx6FS+U/dXXXqTOTp1Z5J9glV9UpjyhUcVcsDqXSC8

و آن را به صورت زیر استفاده کنید:

canlockadmin: [ "nfwx6FS+U/dXXXqTOTp1Z5J9glV9UpjyhUcVcsDqXSC8" ]

هدف از ارائه چندین راز، مواردی است که می‌خواهید رازها را دوره‌ای تغییر دهید (چرخش کلیدها). برای مثال، اگر خط‌مشی شما تغییر سالانه رازها است، می‌توانید در طول یک دوره گذار از دو راز استفاده کنید:

canlockadmin: [ "rH5L8geEzkNVvpAZQMJJcd4AYkpSkkx5S/4qewPDA/U="
                "nfwx6FS+U/dXXXqTOTp1Z5J9glV9UpjyhUcVcsDqXSC8" ]

لغو مقالاتی که پیش‌تر ارسال شده‌اند همچنان با راز قدیمی کار خواهد کرد (که کماکان به فیلد سرآیند Cancel-Key اضافه می‌شود).

از آنجا که تمام مقالات ارسال‌شده دارای فیلد سرآیند Cancel-Lock با راز مدیریتی خواهند بود، باید canlockuser را نیز تنظیم کنید (و ارسال‌کنندگان را به صورت فردی احراز اصالت نمایید)؛ چرا که در غیر این صورت ممکن است ارسال‌کنندگان نتوانند مقالات خود را لغو کنند (مگر اینکه عوامل ارسال آن‌ها، خود فیلدهای سرآیند Cancel-Lock را با رازهای خودشان تولید کنند).

canlockuser

این پارامتر فهرستی از رشته‌ها را می‌پذیرد. به طور پیش‌فرض تنظیم نشده است (هیچ هش مختص به کاربری تولید نخواهد شد).

همان توصیه داشتن بیش از ۳۲ بایت تصادفی در اینجا نیز صدق می‌کند و این رازها نباید با canlockadmin یکسان باشند.

اگر این پارامتر یک فهرست خالی نباشد، هر یک از رازهای ارائه‌شده برای تولید هش‌ها بر پایه هویت اختصاص‌یافته به کاربران توسط readers.conf یا IP ایستای آن‌ها (بسته به تنظیم addcanlockuser) به کار گرفته خواهند شد. توجه داشته باشید که اگر کاربران شما به صورت فردی احراز اصالت نشده باشند، نباید canlockuser را تنظیم کنید؛ زیرا در غیر این صورت هر فردی می‌تواند مقالات هر شخص دیگری با همان هویت یکسان را لغو کند. در صورت نیاز، می‌توانید تولید هش‌های مختص به کاربر را در گروه‌های دسترسی مشترک بین چندین شخص مختلف با هویت یکسان در readers.conf، با تنظیم addcanlockuser روی "none" در آن گروه‌های دسترسی غیرفعال کنید (این مورد برای مثال ممکن است برای اتصالات localhost صادق باشد، اگر برخی مقالات با inews از یک منبع خارجی تزریق شوند).

هنگام استفاده از canlockuser، باید canlockadmin را نیز تنظیم کنید؛ زیرا در غیر این صورت ممکن است همیشه قادر به تولید هش لازم برای لغو مقاله‌ای که توسط کاربران سرور خبری شما ارسال شده است نباشید (به‌ویژه اگر نتوانید هویتی را که کاربر هنگام ارسال مقاله اصلی داشته است بیابید).