راهنمای جامع از تأثیر CDN در SSL/TLS بهمراه مثال و راهکار

از سال 2015 نسخه آخر SSL (3) رسماً دیگر بی ارزش و ناکارآمد شناخته شد. این نسخه با TLS یا Transport layer security جایگزین شد که رمزنگاری قدرتمند تری را ضمن حفظ عملکرد قبل فراهم می کند.

با این حال، اسم اولیه همچنان روی آن مانده به همین دلیل بسیاری همچنان TLS را SSL می نامند.

SSL/TLS که از سال 1995 معرفی و راهی بازار شد، در تکامل اینترنت نقش بسزایی ایفا کرده است، که آن را به یک فاکتور قابل اعتماد برای بسیاری از کسب و کارها مجهز کرد.

گوگل نیز از سال 2014 TLS را رسماً به عنوان یک فاکتور در رتبه دهی خود معرفی کرد که به تقویت و برجسته کردن اهمیت این پروتکل و سرعت بخشی به استفاده بیشتر از آن کمک کرد.

در مورد اهمیت و تاریخچه SSL/TLS به مطالب زیادی می توان اشاره کرد؛ اما در این مطلب قصد داریم بر جنبه عملکردی و امینتی استفاده از SSL در کنار شبکه توزیع محتوا (CDN) موارد و نکاتی را با شما به اشتراک بگذاریم.

یک CDN چطور می تواند عملکرد SSL/TLS را تقویت کند؟

برای اینکه بفهمیم یک CDN چطور عملکرد SSL را بهبود می بخشد باید ابتدا ببینیم که یک اتصال SSL با همتای خود یعنی TCP چه تفاوتی دارد؟

یک اتصال TCP معمولی به وسیله یک فرآیند سه مرحله ای به نام Three-way handshake ممکن می شود. در این اتصال، کلاینت که دستگاه کاربر می باشد یک درخواست برای برقراری اتصال ارسال می کند (SYN).

سپس یک تاییده (SYN/ACK) دریافت کرده و با یک تصدیق نامه (ACK) ان را پاسخ می دهد. در اینجا فرآیند رفت و برگشتی به پایان رسیده و اتصال برقرار می شود.

با فرض اینکه هیچ تداخلی در میان نباشد، مدت زمانی که این پروسه Handshake طول می کشد باید دقیقاً با یک مقدار RTT یا Round trip time یکسان باشد.

اما در طرف مقابل، برقراری اتصال SSL/TLS به یک رفت و برگشت اضافی نیاز دارد. به دلیل اینکه مرورگر و سرور در این شرایط باید:

1. بر روی یک روش رمزنگاری که مورد تایید طرفین باشد، به توافق برسند.
2. از یک فرایند اعتبارسنجی مشترک عبور کنند.
3. کلیدهای متقارن تولید کرده و از آن برای رمزنگاری و رمزگشایی تمام اطلاعات تبادلی در یک Session استفاده کنند.

این تعاملات اضافی زمان بیشتری به فرآیند اضافه می کند، که به دو round trip یا رفت و برگشت دیگر منجر می شود. البته این تعداد بستگی به تنظیمات و پیکربندی های سرور شما دارد.

برای مثال،

اگر زمان رقت و برگشتی یا round trip از San Francisco تا سرور لندن شما 50 میلی ثانیه باشد، ایجاد یک Handshake برای SSL/TLS حداقل 150 میلی ثانیه طول خواهد کشید.

راه حل:

از یک CDN استفاده کنید و زمان رفت و برگشت یا Round trip time را کاهش دهید.

برای اکثر افراد، امنیت SSL از تأخیرات به وجود آمده در اتصالات ارزش بیشتری دارد. اما در هر حال این زمان اضافه شده می تواند دردسر ساز باشد، به همین دلیل است که اکثر کسب و کارهای آنلاین بزرگ از CDN برای جبران این تأخیر اضافی کمک می گیرند.

کاهش Round trip time یکی از اصلی ترین وظایف CDN است. سرویسی که به طور خاص برای بهبود سرعت پاسخ دهی از طریق کاهش فاصله فیزیکی بین وب سایت و کاربر طراحی شده است.

با کاهش RTT، یک CDN تمام تعاملات میانی در فرآیند تبادلات SSL/TSL را سرعت می بخشد. از آنجایی که Handshake به یک RTT سه مرحله ای نیاز دارد، بابت هر میلی ثانیه ای که CDN برای شما صرفه جویی کند، 3 برابر منفعت خواهید برد.

دقت داشته باشید که سناریوی توضیح داده شده در بالا، تنها در زمانی صدق می کند که CDN شما دارای اتصالات باز با سرور اصلی (Origin) باشد. در غیر این صورت، پس از اولین مرحله ی اتصال SSL/TLS ، CDN نیز باید یک فرآیند مذاکره ثانویه را ایجاد کند.

در چنین حالتی زمان SSL به همان مقدار باقی خواهد ماند و حتی شاید کمی بیشتر هم طول بکشد.

