راهکار Remote Key Offloading یا OpenSesame ابر آروان چگونه کار می‌کند؟

Transport Layer Security یا TLS پروتکل مسوول برقراری امنیت در دنیای وب است. TLS این امکان را برای وب‌سایت‌ها فراهم می‌کند که بتوانند هویت خود را به مرورگرهای وب اثبات و با رمزنگاری اطلاعات تبادلی با مرورگرها، آن‌ها را ایمن ‌کنند.

پایه و اساس عمکلرد OpenSesame ابر آروان پروتکل TLS است، پس برای درک چگونگی عملکرد این قابلیت، ابتدا باید درک درستی از عملکرد TLS داشته باشیم.

اهداف اصلی TLS

TLS دو هدف اصلی دارد:

• حفظ محرمانگی (Confidentiality)
• احراز هویت (Authentication)

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

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

یک روش برای دست‌یابی به این محرمانگی، استفاده از رمزنگاری متقارن (Symmetric Cryptography) است. در رمزنگاری متقارن هر دو سمت یک ارتباط، تنها از یک کلید برای رمزنگاری و رمزگشایی داده‌ها استفاده می‌کنند. در TLS رمزنگاری متقارن با استفاده از الگوریتم AES انجام می‌شود. مرورگرهای قدیمی که از این الگوریتم پشتیبانی نمی‌کنند برای این منظور از Triple DES یا RC4 بهره می‌گیرند که هر دوی این الگوریتم‌ها، دیگر روش‌های امنی به‌شمار نمی‌آیند.

از سوی دیگر، احراز هویت روشی برای اثبات هویت شخصی است که در سر دیگر یک ارتباط قرار دارد. TLS برای دست‌یابی به این هدف، از زیرساخت کلید عمومی (Public Key Infrastructure) بهره می‌گیرد. وب‌سایت‌ها با استفاده از گواهی‌نامه‌ (Certificate) و رمزنگاری کلید عمومی (Public key Cryptography)، هویت خود را به مرورگرها اثبات می‌کنند. مرورگرها نیز در این فرآیند، باید از درستی دو چیز اطمینان حاصل کنند:

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

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

هم‌چنین مرورگر برای اطمینان از معتبر بودن گواهی‌نامه‌ی دریافتی از وب‌سرور، به فهرست CAهای معتبر خود رجوع می‌کند. اگر گواهی‌نامه‌ای که دریافت کرده است از سوی یکی از CAهای معتبر موجود در این فهرست امضا (sign) شده باشد، به‌معنای معتبر بودن آن است.

برقراری محرمانگی و احراز هویت با TLS در فرآیندی انجام می‌شود که به آن TLS handshake می‌گویند.

TLS Handshake

TLS را می‌توان نسخه‌ی توسعه‌یافته‌ی Secure Sockets Layer (SSL) دانست اما نکته‌ی مهم آن است که این پروتکل، کاملن مستقل از SSL است.

SSL راهکار امنیتی Netscap در اواسط دهه‌ی ۱۹۹۰ میلادی بود. تا سال ۱۹۹۹ نسخه‌های متفاوتی برای این پروتکل معرفی شد اما چون این پروتکل، راهکار اختصاصی Netscap بود، هرگز به‌عنوان پروتکلی استاندارد از سوی IETF معرفی نشد.

در سال ۱۹۹۹، IETF پروتکل TLS معرفی شد. در TLS 1.0 توسعه‌هایی انجام شده بود که به‌نوعی رفع مشکلات SSL 3.0 به‌شمار می‌آمدند، به همین دلیل تا مدت‌ها از آن با نام SSL 3.1 یاد می‌شد. این امر سبب شد تا با وجود گذشت سالیان بسیار از معرفی TLS، هم‌چنان از لفظ SSL به‌جای آن استفاده شود. اما همان‌طور که توضیح داده شد این دو پروتکل کاملن از هم متمایز و مجزا هستند. بنابراین اگر با فرآیند SSL handshake آشنایی داشته باشید، می‌توان این‌گونه عنوان کرد که با TLS handshake نیز تا حدودی آشنایی دارید.

TLS از دو روش برای handshake استفاده می‌کند که این دو روش عبارت‌اند از:

• روشی مبتنی‌بر RSA
• روشی مبتنی‌بر Diffie-Hellman

