STUNNEL(8)

stunnel TLS Proxy

STUNNEL(8)

نام (NAME)

stunnel - پروکسی بارگذاری TLS و متعادل‌کننده بار

خلاصه دستور (SYNOPSIS)

Unix: stunnel [FILE] | -fd N | -help | -version | -sockets | -options
WIN32: stunnel [ [ -install | -uninstall | -start | -stop | -reload | -reopen | -exit ] [-quiet] [FILE] ] | -help | -version | -sockets | -options

توضیحات (DESCRIPTION)

برنامه stunnel به گونه‌ای طراحی شده است که به عنوان یک پوشش (wrapper) رمزنگاری TLS میان کلاینت‌های دوردست و سرورهای محلی (قابل اجرا توسط inetd) یا سرورهای راه دور عمل کند. ایده اصلی این است که در صورت داشتن دیمن‌های بدون پشتیبانی از TLS روی سیستم خود، می‌توانید به سادگی آنها را به شکلی تنظیم کنید که از طریق کانال‌های امن TLS با کلاینت‌ها ارتباط برقرار نمایند.

از stunnel می‌توان برای افزودن قابلیت TLS به دیمن‌های متداول Inetd مانند سرورهای POP-2، POP-3 و IMAP، به دیمن‌های مستقل مانند NNTP، SMTP و HTTP، و نیز در تونل‌سازی PPP روی سوکت‌های شبکه بدون نیاز به تغییر در کد منبع استفاده کرد.

این محصول شامل نرم‌افزار رمزنگاری نوشته‌شده توسط Eric Young است (eay@cryptsoft.com)

گزینه‌ها (OPTIONS)

•: FILE

استفاده از فایل پیکربندی مشخص‌شده

•: -fd N (فقط یونیکس)

خواندن فایل پیکربندی از توصیف‌گر فایل (file descriptor) مشخص‌شده

•: -help

چاپ منوی راهنمای stunnel

•: -version

چاپ نسخه stunnel و پیش‌فرض‌های زمان کامپایل

•: -sockets

چاپ گزینه‌های پیش‌فرض سوکت

•: -options

چاپ گزینه‌های پشتیبانی‌شده‌ی TLS

•: -install (فقط ویندوز NT و جدیدتر)

نصب سرویس NT

•: -uninstall (فقط ویندوز NT و جدیدتر)

حذف سرویس NT

•: -start (فقط ویندوز NT و جدیدتر)

راه‌اندازی سرویس NT

•: -stop (فقط ویندوز NT و جدیدتر)

توقف سرویس NT

•: -reload (فقط ویندوز NT و جدیدتر)

بارگذاری مجدد فایل پیکربندی سرویس NT در حال اجرا

•: -reopen (فقط ویندوز NT و جدیدتر)

بازگشایی مجدد فایل گزارش سرویس NT در حال اجرا

•: -exit (فقط Win32)

خروج از نسخه در حال اجرای stunnel

•: -quiet (فقط Win32)

عدم نمایش هرگونه کادر پیام (message box)

فایل پیکربندی (CONFIGURATION FILE)

هر خط از فایل پیکربندی می‌تواند یکی از موارد زیر باشد:

یک خط خالی (نادیده گرفته می‌شود).
یک کامنت که با `;' آغاز می‌شود (نادیده گرفته می‌شود).
یک جفت `option_name = option_value'.
عبارت `[service_name]' که آغازگر تعریف یک سرویس است.

پارامتر آدرس یک گزینه می‌تواند یکی از موارد زیر باشد:

یک شماره پورت.
یک جفت آدرس IP (IPv4، IPv6 یا نام دامنه) و شماره پورت جداشده با دو‌نقطه.
مسیر یک سوکت یونیکس (فقط یونیکس).

گزینه‌های عمومی (GLOBAL OPTIONS)

•: chroot = DIRECTORY (فقط یونیکس)

دایرکتوری برای chroot کردن پردازه stunnel

گزینه chroot پردازه stunnel را درون یک محیط ایزوله (chroot jail) نگه می‌دارد. گزینه‌های CApath، CRLpath، pid و exec درون این محیط قرار می‌گیرند و مسیرهای آنها باید نسبت به دایرکتوری مشخص‌شده با chroot باشند.

چندین تابع سیستم‌عامل نیز به قرار گرفتن فایل‌هایشان در محیط ایزوله chroot نیاز دارند، به عنوان مثال:

حل‌کننده با تأخیر نام‌ها (Delayed resolver) معمولاً به /etc/nsswitch.conf و /etc/resolv.conf نیاز دارد.
زمان محلی در فایل‌های گزارش به /etc/timezone نیاز دارد.
برخی عملکردهای دیگر ممکن است به دستگاه‌ها نیاز داشته باشند، مانند /dev/zero یا /dev/null.

•: compression = deflate | zlib | zstd | brotli

انتخاب الگوریتم فشرده‌سازی داده‌ها

پیش‌فرض: بدون فشرده‌سازی (no compression)

فشرده‌سازی داده‌ها فقط برای TLS 1.2 و قبل از آن در دسترس است. در صورت کامپایل با OpenSSL 1.1.0 و جدیدتر، نیازمند کاهش securityLevel به 1 است.

الگوریتم‌های zlib، zstd و brotli در پیکربندی پیش‌فرض OpenSSL غیرفعال هستند.

الگوریتم‌های zstd و brotli در OpenSSL 3.2 اضافه شدند.

فشرده‌سازی داده‌ها در برنامه‌هایی که به مهاجم اجازه تزریق متن آشکار انتخابی (chosen plaintext) را می‌دهند، یک ریسک امنیتی به شمار می‌رود.

روش Deflate روش استاندارد فشرده‌سازی است که در RFC 1951 توصیف شده است.

هشدار: فشرده‌سازی TLS می‌تواند حملات بازیابی متن آشکار (مانند CRIME) را در شرایطی که داده‌های تحت کنترل مهاجم به همراه اطلاعات محرمانه فشرده می‌شوند، امکان‌پذیر سازد.

•: debug = [FACILITY.]LEVEL

سطح گزارش‌گیری و اشکال‌زدایی

مقدار سطح یکی از نام‌ها یا شماره‌های سطوح syslog است: emerg (0)، alert (1)، crit (2)، err (3)، warning (4)، notice (5)، info (6) یا debug (7). تمامی گزارش‌های سطح مشخص‌شده و کلیه سطوح با مقدار عددی کمتر از آن نمایش داده خواهند شد.

سطح debug = debug (یا معادل آن <debug = 7>) پرجزئیات‌ترین خروجی گزارش را تولید می‌کند. این سطح گزارش‌گیری صرفاً برای فهم توسعه‌دهندگان stunnel طراحی شده است و نه کاربران عادی. لطفاً تنها زمانی از سطح debug استفاده کنید که توسط یک توسعه‌دهنده stunnel درخواست شده باشد، یا زمانی که قصد دارید سردرگم شوید.

سطح پیش‌فرض گزارش‌گیری notice (5) است.

از تسهیلات (facility) بخش `daemon' در syslog استفاده خواهد شد مگر اینکه نام تسهیلاتی تعیین گردد. (تسهیلات در Win32 پشتیبانی نمی‌شوند.)

بزرگی و کوچکی حروف برای هر دو مقدار تسهیلات و سطوح نادیده گرفته می‌شود.

•: EGD = EGD_PATH (فقط یونیکس)

مسیر سوکت دیمن جمع‌آوری آنتروپی (Entropy Gathering Daemon)

سوکت Entropy Gathering Daemon برای تغذیه تولیدکننده اعداد تصادفی OpenSSL استفاده می‌شود.

•: engine = auto | ENGINE_ID

انتخاب موتور رمزنگاری سخت‌افزاری یا نرم‌افزاری

پیش‌فرض: رمزنگاری صرفاً نرم‌افزاری

برای مشاهده پیکربندی engine جهت استفاده از گواهی و کلید خصوصی متناظر از یک دستگاه رمزنگاری، بخش مثال‌ها را ببینید.

•: engineCtrl = COMMAND[:PARAMETER]

کنترل موتور سخت‌افزاری

•: engineDefault = TASK_LIST

تنظیم وظایف OpenSSL واگذارشده به موتور جاری

این پارامتر یک فهرست جداشده با کاما از وظایفی را که باید به موتور جاری واگذار شوند مشخص می‌کند.

در صورت پشتیبانی موتور، وظایف زیر ممکن است در دسترس باشند: ALL، RSA، DSA، ECDH، ECDSA، DH، RAND، CIPHERS، DIGESTS، PKEY، PKEY_CRYPTO، PKEY_ASN1.

•: fips = yes | no

فعال یا غیرفعال کردن حالت FIPS 140-2.

این گزینه به شما امکان می‌دهد در صورتی که stunnel با پشتیبانی از FIPS 140-2 کامپایل شده باشد، از ورود به حالت FIPS صرف‌نظر کنید.

پیش‌فرض: no (از نسخه 5.00)

•: foreground = yes | quiet | no (فقط یونیکس)

حالت پیش‌زمینه

ماندن در پیش‌زمینه (انشعاب یا fork نکند).

با پارامتر yes علاوه بر مقصدهای مشخص‌شده با syslog و output، لاگ‌ها را در stderr نیز ثبت می‌کند.

