بستر انتقال ssl چیست؟

[آرام جان گل]

سلام
در تاپیک روش های امنیتی درASP.net خوندم که برای انتقال الگوریتم های Hash و رمز نگاری برخی اطلاعات مثل رمز عبور کاربر از یک بستر امن مثل SSL استفاده کنیم

من نمی دونم این بستر SSL چی هست
لطفاً اگر کسی می دونه زیردیپلم توضیح بده

مرسی

[mehdi.mousavi]

سلام در تاپیک روش های امنیتی درASP.NET خوندم که برای انتقال الگوریتم های Hash و رمز نگاری برخی اطلاعات مثل رمز عبور کاربر از یک بستر امن مثل SSL استفاده کنیم من نمی دونم این بستر SSL چی هست لطفاً اگر کسی می دونه زیردیپلم توضیح بده مرسی

سلام.
SSL مخفف Secure Socket Layer، یکی از تکنولوژیهای استاندارد راه اندازی لینکی برای تبادل ایمن اطلاعات بین Web Server و Browser هستش. اگر دقت کرده باشید، برخی اوقات توی Browser اتون وقتی URL ای رو وارد می کنید، پروتکل بطور خودکار به HTTPS تغییر میکنه. یعنی از HTTP میره به HTTPS. (و عکس قفل روی صفحه ظاهر میشه). اون S آخر، مخفف Secure هستش و نشون میده اطلاعات روی SSL داره منتقل میشه... بدین ترتیب وقتی شما کلمه ساده و رمزنگاری نشده MyPassword رو بسمت سرور ارسال میکنید، هیچکسی نمیتونه وسط این ارتباط قرار بگیره و کلمه MyPassword رو ببینه چون قبلش این کلمه Encrypt شده و بسمت سرور ارسال شده. سمت سرور، کلمه Encrypt شده به حالت اولیه خودش برگردونده میشه و ادامه پردازش صورت میگیره. از اون سمت هم سرور اطلاعات رو Encrypt شده برای شما میفرسته و ...

بکمک این روش، میشه جلوی حملات MITMA رو گرفت. MITMA مخفف Man in the middle attack هستش، به معنی اینکه فردی روی خط ارتباطی شما و سرور قرار بگیره و اطلاعات رو مشاهده، دستکاری و ... کنه.

موفق باشید.

[Mostafa_Dindar]

با تشکر از شما جناب آقای موسوی .
لطفا به حضور پر بارتان در این تالار همچنان ادامه دهید . این تالار با حضور مداوم افرادی همچون شما و تني چند از ديگر اساتيد رونق میگیره .
مرسی

[mehdi.mousavi]

با تشکر از شما جناب آقای موسوی. لطفا به حضور پر بارتان در این تالار همچنان ادامه دهید . این تالار با حضور مداوم افرادی همچون شما و تنی چند از دیگر اساتید رونق میگیره. مرسی

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

موفق باشید.

[emad_67]

بدین ترتیب وقتی شما کلمه ساده و رمزنگاری نشده MyPassword رو بسمت سرور ارسال میکنید، هیچکسی نمیتونه وسط این ارتباط قرار بگیره و کلمه MyPassword رو ببینه چون قبلش این کلمه Encrypt شده و بسمت سرور ارسال شده.
سلام جناب موسوی
در مورد encrypt شدن داده ها از سمت کاربر میشه بیشتر توضیح بدین که چه جوری این عمل انجام میشه؟ مرورگر این کار رو انجام میده؟ کلیدی که داده ها به وسیله ی اون encrypt میشن از سمت سرور به کاربر داده میشه؟
ممنون

[mehdi.mousavi]

سلام جناب موسوی در مورد encrypt شدن داده ها از سمت کاربر میشه بیشتر توضیح بدین که چه جوری این عمل انجام میشه؟ مرورگر این کار رو انجام میده؟ کلیدی که داده ها به وسیله ی اون encrypt میشن از سمت سرور به کاربر داده میشه؟
ممنون


