سه شنبه، ۱۲ خرداد ۹۴ - ۰۹:۳۲

گروه آیسا

شرکت  پویاسازان

SSL_Certificates_Powered_by_GeoTrust_0
تبادل ‌اطلاعات همواره از اهمیت زیادی برخوردار بوده؛ چراکه کاربران در فضای مجازی خواه‌ناخواه قسمتی از وقت خود را برای تبادل اطلاعات صرف می‌کنند.این تبادل می‌تواند انواع مختلفی داشته باشد و به روش‌های گوناگونی انجام شود.اما برای تبادل ایمن اطلاعات باید از روش‌ها و پروتکل‌هایی استفاده کرد تا هنگام تبادل اطلاعات در صورت حمله، سرقت اطلاعات صورت نگیرد؛ به این صورت که اطلاعات تبادل‌شده میان کاربران یا سرور به‌صورت رمزنگاری‌شده صورت می‌پذیرد. حال اینکه پیچیدگی الگوریتم چه میزان باشد، بسته به نوع خدمات متفاوت خواهد بود.
SSL چیست؟
SSL یا Secure Socket Layer راه‌حلی برای برقراری ارتباطات ایمن میان یک سرویس‌دهنده و یک سرویس‌گیرنده است که به‌وسیله شرکت Netscape ارایه شده است. در واقع SSL پروتکلی است که پایین‌تر از لایه کاربرد (لایه چهارم از مدل TCP/IP) و بالاتر از لایه انتقال (لایه سوم از مدل TCP/IP) قرار می‌گیرد. مزیت استفاده از این پروتکل، بهره‌گیری از موارد امنیتی تعبیه‌شده آن برای امن کردن پروتکل‌های غیرامن لایه کاربردی نظیر HTTP، LDAP، IMAP و… است که بر اساس آن الگوریتم‌های رمزنگاری روی داده‌های خام (plain text) که قرار است از یک کانال ارتباطی غیرامن مانند اینترنت عبور کنند، اعمال می‌شود و محرمانه‌ماندن داده‌ها را در طول کانال انتقال تضمین می‌کند.
به بیان دیگر، شرکتی که صلاحیت صدور و اعطای گواهی‌های دیجیتال SSL را دارد، برای هر کدام از دو طرفی که قرار است ارتباطات میان‌شبکه‌ای امن داشته باشند، گواهی‌های مخصوص سرویس‌دهنده و سرویس‌گیرنده را صادر و با مکانیزم‌های احراز هویت خاص خود هویت هر کدام از طرفین را برای طرف مقابل تایید می‌کند. البته این کار باید تضمین کند که اگر اطلاعات حین انتقال مورد سرقت قرار گرفت، برای رباینده قابل درک و استفاده نباشد که این کار را با کمک الگوریتم‌های رمزنگاری و کلیدهای رمزنگاری نامتقارن و متقارن انجام می‌دهد.
ملزومات یک ارتباط مبتنی بر پروتکل امنیتی SSL
برای داشتن ارتباطات امن مبتنی بر SSL عموما به دو نوع گواهی دیجیتال SSL، یکی برای سرویس‌دهنده و دیگری برای سرویس‌گیرنده و یک مرکز صدور و اعطای گواهینامه دیجیتال یا CA نیاز داریم. وظیفه CA این است که هویت طرفین ارتباط، نشانی‌ها، حساب‌های بانکی و تاریخ انقضای گواهینامه را بداند و بر اساس آنها هویت‌ها را تعیین کند.
مکانیزم‌های تشکیل‌دهنده SSL
۱) تایید هویت سرویس‌‌دهنده
با استفاده از این ویژگی در SSL، یک کاربر از صحت هویت یک سرویس‌دهنده مطمئن می‌شود. نرم‌افزارهای مبتنی بر SSL سمت سرویس‌گیرنده، برای مثال یک مرورگر وب نظیر Internet Explorer از تکنیک‌های استاندارد رمزنگاری
مبتنی بر کلید عمومی و مقایسه با کلیدهای عمومی یک سرویس‌دهنده (برای مثال، یک برنامه سرویس‌دهنده وب نظیر IIS ) می‌تواند از هویت او مطلع شود و پس از اطمینان کامل، کاربر می‌تواند نسبت به وارد کردن اطلاعات خود مانند شماره کارت‌های اعتباری یا گذرواژه‌ها اقدام کند.
۲) تایید هویت سرویس‌گیرنده
برعکس حالت قبلی در اینجا سرویس‌دهنده است که باید از صحت هویت سرویس‌گیرنده اطمینان یابد. طی این مکانیزم، نرم‌افزار مبتنی بر SSL سمت سرویس‌دهنده پس از مقایسه نام سرویس‌گیرنده با نام‌های مجاز موجود در فهرست سرویس‌گیرنده‌های مجاز، در صورت مطابقت اجازه استفاده از سرویس‌های مجاز را به او می‌دهد.
۳) ارتباطات رمزشده
تمامی اطلاعات مبادله‌شده میان سرویس‌دهنده و گیرنده باید به‌وسیله نرم‌افزارهای موجود در سمت سرویس‌دهنده و سرویس‌گیرنده رمزنگاری (Encrypt) شده و در طرف مقابل رمزگشایی (Decrypt) شوند تا حداکثر محرمانگی (Confidentiality) در این‌گونه سیستم‌ها لحاظ شود.
اجزای پروتکل SSL
پروتکل SSL دارای دو زیرپروتکل با عناوین زیر است:
۱) SSL Rocord Protocol که نوع قالب‌بندی داده‌های ارسالی را تعیین می‌کند.
۲) SSL Handshake Protocol که براساس قالب تعیین‌شده در پروتکل قبلی، مقدمات ارسال داده‌ها میان سرویس‌دهنده‌ها و سرویس‌گیرنده‌های مبتنی بر SSL را تهیه می‌کند.
بخش‌بندی پروتکل SSL به دو زیرپروتکل دارای مزایای چندی است، از جمله:
اول: در ابتدای کار و طی مراحل اولیه ارتباط (Handshake) هویت سرویس‌دهنده برای سرویس‌گیرنده مشخص می‌شود.
دوم: در همان ابتدای شروع مبادلات، سرویس‌دهنده و گیرنده بر سر نوع الگوریتم رمزنگاری تبادلی توافق می‌کنند.
سوم: در صورت لزوم، هویت سرویس‌گیرنده نیز برای سرویس‌دهنده احراز می‌شود.
چهارم: در صورت استفاده از تکنیک‌های رمزنگاری مبتنی بر کلید عمومی، می‌توانند کلیدهای اشتراکی مخفی را ایجاد کنند.
پنجم: ارتباطات بر مبنای SSL رمزنگاری می‌شود.
 
