نقل قول نوشته شده توسط SZsXsZS مشاهده تاپیک
ببینید ایجاد کانال امن به معنی این هست که دو party که از طریق یک کانال ناامن با هم ارتباط برقرار میکنن میتونن بین خودشون یک کلید مشترک رو تولید کنن بدون اینکه دیگرانی که ممکنه به کانال ارتباطی بین اونها دسترسی داشته باشن (و حتی بتونن داده های رد و بدل شده رو دستکاری بکنن یا خودشون داده های جعلی بفرستن) به این کلید دست پیدا کنن.
اما این قضیه از حمله های MITM جلوگیری نمیکنه! چون درسته مثلا فرد X با فرد Y ارتباط برقرار میکنه و کلیدی رو با هم ایجاد میکنن، ولی خود فرد Y ممکنه واقعا فرد Y نباشه و فقط فردی باشه که وانمود میکنه Y است و در اصل Z باشه. یعنی ما در این روشهای رمزنگاری احراز هویت (authentication) نداریم! برای احراز هویت باید از روش دیگری استفاده بشه. یک روش استفاده از یک shared secret است که قبلا این دو party به شکلی (مثلا از طریق یک کانال جانبی امن) با هم سرش به توافق رسیدن و به اشتراک گذاشتن؛ بطور مثال یک پسورد. اما روشهای دیگر هم وجود داره و چیزی که مثلا برای وب سایت ها در اینترنت استفاده میشه و پروتکل SSL/TLS، استفاده از گواهینامه های دیجیتال است که این گواهینامه ها بر اعتماد به یکسری CA های شناخته شده معتبر (مراجع صدور گواهینامه ها) بنا شدن و ما یکسری CA certificate رو داریم که از قبل همراه سیستم عامل یا مرورگر هستن (البته کاربر خودش هم میتونه گواهینامه های جدیدی رو نصب کنه یا یکسری رو حذف کنه) و و بواسطهء اونهاست که امضاهای دیجیتالی که party ها در جریان پروتکل های ایجاد کلید مشترک ارائه میدن، شناسایی و معتبر شناخته میشن. پس در اینجا هم مشاهده میکنید که ما از قبل یک مبنا و شناسه ای جداگانه برای احراز هویت طرف مقابل داریم (که از طریق دیگری بهمون رسیده). در غیر این صورت راهی برای احراز هویت طرف مقابل نیست. ما میتونیم مطمئن باشیم که کلید مشترکی که بین ما و Y ایجاد شده رو هیچکس دیگری نمیتونه خونده باشه یا جعل و دستکاری کرده باشه، ولی نمیتونیم مطمئن باشیم که Y واقعا همونی باشه که ادعا میکنه و Z نباشه! شاید Z بین ما (X) و Y واقع شده و به ما وانمود میکنه که Y است و به Y هم وانمود میکنه که X است! اینطوری میتونه تمام ارتباطات بین ما و Y رو براحتی بخونه و حتی دستکاری و جعل کنه.

مثلا پروتکل Diffie–Hellman key exchange نقل از ویکیپدیا میگه:
Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack.
ترجمه: «Diffie–Hellman key exchange خودش به تنهایی احراز هویت طرفهای ارتباط را فراهم نمیکند و بنابراین درمقابل حملهء MITM آسیب پذیر است».
منظور ایشون این بود که نمیشه تبادل کلید امن انجام داد و دقیقا اشاره کرده بودن به لو رفتن کلید نه جعل هویت.
اگر پیام ایشون رو دقیق بخونید متوجه میشید.
در مورد توضیحاتی هم که دادید، چند پست قبل توضیح توضیح دادم:
نقل قول نوشته شده توسط Bad Programmer مشاهده تاپیک
در زمان تبادل کلید بله حق با شماست ممکنه این اتفاق بیفته. ولی با تعریف یک پرتوکل و تبادل کلید درست میشه از این نوع ضعف امنیتی هم در امان بود (مثلا یه چیزی شبیه گواهینامه های ssl).
حتی میشه با تخصیص یوز نیم و پسورد به کلاینت و سرور همون اول کار هر دو کلاینت و سرور توسط سرور واسط تایید بشن.
بهتر بود که فقط از اصطلاح "رمزنگاری نامتقارن" استفاده نمیکردم و کامل توضیح میدادم. اگر کسی تاپیک رو کامل بخونه میدونه که چی میگم.


مثلا دقت کرده باشید در بعضی سایتها مرورگر هشدار میده که این گواهینامه self-signed است و بنابراین نمیشه از درستی هویتش مطمئن بود و آیا این ریسک رو قبول میکنید و این گواهینامه رو میپذیرید یا نه!
این بخاطر اینه که اون گواهینامه توسط یک CA certificate معتبر که از قبل در مرورگر نصب شده باشه امضاء نشده و بنابراین اعتبار مشخصاتش (اینکه آیا واقعا به دامین و اسم و مشخصات درج شده در اون تعلق داره یا نه) قابل اثبات نیست.

تعجب میکنم ظاهرا هیچکدام هنوز این مسائل اولیه رو نمیدونید!!
منم تعجب میکنم که استفاده از گواهینامه self-signed رو دور زدن ssl به حساب میارید.