چیزی که در اینجا مهم است این است که CDN شما از قابلیت keep-alive یا "زنده نگه دار"، برخوردار باشد. در این قابلیت، CDN اتصال باز خود با سرور را بین Session های کاربران مختلف برای چند دقیقه حفظ می کند.

این یعنی تا زمانی که سایت شما هر چند دقیقه یک بار بازدید شود، CDN و سرور اصلی دیگر نیازی به انجام مذاکرات اضافی در SSL/TLS نخواهند داشت. پس تمام بازدیدکنندگان شما از زمان صرفه جویی شده در Handshake سریعتر بهره مند خواهند شد.

برای مثال،

پس از اینکه اتصال SSL با پروکسی Los Angeles برقرار شد، در نبود قابلیت keep-alive، CDN باید اتصال خود با سرور لندن را مجدداً باز کند.

RTT بین لندن و LA حدود 30 میلی ثانیه است، و برای ایجاد مذاکرات در اتصال ثانویه SSL، به 90 میلی ثانیه نیاز خواهد بود. این مساوی است با یک Handshake 150 میلی ثانیه ای.

استفاده از CDN برای بهینه سازی

همانطور که گفتیم، مدت زمان RTT برای برقراری یک Handshake اتصال SSL/TLS به پیکربندی ها و تنظیمات سرور شما بستگی دارد.

برای مثال،

RTT اضافی زمانی رخ می دهد که سرور شما برای هندل کردن رکوردهای TLS بیش از یک اندازه مشخص، بهینه نشده باشد. که در نتیجه تعاملات رفت و برگشتی بیشتری لازم خواهد بود.

اما برخی از تنظیمات سمت سرور می توانند ارتباطات SSL/TLS را تسریع بخشند، از جمله:

• شروع کاذب (False start)

این قابلیت مرورگر را قادر می سازد تا داده های اپلیکیشن رمزنگاری شده را حتی قبل از تکمیل مذاکرات SSL ارسال کند.

• Resumption یا از سر گیری Session

این تنظیمات، اطلاعات کاربر و سرور را برای کاهش زمان مذاکرات در بازدیدهای تکراری کش می کند.

CDN های پیشرفته تر از قبل طوری پیکربندی می شوند که برای ارتباطات SSL/TLS بهینه عمل کنند.

تنها با استفاده از یک CDN به طور خودکار تمام گره های محتمل را از بین برده و از عملکرد بهینه TLS بهره مند خواهید شد.

CDN ها چطور می توانند امنیت SSL/TLS را ارتقا بخشند؟

همانطور احتمالاً می دانید ارتباطات SSL/TLS بر وجود گواهینامه SSL تکیه می کنند. این گواهینامه ها شامل اطلاعاتی در خصوص دامنه و سازمان شما هستند؛ بعلاوه ی یک کلید عمومی که برای شروع یک ارتباط رمزنگاری شده مورد استفاده قرار می گیرد.

در خصوص کلیدهای عمومی و خصوصی (Public & private key) در مطالبی دیگر در بلاگ میزبان کلود به طور مفصل صحبت کرده ایم ، که پیشنهاد می کنیم حتماً آن را مطالعه کنید.

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

اول: بین گواهینامه های SSL که از یک ارائه دهنده صلاحیت دار تهیه کرده باشید، و یک SSL رایگان تفاوت وجود دارد؛ گواهینامه ها می توانند توسط یک ایزار OpenSSL toolkit با امضای شخصی تولید شوند.

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

در طرف مقابل ، نوع رایگان به این صورت عمل خواهد کرد که با هر بازدید از سمت کاربران، یک پیغام هشدار دهنده هنگام دسترسی به فایل های HTTPS برای آنها از سمت مرورگر ارسال می شود.

این موضوع می تواند بسیاری از ترافیک شما را فراری دهد.

دوم: تمام گواهینامه های SSL بر اساس کیفیت راه اندازی شان رتبه بندی می شوند، معمولاً بر مبنای معیارهای زیر:

• پشتیبانی از پروتکل- ترجیح با گواهینامه هایی است که از جدیدترین و بروزترین پروتکل ها پشتیبانی کنند.
• پشتیبانی از تبادل کلید- ترجیح با گواهینامه هایی است که از رمزنگاری قدرتمندانه تری در زمان Encode کردن کلیدهای سشن استفاده کند.
• پشتیبانی از Cipher-  ترجیح با گواهینامه هایی است که Cipher ها را به داشتن رمزنگاری قوی تر مجبور می کنند.

از آنجا که رتبه گواهینامه شما برای همگان قابل مشاهده است، و به سادگی می توان با SSLlab ها یا ابزارهایی مشابه آن را مشاهده کرد، بر نظر کاربر نسبت به وب سایت شما تأثیرگذار خواهد بود.