Diffie-Hellman و RSA، الگوریتم‌هایی هستند که در دنیای رمزنگاری امروز از آن‌ها استفاده می‌شود. به زبان ساده وظیفه‌ی این دو الگوریتم، رمزگذاری پیام‌ها است. آن‌چه سبب تمایز آن‌ها از یک‌دیگر می‌شود، شیوه‌ی رمزنگاری و احراز هویت پیام‌ها به‌وسیله‌ی آن‌ها است.

پیش از بررسی این دو روش، آشنایی اجمالی با برخی اصطلاحات، ضروری است:

• Client random (عدد تصادفی کاربر): توالی ۳۲ بایتی که کاربر تولید می‌کند و به‌ازای هر ارتباطی منحصربه‌فرد است. این قالب ۳۲ بایتی، به‌شکل ۲۸ بایت تصادفی به همراه ۴ بایت timestamp است.
• Server random (عدد تصادفی سرور): مشابه Client random تنها با این تفاوت که این مقدار را سرور تولید می‌کند.
• Premaster secret (رمز تولیدی): مقداری ۴۸ بایتی که می‌تواند با هر دوی Client random و Server random ترکیب شود تا Session key به‌دست آید.
• Session key (کلید نشست): کلیدی که در رمزنگاری متقارن استفاده می‌شود و هر دو سر ارتباط TLS (کاربر و سرور) از آن برای رمزنگاری و رمزگشایی داده‌های تبادلی خود در این ارتباط، استفاده می‌کنند.
• Cipher suite: شناسه‌ای ویژه به‌منظور ترکیب و نشان دادن الگوریتم‌هایی که در فرآیند TLS handshake از آن‌ها استفاده می‌شود. Cipher suite مشخص‌کننده‌ی الگوریتم مورد استفاده برای هر یک از موارد زیر است:
  • الگوریتم مسوول انتشار کلید (معمولن این الگوریتم نوعی از Diffie-Hellman یا RSA است)
  • الگوریتم مسوول احراز هویت (نوع گواهی‌نامه)
  • الگوریتم مسوول محرمانگی (Symmetric cipher)
  • الگوریتم مسوول یکپارچگی (تابع hash)

RSA Handshake

فرآیند RSA handshake به‌شکل زیر است:

• ارسال پیام Client Hello از سمت کاربر: در این مرحله، کاربر (مرورگر) برای سرور پیامی را حاوی نسخه‌ی TLS مورد استفاده‌ی خود و اطلاعاتی برای آغاز TLS handshake مانند عدد تصادفی کاربر و فهرستی از Cipher suiteهای مورد پشتیبانی خود ارسال می‌کند. مرورگرهای امروزی به همراه این پیام ممکن است SNI را نیز ارسال کنند.
• ارسال پیام Server Hello از سمت سرور: سرور پس از دریافت Client Hello، پارامترهایی را از آن انتخاب می‌کند، آن‌ها را در پیام Server Hello قرار می‌دهد و برای مرورگر ارسال می‌کند. این پیام حاوی عدد تصادفی سرور، Cipher Suite مورد انتخاب سرور و گواهی‌نامه‌ی سرور خواهد بود. گواهی‌نامه حاوی نام دامنه و کلید عمومی است.
• تبادل کلید از سوی کاربر: کاربر پس از اعتبارسنجی گواهی‌نامه و تایید معتبر بودن آن، Premaster Secret را تولید و آن را با کلید عمومی دریافتی از گواهی‌نامه‌ی سرور، رمزنگاری می‌کند و برای سرور می‌فرستد.

سرور با دریافت این پیام آن را با کلید خصوصی خود رمزگشایی می‌کند و به Premaster Secret دست می‌یابد. حال که کاربر و سرور به Premaster Secret و مقادیر تصادفی یکدیگر (Client Random و Server Rrandom) دسترسی دارند، این مقادیر را با یکدیگر ترکیب می‌کنند و کلید نشست را به‌دست می‌آورند.

فرآیند handshake پس از ارسال پیام “Finished“ از جانب کاربر و سرور کامل می‌شود. سایر پیام‌های تبادلی پس از این پیام‌ میان کاربر و سرور، همگی با Session Key رمزنگاری خواهند شد.

