اخبار داخلی آرمان داده پویان

مقالات

مراحل دست‌دهی در پروتکل SSL/TLS

مراحل دست‌دهی

در پروتکل SSL/TLS

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

گام اول

توافق بر سر امکانات امنیتی

در این مرحله کاربر فهرستی از پروتکل‌ها و الگوریتم‌های امنیتی خود را ارسال می‌نماید. امکاناتی از قبیل ویرایش‌های SSL، الگوریتم‌های رمز‌نگاری متقارن و روش‌های فشرده‌سازی‌ که پشتیبانی می‌نماید به همراه یک عدد تصادفی و شناسه‌ی نشست‌ها. این اطلاعات در قالب Client-Hello به سمت سرور ارسال می‌شود. سرور در پاسخ، بسته‌ی Server-Hello که حاوی فهرست امکانات امنیتی کاربر است که آن‌ها را تایید کرده است.

Client-Hello شامل:

  • ویرایش SSL: ویرایش SSL ای که کاربر پشتیبانی می‌نماید.
  • کلید جلسات:  شناسه‌ای که کاربر می‌خواهد برای این ارتباط استفاده نماید. در اولین Client Hello کلید‌نشست خالی می‌باشد.
  • Cipher Suite: در این قسمت الگوریتم‌های رمز‌نگاری به ترتیب دلخواه کاربر فهرست می‌گردد. در هر Cipher Suite هم الگوریتم تبادل‌کلید و هم یک Cipher Spec وجود دارد. سرور یک Cipher Suite را انتخاب نموده و در صورت نبود یک گزینه‌ی قابل قبول، هشدار شکست دست‌دهی برای کاربر فرستاده شده و ارتباط قطع می‌گردد.
  • روش فشرده‌سازی: فهرستی از الگوریتم‌های فشرده‌سازی که کاربر پشتیبانی می‌نماید. اگر سرور هیچکدام از الگوریتم‌های فهرست شده را پشتیبانی نکند ارتباط شکست می‌خورد. این قسمت null نیز می‌تواند باشد وبدین معنی است که کاربر تمایلی به فشرده‌سازی ندارد.

 

  • پیام پایان سلام: این پیغام در آخر توسط سرور ارسال می‌گردد و بدین معناست که روند سلام به پایان رسیده است.

گام دوم

احراز هویت سرور

گواهی سرور: اگر نیاز به احراز هویت سرور باشد (که در اکثر موارد نیز هست)، سرور گواهی خود را بلافاصله بعد از پیغام Server-Hello ارسال می‌نماید. نوع گواهی بایستی متناسب با نوع کاربرد مورد نظر باشد. گواهی سرور در پروتکل SSL در بیشتر مواقع X.509.V3 می‌باشد.

 

گام سوم

احراز هویت کاربر و تبادل کلید(اختیاری)

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

تبادل کلید کاربر: محتویات این پیام بستگی به الگوریتم کلید عمومی انتخابی بین Client Hello و Server Hello دارد. کاربر یا از یک Premaster Key که توسط الگوریتم رمزنگاری RSA، رمز شده است استفاده می‌نماید و یا از دیفی-هلمن برای توافق بر سر یک کلید و احراز هویت. زمانی که از RSA استفاده می‌گردد یک pre_master_secret توسط کاربر تولید شده و توسط کلید عمومی سرور رمزگذاری می‌گردد و سپس به سمت سرور ارسال می‌شود. سرور نیز با استفاده از کلید خصوصی‌اش آن را رمزگشایی می‌نماید. سپس هر دو طرف pre-master-secret را به mster-secret تبدیل می‌نمایند.

تایید گواهی(اختیاری)

اگر کاربر گواهی‌اش را ارسال نماید، یک گواهی امضا شده به جهت تایید این گواهی ارسال می‌شود.

تبادل cipher Spec

پیام تبادل cipher spec توسط کاربر ارسال می‌شود و محتویات pending cipher spec توسط کاربر در داخل Current Cipher Spec کپی می‌شود. زمانی هم که نشست قبلی ادامه می‌یابد، change Cipher Spec بعد از hello message ارسال خواهد شد.

گام چهارم

پایان

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

تعداد بازدید: 215


تازه ترین ها