پیش‌فرض: background در حالت دیمن

•: iconActive = ICON_FILE (فقط واسط گرافیکی)

آیکون واسط گرافیکی برای نمایش در هنگام وجود اتصالات برقرارشده

در پلتفرم ویندوز این پارامتر باید یک فایل .ico حاوی یک تصویر ۱۶ در ۱۶ پیکسل باشد.

•: iconError = ICON_FILE (فقط واسط گرافیکی)

آیکون واسط گرافیکی برای نمایش در زمانی که هیچ پیکربندی معتبری بارگذاری نشده باشد

در پلتفرم ویندوز این پارامتر باید یک فایل .ico حاوی یک تصویر ۱۶ در ۱۶ پیکسل باشد.

•: iconIdle = ICON_FILE (فقط واسط گرافیکی)

آیکون واسط گرافیکی برای نمایش در زمانی که هیچ اتصال برقرارشده‌ای وجود ندارد

در پلتفرم ویندوز این پارامتر باید یک فایل .ico حاوی یک تصویر ۱۶ در ۱۶ پیکسل باشد.

•: log = append | overwrite

نحوه مدیریت فایل گزارش

این گزینه به شما اجازه می‌دهد تعیین کنید که آیا فایل گزارش (مشخص‌شده با گزینه output) هنگام باز شدن یا بازگشایی مجدد، افزوده (append) شود یا رونویسی (overwrite) گردد.

پیش‌فرض: append

•: output = FILE

افزودن پیام‌های گزارش به یک فایل

از دستگاه /dev/stdout می‌توان برای ارسال پیام‌های لاگ به خروجی استاندارد استفاده کرد (برای مثال جهت ثبت آنها با ابزار splogger مربوط به daemontools).

•: pid = FILE (فقط یونیکس)

محل فایل شناسه پردازه (pid)

اگر آرگومان خالی باشد، هیچ فایل pid ساخته نخواهد شد.

مسیر pid در صورت تعیین، نسبت به دایرکتوری chroot سنجیده می‌شود.

•: provider = PROVIDER_ID

شناسه ارائه‌دهنده (provider) مورد استفاده را مشخص می‌کند. PROVIDER_ID یک شناسه یکتا است که به یک ارائه‌دهنده خدمات رمزنگاری خاص اشاره دارد.

این گزینه نیازمند OpenSSL 3.0 یا جدیدتر است.

•: providerParameter = PROVIDER_ID:PARAMETER=VALUE

یک پارامتر خاص را برای ارائه‌دهنده داده‌شده تنظیم می‌کند. PROVIDER_ID ارائه‌دهنده را مشخص کرده، PARAMETER نام پارامتر و VALUE مقدار آن است. این گزینه امکان سفارشی‌سازی پیکربندی ارائه‌دهنده خدمات رمزنگاری انتخاب‌شده را فراهم می‌کند.

این گزینه نیازمند OpenSSL 3.5 یا جدیدتر است.

•: RNDbytes = BYTES

تعداد بایت‌های خوانده‌شده از فایل‌های سید تصادفی

•: RNDfile = FILE

مسیر فایل حاوی داده‌های سید تصادفی

کتابخانه OpenSSL ابتدا از داده‌های این فایل برای دانه‌بندی (seed) تولیدکننده اعداد تصادفی استفاده خواهد کرد.

•: RNDoverwrite = yes | no

رونویسی فایل‌های سید تصادفی با داده‌های تصادفی جدید

پیش‌فرض: yes

•: service = SERVICE (فقط یونیکس)

نام سرویس stunnel

نام سرویس مشخص‌شده برای syslog و به عنوان نام سرویس در حالت inetd برای TCP Wrappers استفاده می‌شود. اگرچه این گزینه از نظر فنی در بخش‌های سرویس نیز قابل تعیین است، اما تنها در گزینه‌های عمومی سودمند است.

پیش‌فرض: stunnel

•: setEnv = VAR_NAME=VALUE

تغییر یا افزودن یک متغیر محیطی برای پردازه‌های فرزند. اگر VAR_NAME از قبل وجود داشته باشد، مقدار آن به‌روز خواهد شد؛ در غیر این صورت، یک متغیر جدید ایجاد می‌شود. این تغییر فقط بر پردازه‌های فرزند ایجادشده اعمال می‌شود و بر محیط فعلی تأثیری ندارد.

•: syslog = yes | no (فقط یونیکس)

فعال‌سازی ثبت گزارش از طریق syslog

پیش‌فرض: yes

•: taskbar = yes | no (فقط WIN32)

فعال‌سازی آیکون نوار وظیفه (taskbar)

پیش‌فرض: yes

گزینه‌های سطح سرویس (SERVICE-LEVEL OPTIONS)

هر بخش پیکربندی با نام یک سرویس درون براکت‌های قلاب‌شکل آغاز می‌شود. نام سرویس برای کنترل دسترسی libwrap (همان TCP Wrappers) استفاده می‌شود و به شما امکان می‌دهد سرویس‌های stunnel را در فایل‌های گزارش خود تشخیص دهید.

توجه داشته باشید که اگر می‌خواهید stunnel را در حالت inetd اجرا کنید (که در آن یک سوکت شبکه توسط سروری مانند inetd، xinetd یا tcpserver در اختیار آن قرار می‌گیرد)، باید بخش حالت INETD (INETD MODE) را در ادامه مطالعه نمایید.

•: accept = [HOST:]PORT

پذیرش اتصالات روی نشانی مشخص‌شده

اگر هیچ میزبانی مشخص نشود، به طور پیش‌فرض روی تمامی نشانی‌های IPv4 میزبان محلی گوش می‌دهد.

برای گوش دادن روی تمامی نشانی‌های IPv6 از دستور زیر استفاده کنید:

accept = :::PORT

•: CAengine = ENGINE-SPECIFIC_CA_CERTIFICATE_IDENTIFIER

بارگذاری یک گواهی CA معتبر از یک موتور رمزنگاری (engine)

گواهی‌های CA بارگذاری‌شده به همراه گزینه‌های verifyChain و verifyPeer استفاده خواهند شد.

استفاده از چندین گزینه CAengine در یک بخش سرویس منفرد مجاز است.

موتورهای پشتیبانی‌شده فعلی: pkcs11، cng.

•: CApath = CA_DIRECTORY

بارگذاری گواهی‌های معتبر CA از یک دایرکتوری

گواهی‌های CA بارگذاری‌شده به همراه گزینه‌های verifyChain و verifyPeer استفاده خواهند شد. توجه داشته باشید که گواهی‌های موجود در این پوشه باید با فرمت XXXXXXXX.0 نام‌گذاری شوند که در آن XXXXXXXX مقدار هش از موضوع (subject) کدگذاری‌شده DER گواهی است.

از این پارامتر می‌توان برای ارائه گواهی CA ریشه مورد نیاز جهت اعتبارسنجی منگنه کردن OCSP (OCSP stapling) در حالت سرور نیز استفاده کرد.

الگوریتم هش در OpenSSL 1.0.0 تغییر یافته است. هنگام ارتقا از OpenSSL 0.x.x به OpenSSL 1.x.x یا جدیدتر، اجرای دستور c_rehash روی این دایرکتوری الزامی است.

مسیر CApath در صورت تعیین، نسبت به دایرکتوری chroot محاسبه می‌شود.

•: CAfile = CA_FILE

بارگذاری گواهی‌های معتبر CA از یک فایل

گواهی‌های CA بارگذاری‌شده به همراه گزینه‌های verifyChain و verifyPeer استفاده خواهند شد.

از این پارامتر می‌توان برای ارائه گواهی CA ریشه مورد نیاز جهت اعتبارسنجی منگنه کردن OCSP در حالت سرور نیز استفاده کرد.

•: CAstore = URI_CA

بارگذاری گواهی‌های معتبر CA از منبعی که با یک URI مشخص شده است

این گزینه امکان بارگذاری گواهی‌های CA را از منابع خارجی پشتیبانی‌شده توسط چارچوب OSSL_STORE، مانند ماژول PKCS#11 (مثلاً توکن سخت‌افزاری)، مخزن گواهی سیستم، یا یک منبع راه دور فراهم می‌سازد.

این گزینه را می‌توان به صورت مستقل از CAfile و CAdir به کار برد، و به طور مشابه گواهی‌های مورد استفاده verifyChain یا verifyPeer و نیز اعتبارسنجی منگنه کردن OCSP در حالت سرور را فراهم می‌کند.

این گزینه نیازمند OpenSSL 3.0 یا جدیدتر است.

•: cert = CERT_FILE | URI

نام فایل زنجیره گواهی (certificate chain)

این پارامتر فایلی را مشخص می‌کند که حاوی گواهی‌های مورد استفاده stunnel برای احراز هویت خود در برابر کلاینت یا سرور راه دور است. این فایل باید شامل کل زنجیره گواهی باشد که از گواهی واقعی سرور/کلاینت آغاز شده و به گواهی خودامضاشده‌ی CA ریشه ختم می‌شود. این فایل باید با فرمت PEM یا P12 باشد.

وجود زنجیره گواهی در حالت سرور الزامی و در حالت کلاینت اختیاری است.