مشکل روش RSA Handshake آن است که اگر کلید خصوصی سرور به هر روشی لو برود، شخص ثالثی که به این کلید دست یافته است، می‌تواند به Session Key دست یابد و از این راه تمامی پیام‌های تبادلی میان همه‌ی کاربران و سرور را رمزگشایی کند.

Ephemeral Diffie-Hellman handshake

Diffie-Hellman handshake از دو مکانیسم مختلف بهره می‌گیرد که یکی از آن‌ها برای انتشار کلید و دیگری برای احراز هویت سرور است. وجه تمایز این روش با RSA Handshake، در شیوه‌ی انتشار Shared Pre Master Key است که در این‌جا مبتنی‌بر الگوریتم Diffie-Hellman است.

در الگوریتم Diffie-Hellman متغیرهایی تعریف می‌شوند که دو سر یک ارتباط از این پارامترها برای به‌دست آوردن Session Key نهایی استفاده می‌کنند. این متغیرها عبارت‌اند از:

• g: مقداری تصادفی که در پیام hello میان سرور و مرورگر تبادل‌شده و سرور و مرورگر بر سر این مقدار به توافق می‌رسند.
• a: مقدار Premaster Secret سرور
• b: مقدار Premaster Secret کاربر

به‌شکل خلاصه در الگوریتم Diffie-Hellma یک سر ارتباط، پارامتر g^a یا (g به توان a) را برای سمت دیگر ارسال می‌کند و آن سمت نیز پارامتر g^b یا (g به توان b) خود را برای این سمت می‌فرستد. حال هر دو سمت ارتباط از g^ab یا (g به توان ab) به‌عنوان یکی از متغیرهای محاسبه‌ی Session Key نهایی استفاده می‌کنند.

فرآیند Diffie-Hellman handshake به‌شکل زیر است:

• ارسال Client hello از سمت کاربر: مشابه RSA handshake در این‌جا نیز این پیام حاوی فهرستی از cipher suiteها، client random و پارامتر g (اطلاعات بیش‌تر در RFC 8446) است.
• ارسال Server hello از سمت سرور: سرور پس از دریافت پیام Client hello و انتخاب پارامترهای handshake، پیام hello خود را برای کاربر ارسال می‌کند. این پیام حاوی Server Random، مقدار g مورد توافق، Cipher suite انتخابی سرور و گواهی‌نامه‌ی سرور است. تفاوت RSA handshake و Diffie-Hellman از این مرحله به بعد آغاز می‌شود.
• تبادل کلید از سمت سرور: در این پیام، سرور پارامترهای Diffie-Hellman را ارسال می‌کند (مقدار g^a). هم‌چنین برای اثبات مالکیت گواهی‌نامه، امضای دیجیتال تمام پیام‌های ارسالی تا این مرحله را محاسبه و آن را نیز به همراه پارامترهای Diffie-Hellman ارسال می‌کند.
• تبادل کلید از سمت کاربر: پس از اعتبارسنجی امضای دیجیتال و تایید آن، کاربر در این پیام پارامترهای Diffie-Hellman handshake (g^b) خود را برای سرور می‌فرستد.

حال که کاربر و سرور هر دو به g^ab دسترسی دارند، این مقدار را با مقادیر Client Random و Server Random ترکیب کرده Session Key را به‌دست می‌آورند. باز هم مشابه RSA handshake، در این‌جا نیز فرآیند handshake با ارسال پیام Finished از سوی سرور و کاربر خاتمه می‌یابد. سایر پیام‌های ارسالی پس از این پیام میان کاربر و سرور به‌کمک Session Key رمزنگاری خواهند شد.

OpenSesame ابر آروان چیست و چگونه کار می‌کند؟

یکی از چالش‌های بزرگ قانونی و امنیتی برای موسسات مالی و بانکی، قرار دادن Private Key در اختیار CDNها است. اگر دوباره به دیاگرام‌های handshake بالا نگاه کنید خواهید دید که در کل فرآیند handshake تنها در یک مرحله از Private Key استفاده می‌شود.