سلام.
تکنولوژی SSL بر مبنای رمزگذاری public key بنا شده. تو رمزگذاری عادی عموما دو طرف ارتباط از رمز مشترکی آگاه هستن و توسط اون پیامها رو رمزگذاری کرده یا اونها رو از حالت رمزگذاری شده خارج میکنن. وقتی شما به سروری متصل میشید و میخواهید اطلاعات رو بین Client و Server رمزگذاری کنید، باید ابتدا رمزی رو بین هر دو دستگاه به اشتراک بذارید تا هر دو بدونن که رمزی که توسط اون میتونن اطلاعات رو به رمز در آورده یا از حالت رمزگذاری شده خارج کنن، چی هستش. حالا اینجا این خطر بوجود میاد که "اگر قرار باشه من رمز رو روی خط ارسال کنم، اونوقت اون مهاجم بد ذات که روی خط ارتباطی من و سرور نشسته، میتونه رمز رو ببینه و دیگه چنین ارتباطی ایمن نیست، چون غیر من و سرور، نفر سومی هم از اون مطلع هستش!" پس چیکار باید کرد؟ Client (یا سرور) چطور میتونه با طرف مقابل یه ارتباط ایمن برقرار کنه و این Password (یا Secret Key هم بهش میگن) رو چطور میتونه بصورت ایمن بدست طرف مقابل برسونه؟؟؟ آیا اصلا نیازی به تبادل این رمز هست؟

این سوال باعث شد تا دانشمندان روش Public Key Cryptography رو ابداع کنن. توی این روش (که SSL هم از اون استفاده میکنه)، هر طرف (Client و Server) دو تا کلید دارن. یکی کلید مخصوص خودشون هست و دیگری کلید عمومی. کلید عمومی رو همه میتونن داشته باشن و اهمیتی نداره که کسی از اون مطلع باشه. اطلاعات، توسط کلید عمومی رمزگذاری میشن و این اطلاعات رمز گذاری شده، فقط و فقط بکمک کلید خصوصی باز میشن. یعنی اگر کسی کلید خصوصی رو نداشته باشه، نمیتونه اطلاعات رو باز کنه (یا حتی رمزنگاری کنه). دقت کنید، که قرار نیست من اینجا تمام جزییات رو توضیح بدم و فقط لپ مطلب رو براتون میگم. اگر به جزییات علاقمند هستید، کتابهای Michael Howrad مرد امنیتی مایکروسافت رو بخونید. توی این کتابها، تمامی جزییات مورد نظرتون رو خواهید بافت. اینکه Key چطور باید Exchange بشه، MAC (یا keyed hash function) چی هستش، MIC چی هستش، Block Cipher چیه، TLS چه فرقی با SSL داره و و و همه و همه در کتابهای مزبور پیدا میشن...

حالا برگردیم سراغ SSL. با یک مثال خیلی ساده، روند کار رو توضیح میدم:



مشتری میخواد با سایتی که روی SSL سرویس میده ارتباط برقرار کنه. URL سایت مزبور رو میزنه و سایت شروع میکنه به سرویس دادن روی پورت 443 که همون https باشه. همونطور که میدونید، http پورت 80 هستش و https پورت 443...
تو این مرحله، سایت مزبور کلید عمومی خودش رو به مشتری میده. مشتری وقتی این کلید رو گرفت، نگاه میکنه ببینه آیا این کلید معتبر هست یا نه، اینکه مثلا منقضی شده یا خیر، آیا برای سایت مزبور هستش یا نه و از این قبیل اعتبار سنجیها...
وقتی مشتری مطمئن شد که میشه به گواهی دریافتی اعتماد کرد، مشتری کلید عمومی خودش رو برای سایت ارسال میکنه.
تو این مرحله، یک کد جدید ساخته میشه که توسط کلید عمومی مشتری و کلید خصوصی سایت، رمزنگاری شده. وقتی این کد تولید شد، سایت اونو برای مشتری ارسال میکنه.
مرورگر مشتری، کد دریافتی رو بررسی میکنه و اونو توسط کلیدهای خودش، میتونه بخونه. تو این مرحله، هر دو سمت کلیدهای مورد نظر رو دارن و میتونن با هم در ایمنی کامل ارتباط خودشون رو ادامه بدن...

