چرا این موضوع مهم است؟
TLS 1.3 handshake را ساده‌تر و الگوریتم‌های قدیمی را حذف کرده است. client و server روی پارامترها توافق می‌کنند، server هویت خود را با certificate chain اثبات می‌کند و key exchange کلیدهای موقتی جلسه را می‌سازد.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع Handshake و مدل اعتماد TLS 1.3، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
openssl s_client، curl -v و browser devtools را برای دیدن SNI، ALPN، certificate chain و protocol version استفاده کنید. expiry تنها failure نیست؛ hostname و chain نیز باید معتبر باشند.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
TLS termination روی proxy مرز رمزنگاری را جابه‌جا می‌کند. اگر upstream plaintext است، فرض end-to-end encryption غلط است. همچنین wildcard certificate مجوز اعتماد به headerهای proxy نیست.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک server آزمایشی با certificate معتبر/نامعتبر بسازید، handshake را با openssl ببینید و hostname mismatch، expired cert و protocol mismatch را جدا تست کنید.
برای هر مرحله timestamp و خروجی را ذخیره کنید. یک failure کنترل‌شده ایجاد کنید تا مطمئن شوید monitoring واقعاً failure را می‌بیند. سپس سیستم را به baseline برگردانید و زمان recovery را ثبت کنید.
عیب‌یابی بر پایهٔ Evidence
Troubleshooting را با تغییر config شروع نکنید. اول محل دقیق failure را پیدا کنید: آیا ورودی وارد سیستم می‌شود؟ آیا state مورد انتظار ساخته شده؟ آیا policy اجازه می‌دهد؟ آیا خروجی از component خارج می‌شود؟ log، packet capture، metric و state API باید به یک timeline مشترک وصل شوند. نبودن event نیز evidence است؛ اگر request قبل از یک component دیده می‌شود و بعد از آن نه، دامنهٔ مسئله کوچک شده است.
Performance و ظرفیت
عملکرد را فقط با average نسنجید. p95/p99 latency، saturation، queue depth، retry و resource pressure تصویر بهتری می‌دهند. تغییری که در lab کوچک سریع است ممکن است زیر concurrency یا dataset واقعی bottleneck متفاوتی نشان دهد. capacity limitها را قبل از rollout بزرگ شناسایی کنید و alert را به thresholdهای قابل اقدام وصل کنید.
Production readiness
قبل از rollout نهایی، owner، change window، blast radius، success metric و rollback trigger باید مشخص باشند. اگر dependency خارجی دارید، رفتار هنگام timeout یا unavailable شدن آن را تست کنید. اگر config به چند host می‌رود، rollout مرحله‌ای و inventory دقیق لازم است. یک تغییر خوب باید observable، explainable و reversible باشد.
Runbook و انتقال دانش
در مستندسازی، فقط «چه دستورهایی اجرا شد» را ننویسید. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. اگر همکار دیگری بتواند با همان ورودی آزمایش را تکرار کند و به نتیجهٔ مشابه برسد، runbook ارزش عملیاتی دارد. اگر فقط نویسنده می‌داند چرا مرحله‌ای لازم است، دانش هنوز منتقل نشده است.
قبل از Production چه چیزی را اعتبارسنجی کنیم؟
نتیجهٔ Lab را مستقیم به Production تعمیم ندهید. یک change plan کوتاه بسازید که در آن دامنهٔ تغییر، owner، زمان اجرا، dependencyها، success metric و rollback trigger مشخص باشد. ابتدا روی canary یا درصد کوچکی از workload اجرا کنید و حداقل یک چرخهٔ واقعی restart، credential rotation یا deploy دوم را ببینید؛ بسیاری از خطاها در اولین اجرای سالم ظاهر نمی‌شوند. رفتار هنگام unavailable شدن dependency خارجی، پر شدن disk، timeout شبکه و ورودی نامعتبر را نیز بررسی کنید. اگر feature امنیتی است، test منفی باید نشان دهد مسیر غیرمجاز واقعاً بسته است؛ اگر feature performance است، benchmark باید با load و dataset نزدیک به واقعیت اجرا شود. در پایان، تصمیم rollout را با evidence ثبت کنید، نه با جملهٔ مبهم «به‌نظر خوب است».
نگهداری بلندمدت و بازبینی دوره‌ای
معماری بعد از deploy ثابت نمی‌ماند. نسخهٔ سیستم‌عامل، dependency، policy سازمان، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین باید بازبینی دوره‌ای تعریف شود: نسخه‌های پشتیبانی‌نشده را پیدا کنید، exceptionهای قدیمی را ببندید، alertهای بی‌ارزش را حذف کنید و recovery را دوباره تمرین کنید. اگر configuration در Git نگهداری می‌شود، drift میان state واقعی و repository را اندازه بگیرید. اگر ابزار SaaS یا سرویس خارجی است، تغییر API، pricing، limit و مدل permission را دنبال کنید. مستندات باید تاریخ review داشته باشند تا تیم بداند کدام فرض‌ها هنوز معتبرند. نگهداری خوب یعنی سیستم بعد از شش ماه هم قابل توضیح و قابل بازیابی باشد، نه اینکه فقط روز اول deploy موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ Handshake و مدل اعتماد TLS 1.3 ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از Cloudflare انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
در handshake دقیقاً چه چیزهایی را باید از هم جدا کنیم؟
درک TLS با تفکیک سه پرسش آسان‌تر می‌شود: طرف مقابل کیست، کلید مشترک چگونه به دست می‌آید و داده چگونه حفاظت می‌شود؟ گواهی و بررسی زنجیره اعتماد به پرسش اول کمک می‌کنند. تبادل کلید و مشتق‌سازی کلیدها به پرسش دوم مربوط‌اند. حفاظت رکوردهای داده با کلیدهای حاصل انجام می‌شود. یک گواهی معتبر به تنهایی ثابت نمی‌کند برنامه پشت آن بی‌نقص است؛ فقط بخشی از رابطه هویت و اتصال را تأیید می‌کند. به همین دلیل قفل مرورگر را نباید معادل صحت محتوای صفحه یا قابل اعتماد بودن کسب‌وکار دانست.
برای بررسی عملی، دامنه مورد انتظار را از قبل بنویسید و اتصال را با همان نام برقرار کنید. اتصال به آدرس IP بدون ارسال نام مناسب ممکن است گواهی پیش‌فرض میزبان را برگرداند. روی سروری که چند دامنه دارد، SNI به انتخاب پیکربندی مناسب کمک می‌کند. SNI معمولی را نباید خودبه‌خود محرمانه تصور کرد؛ پنهان‌سازی آن به سازوکار و پشتیبانی جداگانه وابسته است. همچنین نام انتخاب پروتکل کاربردی یا ALPN می‌تواند توضیح دهد چرا دو مشتری با یک میزبان رفتار HTTP متفاوت دارند.
اعتبارسنجی گواهی فقط بررسی تاریخ نیست
زنجیره باید به مرجع مورد اعتماد مشتری برسد و هویت درخواست‌شده با نام‌های مجاز گواهی مطابقت داشته باشد. ساعت اشتباه دستگاه ممکن است گواهی سالم را هنوز نامعتبر یا منقضی نشان دهد. کمبود گواهی میانی نیز ممکن است روی یک دستگاه دیده شود و روی دستگاه دیگر به دلیل cache پنهان بماند. بنابراین آزمون را فقط با مرورگری که قبلاً بارها سایت را دیده انجام ندهید. یک مشتری تازه و محیطی با trust store مشخص، برای تشخیص زنجیره ناقص مفیدتر است.
در ابزار خط فرمان، نمایش گواهی به معنی تأیید موفق آن نیست. خروجی وضعیت اعتبارسنجی و نام میزبان را صریح بررسی کنید. غیرفعال کردن بررسی گواهی شاید برای جدا کردن موقت علت در آزمایشگاه مفید باشد، اما نباید به تنظیم دائمی مشتری تبدیل شود. اگر برنامه فقط با این گزینه کار می‌کند، مسئله حل نشده و هویت سرور عملاً بررسی نمی‌شود. بهتر است خطا را به یکی از دسته‌های نام، زمان، زنجیره یا مرجع اعتماد محدود کنید و همان علت را اصلاح کنید.
Forward secrecy و ازسرگیری اتصال
در تبادل کلید موقتی، افشای بعدی کلید بلندمدت سرور به تنهایی نباید کلید نشست‌های قدیمی ثبت‌شده را آشکار کند. این ویژگی به روش برقراری نشست وابسته است و نباید آن را به هر شکل استفاده از کلید ازپیش‌مشترک تعمیم داد. حافظه فرایند، کلیدهای نشست و لاگ‌های حساس همچنان ارزش حفاظتی دارند. ازسرگیری نشست برای کاهش هزینه اتصال مفید است، اما سیاست عمر ticket و اشتراک کلیدهای آن میان سرورها بخشی از طراحی عملیاتی است.
داده زودهنگام یا صفر رفت‌وبرگشت محدودیت مهم بازپخش دارد. عملیاتی مانند ایجاد سفارش، انتقال اعتبار یا تغییر رمز نباید صرفاً به دلیل رمزنگاری شدن، مناسب این مسیر فرض شوند. برنامه باید بداند کدام درخواست قابلیت تکرار امن دارد و چگونه تکرار را کنترل می‌کند. اگر این قرارداد روشن نیست، فعال نکردن داده زودهنگام انتخاب ساده‌تری است. برای آزمون یک سامانه، موفقیت handshake، اعتبار هویت و رفتار درخواست تکراری را سه نتیجه جدا ثبت کنید.
وقتی TLS روی پراکسی پایان می‌یابد
اگر رمزنگاری در لبه تمام شود، ارتباط لبه تا برنامه مسیر مستقلی است. می‌توان برای آن نیز TLS و حتی احراز هویت دوطرفه داشت، ولی این امر خودکار نیست. نقشه مسیر داده باید نشان دهد متن روشن کجا دیده می‌شود، چه کسی کلید خصوصی را در اختیار دارد و کدام سرویس مجاز به خواندن header هویت است. چنین نقشه‌ای تصمیم درباره محل خاتمه TLS را به یک تصمیم معماری قابل بررسی تبدیل می‌کند.