الگوریتم‌های رمزنگاری پشتیبانی‌شده در SSL
در استاندارد SSL، از اغلب الگوریتم‌های عمومی رمزنگاری و مبادلات کلید (Key Exchcenge Algorithm) نظیرRSA, RC4, RC4,MD5, KEA, DSA, DES و RSA Key Exchauge، SHA-1،Skipjack و DES3 پشتیبانی می‌شود و بسته به اینکه نرم‌افزارهای سمت سرویس‌دهنده و سرویس‌دهنده نیز از موارد مذکور پشتیبانی کنند، ارتباطات SSL می‌تواند براساس هر کدام از این الگوریتم‌ها صورت پذیرد. البته بسته به طول کلید مورد استفاده در الگوریتم و قدرت ذاتی الگوریتم می‌توان آنها را در رده‌های مختلفی قرار داد که توصیه می‌شود با توجه به سناریوهای موردنظر، از الگوریتم‌های قوی‌تر نظیر DES3 با طول کلید ۱۶۸ بیت برای رمزنگاری داده‌ها و همچنین الگوریتم SHA-1 برای مکانیزم‌های تایید پیغام MD5 استفاده شود یا اینکه اگر امنیت در این حد مورد نیاز نبود، می‌توان در مواردی خاص از الگوریتم رمزنگاری RC4 با طول کلید ۴۰ بیت و الگوریتم تایید پیغام MD5 استفاده کرد.
نقدی بر SSL
با توجه به نسخه‌های متعدد این پروتکل حملات و آسیب‌های متفاوتی می‌تواند به‌وجود بیاید؛ چراکه نسخه قدیمی این پروتکل قدیمی و دارای باگ است و آخرین نسخه حملات برای آن انجام می‌شود. این پروتکل تا حد مناسبی ایمن است، اما نکته اساسی‌ این است که اغلب سایت‌ها از نسخه جدید استفاده نکرده و همچنان نسخه‌های قدیمی را به کار می‌گیرند.
استفاده از این پروتکل‌ها تضمین‌دهنده‌‌ این است که یک نفوذگر نباید بتواند اطلاعات رمزشده را در طول مسیر رمز‌گشایی (تغییر و …) کند. SSL یک پروتکل قدیمی است و نسخه‌ سوم آن مربوط به ۱۵ سال پیش است، اما همچنان در مرورگرها از آن پشتیبانی می‌شود. بیشتر سایت‌ها از نسخه‌های TLS استفاده می‌کنند، اما در صورت پشتیبانی نکردن مرورگر کاربر از TLS سعی می‌کنند از نسخه‌های قدیمی‌تر‌ مانند SSLv3 برای برقراری ارتباط استفاده کنند. تا اینجا عملکرد این پروتکل توضیح داده شد، اما نکته اساسی این است که این پروتکل رمزنگاری تبادل اطلاعات تا چه اندازه قابل اطمینان و ایمن است؛ چراکه از طرفی برای تبادل امن اطلاعات استفاده می‌شود و از طرفی خود نیز باید ایمن باشد که متاسفانه باید گفت طی سال‌های اخیر عملکرد مناسبی از خود نشان نداده و حملات موفقیت‌آمیز متعددی نسبت به آن انجام شده است. مانند ضعف امنیتی هارت بلید که موجب لو رفتن اطلاعات رمزنگاری‌شده کاربران و سرور بود و در آن زمان این باگ نمایان شد. باگ یادشده موجب رخنه شدید اطلاعاتی در فضای مجازی شد و آسیب‌های جدی بر پیکره سایت‌های استفاده کننده از این پروتکل وارد کرد.
Poodle
این باگ به‌تازگی بر اساس مطلبی که در پایگاه سایت بیان ارایه شده برای این پروتکل شناسایی شده است:
در هنگام اولین اتصال به سرویس‌دهنده (وب سرور)، سرویس‌گیرنده (مرورگر کاربر) سعی می‌کند از طریق بالاترین نسخه‌ای که پشتیبانی می‌کند (برای مثال TLS 1.2) ارتباط را ایجاد کند. اگر وب‌سرور نیز قابلیت پشتیبانی از این نسخه را داشته باشد، ارتباط برقرار می‌شود؛ در غیر این صورت اگر برای مثال وب سرور از نسخه‌ TLS 1.0 استفاده کند، مرورگر کاربر نیز به نسخه‌ پایین‌تر یعنی TLS 1.0 سوییچ می‌کند. به این رویکرد downgrade گفته می‌شود که می‌تواند به‌وسیله یک نفوذگر داخل شبکه‌ کاربر نیز اتفاق بیفتد. نفوذگر مرورگر کاربر را وادار می‌کند از طریق SSLv3 اتصال را برقرار کند. در SSLv3 برای رمزنگاری از روش‌های RC4 یا یک روش رمز بلوکی در حالت CBC استفاده می‌شود. در ساختار رمز بلوکی در حالت CBC این پروتکل مشکلی وجود دارد که موجب می‌شود نفوذگر بتواند با آزمون و خطا، با تعداد درخواست‌های اندکی، قسمتی از درخواست رمزشده میان مرورگر و وب‌سرور را حدس بزند. این داده‌ حدس زده‌شده می‌تواند کوکی کاربر باشد که نفوذگر با استفاده از آن می‌تواند وارد حساب کاربر شود. اصل مبنای تئوری این آسیب‌پذیری از سوی Serge Vaudenay در سال ۲۰۰۱ مطرح شده بود، اما او فکر می‌کرده است که امکان استفاده عملی از این آسیب‌پذیری وجود ندارد و در نهایت این آسیب‌پذیری از سوی مهندسان گوگل اعلام شد و Poodle نام گرفت.
چه کسی تحت تاثیر این آسیب‌پذیری قرار می‌گیرد؟
کاربران هر سایتی (سرویس‌دهنده) که از SSLv3 پشتیبانی کند (در تنظیمات وب‌سرور غیرفعال نکرده باشد)، آسیب‌پذیرند. در‌ واقع حتی اگر سایت از نسخه‌های TLS استفاده کند به‌دلیل قابلیت downgrade (بازگشت به نسخه‌ قبلی) آسیب‌پذیر است؛ زیرا نفوذگر داخل شبکه می‌تواند مرورگر کاربر را وادار کند تا از طریق SSLv3 اتصال برقرار کند.
کاربر چگونه تحت تاثیر این آسیب‌پذیری قرار می‌گیرد؟
نفوذگر (داخل شبکه‌ کاربر) با بهره‌برداری از این آسیب‌پذیری می‌تواند اطلاعات حساس کاربر مانند (کوکی که هویت کاربر است) را برباید و در نهایت وارد حساب کاربر شود. در پایان باید قاطعانه بیان کرد که استفاده از این پروتکل ناپایدار برای سایت‌های مهم توصیه نمی‌شود یا حداقل استفاده از آخرین نسخه این پروتکل توصیه می‌شود. البته باید گفت روش‌های جایگزین این پروتکل هنوز به‌صورت همه‌گیر استفاده نشده و باید دید در آینده چه اتفاقی خواهد افتاد.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.

logo-samandehi