اما اجازه بدید از سمت سرور هم یک نگاه کوجکی داشته باشیم و ببینیم این کلید هایی که سرور در اختیار Client قرار میده، از کجا اومده و سرور چطوری برای این ارتباط Config شده. فرض کنید قراره سایتی طراحی کنیم که در بخش ابتدایی اون، باید کاربرها ID/PWD خودشون رو وارد کنن. اسم این سایت رو میذاریم MySite.com...


MySite ابتدا یک درخواست CSR درست میکنه و طی این روند کلید خصوصی تولید میشه!
MySite به سراغ یک CA مثل Verisign (یا هر CA دیگه) میره، CSR رو به اون میده تا CA اونو اعتبار سنجی کنه. CA مطمئن میشه که MySite.com متعلق به من هستش و منم جزء سازمانهای رسمی موجود در رکوردهاش هستم (و مسائل امنیتی دیگه...)...
در این مرحله، CA به من (یا همون MySite)، یک کلید عمومی میده، کلیدی که توسط کلید خصوصی خودش رمزگذاری شده!
حالا من با خیال آسوده اون Certificate رو روی سرور خودم نصب میکنم.

(هر چی بیشتر مینویسم، بیشتر یادم میاد!) یه مساله رو من باید اول از همه مطرح میکردم. اونم اینکه SSL فقط برای ایمن کردن ارتباط بکار نمیره! SSL دو کاربرد داره. یکیش ایمن کردن ارتباطه. دیگری، (که اینم خیلی مهمه) شناسایی هویت سرور هستش. شما از کجا میتونید مطمئن بشید که Gmail همون Gmail هستش؟ شاید سایت مزبور واقعا اونی نباشه که ادعا میکنه...

در هر حال، باز هم میگم، من وارد جزییات مطلب نشدم...
موفق باشید.

[Microname]

سلام
چرا استفاده از این پروتکل(https) همیشگی نیست!؟
چرا مثلا http منسوخ نمیشه؟(منظورم در مقایسه با https است) و همواره از این پروتکل با امن جدید استفاده نکنیم؟
آیا هزینه ای داره؟ و به خاطر هزینه هست؟

[mehdi.mousavi]

سلام چرا استفاده از این پروتکل(https) همیشگی نیست!؟ چرا مثلا http منسوخ نمیشه؟(منظورم در مقایسه با https است) و همواره از این پروتکل با امن جدید استفاده نکنیم؟ آیا هزینه ای داره؟ و به خاطر هزینه هست؟

سلام.
البته که هزینه داره! بدلیل Encrypt/Decrypt کردن داده ها، سرعت ارسال درخواستها و طبیعتا گرفتن پاسخ پایین میاد. در نتیجه سرور باید کار بیشتری انجام بده و بیشتر تحت فشار قرار میگیره. ضمنا، به چه دلیل باید از این Protocol برای نقل و انتقال اطلاعات استفاده کرد؟ شما برای نگهداری جزوات دانشگاهی، یه صندوق امانات میگیرید، یا نگهداری فلان جواهر کمیاب؟ وقتی "دارایی" شما (asset میگن تو security بهش) ارزش محافظت کردن رو نداره، چرا باید بیهوده ازش محافظت بشه؟ اولین سوالی که همواره در مباحث امنیتی برقرار هشتس پرسیدن این سوال و پاسخ دادن به اونه: "asset های ما چی هستن و آیا ارزش محافظت کردن رو دارن؟" از طرف دیگه، برای گرفتن Certificate از CA ها باید سالانه هزینه ای رو پرداخت کنید.