گزینه cert را می‌توان چندین بار تعیین کرد. اولین گواهی ارائه‌شده به عنوان گواهی سرور یا کلاینت استفاده می‌شود، در حالی که گواهی‌های بعدی به عنوان عناصر میانی زنجیره در نظر گرفته می‌شوند. این قابلیت نیازمند OpenSSL نسخه 1.0.2 یا جدیدتر است.

در صورت فعال بودن یک موتور یا ارائه‌دهنده سخت‌افزاری، از این پارامتر به عنوان شناسه گواهی (PKCS#11 URI) نیز استفاده می‌شود.

نکته: استفاده از provider نیازمند OpenSSL 3.0 یا جدیدتر است

•: checkEmail = EMAIL

اعتبارسنجی نشانی ایمیل در موضوع گواهی طرف مقابل (موجودیت انتهایی یا برگ)

در صورتی که بررسی موضوع گواهی تعیین نشده باشد، یا نشانی ایمیل گواهی طرف مقابل با هر یک از نشانی‌های مشخص‌شده با checkEmail مطابقت داشته باشد، گواهی‌ها پذیرفته می‌شوند.

تعیین چندین گزینه checkEmail در یک بخش سرویس مجاز است.

این گزینه نیازمند OpenSSL 1.0.2 یا جدیدتر است.

•: checkHost = HOST

اعتبارسنجی نام میزبان در موضوع گواهی طرف مقابل (موجودیت انتهایی یا برگ)

در صورتی که بررسی موضوع گواهی تعیین نشده باشد، یا نام میزبان گواهی طرف مقابل با هر یک از نام‌های میزبان مشخص‌شده با checkHost مطابقت داشته باشد، گواهی‌ها پذیرفته می‌شوند.

تعیین چندین گزینه checkHost در یک بخش سرویس مجاز است.

این گزینه نیازمند OpenSSL 1.0.2 یا جدیدتر است.

•: checkIP = IP

اعتبارسنجی نشانی IP در موضوع گواهی طرف مقابل (موجودیت انتهایی یا برگ)

در صورتی که بررسی موضوع گواهی تعیین نشده باشد، یا نشانی IP گواهی طرف مقابل با هر یک از نشانی‌های IP مشخص‌شده با checkIP مطابقت داشته باشد، گواهی‌ها پذیرفته می‌شوند.

تعیین چندین گزینه checkIP در یک بخش سرویس مجاز است.

این گزینه نیازمند OpenSSL 1.0.2 یا جدیدتر است.

•: ciphers = CIPHER_LIST

انتخاب رمزهای مجاز TLS (نسخه TLSv1.2 و قبل از آن)

این گزینه تأثیری بر مجموعه‌رمزهای (ciphersuites) نسخه TLSv1.3 ندارد.

فهرستی جداشده با دو‌نقطه از رمزهای مجاز در اتصال TLS، به عنوان مثال DES-CBC3-SHA:IDEA-CBC-MD5.

•: ciphersuites = CIPHERSUITES_LIST

انتخاب مجموعه‌رمزهای مجاز TLSv1.3

فهرستی جداشده با دو‌نقطه از نام مجموعه‌رمزهای TLSv1.3 به ترتیب اولویت.

گزینه ciphersuites در صورت کامپایل با OpenSSL 3.0 یا جدیدتر، رمزهای ناشناخته را نادیده می‌گیرد.

این گزینه نیازمند OpenSSL 1.1.1 یا جدیدتر است.

پیش‌فرض: TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256

•: client = yes | no

حالت کلاینت (سرویس راه دور از TLS استفاده می‌کند)

پیش‌فرض: no (حالت سرور)

•: config = COMMAND[:PARAMETER]

دستور پیکربندی OpenSSL

دستور پیکربندی OpenSSL با پارامتر مشخص‌شده اجرا می‌شود. این امر اجازه می‌دهد هر دستور پیکربندی از درون فایل پیکربندی stunnel فراخوانی شود. دستورات پشتیبانی‌شده در صفحه راهنمای SSL_CONF_cmd(3ssl) شرح داده شده‌اند.

می‌توان از چندین خط config برای تعیین چندین دستور پیکربندی استفاده کرد.

به جای فعال کردن config = Curves:list_curves، از گزینه curves برای پشتیبانی از منحنی‌های بیضوی استفاده کنید.

این گزینه نیازمند OpenSSL 1.0.2 یا جدیدتر است.

•: connect = [HOST:]PORT

اتصال به یک نشانی راه دور

اگر هیچ میزبانی مشخص نشود، میزبان به طور پیش‌فرض localhost خواهد بود.

تعیین چندین گزینه connect در یک بخش سرویس مجاز است. اگر میزبان به چندین نشانی حل شود و/یا چندین گزینه connect تعیین شده باشد، نشانی راه دور با استفاده از الگوریتم نوبت‌گردشی (round-robin) انتخاب می‌شود.

•: CRLpath = DIRECTORY

دایرکتوری فهرست‌های ابطال گواهی (CRL)

این پوشه‌ای است که stunnel هنگام استفاده از گزینه‌های verifyChain و verifyPeer و با CRLcheckChain برای بررسی کامل زنجیره CRL، در آن به دنبال CRLها می‌گردد. توجه داشته باشید که CRLهای موجود در این پوشه باید با فرمت XXXXXXXX.r0 نام‌گذاری شوند که XXXXXXXX مقدار هش از CRL است.

الگوریتم هش در OpenSSL 1.0.0 تغییر کرده است. هنگام ارتقا از OpenSSL 0.x.x به OpenSSL 1.x.x اجرای c_rehash روی این دایرکتوری ضروری است.

مسیر CRLpath در صورت تعیین، نسبت به دایرکتوری chroot سنجیده می‌شود.

•: CRLfile = CRL_FILE

فایل فهرست‌های ابطال گواهی (CRL)

این فایل شامل چندین CRL است که به همراه گزینه‌های verifyChain و verifyPeer، و با CRLcheckChain برای بررسی کامل زنجیره CRL استفاده می‌شود.

•: CRLcheckChain = yes | no

بررسی CRLها برای کل زنجیره گواهی طرف مقابل

این گزینه نیازمند verifyChain = yes و یکی از دو گزینه CRLfile یا CRLpath است.

به طور پیش‌فرض، بررسی CRL تنها برای گواهی انتهایی (برگ) طرف مقابل انجام می‌شود. با تنظیم CRLcheckChain = yes، بررسی CRL علاوه بر آن برای تمامی گواهی‌های موجود در زنجیره صادرکننده تأییدشده نیز صورت می‌پذیرد. حالت زنجیره کامل (Full-chain) در صورت مفقود بودن، منقضی شدن یا نامعتبر بودن CRL صادرکننده، ارتباط را قطع می‌کند (fail closed).

برای زنجیره‌ای مانند Root CA -> Intermediate CA -> Leaf، یک CRL ارائه‌شده توسط میانی برای گواهی برگ، و یک CRL ارائه‌شده توسط ریشه برای گواهی میانی مورد نیاز است.

پیش‌فرض: no

•: curves = list

منحنی‌های ECDH جداشده با `:'

نکته: این گزینه تنها برای سوکت‌های حالت سرور پشتیبانی می‌شود.

برای نسخه‌های OpenSSL قدیمی‌تر از 1.1.1 تنها نام یک منحنی مجاز است.

برای دریافت فهرست منحنی‌های پشتیبانی‌شده از دستور زیر استفاده کنید:

openssl ecparam -list_curves

پیش‌فرض:

X25519:P-256:X448:P-521:P-384 (OpenSSL 1.1.1 یا جدیدتر)
prime256v1 (OpenSSL قدیمی‌تر از 1.1.1)

•: logId = TYPE

نوع شناسه اتصال

این شناسه به شما امکان می‌دهد ورودی‌های گزارش تولیدشده برای هر یک از اتصالات را از یکدیگر تشخیص دهید.

انواع پشتیبانی‌شده فعلی:

•: sequential

شناسه عددی ترتیبی تنها درون یک نمونه منفرد از stunnel یکتا است، اما بسیار فشرده است. این نوع برای تحلیل دستی لاگ‌ها بسیار مناسب است.

•: unique

این شناسه حرفی-عددی به صورت سراسری یکتا است، اما از شماره ترتیبی طولانی‌تر است. این نوع برای تحلیل خودکار لاگ‌ها بیشترین کاربرد را دارد.

•: thread

شناسه ریسه (thread) سیستم‌عامل نه یکتا است (حتی درون یک نمونه منفرد stunnel) و نه کوتاه. این گزینه برای اشکال‌زدایی مشکلات نرم‌افزاری یا خطاهای پیکربندی بیشترین فایده را دارد.

•: process

شناسه پردازه (PID) سیستم‌عامل ممکن است در حالت inetd مفید باشد.

پیش‌فرض: sequential

•: debug = LEVEL

سطح گزارش‌گیری و اشکال‌زدایی

سطح یکی از نام‌ها یا شماره‌های سطوح syslog است: emerg (0)، alert (1)، crit (2)، err (3)، warning (4)، notice (5)، info (6) یا debug (7). تمامی گزارش‌های سطح مشخص‌شده و کلیه سطوح با مقدار عددی کمتر از آن نمایش داده خواهند شد. پیش‌فرض برابر notice (5) است.

اگرچه سطح debug = debug یا debug = 7 پرجزئیات‌ترین خروجی را تولید می‌کند، اما تنها برای استفاده توسعه‌دهندگان stunnel در نظر گرفته شده است. لطفاً فقط در صورتی از این مقدار استفاده کنید که توسعه‌دهنده باشید، یا قصد داشته باشید گزارش‌های خود را برای پشتیبانی فنی ما ارسال نمایید. در غیر این صورت، لاگ‌های تولیدشده قطعاً گیج‌کننده خواهند بود.

•: delay = yes | no

به تأخیر انداختن جستجوی DNS برای گزینه connect

این گزینه برای DNS پویا (Dynamic DNS)، یا زمانی که DNS هنگام راه‌اندازی stunnel در دسترس نیست (VPN کاربران سیار، پیکربندی‌های dial-up) بسیار سودمند است.

حالت جستجوگر با تأخیر (Delayed resolver) به طور خودکار زمانی فعال می‌شود که stunnel هنگام راه‌اندازی در حل نام هر یک از مقصدهای connect برای یک سرویس با شکست روبرو شود.

حالت جستجوگر با تأخیر باعث اعمال اجباری failover = prio می‌شود.

پیش‌فرض: no

•: engineId = ENGINE_ID

انتخاب شناسه موتور برای این سرویس

•: engineNum = ENGINE_NUMBER

انتخاب شماره موتور برای این سرویس

شماره‌گذاری موتورها از 1 آغاز می‌شود.

•: exec = EXECUTABLE_PATH

اجرای یک برنامه محلی از نوع inetd

مسیر exec در صورت تعیین، نسبت به دایرکتوری chroot سنجیده می‌شود.

متغیرهای محیطی زیر روی پلتفرم‌های یونیکس تنظیم می‌شوند: REMOTE_HOST، REMOTE_PORT، SSL_CLIENT_DN، SSL_CLIENT_I_DN.

•: execArgs = $0 $1 $2 ...

آرگومان‌های exec شامل نام برنامه ($0)

کوتیشن‌گذاری در حال حاضر پشتیبانی نمی‌شود. آرگومان‌ها با مقدار دلخواهی از فاصله خالی از یکدیگر تفکیک می‌شوند.

•: failover = rr | prio

راهبرد بازگشت از خرابی (Failover) برای چندین مقصد "connect".

•: rr

نوبت‌گردشی (round robin) - توزیع بار عادلانه

•: prio

اولویت - استفاده از ترتیبی که در فایل پیکربندی مشخص شده است

پیش‌فرض: prio

•: ident = USERNAME

استفاده از بررسی نام کاربری IDENT (RFC 1413)

•: include = DIRECTORY

شامل کردن تمامی بخش‌های فایل پیکربندی موجود در DIRECTORY

فایل‌ها به ترتیب صعودی الفبایی نام‌هایشان وارد می‌شوند. قاعده نام‌گذاری پیشنهادی برای فایل‌ها به این صورت است:

برای گزینه‌های عمومی:

00-global.conf

برای گزینه‌های محلی سطح سرویس:

01-service.conf
02-service.conf

•: key = KEY_FILE | URI

کلید خصوصی برای گواهی مشخص‌شده با گزینه cert

برای احراز هویت مالک گواهی به یک کلید خصوصی نیاز است. از آنجا که این فایل باید محرمانه باقی بماند، فقط باید توسط مالکش قابل خواندن باشد. روی سیستم‌های یونیکس می‌توانید از دستور زیر استفاده کنید:

chmod 600 keyfile

در صورت فعال بودن یک موتور رمزنگاری یا ارائه‌دهنده سخت‌افزاری، از این پارامتر به عنوان شناسه کلید خصوصی (PKCS#11 URI) نیز استفاده می‌شود.

نکته: ارائه‌دهنده (provider) نیازمند OpenSSL 3.0 یا جدیدتر است

پیش‌فرض: مقدار گزینه cert

•: libwrap = yes | no

فعال یا غیرفعال کردن استفاده از /etc/hosts.allow و /etc/hosts.deny.

پیش‌فرض: no (از نسخه 5.00)

•: local = HOST

به طور پیش‌فرض، نشانی IP رابط خروجی به عنوان مبدأ برای اتصالات راه دور استفاده می‌شود. از این گزینه برای مقیدسازی (bind) یک نشانی IP محلی ایستا به جای آن استفاده کنید.

•: OCSP = URL

انتخاب پاسخ‌دهنده OCSP برای اعتبارسنجی گواهی طرف مقابل (موجودیت انتهایی یا برگ)

•: OCSPaia = yes | no

اعتبارسنجی گواهی‌ها با پاسخ‌دهندگان OCSP مندرج در AIA آنها

این گزینه به stunnel امکان می‌دهد گواهی‌ها را با فهرستی از نشانی‌های اینترنتی پاسخ‌دهنده OCSP که از افزونه AIA (دسترسی به اطلاعات مرجع یا Authority Information Access) آنها استخراج شده است، اعتبارسنجی کند.

•: OCSPflag = OCSP_FLAG

مشخص کردن پرچم پاسخ‌دهنده OCSP

می‌توان از چندین OCSPflag برای تعیین چندین پرچم استفاده کرد.

پرچم‌های پشتیبانی‌شده در حال حاضر: NOCERTS، NOINTERN، NOSIGS، NOCHAIN، NOVERIFY، NOEXPLICIT، NOCASIGN، NODELEGATED، NOCHECKS، TRUSTOTHER، RESPID_KEY، NOTIME

•: OCSPnonce = yes | no

ارسال و اعتبارسنجی افزونه nonce مربوط به OCSP

این گزینه از پروتکل OCSP در برابر حملات بازپخش (replay attacks) محافظت می‌کند. به دلیل بار پردازشی محاسباتی آن، افزونه nonce معمولاً فقط در پاسخ‌دهنده‌های داخلی (مانند شبکه‌های سازمانی) پشتیبانی می‌شود، و نه در پاسخ‌دهنده‌های عمومی OCSP.

•: OCSPrequire = yes | no

الزام به دریافت یک پاسخ قاطع از سوی OCSP

غیرفعال کردن این گزینه اجازه برقراری ارتباط را می‌دهد حتی اگر هیچ پاسخ قاطعی از طریق منگنه‌سازی (stapling) و درخواست مستقیم به پاسخ‌دهنده OCSP دریافت نشده باشد.

پیش‌فرض: yes

•: options = SSL_OPTIONS

گزینه‌های کتابخانه OpenSSL

پارامتر، نام گزینه OpenSSL است همان‌گونه که در راهنمای SSL_CTX_set_options(3ssl) توصیف شده است، اما بدون پیشوند SSL_OP_. دستور stunnel -options گزینه‌هایی را که در ترکیب کنونی stunnel و کتابخانه OpenSSL مورد استفاده برای ساخت آن مجاز هستند فهرست می‌کند.

می‌توان از چندین خط options برای مشخص کردن چندین گزینه استفاده کرد. نام گزینه می‌تواند با یک خط تیره ("-") پیشوند شود تا آن گزینه غیرفعال گردد.

برای مثال، برای سازگاری با پیاده‌سازی ناقص TLS در Eudora، می‌توان از گزینه زیر استفاده کرد:

options = DONT_INSERT_EMPTY_FRAGMENTS

پیش‌فرض:

options = NO_SSLv2
options = NO_SSLv3

در صورت کامپایل با OpenSSL 1.1.0 یا جدیدتر، به جای غیرفعال کردن نگارش‌های خاصی از پروتکل TLS، از گزینه sslVersionMax یا sslVersionMin استفاده کنید.

•: protocol = PROTO

پروتکل لایه کاربرد برای مذاکره TLS

این گزینه مذاکره اولیه و وابسته به پروتکل رمزنگاری TLS را فعال می‌کند. گزینه protocol نباید همراه با رمزنگاری TLS روی یک پورت جداگانه استفاده شود.

پروتکل‌های پشتیبانی‌شده در حال حاضر:

•: cifs

افزونه اختصاصی (بدون مستندات رسمی) از پروتکل CIFS که در Samba پیاده‌سازی شده بود. پشتیبانی از این افزونه در Samba 3.0.0 متوقف گردید.

•: capwin

https://www.capwin.org پشتیبانی از برنامه

•: capwinctrl

https://www.capwin.org پشتیبانی از برنامه

این پروتکل تنها در حالت کلاینت پشتیبانی می‌شود.

•: connect

بر پایه بخش 5.2 از RFC 2817 - ارتقا به TLS درون HTTP/1.1 - درخواست یک تونل با CONNECT

این پروتکل تنها در حالت کلاینت پشتیبانی می‌شود.

•: imap

بر پایه RFC 2595 - استفاده از TLS با IMAP، POP3 و ACAP

•: ldap

بر پایه RFC 2830 - پروتکل سبک‌وزن دسترسی به دایرکتوری (نگارش 3): افزونه امنیت لایه انتقال

•: nntp

بر پایه RFC 4642 - استفاده از امنیت لایه انتقال (TLS) با پروتکل انتقال اخبار شبکه (NNTP)

این پروتکل تنها در حالت کلاینت پشتیبانی می‌شود.

•: pgsql

بر پایه https://www.postgresql.org/docs/8.3/static/protocol-flow.html#AEN73982

•: pop3

بر پایه RFC 2449 - سازوکار افزونه‌های POP3

•: proxy

ارسال نشانی IP اصلی کلاینت با پروتکل HAProxy PROXY نگارش 1 https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

•: smtp

بر پایه RFC 2487 - افزونه سرویس SMTP برای SMTP امن بر بستر TLS

•: socks

نگارش‌های 4، 4a و 5 از SOCKS پشتیبانی می‌شوند. خود پروتکل SOCKS درون لایه رمزنگاری TLS کپسوله‌سازی می‌شود تا از نشانی مقصد نهایی محافظت شود.

https://www.openssh.com/txt/socks4.protocol

https://www.openssh.com/txt/socks4a.protocol

دستور BIND در پروتکل SOCKS پشتیبانی نمی‌شود. پارامتر USERID نادیده گرفته می‌شود.

برای نمونه فایل‌های پیکربندی VPN مبتنی بر رمزنگاری SOCKS به بخش مثال‌ها مراجعه کنید.

•: protocolAuthentication = AUTHENTICATION

نوع احراز هویت برای مذاکرات پروتکل

در حال حاضر این گزینه فقط در پروتکل‌های سمت کلاینت `connect' و `smtp' پشتیبانی می‌شود.

انواع احراز هویت پشتیبانی‌شده برای پروتکل `connect' عبارتند از `basic' یا `ntlm'. نوع احراز هویت پیش‌فرض `connect' برابر `basic' است.

انواع احراز هویت پشتیبانی‌شده برای پروتکل `smtp' عبارتند از `plain' یا `login'. نوع احراز هویت پیش‌فرض `smtp' برابر `plain' است.

•: protocolDomain = DOMAIN

دامنه برای مذاکرات پروتکل

در حال حاضر این گزینه فقط در پروتکل سمت کلاینت `connect' پشتیبانی می‌شود.

•: protocolHeader = HEADER

سرآیند (header) برای مذاکرات پروتکل

در حال حاضر این گزینه فقط در پروتکل سمت کلاینت `connect' پشتیبانی می‌شود.

•: protocolHost = ADDRESS

نشانی میزبان برای مذاکرات پروتکل

برای مذاکرات پروتکل `connect'، گزینه protocolHost مقدار HOST:PORT سرور نهایی TLS را که پروکسی باید به آن متصل شود مشخص می‌نماید. سرور پروکسی که مستقیماً توسط stunnel به آن متصل می‌شود باید با گزینه connect مشخص گردد.

برای مذاکرات پروتکل `smtp'، گزینه protocolHost مقدار کلاینت SMTP HELO/EHLO را کنترل می‌کند.

•: protocolPassword = PASSWORD

گذرواژه برای مذاکرات پروتکل

در حال حاضر این گزینه فقط در پروتکل‌های سمت کلاینت `connect' و `smtp' پشتیبانی می‌شود.

•: protocolUsername = USERNAME

نام کاربری برای مذاکرات پروتکل

در حال حاضر این گزینه فقط در پروتکل‌های سمت کلاینت `connect' و `smtp' پشتیبانی می‌شود.

•: PSKidentity = IDENTITY

شناسه PSK برای کلاینت PSK

از PSKidentity می‌توان در کلاینت‌های stunnel برای انتخاب شناسه PSK مورد استفاده جهت احراز هویت بهره برد. این گزینه در بخش‌های سرور نادیده گرفته می‌شود.

پیش‌فرض: اولین شناسه مشخص‌شده در فایل PSKsecrets.

•: PSKsecrets = FILE

فایل حاوی شناسه‌های PSK و کلیدهای متناظر آنها

هر خط از فایل در قالب زیر است:

IDENTITY:KEY

کلیدهای هگزادسیمال به صورت خودکار به فرمت دودویی تبدیل می‌شوند. طول کلیدها باید حداقل 16 بایت باشد که مستلزم حداقل 32 نویسه هگزادسیمال است. این فایل نباید برای عموم کاربران قابل خواندن یا نوشتن باشد.

•: pty = yes | no (فقط یونیکس)

تخصیص یک شبه‌ترمینال (pseudoterminal) برای گزینه `exec'

•: redirect = [HOST:]PORT

تغییر مسیر اتصالات کلاینت TLS در صورت شکست در احراز هویت مبتنی بر گواهی

این گزینه فقط در حالت سرور کار می‌کند. برخی مذاکرات پروتکل نیز با گزینه redirect ناسازگار هستند.

•: renegotiation = yes | no

پشتیبانی از مذاکره مجدد TLS (renegotiation)

کاربردهای مذاکره مجدد TLS شامل برخی سناریوهای احراز هویت یا تعویض مجدد کلید در اتصالات طولانی‌مدت است.

از سوی دیگر این ویژگی می‌تواند حمله منع سرویس (DoS) از طریق مصرف شدید پردازنده را تسهیل کند:

https://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html

لطفاً توجه داشته باشید که غیرفعال کردن مذاکره مجدد TLS این مسئله را به طور کامل رفع نمی‌کند.

پیش‌فرض: yes (در صورت پشتیبانی OpenSSL)

•: reset = yes | no

تلاش برای استفاده از پرچم TCP RST جهت اعلام خطا

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

پیش‌فرض: yes

•: retry = yes | no | DELAY

اتصال مجدد یک بخش connect+exec پس از قطع شدن آن

مقدار DELAY تعداد میلی‌ثانیه‌ها پیش از تلاش مجدد را مشخص می‌کند. "retry = yes" همان اثر "retry = 1000" را دارد.

پیش‌فرض: no

•: securityLevel = LEVEL

تنظیم سطح امنیت

معنای هر سطح در زیر توصیف شده است:

•: سطح 0 (level 0)

همه چیز مجاز است.

•: سطح 1 (level 1)

سطح امنیت متناظر با حداقل 80 بیت امنیت است. هر پارامتری که امنیتی کمتر از 80 بیت ارائه دهد حذف می‌گردد. در نتیجه کلیدهای RSA، DSA و DH کوتاه‌تر از 1024 بیت و کلیدهای ECC کوتاه‌تر از 160 بیت ممنوع هستند. کلیه مجموعه‌رمزهای صادراتی (export cipher suites) ممنوع هستند چرا که همگی کمتر از 80 بیت امنیت دارند. نسخه 2 پروتکل SSL ممنوع است. هرگونه مجموعه‌رمز که از MD5 برای MAC استفاده کند نیز ممنوع است. علاوه بر این، پروتکل‌های SSLv3، TLS 1.0 و TLS 1.1 همگی در OpenSSL 3.0 و جدیدتر غیرفعال هستند.

•: سطح 2 (level 2)

سطح امنیت روی 112 بیت امنیت تنظیم می‌شود. در نتیجه کلیدهای RSA، DSA و DH کوتاه‌تر از 2048 بیت و کلیدهای ECC کوتاه‌تر از 224 بیت ممنوع هستند. علاوه بر موارد مستثنی در سطح 1، هرگونه مجموعه‌رمز که از RC4 استفاده کند نیز ممنوع است. فشرده‌سازی غیرفعال است. نسخه 3 پروتکل SSL نیز برای نگارش‌های OpenSSL قدیمی‌تر از 3.0 مجاز نیست.

•: سطح 3 (level 3)

سطح امنیت روی 128 بیت امنیت تنظیم می‌شود. در نتیجه کلیدهای RSA، DSA و DH کوتاه‌تر از 3072 بیت و کلیدهای ECC کوتاه‌تر از 256 بیت ممنوع هستند. علاوه بر موارد مستثنی در سطح 2، مجموعه‌رمزهایی که رازداری پیشرو (forward secrecy) را ارائه نمی‌دهند ممنوع هستند. بلیت‌های نشست (Session tickets) غیرفعال هستند. نگارش‌های TLS پایین‌تر از 1.1 برای نسخه‌های OpenSSL قدیمی‌تر از 3.0 مجاز نیستند.

•: سطح 4 (level 4)

سطح امنیت روی 192 بیت امنیت تنظیم می‌شود. در نتیجه کلیدهای RSA، DSA و DH کوتاه‌تر از 7680 بیت و کلیدهای ECC کوتاه‌تر از 384 بیت ممنوع هستند. مجموعه‌رمزهایی که از SHA1 برای MAC استفاده می‌کنند ممنوع هستند. نگارش‌های TLS پایین‌تر از 1.2 برای نسخه‌های OpenSSL قدیمی‌تر از 3.0 مجاز نیستند.

•: سطح 5 (level 5)

سطح امنیت روی 256 بیت امنیت تنظیم می‌شود. در نتیجه کلیدهای RSA، DSA و DH کوتاه‌تر از 15360 بیت و کلیدهای ECC کوتاه‌تر از 512 بیت ممنوع هستند.

•: پیش‌فرض: 2

گزینه securityLevel تنها در صورت کامپایل با OpenSSL 1.1.0 و جدیدتر در دسترس است.

•: requireCert = yes | no

الزام به ارائه گواهی کلاینت برای verifyChain یا verifyPeer

با تنظیم requireCert روی no، سرور stunnel اتصالات کلاینت‌هایی را که گواهی ارائه نکرده‌اند می‌پذیرد.

هر دو گزینه verifyChain = yes و verifyPeer = yes مستلزم requireCert = yes هستند.

پیش‌فرض: no

•: setgid = GROUP (فقط یونیکس)

شناسه گروه یونیکس (GID)

به عنوان گزینه عمومی: اجرای setgid() به گروه مشخص‌شده در حالت دیمن و پاک کردن تمامی گروه‌های دیگر.

به عنوان گزینه سطح سرویس: تنظیم گروه سوکت یونیکس مشخص‌شده با "accept".

•: setuid = USER (فقط یونیکس)

شناسه کاربر یونیکس (UID)

به عنوان گزینه عمومی: اجرای setuid() به کاربر مشخص‌شده در حالت دیمن.

به عنوان گزینه سطح سرویس: تنظیم مالک سوکت یونیکس مشخص‌شده با "accept".

•: sessionCacheSize = NUM_ENTRIES

اندازه حافظه موقت (کش) نشست‌ها

گزینه sessionCacheSize حداکثر تعداد مدخل‌های حافظه موقت داخلی نشست‌ها را مشخص می‌کند.

می‌توان از مقدار 0 برای اندازه نامحدود استفاده کرد. به دلیل خطر حمله منع سرویس (DoS) از طریق تخلیه حافظه، این مقدار برای محیط‌های عملیاتی پیشنهاد نمی‌شود.

•: sessionCacheTimeout = TIMEOUT

مهلت زمانی حافظه موقت نشست‌ها

این مقدار، تعداد ثانیه‌های نگهداری نشست‌های کش‌شده‌ی TLS است.

•: sessionResume = yes | no

مجاز یا غیرمجاز بودن ازسرگیری نشست (session resumption)

پیش‌فرض: yes

•: sessiond = HOST:PORT

نشانی سرور کش TLS متعلق به sessiond

•: sni = SERVICE_NAME:SERVER_NAME_PATTERN (حالت سرور)

استفاده از سرویس به عنوان یک سرویس ثانویه (سرور مجازی مبتنی بر نام) برای افزونه Server Name Indication (SNI) در TLS (RFC 3546).

شناسه SERVICE_NAME سرویس اصلی را مشخص می‌کند که اتصالات کلاینت را با گزینه accept می‌پذیرد. عبارت SERVER_NAME_PATTERN نام میزبان مورد نظر برای تغییر مسیر را مشخص می‌نماید. الگو می‌تواند با نویسه `*' آغاز شود، برای مثال `*.example.com'. معمولاً چندین سرویس ثانویه برای یک سرویس اصلی واحد مشخص می‌شوند. گزینه sni را می‌توان بیش از یک بار درون یک سرویس ثانویه واحد نیز تعریف کرد.

این سرویس و همچنین سرویس اصلی نمی‌توانند در حالت کلاینت پیکربندی شوند.

گزینه connect در سرویس ثانویه هنگام مشخص شدن گزینه protocol نادیده گرفته می‌شود، چرا که protocol پیش از دست‌تکانی TLS به میزبان راه دور متصل می‌گردد.

بررسی‌های Libwrap (فقط یونیکس) دو بار انجام می‌شوند: یک بار با نام سرویس اصلی پس از پذیرش اتصال TCP، و یک بار با نام سرویس ثانویه در طول دست‌تکانی TLS.

گزینه sni تنها در صورت کامپایل با OpenSSL 1.0.0 و جدیدتر در دسترس است.

•: sni = SERVER_NAME (حالت کلاینت)

استفاده از پارامتر به عنوان مقدار افزونه TLS Server Name Indication (RFC 3546).

خالی گذاشتن SERVER_NAME ارسال افزونه SNI را غیرفعال می‌کند.

گزینه sni تنها در صورت کامپایل با OpenSSL 1.0.0 و جدیدتر در دسترس است.

•: socket = a|l|r:OPTION=VALUE[:VALUE]

تنظیم یک گزینه روی سوکت پذیرش (accept)، محلی (local) یا راه دور (remote)

مقادیر گزینه linger به صورت l_onof:l_linger هستند. مقادیر مربوط به زمان به صورت tv_sec:tv_usec می‌باشند.

مثال‌ها:

socket = l:SO_LINGER=1:60
    set one minute timeout for closing local socket
socket = r:SO_OOBINLINE=yes
    place out-of-band data directly into the
    receive data stream for remote sockets
socket = a:SO_REUSEADDR=no
    disable address reuse (enabled by default)
socket = a:SO_BINDTODEVICE=lo
    only accept connections on loopback interface

•: sslVersion = SSL_VERSION

انتخاب نگارش پروتکل TLS

نگارش‌های پشتیبانی‌شده: all, SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3

در دسترس بودن پروتکل‌های خاص به کتابخانه OpenSSL لینک‌شده بستگی دارد. نگارش‌های قدیمی‌تر OpenSSL از TLSv1.1، TLSv1.2 و TLSv1.3 پشتیبانی نمی‌کنند. نگارش‌های جدیدتر OpenSSL از SSLv2 پشتیبانی نمی‌کنند.

پروتکل‌های منسوخ‌شده SSLv2 و SSLv3 در حال حاضر به طور پیش‌فرض غیرفعال هستند.

تنظیم گزینه

sslVersion = SSL_VERSION

در صورت کامپایل با OpenSSL 1.1.0 و جدیدتر، معادل گزینه‌های زیر است:

sslVersionMax = SSL_VERSION
sslVersionMin = SSL_VERSION

•: sslVersionMax = SSL_VERSION

حداکثر نگارش‌های پشتیبانی‌شده پروتکل

نگارش‌های پشتیبانی‌شده: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3

مقدار all نگارش‌های پروتکل را تا بالاترین نگارش پشتیبانی‌شده توسط کتابخانه OpenSSL لینک‌شده فعال می‌کند.

در دسترس بودن پروتکل‌های خاص به کتابخانه OpenSSL پیوندشده بستگی دارد.

گزینه sslVersionMax تنها در صورت کامپایل با OpenSSL 1.1.0 و جدیدتر در دسترس است.

پیش‌فرض: all

•: sslVersionMin = SSL_VERSION

حداقل نگارش‌های پشتیبانی‌شده پروتکل

نگارش‌های پشتیبانی‌شده: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3

مقدار all نگارش‌های پروتکل را تا پایین‌ترین نگارش پشتیبانی‌شده توسط کتابخانه OpenSSL پیوندشده فعال می‌کند.

در دسترس بودن پروتکل‌های خاص به کتابخانه OpenSSL پیوندشده بستگی دارد.

گزینه sslVersionMin تنها در صورت کامپایل با OpenSSL 1.1.0 و جدیدتر در دسترس است.

پیش‌فرض: TLSv1

•: stack = BYTES (به جز مدل FORK)

اندازه پشته (stack) پردازنده برای ریسه‌های ایجادشده

اندازه پشته بیش از حد برای ریسه‌ها مصرف حافظه مجازی را افزایش می‌دهد. اندازه ناکافی پشته ممکن است موجب فروپاشی (crash) برنامه گردد.

پیش‌فرض: 65536 بایت (کافی برای تمامی پلتفرم‌های آزمایش‌شده توسط ما)

•: ticketKeySecret = SECRET

کلید متقارن هگزادسیمال مورد استفاده برای حفاظت از محرمانگی بلیت نشست (session ticket)

بلیت‌های نشست تعریف‌شده در RFC 5077 قابلیت بهبودیافته‌ای برای ازسرگیری نشست ارائه می‌دهند، به طوری که نگهداری وضعیت هر نشست در حافظه موقت سمت سرور الزامی نخواهد بود.

ترکیب گزینه‌های ticketKeySecret و ticketMacSecret امکان ازسرگیری یک نشست مذاکره‌شده را روی گره‌های دیگر خوشه (cluster) یا پس از راه‌اندازی مجدد سرور فراهم می‌کند.

طول کلید باید 16 یا 32 بایت باشد، که دقیقاً معادل 32 یا 64 رقم هگزادسیمال است. می‌توان به صورت اختیاری از دو‌نقطه بین بایت‌های دوحرفی هگزادسیمال استفاده کرد.

این گزینه فقط در حالت سرور کار می‌کند.

گزینه ticketKeySecret تنها در صورت کامپایل با OpenSSL 1.0.0 و جدیدتر در دسترس است.

برای پشتیبانی از ticket در نسخه‌های OpenSSL قدیمی‌تر از 1.1.1، غیرفعال کردن گزینه NO_TICKET الزامی است، اما توجه داشته باشید که این گزینه با گزینه redirect ناسازگار است.

•: ticketMacSecret = SECRET

کلید متقارن هگزادسیمال مورد استفاده برای حفاظت از یکپارچگی بلیت نشست

این گزینه فقط در حالت سرور کار می‌کند.

گزینه ticketMacSecret تنها در صورت کامپایل با OpenSSL 1.0.0 و جدیدتر در دسترس است.

•: TIMEOUTbusy = SECONDS

زمان انتظار برای داده‌های مورد انتظار

•: TIMEOUTclose = SECONDS

زمان انتظار برای close_notify (برای MSIE دارای اشکال روی 0 تنظیم شود)

•: TIMEOUTconnect = SECONDS

زمان انتظار برای اتصال به یک میزبان راه دور

•: TIMEOUTidle = SECONDS

مدت زمان باز نگه داشتن یک اتصال بیکار (idle)

•: TIMEOUTocsp = SECONDS

زمان انتظار برای اتصال به یک پاسخ‌دهنده OCSP

•: transport = tcp | udp

انتخاب پروتکل لایه انتقال

مقادیر پشتیبانی‌شده:

•: tcp

استفاده از TLS استاندارد روی TCP (پیش‌فرض).

•: udp

استفاده از DTLS روی UDP.

هر دیتاگرام یک اتصال منطقی جدید را درون سرویس باز می‌کند. سرور برای هر کلاینت از یک سوکت متصل مجزا استفاده می‌نماید و کوکی‌های DTLS از حملات انعکاسی DDoS جلوگیری می‌کنند.

پیش‌فرض: tcp

•: transparent = none | source | destination | both (فقط یونیکس)

فعال‌سازی پشتیبانی از پروکسی شفاف (transparent proxy) روی پلتفرم‌های منتخب

مقادیر پشتیبانی‌شده:

•: none

غیرفعال‌سازی پشتیبانی از پروکسی شفاف. این مقدار پیش‌فرض است.

•: source

بازنویسی نشانی به گونه‌ای که دیمن پوشش‌یافته به نظر برسد از دستگاه کلاینت TLS متصل می‌شود به جای ماشینی که stunnel روی آن اجرا می‌شود.

این گزینه در حال حاضر در موارد زیر در دسترس است:

•: حالت راه دور (گزینه connect) روی Linux >=2.6.28

این پیکربندی مستلزم اجرای stunnel با دسترسی ریشه (root) و بدون گزینه setuid است.

این پیکربندی نیازمند تنظیمات زیر برای iptables و مسیریابی است (احتمالاً در /etc/rc.local یا فایلی معادل):

iptables -t mangle -N DIVERT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
ip rule add fwmark 1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100
echo 0 >/proc/sys/net/ipv4/conf/lo/rp_filter

stunnel نیز باید با دسترسی ریشه و بدون گزینه setuid اجرا گردد.

•: حالت راه دور (گزینه connect) روی Linux 2.2.x

این پیکربندی نیازمند آن است که هسته با گزینه transparent proxy کامپایل شده باشد. سرویس متصل‌شده باید روی یک میزبان مجزا نصب شود. مسیریابی به سمت کلاینت‌ها باید از طریق سیستم stunnel عبور کند.

stunnel نیز باید با دسترسی ریشه و بدون گزینه setuid اجرا شود.

•: حالت راه دور (گزینه connect) روی FreeBSD >=8.0

این پیکربندی نیازمند تنظیمات اضافی فایروال و مسیریابی است. stunnel نیز باید با دسترسی ریشه و بدون گزینه setuid اجرا گردد.

•: حالت محلی (گزینه exec)

این پیکربندی از طریق پیش‌بارگذاری کتابخانه مشترک libstunnel.so کار می‌کند. متغیر محیطی _RLD_LIST روی Tru64، و متغیر LD_PRELOAD روی سایر پلتفرم‌ها استفاده می‌شود.

•: destination

به جای گزینه connect از مقصد اصلی استفاده می‌شود.

یک بخش سرویس برای مقصد شفاف ممکن است به این شکل باشد:

[transparent]
client = yes
accept = <stunnel_port>
transparent = destination

این پیکربندی برای کارکرد به تنظیمات iptables نیاز دارد، احتمالاً در /etc/rc.local یا فایل معادل آن.

برای یک مقصد اتصال که روی همان میزبان نصب شده است:

/sbin/iptables -t nat -I OUTPUT -p tcp --dport <redirected_port> \
    -m ! --uid-owner <stunnel_user_id> \
    -j DNAT --to-destination <local_ip>:<stunnel_port>

برای یک مقصد اتصال که روی یک میزبان راه دور نصب شده است:

/sbin/iptables -I INPUT -i eth0 -p tcp --dport <stunnel_port> -j ACCEPT
/sbin/iptables -t nat -I PREROUTING -p tcp --dport <redirected_port> \
    -i eth0 -j DNAT --to-destination <local_ip>:<stunnel_port>

گزینه مقصد شفاف در حال حاضر تنها روی لینوکس پشتیبانی می‌شود.

•: both

استفاده همزمان از هر دو حالت پروکسی شفاف source و destination.

دو گزینه موروثی و قدیمی نیز برای سازگاری رو به عقب پشتیبانی می‌شوند:

•: yes

نام این گزینه به source تغییر یافته است.

•: no

نام این گزینه به none تغییر یافته است.

•: verify = LEVEL

اعتبارسنجی گواهی طرف مقابل

این گزینه منسوخ شده و باید با گزینه‌های verifyChain و verifyPeer جایگزین گردد.

•: سطح 0 (level 0)

درخواست زنجیره گواهی طرف مقابل و نادیده گرفتن آن.

•: سطح 1 (level 1)

اعتبارسنجی زنجیره گواهی طرف مقابل در صورت حضور آن.

•: سطح 2 (level 2)

اعتبارسنجی زنجیره گواهی طرف مقابل.

•: سطح 3 (level 3)

اعتبارسنجی زنجیره گواهی طرف مقابل و گواهی طرف مقابل (برگ) در برابر گواهی نصب‌شده به صورت محلی.

•: سطح 4 (level 4)

نادیده گرفتن زنجیره گواهی طرف مقابل و صرفاً اعتبارسنجی گواهی برگ طرف مقابل در برابر گواهی محلی.

•: پیش‌فرض

بدون اعتبارسنجی (No verify).

•: verifyChain = yes | no

اعتبارسنجی زنجیره گواهی طرف مقابل از گواهی CA ریشه به بعد

برای اعتبارسنجی گواهی سرور، ضروری است که یک گواهی خاص با checkHost یا checkIP نیز الزام گردد.

گواهی خودامضاشده‌ی CA ریشه باید در فایل مشخص‌شده با CAfile یا در دایرکتوری مشخص‌شده با CApath ذخیره شود.

پیش‌فرض: no

•: verifyPeer = yes | no

اعتبارسنجی گواهی طرف مقابل (موجودیت انتهایی یا برگ)

گواهی برگ طرف مقابل باید در فایل مشخص‌شده با CAfile یا در دایرکتوری مشخص‌شده با CApath ذخیره شود.

پیش‌فرض: no

مقدار بازگشتی (RETURN VALUE)

stunnel در صورت موفقیت مقدار صفر و در صورت بروز خطا مقداری غیر صفر برمی‌گرداند.

سیگنال‌ها (SIGNALS)

از سیگنال‌های زیر می‌توان برای کنترل stunnel در محیط یونیکس استفاده کرد:

•: SIGHUP

بارگذاری مجدد اجباری فایل پیکربندی.

برخی از گزینه‌های عمومی دوباره بارگذاری نخواهند شد:

chroot
foreground
pid
setgid
setuid

استفاده از گزینه `setuid' همچنین مانع از مقید شدن stunnel به پورت‌های ممتاز (<1024) در زمان بارگذاری مجدد پیکربندی می‌شود.

هنگامی که گزینه `chroot' استفاده می‌شود، stunnel تمام فایل‌های خود را (شامل فایل پیکربندی، گواهی‌ها، فایل گزارش و فایل pid) درون محیط ایزوله chroot جستجو خواهد کرد.

•: SIGUSR1

بستن و بازگشایی مجدد فایل گزارش stunnel. از این قابلیت می‌توان برای چرخش فایل‌های لاگ (log rotation) استفاده کرد.

•: SIGUSR2

ثبت فهرست اتصالات فعال در گزارش.

•: SIGTERM, SIGQUIT, SIGINT

خاموش کردن و توقف کامل stunnel.

نتیجه ارسال هرگونه سیگنال دیگر به سرور نامشخص و تعریف‌نشده است.

مثال‌ها (EXAMPLES)

به منظور ارائه کپسوله‌سازی TLS برای سرویس محلی imapd خود، از دستورات زیر استفاده کنید:

[imapd]
accept = 993
exec = /usr/sbin/imapd
execArgs = imapd

یا در حالت راه دور:

[imapd]
accept = 993
connect = 143

برای اینکه کلاینت ایمیل محلی شما بتواند به یک سرویس imapd مجهز به TLS روی سروری دیگر متصل شود، کلاینت ایمیل را برای اتصال به پورت 119 روی localhost پیکربندی کرده و از نمونه زیر استفاده نمایید:

[imap]
client = yes
accept = 143
connect = servername:993

اگر می‌خواهید برای دیمن pppd خود روی پورت 2020 تونل‌سازی ایجاد کنید، از نمونه‌ای شبیه به این استفاده کنید:

[vpn]
accept = 2020
exec = /usr/sbin/pppd
execArgs = pppd local
pty = yes

اگر قصد دارید از stunnel در حالت inetd برای راه‌اندازی پردازه imapd خود استفاده کنید، از این stunnel.conf استفاده نمایید. توجه داشته باشید که نباید هیچ بخش [service_name] وجود داشته باشد.

exec = /usr/sbin/imapd
execArgs = imapd

برای راه‌اندازی VPN مبتنی بر SOCKS، سرویس کلاینت زیر را پیکربندی کنید:

[socks_client]
client = yes
accept = 127.0.0.1:1080
connect = vpn_server:9080
verifyPeer = yes
CAfile = stunnel.pem

پیکربندی متناظر روی میزبان vpn_server به این صورت است:

[socks_server]
protocol = socks
accept = 9080
cert = stunnel.pem
key = stunnel.key

حال پیکربندی خود را روی ماشین کلاینت با دستور زیر آزمایش کنید:

curl --socks4a localhost http://www.example.com/

یک نمونه از پیکربندی SNI در حالت سرور:

[virtual]
; primary service
accept = 443
cert =  default.pem
connect = default.internal.mydomain.com:8080
[sni1]
; secondary service 1
sni = virtual:server1.mydomain.com
cert = server1.pem
connect = server1.internal.mydomain.com:8081
[sni2]
; secondary service 2
sni = virtual:server2.mydomain.com
cert = server2.pem
connect = server2.internal.mydomain.com:8082
verifyPeer = yes
CAfile = server2-allowed-clients.pem

نمونه‌ای از پیکربندی پیشرفته موتور رمزنگاری که امکان احراز هویت با کلیدهای خصوصی ذخیره‌شده در مخزن گواهی ویندوز را فراهم می‌کند (فقط ویندوز). با موتور CAPI نیازی به انتخاب دستی کلید کلاینت نخواهید داشت. کلید کلاینت به صورت خودکار بر اساس فهرست CAهای مورد اعتماد سرور انتخاب می‌شود.

engine = capi
[service]
engineId = capi
client = yes
accept = 127.0.0.1:8080
connect = example.com:8443

نمونه‌ای از پیکربندی پیشرفته موتور رمزنگاری جهت استفاده از گواهی و کلید خصوصی متناظر از یک موتور pkcs11:

engine = pkcs11
engineCtrl = MODULE_PATH:opensc-pkcs11.so
engineCtrl = PIN:123456
[service]
engineId = pkcs11
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=MyCert
key = pkcs11:token=MyToken;object=MyKey

نمونه‌ای از پیکربندی پیشرفته موتور رمزنگاری جهت استفاده از گواهی و کلید خصوصی متناظر از یک توکن SoftHSM:

engine = pkcs11
engineCtrl = MODULE_PATH:softhsm2.dll
engineCtrl = PIN:12345
[service]
engineId = pkcs11
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=KeyCert

نمونه‌ای از پیکربندی پیشرفته ارائه‌دهنده (provider) جهت استفاده از گواهی و کلید خصوصی متناظر از یک ارائه‌دهنده `pkcs11prov`:

نکته: نیازمند OpenSSL 3.0 یا جدیدتر است

setEnv = PKCS11_MODULE_PATH=opensc-pkcs11.dll
setEnv = PKCS11_PIN:123456
provider = pkcs11prov
[service]
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=MyCert
key = pkcs11:token=MyToken;object=MyKey

نکته: نیازمند OpenSSL 3.5 یا جدیدتر است

provider = pkcs11prov
providerParameter = pkcs11prov:pkcs11_module=opensc-pkcs11.dll
providerParameter = pkcs11prov:pin=123456
[service]
client = yes
accept = 127.0.0.1:8080
connect = example.com:843
cert = pkcs11:token=MyToken;object=MyCert
key = pkcs11:token=MyToken;object=MyKey

در ویندوز، کتابخانه PKCS#11 باید در دایرکتوری `ossl-modules` قرار گیرد، یا مسیر کامل و مطلق آن در پارامتر `PKCS11_MODULE_PATH` یا `pkcs11_module` ارائه شود.

نکات (NOTES)

محدودیت‌ها (RESTRICTIONS)

به دلیل ماهیت پروتکل FTP که از چندین پورت برای انتقال داده‌ها استفاده می‌کند، نمی‌توان از stunnel برای دیمن FTP استفاده کرد. با این وجود، نگارش‌های مجهز به TLS برای دیمن‌های FTP و telnet موجود هستند.

حالت INETD (INETD MODE)

متداول‌ترین کاربرد stunnel گوش دادن روی یک پورت شبکه و برقراری ارتباط یا با یک پورت جدید از طریق گزینه connect، یا با یک برنامه جدید از طریق گزینه exec است. با این حال یک حالت ویژه زمانی رخ می‌دهد که بخواهید برنامه‌ای دیگر اتصالات ورودی را بپذیرد و stunnel را اجرا کند، برای مثال با inetd، xinetd یا tcpserver.

برای مثال، اگر خط زیر را در inetd.conf داشته باشید:

imaps stream tcp nowait root @bindir@/stunnel stunnel @sysconfdir@/stunnel/imaps.conf

در این موارد، برنامه با سبک inetd مسئول مقیدسازی سوکت شبکه (در بالا imaps) و تحویل آن به stunnel هنگام دریافت اتصال است. بنابراین نباید هیچ گزینه accept در stunnel تعریف شده باشد. تمام گزینه‌های سطح سرویس باید در بخش گزینه‌های عمومی قرار گیرند، و هیچ بخش [service_name] وجود نخواهد داشت. برای مشاهده نمونه‌های پیکربندی به بخش مثال‌ها (EXAMPLES) مراجعه فرمایید.

گواهی‌ها (CERTIFICATES)

هر دیمن مجهز به TLS باید یک گواهی معتبر X.509 به طرف مقابل ارائه دهد. همچنین برای رمزگشایی داده‌های ورودی به یک کلید خصوصی نیاز دارد. ساده‌ترین روش برای به دست آوردن گواهی و کلید، تولید آنها با بسته رایگان OpenSSL است. می‌توانید اطلاعات بیشتری درباره تولید گواهی‌ها در صفحات فهرست‌شده در زیر بیابید.

فایل .pem باید شامل کلید خصوصی رمزگذاری‌نشده و یک گواهی امضاشده (نه یک درخواست گواهی یا CSR) باشد. بنابراین فایل باید به این صورت باشد:

-----BEGIN RSA PRIVATE KEY-----
[encoded key]
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
[encoded certificate]
-----END CERTIFICATE-----

تولید تصادفی (RANDOMNESS)

stunnel برای اینکه TLS بتواند از تصادفی‌سازی مناسبی بهره‌مند شود، نیاز دارد تولیدکننده اعداد شبه‌تصادفی (PRNG) را مقداردهی اولیه (seed) کند. منابع زیر به ترتیب بارگذاری می‌شوند تا داده‌های تصادفی کافی گردآوری شود:

فایل مشخص‌شده با فلگ RNDfile.
فایل مشخص‌شده با متغیر محیطی RANDFILE، در صورت تنظیم.
فایل .rnd در دایرکتوری خانگی شما، در صورتی که RANDFILE تنظیم نشده باشد.
فایل مشخص‌شده با `--with-random' در زمان کامپایل.
محتویات صفحه نمایش در صورت اجرا روی ویندوز.
سوکت egd مشخص‌شده با پرچم EGD.
سوکت egd مشخص‌شده با `--with-egd-sock' در زمان کامپایل.
دستگاه /dev/urandom.

توجه داشته باشید که در رایانه‌های ویندوزی فاقد تعامل کاربر با کنسول (حرکات ماوس، ایجاد پنجره‌ها و غیره) محتویات صفحه نمایش تنوع کافی برای تأمین آنتروپی ندارند و باید یک فایل تصادفی برای استفاده با فلگ RNDfile ارائه دهید.

توجه داشته باشید که فایل مشخص‌شده با پرچم RNDfile باید حاوی داده‌های تصادفی باشد -- این بدان معناست که در هر بار اجرای stunnel باید شامل اطلاعات متفاوتی باشد. این کار به طور خودکار انجام می‌شود مگر اینکه از فلگ RNDoverwrite استفاده شده باشد. اگر مایلید این فایل را به صورت دستی به‌روزرسانی کنید، دستور openssl rand در نسخه‌های اخیر OpenSSL سودمند خواهد بود.

نکته مهم: در صورت در دسترس بودن /dev/urandom، کتابخانه OpenSSL معمولاً هنگام بررسی وضعیت تصادفی، PRNG را با آن مقداردهی اولیه می‌کند. روی سیستم‌های دارای /dev/urandom به احتمال قوی OpenSSL از آن استفاده خواهد کرد، حتی اگر در انتهای فهرست فوق قرار گرفته باشد. این رفتار مربوط به OpenSSL است و نه stunnel.

پارامترهای DH (DH PARAMETERS)

نگارش 4.40 و جدیدتر stunnel شامل پارامترهای 2048 بیتی سخت‌کدشده (hardcoded) برای DH است. از نگارش 5.18 stunnel، این پارامترهای ثابت هر 24 ساعت یک بار با پارامترهای موقت DH که به صورت خودکار تولید می‌شوند جایگزین می‌گردند. تولید پارامترهای DH ممکن است چند دقیقه طول بکشد.

همچنین می‌توان پارامترهای ایستا برای DH را در فایل گواهی تعیین کرد که در این صورت تولید خودکار پارامترهای موقت DH غیرفعال می‌شود: