View Full Version : در باره ی SSL
sonixax
پنج شنبه 04 فروردین 1390, 23:58 عصر
سلام به همگی ،
من یک سولی برام پیش اومده - SSL دیتای رد و بدل شده رو با یک کلید خصوصی و یک کلید عمومی کد گذاری میکنه و بعدش دو طرف با استفاده از این کلید ها اطلاعات رو انکریپت و یا دیکریپت میکنند .
حالا سوال من اینه ، به هر حال هر دو طرف باید کلید هاشون رو در اختیار همدیگه بذارند که بتونند اطلاعاتی که کد شده رو دیکد کنند ، حالا اگر یکی بیاد بین این دو سیستم قرار بگیره و کلید ها رو در بین راه بگیره میتونه اون اطلاعات رو هم دیکد کنه !
چه طوری میشه که نمیتونند این کار رو بکنند ؟
بعد یک سوال دیگه هم دارم ، اسکریپتی که مینویسیم حالا به هر زبانی هم باید این داستان رو حالش باشه یا نیازی نیست ؟
چون تا جایی که من میدونم این وظیفه ی وب سرور هست نه اسکریپت ولی با این حال برخی CMS ها رو دیدم که خودشون یک بخشی برای فعال کردن SSL دارند .
ممنون میشم که توضیح بدید .
eshpilen
جمعه 05 فروردین 1390, 00:49 صبح
داستان تاجاییکه بنده میدونم بصورت کلی و مفهومی با اغماض و احتمال نقص و اشتباه در بعضی جزییات به این شکل هست:
- کلاینت با سرور مورد نظر تماس میگیره.
در این مرحله هنوز ثابت نشده که طرف مقابل واقعا سرور مورد نظر (وابسته به اون آدرس خاص) هست یا اینکه کسی بین راه قرار نداره و اطلاعات رو دستکاری یا جعل نمیکنه.
- سرور مورد نظر کلید عمومی خودش و یکسری اطلاعات دیگر لازم برای تعیین هویتش (مثلا نام دامین یا مشخصات حقوقی شرکت) رو که مجموعهء این اطلاعات توسط کلید خصوصی شرکت واسطه ای مثل VeriSign امضای دیجیتال شده، به کلاینت ارسال میکنه.
- کلاینت بررسی میکنه که امضای دیجیتال صحیح باشه. میدونید که بررسی صحت امضای دیجیتال با کلید عمومی طرفی که امضاء دیجیتال رو توسط کلید خصوصی خودش انجام داده قابل انجام هست. و میدونید که مرورگرها کلید عمومی تعدادی از این شرکتها رو دارن.
- اگر امضاء دیجیتال صحیح بود یعنی اون شرکت/سایت همونی هست که ادعا میکنه چون کلید عمومی + اطلاعات هویتی دیگر اون قبلا توسط شرکت واسطه ای که مرورگر بهش اعتماد داره به ثبت رسیده و امضای دیجیتال شده.
حالا شما مطمئنید که کلید عمومی واقعی اون سایت رو در اختیار دارید و میتونید دیتای خودتون رو با این کلید عمومی رمز کرده و براش بفرستید و تنها اون سایت که کلید خصوصی متناظر رو در اختیار داره میتونه دیتا رو رمزگشایی بکنه. کسی اگر بین راه اطلاعات رو بگیره، بازم به دلیل نداشتن کلید خصوصی نمیتونه هیچ کاری با اون اطلاعات بکنه.
حالا سوال اینه که اگر اون سایت اطلاعاتی رو که میخواد به شما بده با کلید خصوصی خودش رمز کنه و به شما ارسال کنه، هرکسی در بین راه میتونه استراق سمع کنه و با استفاده از کلید عمومی اون سایت اطلاعات رو رمزگشایی کنه.
خب راه حلش ساده هست و درواقع این کار انجام نمیشه بلکه پروتکل SSL روش دیگری داره:
کلاینت یک کلید موقتی تولید شده بصورت رندوم رو که تنها در اون جلسهء ارتباطی مورد استفاده قرار میگیره با کلید عمومی سایت مورد نظر رمز کرده و به سایت مورد نظر ارسال میکنه. این کلید برای استفاده در یک الگوریتم رمزنگاری متقارن هست چون برای بقیهء ارتباط عملا از الگوریتم های متقارن استفاده میشه که سرعت بیشتری دارن. وقتی سایت مورد نظر کلید موقتی رو دریافت کرد (با کلید خصوصی خودش میتونه کلید مورد نظر رو که با کلید عمومی خودش رمزگذاری شده رمزگشایی کنه)، دو طرف میتونن دیتای خودشون رو با کلید موقتی که اکنون دو طرف ازش اطلاع دارن ولی هیچکس دیگری نمیتونسته از اون اطلاع پیدا کنه رمز کرده و به همدیگر ارسال کنن بدون اینکه کسی بین راه قادر به رمزگشایی این اطلاعات باشه.
ضمنا برای امنیت بیشتر این کلید ممکنه چند بار در طول ارتباط و با فواصل زمانی معین یا معیارهای دیگری عوض بشه. البته اینا دیگه جزییاتش هست که باید رفرنس خود پروتکل رو بخونید. بازم میگم که امنیت و رمزنگاری مقولهء پیچیده و گسترده و ظریفی هست. بطور مثال احتمالا کلید موقتی نهایی با مشارکت سرور هم تولید میشه. یعنی بخشی از کلید موقتی یا آنتروپی مورد نیاز رو سرور تولید میکنه و بخش دیگر رو کلاینت تا به این روش امنیت بازهم بالاتر بره. البته ممکنه اینطور نباشه!! خواستم بگم که ممکنه چقدر ریزه کاری داشته باشه.
بنده چون دربارهء این مسائل زیاد مقاله و مطلب راجع به پروتکل های امنیتی خوندم همه جور ترفندی دیدم و فکر میکنم ذهنم روشن هست!
البته ممکنه بنده خیلی جزییات رو از قلم انداخته باشم، ولی کلیتش همینه تاجایی که میدونم. هرکدوم از اجزای بکار رفته هم اسم دارن که بنده چون دقیق و مطمئن یادم نبود ذکر نکردم. مثلا Certificate (http://en.wikipedia.org/wiki/Public_key_certificate) که میگن احتمالا همون کلید عمومی و مشخصات هویتی سایت/شرکت مورد نظر هست در فرمت باینری خاصی که توسط شرکتهای واسطه امضاء شده. به اون شرکتهای واسط هم فکر میکنم Certificate authority (http://en.wikipedia.org/wiki/Certificate_authority) یا به اختصار CA گفته میشه.
فراموش نکنید هیچ طرفی هیچوقت کلید خصوصی طرف مقابل رو نداره؛ حتی شرکتهای واسطه. و هرچیزی که با کلید عمومی یک طرف رمز بشه فقط میتونه با کلید خصوصی مربوطه که فقط پیش مالک اصلی باقی میمونه رمزگشایی بشه. بعکس هرچیزی که با کلید خصوصی رمز بشه میشه با کلید عمومی رمزگشاییش کرد که کلید عمومی هم فرض میشه که در دسترس همگان هست و یا حداقل سعی در پنهان کردن اون نمیشه.
توجه کنید که در این روش شما برای تایید صحت اولیه، به یک شرکت واسطه متوسل شدید و اعتماد کردید. شرکتی مثل VeriSign. البته VeriSign یه شرکت قدیمی و معروف برای این کار بود ولی الان وضعیتش رو نمیدونم و شرکتهای دیگری هم الان هستن که در قسمتی از تنظیمات مرورگر میتونید لیست Certificate ها یا کلیدهای عمومی اونها رو پیدا کنید.
مثلا در فایرفاکس: Tools menu -> Options -> Advanced -> Encryption -> View Certificates رو نگاهی بکنید.
ممکنه گاهی مرورگر از بعضی سایتها در پروتکل SSL کلیدهای عمومی/گواهینامه هایی دریافت کنه که بوسیلهء شرکتهای واسطه ای که برای مرورگر تعریف نشدن و کلید عمومی اونها رو در اختیار نداره امضاء شده باشن. این مسئله اخیرا زیاد دیده میشه بخصوص در ارتباط با سایتهای داخلی. حتی ظاهرا گاهی شرکت واسطه ای درکار نیست و کلید عمومی/گواهینامه توسط خود اون سایت/شرکت طرف تماس امضاء دیجیتال شده. در این موارد شما نمیتونید مطمئن بشید که واقعا طرف مقابل همونی هست که آدرس دامین و مشخصات نشون میدن، و مثلا ممکنه کسی در بین راه اطلاعات رو جعل کرده باشه یا عملا به سایت دیگری وصل شده باشید که به دامین مورد نظر ارتباطی نداره. در این مواقع حتما دیدید که مرورگر هشدار و توضیح لازم رو میده و برقراری ارتباط با سایت مورد نظر رو فقط بر اساس تصمیم نهایی شما اجازه میده.
بنظرم اگر وقتی آدرس https سایتهای معروفی رو در مرورگر وارد میکنید که قاعدتا باید توسط شرکتهای معتبر شناخته شده توسط مرورگر به ثبت رسیده باشن، ولی مرورگر پیام مورد بالا رو میده، اونوقت این میتونه نشانهء تلاشی برای جعل ارتباط باشه. یعنی ممکنه بین راه اطلاعات جعل میشن و شاید اصلا به سایت دیگری وصل شدید که میخواد خودش رو به جای سایت مورد نظر جا بزنه.
eshpilen
جمعه 05 فروردین 1390, 01:07 صبح
البته شما هم به همین صورت میتونید کلید عمومی/گواهینامهء خودتون رو به سایت مورد نظر ارسال کنید تا هویت شما برای سایت مورد نظر ثابت بشه، ولی معمولا این کار صورت نمیگیره و از طرف سرور تقاضا یا مورد الزام واقع نمیشه و ارسال گواهینامه و اثبات هویت منحصر به سمت سرور هست. مثلا مرورگر شما گواهینامهء شما رو به سرورهایی که با https بهشون وصل میشید نمیفرسته و اصلا شما معمولا گواهینامه و کلید عمومی و خصوصی ای ندارید چه برسه به اینکه بخواد توسط شرکتهای واسطه ثبت هم شده باشه.
در همون حول و حوش گزینه های تنظیمات فایرفاکس اگر نگاه کنید چند تنظیم هم برای گواهینامهء شخصی شما داره، ولی هیچ گواهینامهء شخصی ای موجود نیست و اگر یک فایل گواهینامه داشتید میتونید اون رو Import کنید. بهرصورت در وب عمومی تقریبا کاربردی نداره.
sonixax
جمعه 05 فروردین 1390, 01:43 صبح
خوب دوزاریم افتاد - سپاس از شما .
فقط یک پرسشی هم دارم ، نمونه کدی دارید (زبانش زیاد مهم نیست) که که یک استرینگ ساده رو با یک کلید بشه قفل کرد ولی با همون کلید نشه بازش کرد و نیاز به کلید دیگه ای باشه ؟
شبیه همین داستان کلید خصوصی و عمومی .
و دست آخر هم این داستان انکریپشن به اسکریپت سرور ساید ما ربطی نداره ، درسته ؟ یعنی اون به همون روال قبلی کار خودش رو میکنه ؟! فقط نمیدونم چرا بعضی CMS ها یک بخشی برای فعال کردنش داند ! شاید Htaccess رو دست کاری میکنند گه نشه از HTTP استفاده کرد ؟! درسته یا نه ؟
بعد چند % امکان داره که بشه یک امضای دیجیتال رو جعل کرد و اینکه کلید عمومی بر مبنای کلید خصوصی تولید میشه یا به عکس یا کلن این دو تا کلید هیچ ربطی به هم ندارند ؟
بنده چون دربارهء این مسائل زیاد مقاله و مطلب راجع به پروتکل های امنیتی خوندم همه جور ترفندی دیدم و فکر میکنم ذهنم روشن هست!و اینکه ممکنه چند تاشون رو معرفی کنید ، شدیدا به خاطر اینکه در این زمینه اطلاعاتم نزدیک به صفره از خودم بدم اومده :لبخند:
خیلی مرسی
eshpilen
جمعه 05 فروردین 1390, 12:13 عصر
خوب دوزاریم افتاد - سپاس از شما .
فقط یک پرسشی هم دارم ، نمونه کدی دارید (زبانش زیاد مهم نیست) که که یک استرینگ ساده رو با یک کلید بشه قفل کرد ولی با همون کلید نشه بازش کرد و نیاز به کلید دیگه ای باشه ؟
شبیه همین داستان کلید خصوصی و عمومی .
نمونه کد؟ یعنی یک روش ساده و غیر از الگوریتم های معتبر رسمی؟
تنها روشهای ممکن و امن همون روشهای استاندارد بر اساس مسائل ریاضی هستن و چند الگوریتم برای این کار داریم که معروفترین و قدیمی ترین اونا RSA هست.
البته فکر میکنم در مثالهایی که برای توضیح طرز کار اینها بیان شده موارد خیلی ساده شده ای بصورت مثال وجود دارن.
بیش از این منبع خاصی سراغ ندارم که ارائه کنم. بنظرم منابع موجود رو راحت میشه پیداشون کرد.
و دست آخر هم این داستان انکریپشن به اسکریپت سرور ساید ما ربطی نداره ، درسته ؟ یعنی اون به همون روال قبلی کار خودش رو میکنه ؟! فقط نمیدونم چرا بعضی CMS ها یک بخشی برای فعال کردنش داند ! شاید Htaccess رو دست کاری میکنند گه نشه از HTTP استفاده کرد ؟! درسته یا نه ؟
این کار معمولا به عهدهء فریمورک و کتابخانه های اون هست، چون پیاده سازی الگوریتمش کار هرکسی نیست. پیچیده و حجیم و ظریفه (پروتکل SSL بکنار و الگوریتم رمزنگاری نامتقارن بکنار - هردو مشکل هستن). خیلی جاها این کار کم و بیش بصورت Transparent انجام میشه. اما خب بهرحال یه تنظیمات و مثلا عوض کردن اسم توابع مورد استفاده و جزییات دیگری شاید وجود دارن که اون CMS ها انجام میدن، یا شاید بهینه سازیهایی بخاطر افزایش سرعت و غیره. بیش از این اطلاعی ندارم. فقط میدونم بالاخره جزییات و تنظیماتی اکثرا هست و در بعضی فریمورک ها و کتابخانه ها هم این کار بصورت کاملا Transparent ممکنه انجام نشه و نیاز به کد و الگوریتم اضافه ای در سطح برنامه نویس داشته باشه.
بعد چند % امکان داره که بشه یک امضای دیجیتال رو جعل کرد و اینکه کلید عمومی بر مبنای کلید خصوصی تولید میشه یا به عکس یا کلن این دو تا کلید هیچ ربطی به هم ندارند ؟امکان جعل امضای دیجیتال وجود نداره. مگر اینکه مسئلهء ریاضی ای که الگوریتم نامتقارن بر مبنای اون هست شکسته بشه (حل بشه) و یا ضعفی در یکی دیگر از الگوریتم های مورد استفاده مثل الگوریتم هش استفاده شده باشه. بطور مثال قبلا تونستن حداقل چند مورد خاص از امضاهای جعلی با استفاده از ضعفی که در الگوریتم هش MD5 پیدا شد تولید کنن. بخاطر همین الان در امضاهای دیجیتال از الگوریتم های هش دیگری استفاده میشه، البته ظاهرا بعضیا همچنان از MD5 استفاده میکنن!
کلید عمومی و خصوصی کاملا به هم مربوط هستن. جزییاتش رو بیاد ندارم اما کلا یه جورایی به این شکل هست: a*b=c. جای a و b دو عدد صحیح خیلی خیلی خیلی بزرگ قرار دارند که این دوتا با هم در حکم کلید خصوصی هستن، و c که حاصلضرب اوناست همون کلید عمومی میشه. البته a و b هر عدد صحیح بزرگی نمیتونن باشن، بلکه عدد اول هستن یا اینکه نسبت به همدیگر اول هستن (دقیقا یادم نیست کدومش). اینا که گفتم مال الگوریتم RSA هست.
نکتهء کلیدی این هست که در ریاضیات هنوز روش و فرمول/الگوریتم کارایی برای فاکتور گرفتن از چنین عدد بزرگی (c) کشف نشده و در نتیجه امکان بدست آوردن a و b از طریق داشتن c درحد غیرممکن هست. و این الگوریتم از همین نکته استفاده میکنه و از دانشی که مالک نسبت به a و b داره استفاده میکنه. طرز رمز کردن پیامها فرمول خاصی داره که بنده دقیقا یادم نیست (فکر میکنم اساسا از تابع ریاضی Mod و باقیمانده و شاخهء خاصی از این ریاضیات استفاده میشه) ولی میتونید در نت پیداش کنید.
و اینکه ممکنه چند تاشون رو معرفی کنید ، شدیدا به خاطر اینکه در این زمینه اطلاعاتم نزدیک به صفره از خودم بدم اومده :لبخند:منابع پروتکل های امنیتی. Cryptography. همه جا هست. من همینطوری هرچی دستم اومد خوندم. هرچی برخورد کردم و برام سوال بود. در ویکیپدیا و جاهای دیگه. خلاصه هرچی هست میتونید بخونید و ماهها روش وقت بذارید.
کتاب Handbook of Applied Cryptography (http://www.cacr.math.uwaterloo.ca/hac/) هم یک کتاب معروف تقریبا جامع و دقیق پایه ای هست که البته بهتره ریاضیاتتون کاملا قوی باشه چون ریاضیات پیشرفته خیلی زیاد درش بکار رفته. البته تعجبی نیست چون ریاضیات در این حیطه اساسی و اصل مطلب هست. ولی ظاهرا کتابهای دیگری هم که کمتر حالت ریاضی داشته باشن وجود دارن.
eshpilen
جمعه 05 فروردین 1390, 13:10 عصر
بد نیست بعنوان تکمیل مطلب عرض کنم که الگوریتمی برای فاکتورگیری اعداد صحیح بزرگ بوسیلهء رایانه های کوانتمی کشف شده که قادر هست این کار رو در زمان polynomial انجام بده و این به معنای شکسته شدن امنیت الگوریتم RSA هست که این امر اگر بقدر کافی ناگهانی و سریع رخ بده فاجعه ای جهانی محسوب میشه چون تجارت الکترونیک و بخش بسیار بزرگی از سیستمهای امنیتی دنیا بی دفاع خواهند شد!
اما رایانه های کوانتمی هنوز به شکل عملیاتی وجود ندارن و تاحالا فقط اصول پایهء اونها به شکل خیلی ابتدایی تست شده. شایعاتی وجود داره مبنی بر اینکه ممکنه سازمانهای اطلاعاتی کشورهای پیشرفته رایانه های کوانتمی دراختیار داشته باشن؛ البته مشخص هست که به احتمال خیلی زیاد این شایعات خالی بندی محض هست!! چون اونوقت نیاز هست که دانش و امکانات دانشمندان در خدمت این سازمانها خیلی جلوتر از دانش و امکانات و فناوری بقیهء بشریت باشه. مگر اینکه چیزی شبیه معجزه رخ داده باشه. ضمنا پنهان نگه داشتن چنین واقعیتی هم غیرممکن یا حداقل بسیار سخت بنظر میرسه.
تاجاییکه میدونم حداقل یک الگوریتم دیگر برای امضای دیجیتال وجود داره که حتی باوجود رایانه های کوانتمی امنیت خواهد داشت.
ضمنا فکر میکنم الگوریتم های رمزنگاری نامتقارن دیگری هم وجود دارن که بر مسئلهء فاکتورگیری اعداد صحیح استوار نیستن (ولی بطور مشابهی بر مسائل ریاضی دشوار استوار هستن که ممکنه روزی راه حلی براشون کشف بشه).
sonixax
جمعه 05 فروردین 1390, 18:03 عصر
اینجا دکمه ی سپاس نداره ، برای همین سپاس دوست گرامی .
vBulletin® v4.2.5, Copyright ©2000-1404, Jelsoft Enterprises Ltd.