ابر آروان با درک این چالش و دغدغه‌ی مشتریان خود، محصولی تولید و عرضه کرده است که بتواند به‌کمک آن، بدون دریافت Private Key از این مشتریان خاص، فرآیند TLS handshake را به‌گونه‌ای تقسیم کند که بخش بزرگ این فرآیند در سرورهای لبه‌‌ی ابر آروان انجام شود و مرحله‌ای از این فرآیند که مربوط به بررسی Private Key است، به سرور اصلی میزبان سایت که کلید خصوصی روی آن قرار دارد، ارجاع شود. در نتیجه این مشتریان می‌توانند از تمامی خدمات ابر آروان مانند شتاب‌دهی، خدمات DDoS protection و برقراری ارتباطی امن با مشتریان برمبنای TLS استفاده کنند بدون آن‌که نیازی به در اختیار گذاشتن کلید خصوصی خود در اختیار سرورهای لبه‌‌ی ابر آروان داشته باشند. نام این محصول OpenSesame است.

با استفاده از این محصول، فرآیند RSA Handshake به‌شکل زیر است:

و فرآیند Diffie-Hellman نیز به‌شکل زیر خواهد بود:

ابر آروان به‌کمک تغییراتی که در Nginx و OpenSSL انجام داده و هم‌چنین توسعه‌ی محصولی متعلق به خود، توانسته کاری کند که مرحله‌ی مربوط به بررسی Private Key، به‌شکل Remote و با ارتباط با سرور اصلی میزان سایت (Origin Server) انجام شود و از این راه نیازی به دریافت Private Key از مشتریان استفاده‌کننده از خدمت OpenSesame ابر آروان نباشد.

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

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

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

برای امنیت بیش‌تر، ارتباط میان سرورهای ابر آروان و سرور اصلی میزبان سایت با استفاده از یکی از دو Cipher Suite زیر انجام می‌شود:

• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384

این دو، از قوی‌ترین ciCher Suiteهای OpenSSL هستند و امنیت بالای ارتباط میان سرورهای لبه‌‌ی ابر آروان و سرور اصلی میزبان سایت را تضمین می‌کنند.

تضمین بیش‌ترین سرعت

وظیفه‌ی ابر آروان سرعت بخشیدن به سایت‌ها و دسترسی کاربران به محتوای آن‌ها در کم‌ترین زمان ممکن است. این امر برای سایت‌هایی که از خدمت OpenSesame ابر آروان نیز استفاده می‌کنند، صدق می‌کند.

به بیان بهتر، سرعت دسترسی به محتوای سایتی که از خدمت OpenSesame ابر آروان استفاده می‌کند باید به‌اندازه‌ی سرعت بارگذاری سایتی باشد که از این خدمت بهره نمی‌گیرد. اما پرسشی که ممکن است پیش آید آن است که:

چه‌طور با وجود نیاز به یک ارتباط اضافه‌تر در فرآیند TLS handshake میان سرورهای لبه‌‌ی ابر آروان و سرور اصلی میزبان سایت، این امر ممکن است؟

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

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

هنگام استفاده از OpenSesame نیز این امر کاملن صادق است. به این معنا که ارتباط بازدیدکنندگان سایت، به‌جای سرور اصلی میزبان سایت با سرورهای لبه‌‌ی ابر آروان است و آن‌ها در کم‌ترین زمان ممکن از نزدیک‌ترین دیتاسنتر پاسخ خود را دریافت می‌کنند. تنها ارتباط کمی طولانی‌تر مربوط به تک ارتباطی میان سرور لبه‌‌ی ابر آروان و سرور اصلی میزبان سایت در فرآیند TLS handshake است.

همان‌طور که در تصویر نشان داده شده است، استفاده نکردن از  CDN ابر آروان، ارتباط TLS میان بازدیدکننده و سرور اصلی میزبان سایت، نیازمند دو رفت و برگشت (Roundtrip) است. اما در حالت استفاده از خدمت OpenSesame آروان، ارتباط میان بازدید‌کننده‌ی سایت با سرور لبه‌ی ابر آروان در کوتاه‌ترین زمان ممکن انجام می‌شود و ارتباط TLS میان سرور لبه‌ی ابر آروان و سرور اصلی میزبان سایت نیز تنها نیازمند یک رفت و برگشت است. به‌ این ‌ترتیب باز هم تاخیر دسترسی بازدیدکننده‌ی سایت به محتوا در کم‌ترین زمان ممکن انجام می‌شود.

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

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