برای برخی از کارها، حرف شما کاملا منطقی هستش. مثلا، یانکها کلیه سرویسهاشون رو باید روی SSL ارائه کنن. اینجا "دارایی" حسابهای مشتریان هستش و Expose شدن حتی بخش کوچکی از اطلاعات حساب میتونه یه Vulnerability محسوب میشه (آسیب پذیری) و زیانهای بیشماری به دارنده حساب (یا اون بانکدار) بزنه. اما حالا این سایت رو در نظر بگیرید. آیا این اطلاعات، (دارایی) ارزش محافظت شدن رو دارن؟ مطمئنا خیر. بنابراین دلیلی برای صرف هزینه بیشتر و محافظت از اونها وجود نداره.

موفق باشید.

[Microname]

درسته حق با شماست ، مثلا نمی آییم جزوات دانشگاهی به صندوق امانات بدهیم اما بی اهمیت هم نیستند!
شما به دیگر کاربرد ssl اشاره کردید و گفتید با استفاده از این پروتکل درستی ، مقصد مشخص می شود. آیا درستی مقصد برای کاربر ، چه اطلاعات در حد حیاتی باشه و یا چه در حد متوسط باشه(یا حتی ضعیف) مهم نیستند؟

[mehdi.mousavi]

درسته حق با شماست ، مثلا نمی آییم جزوات دانشگاهی به صندوق امانات بدهیم اما بی اهمیت هم نیستند! شما به دیگر کاربرد ssl اشاره کردید و گفتید با استفاده از این پروتکل درستی ، مقصد مشخص می شود. آیا درستی مقصد برای کاربر ، چه اطلاعات در حد حیاتی باشه و یا چه در حد متوسط باشه(یا حتی ضعیف) مهم نیستند؟

سلام.
به مطلبی که گفتم دقت کنید! این شما هستید که Asset خودتون رو "ارزیابی" میکنید و تشخیص میدید که آیا فلان جزوه دانشگاهی "ارزش" نگهداری ویژه رو داره یا نه. من فقط مثال زدم که اصل ماجرا رو شما متوجه بشید...

یعنی چی درستی مقصد مهم نیست؟ البته که مهمه اما اگر اطلاعات شما "در معرض خطر" هم قرار بگیره، به بیان دیگه، به سایت دیگه ای که ادعا میکنه سایت "برنامه نویس" هست (و در واقعیت نیست) متصل بشید و نوشته فوق رو اونجا بذارید، چیزی از دست داده اید؟؟؟ نوشته فوق باعث میشه شما در "معرض خطر" قرار بگیرید؟؟؟

ببینید. همواره باید Trade Off ها رو در نظر گرفت. چیزی که از نظر شما مهمه، ممکنه از نظر من بی ارزش باشه. چیزی که الان، اهمیت داره، ممکنه 5 دقیقه دیگه کاملا بی اهمیتی باشه. "ارزش گذاری" داراییها رو "مالک" اون داراییها انجام میده ...

گذشته از اینها، وقتی Terms Of Use و Private Privacy و دیگر اطلاعات موجود در سایتها رو هنگام ایجاد ID/PWD بخونید، عموما به این مسائل اشاره میکنن و اونجا میگن که ما "در این حد" از اطلاعات شما نگهداری میکنیم، یا "این اطلاعات" رو Share میکنیم یا ... و شما هم خود خواسته ID/PWD رو ایجاد میکنید و توی اون سایت فعالیت می کنید.

در نتیجه، اگر من به اشتباه به سایت "برنامه ننویس" جای "برنامه نویس" متصل بشم و فعالیتی هم اونجا داشته باشم، خطری حقوقی متوجه سایت "برنامه نویس" نیست چون اونها ذکر کرده اند که تحت چه شرایطی فعالیت میکنن...

اما بله. تو یه دنیای ایده آل، بهتره همه از همه چیز مطمئن باشیم و همه کارها درست انجام بشه و ... اما آیا واقعا چنین چیزی میسره؟؟؟

موفق باشید.