با این وجود، جدا از تأثیرات منفی روانشناختی، این رتبه به شما اطلاع می دهد که تنظیمات SSL/TLS شما تا چه حد امن هستند، و تا چه میزان می توانند در معرض تهدیدات سایبری قرار گیرند. مسلماً رخدادهای ناگوار می توانند از لحاظ مالی نیز به کسب و کار شما آسیب وارد کنند.

راه حل

CDN برای یک گواهینامه رتبه A+ بی دردسر

استفاده از یک CDN به این معناست که اولین مرحله ی اتصال SSL/TLS شما همیشه با استفاده از گواهینامه ارائه دهنده ایجاد و برقرار می شود؛ گواهینامه ای که روی یک پروکسی CDN میزبانی می شود.

این موضوع دارای مزیت Auto-optimizing یا بهینه سازی خودکار جنبه های امنیتی در ارتباطات SSL شماست.

ممکن است تنظیمات تعریف شده شما برای SSL تان به اندازه کافی بهینه و صحیح نباشند، یا شاید از یک SSL رایگان استفاده کنید. اما از زمانی که از یک پروکسی CDN استفاده کنید، تمام بازدیدکنندگان شما توسط یک گواهینامه رتبه A+ (Grade A+) محافظت شده و گواهینامه توسط یک CA یا سازمان صلاحیت دار بین المللی امضا می شود.

در آخر، زمانی که مشکلات امنیتی SSL جدیدی رخ دهند، ارائه دهنده CDN شما با سرعت بالاتری می تواند به آن رسیدگی کند چراکه آپدیت کردن تنظیمات SSL بخشی از سرویس مدیریت شده آنهاست.

ایمن سازی مرحله دو

حتی با بهینه سازی خودکار CDN برای مرحله اول اتصال SSL، توصیه می شود که برای مرحله دوم (Second leg) نیز از تنظیمات SSL بر روی سرور اصلی تان استفاده کنید.

با اینکه دست یابی هکرها به مرحله دوم بسیار نادر است، اما با این وجود همیشه بهتر است بالاترین سطح را برای امنیت در نظر بگیرید. بخصوص اگر کسب و کاری را مدیریت می کنید که در معرض حملات سایبری قرار دارد.

CDN در خدمت راه اندازی آسان HSTS

امنیت انتقال سخت گیرانه ی HTTP یا HSTS یک ویژگی امنیتی خاصی است که از این موضوع اطمینان حاصل می کند که دامنه شما تنها با اتصال SSL/TLS در دسترس خواهد بود.

HSTS برای وب سایت هایی بسیار مفید است که زیردامنه های زیادی دارند؛ چراکه می توان از این قابلیت برای مدیریت SSL/TLS در تمام زیر دامنه ها به صورت انبوه استفاده کرد.

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

به کمک سرویس پیشرفته CDN ابری میزبان کلود می توانید با یک کلیک مرحله اتصال مرورگر به سرورهای CDN را به SSL/TLS میزبان کلود مجهز کنید، و یا از گواهینامه خریداری شده خود استفاده کنید.

بعلاوه سرویس میزبان کلود این قابلیت را نیز برای شما فراهم کرده تا بتوانید اتصالات بین سرورهای CDN و سرور اصلی را نیز به کمک SSL/TLS ایمن و رمزنگاری کنید. این قابلیت نیز تنها با یک کلیک برای شما فعال خواهد شد.

علاوه بر این CDN میزبان کلود از ویژگی HSTS نیز پشتیبانی کرده و  می توانید این ویژگی را نیز به آسانی با فعال کردن یک دکمه برای سایت خود پیاده سازی کنید.

پیشنهاد می کنیم به صفحه CDN ابری میزبان کلود مراجعه کرده و با ویژگی های بی نظیر این سرویس بیشتر آشنا شوید. در ضمن می توانید در صورت داشتن هر سوال یا نیاز به دریافت راهنمایی جهت فعال سازی، با کارشناسان ما در تماس باشید.

جمع بندی

برقراری ارتباطات ایمن و رمزنگاری شده به وسیله پروتکل های SSL/TLS دیگر به یک ضرورت برای وب سایت ها تبدیل شده است. این امر نه تنها برای کاربران حائز اهمیت بوده و در صورت غیبت با ترک آنان همراه خواهد شد، بلکه از سوی موتورهای جستجو نیز به عنوان یک فاکتور حیاتی در رتبه دهی محسوب می شود. ایجاد تنظیمات و قوانین صحیح در پیکربندی های SSL می تواند کمی پیچیده بوده و به دانش فنی نیاز داشته باشد؛

در صورتی که این تنظیمات به درستی اعمال نشوند، ممکن است گواهینامه شما اعتبار لازم را ایجاد نکند؛ به همین دلیل CDN خرید  می تواند به شما کمک کند تا به سادگی ارتباطات بین مرورگر و سرورها را ایمن کرده و از گواهینامه ای معتبر و پیکربندی حرفه ای بهره مند شوید. در این مطلب به نحوه تأثیرگذاری CDN در گواهینامه های SSL اشاره کردیم. امیدواریم این مطلب برای شما مفید واقع شده باشد.