Printable View
http://www.iranssl.com/Default.aspx
سوال : آیا ما تحت تحریم نیستیم؟ خوب این دیگه چیه؟ و از طرفی شایع شده که NSA کد های ایران را شکسته است !!! آیا این مطلب صحت دارد؟
http://www.freerepublic.com/focus/f-news/1145946/posts
http://www.washingtonmonthly.com/arc..._05/003996.php
عزیز برادر ، ارائه گواهی های SSL روی وب چه ربطی به احمد چلبی و افشای کدهای رمز وزارت اطلاعات در عراق داره ؟ و هر دوی اینها چه ارتباطی با تحریم دارن ؟ داری در مورد چی حرف میزنی ؟
(:D)
http://ads.netsups.com/engine/view.a...nw=468&banh=60
من اینجا به این سوالات برخوردم گفتم آیا این حرفا صحت دارد؟
دوستان عزیز
سلام
گواهینامه های ssl ارتباطی با کدسازمان اطلاعاتی ایران که خبرش توسط آقای احمد چلبی منتشر شده نداره.
البته گواهینامه های ssl هنوز برای ایران یک کالای تحریم شده است و سایت IranSSL به سختی توانسته است آنرا به مردم ایران هدیه کند.
چون بدون داشتن گواهینامه SSL هیچ نوع تجارت الکترونیکی و تبادل مالی و یا تبادل اطلاعات باارزش از طریق اینترنت قابل اجرا نیست.
هم اکنون هم مراکز بزرگی نظیر صدا و سیما و شرکت توانیر و بسیار ارگانها و شرکتهای دیگر از محضولات IranSSL استفاده میکنند.
به امید روزهای بهتر برای تمام ایرانیان
سایت IranSSL
نقل قول:
البته گواهینامه های ssl هنوز برای ایران یک کالای تحریم شده است و سایت IranSSL به سختی توانسته است آنرا به مردم ایران هدیه کند.
نقل قول:
سایت IranSSL
SSL یا Secure Socket Layer یک Open Protocol است . OP ها طبق قاعده ای از پیش مشخص شده قابل محدودیت گذاری یا تحریم و ... نیستند . یعنی همانطور که تو میتونی براحتی از HTTP استفاده کنی ( چه با وب سرورهای موجود چه با وب سروری که خودت با اتکاء به HTTP تولید میکنی ) میتونی براحتی و بدون لحاظ هیچ نوع قاعده یا محدودیتی از SSL استفاده کنی . غیر از منطق و پروتکل ، پیاده سازی های رایگان و بدون محدودیتی از SSL هم موجودند که استفاده از اونها بسیار متداول است ، مثل Open SSL . چیزی که نقش حیاتی و مهمی در معماری SSL ایفا میکنه CA یا Certification Authority است . CA باید برای کانالهای ارتباطی بر فراز PKI ، اعتماد سازی کند . این اعتماد سازی با صدور Certification های مختلف و البته با استانداردهائی مثل X.509 امکان پذیر هست . حالا اگر مجموعه ای ( مثل بانک سامان ) بخاد تبادلات اطلاعات خودش رو بر فراز SSL انجام بده ، میتونه براحتی یک CA شخصی ایجاد کنه ، و با استفاده از یک نسخهء پیاده سازی شدهء SSL ( مانند OpenSSL ) یک سیستم PKI کامل و به تمام معنا داشته باشه . CA های وضعیتهای مختلفی دارن ، بعضی مثل VeriSign بین المللی و دارای گرایش تجاری-بازرگانی هستند و بعضی مثل NIST داری گرایش دولتی-نظامی . سازمانها و شرکتهای مختلف برای بهینه سازی هزینه ها و عدم ورود به حوزهء چالشخیز PKI یا بخاطر ماهیت و ذات بیزینس شان ( خصوصا" برای تبادلات Cross-Enterprise یا بین سازمانی ) از CA های معتبر و قابل اعتماد استفاده میکنند و روی گواهی های امنیتی آنها توافق میکنند . حالا اینجا معنای تحریم میتونه نمود داشته باشه . بسیاری از CA های معتبر دنیا کشورهائی مانند ایران رو از دسترسی به خدمات ارائه گواهی نامه امنیتی محروم کرده اند ، مانند VeriSign . اما این فقط به این معنی است که ایرانی ها برای تبادلات ایمن نمیتونن از اون CA استفاده کنن ، نه اینکه SSL تحریم شده است ، این اصلا" بی معنیه . حالا گویا IranSSL قصد داره نقش یک CA مستقل رو ایفا کنه ( حداقل توی سایتشون که اینطور نوشته ) و کمک کنه تبادل اطلاعات بین مشتری و خادم ، روی SSL و با استفاده از گواهی های امنیتی IranSSL انجام بشه .
موفق باشید
----
اینجا لیستی از نقاط ضعف و ریسکهای خطر موجود روی سرور IranSSL نوشته بودم که بخاطر احترام به حریم تجاری - بازرگانی این شرکت موقتا" حذفش کردم . طبیعیه اگر این دوستان مایل باشن میتونم این اطلاعات رو با جزئیات همینجا منتشر کنم ، یا در اختیار خودشون قرار بدم و بدیهیه که انتظار داشته باشم فید بک قابل قبولی در مورد رفع این نقاط ضعف دریافت کنم .
- .نقاط ضعف نرم افزارها
. نقاط ضعف پیکره بندی
.ضعف پیکره بندی IIS
.وجود نرم افزارها و سرویسهای غیر ضروری
.کشف اطلاعات محرمانه در مورد ساختار نرم افزاری سرور
. دو سرویس دارای نقیصه
. مسائل مربوط به Root CA آمریکائی و مشکلات مرتبط
. و ...
----
پرسیده : آیا میدانید ٬
این یه تیکه خیلی جالب بود .نقل قول:
خدمات سایت IranSSL مورد تایید شرکتهای بزرگی همچون Microsoft و Netscape میباشد ؟
موفق باشید . :roll:
منظور از SSL در پست فوق , SSL Protocol نیست بلکه منظور SSL Certificate است.نقل قول:
حالا اگر مجموعه ای ( مثل بانک سامان ) بخاد تبادلات اطلاعات خودش رو بر فراز SSL انجام بده ، میتونه براحتی یک CA شخصی ایجاد کنه ، و با استفاده از یک نسخهء پیاده سازی شدهء SSL ( مانند OpenSSL ) یک سیستم PKI کامل و به تمام معنا داشته باشه .
مطلب فوق درست است اما مدل PKI را کامل نمیکند چرا که مدل PKI بدون Certification اصولا بی معنا است. زیرا کلید عمومی و خصوصی که توسط یک CA شخصی درست شده باشد به دلیل نداشتن اعتبارات لازم میتواند توسط هر کس دیگری نیز ساخته شود. البته بانک سامان هم اکنون از گواهینامه های سایت IranSSL استفاده میکنند.
اما زمانیکه از گواهینامه صادر شده توسط خودشان استفاده میکردند البته اطلاعات ایشان محرمانه و بدون هرگونه ضمانتی انتقال میافت اما یک شخص سودجو هم میتوانست یک گواهینامه مشابه برای خود بسازد و با راه اندازی یک سرور جعلی (Fake) بر سرراه کاربران قراربگیرد. کاربر که همیشه به پیام اخطار ویندوز عادت داشته اینب ار هم OK میزند و وارد سایت جعلی میشود و از این به بعد هر اتفاق دیگری ممکن است رخ بدهد.
پس درمیابیم که گواهینامه SSL بدون certification عملا بی ارزش است.
و درواقع همین Certified کردن (تایید هویت الکترونیکی) است که مورد تحریم است و نه خود پروتکل SSL.
با تشکر
سایت IranSSL
Certification توسط CA صادر میشود و در الگوی PKI ، هیچ "اعتباری" به غیر از اعتماد به CA وجود نداره . نتیجتا" شما برای بانک سامان همانقدر اعتبار دارید که VeriSign برای یاهو اعتبار دارد و CAی شخصی من برای من . در واقع الا وجود اعتماد به حراست از جفت کلید و فرآیند تصدیق یا لغو کلیدها ، عیچ "اعتبار" دیگری معنا ندارد . فی المثل حالا اگر بانک سامان توسط آقا زادهء رئیس بانک ( که گویا اینکاره است ) یک CA خصوصی برای اعتبار بخشی به فرآیند ایجاد کانالهای امن سایتشان ایجاد کند ، و بتواند از حریم آن حفاظت کند ، گواهی هایش مانند گواهی های شما و ... برای او معتبر و قابل اعتماد است .نقل قول:
... اما مدل PKI را کامل نمیکند چرا که مدل PKI بدون Certification اصولا بی معنا است. زیرا کلید عمومی و خصوصی که توسط یک CA شخصی درست شده باشد به دلیل نداشتن اعتبارات لازم میتواند توسط هر کس دیگری نیز ساخته شود
خوب ، این اتفاق حالا هم ممکنه بیفته . فرقی نمیکنه . اگر بنا را بر بی سوادی کاربران SSL بگذاریم ، بودن و نبودن یک CA معتبر ، میخواهید شما باشید ، یا دیگران ، فرقی نمیکند .نقل قول:
زمانیکه از گواهینامه صادر شده توسط خودشان استفاده میکردند البته اطلاعات ایشان محرمانه و بدون هرگونه ضمانتی انتقال میافت اما یک شخص سودجو هم میتوانست یک گواهینامه مشابه برای خود بسازد و با راه اندازی یک سرور جعلی (Fake) بر سرراه کاربران قراربگیرد. کاربر که همیشه به پیام اخطار ویندوز عادت داشته اینب ار هم OK میزند و وارد سایت جعلی میشود و از این به بعد هر اتفاق دیگری ممکن است رخ بدهد.
دوست عزیز ، Certified شدن ، یک مفهوم ملموس فیزیکی و یکتا نیست که بتوان آن را تحریم کرد . به عنوان مثال VeriSignایران و چند کشور دیگر را تحریم کرده است ، یعنی گواهی الکترونیکی به ما نمیدهد ، خوب چه اهمیتی داره ؟ ما میتوانیم یک CA شخصی راه بندازیم ، مثل شما ، گواهی ها و کلید های خودمون رو داشته باشیم و به مشتری هامون تضمین های خودمون رو بدیم . به محض اینکه کسی به ما اعتماد کرد و برای تبادلات رمز شده اش از گواهی های ما استفاده کرد ، یک الگوی PKI کامل و قابل اعتماد ایجاد شده است . Certified شدن مبتنی بر اعتماد طرفین است نه نظر فلان شرکت امریکائی یا اروپائی ، یعنی نه پروتکل نه گواهی های اعتباری نه نرم افزارهای مرتبط هیچکدام محدودیت پذیر نیستند ، چون منطق PKI بر پایه ء ترکیب رمزنگاری و اعتماد سازی دو طرفه معنا پیدا میکنه .نقل قول:
درواقع همین Certified کردن (تایید هویت الکترونیکی) است که مورد تحریم است و نه خود پروتکل SSL.
موفق باشید :)
داردنقل قول:
در الگوی PKI ، هیچ "اعتباری" به غیر از اعتماد به CA وجود نداره
اینکار را قبلا کرده بودند اما تصمیم گرفتند از گواهینامه های IranSSL استفاده کنند بدلیل همان تفاوتی که در ادامه اشاره میکنم.نقل قول:
حالا اگر بانک سامان توسط آقا زادهء رئیس بانک ( که گویا اینکاره است ) یک CA خصوصی برای اعتبار بخشی به فرآیند ایجاد کانالهای امن سایتشان ایجاد کند
به هیچ عنواننقل قول:
این اتفاق حالا هم ممکنه بیفته .
اساسا دلیل وجود Certification و امکاناتی نظیر TrustLogo تنها جهت جلوگیری از خطای کاربران کم اطلاع است.نقل قول:
اگر بنا را بر بی سوادی کاربران SSL بگذاریم ، بودن و نبودن یک CA معتبر ، میخواهید شما باشید ، یا دیگران ، فرقی نمیکند .
باید به شما بگویم که Certification دقیقا یک مفهوم یکتا است. و اگر هویت سایتی یا شخصی یا بطور کلی هویت در سیستم PKI یکتا نباشد , پس چه نیازی به تایید هویت به صورت الکترونیکی است و در دنیای Cyber هر کسی میتواند خودش را بجای کس دیگر و هر سروری بجای سرور دیگر جا بزند. پس با این فرض که تایید هویت یک امر یکتا نباشد بنظر میرسد که تکنولوژی PKI و گواهینامه های دیجیتالی بازیچه ای بیش نیستند.؟!؟!؟! نه دوست من اینگونه نیست.نقل قول:
دوست عزیز ، Certified شدن ، یک مفهوم ملموس فیزیکی و یکتا نیست
به هیچ عنوان اعتماد اولیه طرفین اهمیتی ندارد بلکه این اعتماد باید بوجود بیاید.نقل قول:
Certified شدن مبتنی بر اعتماد طرفین است نه نظر فلان شرکت امریکائی یا اروپائی
:idea: اما توضیحات بیشتر :
در بحث اعتماد در سیستم PKI و گواهینامه های دیجیتالی و علی الخصوص SSL Certificate اگر ما سه شخصیت را فرض کنیم ( که البته تعداد آنها بیشتر است) و اینها عبارتند از CA (معرف Certificate Authority) و B (معرف Business) و C (معرف Customer) , دو نوع ارتباط کلی (تعداد ارتباط ها نیز بیشتر است) بوجود میآید : اول B2CA و دوم C2B.
حال برفرض اینکه قبول کنیم CA و B دو شخصیت تک و مشخص هستند (که در بیشتر موارد اینگونه نیست) و فرض ما را قبول کنیم که اعتمادی از طرف B به طرف CA برقرار شده است, در این حالت این مدل کار میکند. اما برای برقراری اعتماد از طرف C به طرف B چطور ؟ چند کاربر C برای یک B وجود دارد ؟ یکی ؟ دوتا ؟ ... هزارتا ؟ یا نامشخص ؟ چه تعداد از کاربران C از وجود ارتباطی ما بین B و CA آگاه هستند ؟ اصلا چه تعداد B را میشناسند و چه تعداد CA را ؟ ممکن است یک CA برای تعداد زیادی C شناخته شده باشد ( مانند CA ملی شرکت خدمات انفورماتیک) اما مسلما C هایی هم هستند که CA را نمیشناسند. دراینجا یک عامل و شخصیت دیگری مورد نیاز است. سیستمی که بتواند اعتمادی از طرف تمامی Cها به طرف یک B جلب کند.
سؤال : چگونه شما (منظور کاربران ایرانی است) پس از ورود به سایت Gold Quest با وارد کردن شماره کارت اعتباری خود اقدام به خرید سکه میکردید ؟ آیا با شرکت Gold Quest آشنایی داشتید ؟ آیا از تعداد کارمندان و نوع عملکرد آنها آگاهی داشته و دارید ؟ یا اینکه بواسطه تبلیغات زیادی که کرده اند اعتماد شما را جلب کرده اند؟
جواب : هیچکدام. شما به اعتماد گواهینامه ای که سایت شرکت Gold Quest از Verisign گرفته بود به او اعتماد کردید.
سؤال : شما از کجا به شرکت Verisign اعتماد کردید ؟ آیا از موقعیت آنها و تعداد کارمندانشان و اعتبارات مالی آنها و ... خبر داشته و دارید ؟ یا اینکه تنها چون اسم آنرا زیاد شنده اید و بگفته خودشان بزرگترین CA دنیا هستند به آنها اعتماد کرده اید ؟
جواب : هیچکدام. شما با توجه به تایید هویتی که انجام داده اید بوسیله کسی که به او اعتماد داشته اید , هم به Verisign و هم به Gold Quest اعتماد کرده اید. شما اینکار را بدون اینکه متوجه بشوید انجام داده اید.
سؤال : اما شما واقعا به چه کسی اعتماد کرده اید ؟
جواب : به سیستم عامل خود و در رأس آن به مرورگر اینترنت خود. در ویندوز این معتمد شما میتواند IE باشد.
در تمامی مرورگرهای اینترنت یک لیستی وجود دارد به نام Root Certificate Trusted List و در آن نام تمامی صادر کنندگان گواهینامه ای که از نظر شرکت ارائه دهنده آن مرورگر (مثلا Microsoft) معتبر هستند ذکر شده است و هرزمانی که شما به اینترنت وصل میشود این لیست به صورت خودکار و اتوماتیک Update میشود تا احیانا شرکتهایی که اعتبار خود را از دست داده اند از لیست حذف شوند و آنهایی که اعتبار به دست آورده اند به لیست اضافه شوند.
شرکتهای ارائه دهنده نرم افزارهای مرورگر اینترنت با توجه به ضوابط استاندارد و قانونی اقدام به تهیه این لیست میکنند. از جمله فاکتورهای یک CA قابل اعتماد میتوان به اعتبار مالی بسیار بالا , اخذ مجوزهای لازم و ... اشاره کرد.
در زمان برقراری هر ارتباط امن در مرورگر شما به صورت استاندارد سه سؤال مورد بررسی قرار میگیرد :
1) آیا گواهینامه توسط یک صادر کننده معتبر صادر شده است ؟
لطفا توجه کنید که شما به این سؤال پاسخ نمیدهید بلکه مرورگر اینترنت شما این سؤال را از بخش مربوطه در سیستم عامل و یا از بخش مربوطه که در خودش قرار دارد میپرسد. پس در اینجا درمیابیم که اولا اعتماد شما به CA و همینطور اعتماد کاربران به CA اصلا ملاک نیست و ثانیا Certification یک مفهوم یکتا است.
2) آیا گواهینامه درحال استفاده متعلق به کسی است که ادعا میکند ؟
3) آیا گواهینامه از لحاظ تاریخ معتبر است ؟
گواهینامه هایی که درسایت IranSSL ارائه میشوند مورد تایید شرکتهای Microsoft , Netscape , Opera و تمامی مرورگرهای معروف دنیا هستند. این گواهینامه ها هم شامل گواهینامه های سرور و هم شامل گواهینامه های شخصی (امضای دیجیتالی) میباشند.
جالب است بدانید که یکی از دلایل عملی نبودن طرح CA ملی همین است که آنها نمیتوانند یک اعتماد مطلق و 100% را برقرار کنند. چون برای اینکار باید یکی از سه راه زیر را انتخاب کرده و انجام دهند :
1) از شرکتهایی نظیر Microsoft بخواهند که نام آنها را در لیست خود اضاف کنند.
این راه به دلیل تحریمها به هیچ عنوان عملی نیست .
2) یک Patch به تمام کاربران خود بدهند و ازآنها بخواهند (یا آنها را مجبور کنند) که این Patch را بر روی سیستم خود نصب کنند.
(من شخصا به عنوان یک کاربر معمولی اینترنت به هیچ Patch بدون امضایی اعتماد نخواهم کرد)
3) گواهینامه های خود را به همراه سیستم عامل ملی ارائه دهند که خود سیستم عامل ملی هنوز بسیار بحث برانگیز است.
:idea: نتیجه میگیریم که :
گواهینامه هایی که سایت IranSSL یا Verisign یا Thawte صادر میکنند با گواهینامه ای که یک شرکت برای خودش صادر کند بسیار متفاوت است.
امیدوارم که خسته نشده باشید.
در دورانی از IT که ما درحال گذراندن آن در ایران هستیم هم اکنون چیزی که بسیار پراهمیت است بحث آموزش و اطلاع رسانی است. از لحاظ تئوری تجارت الکترونیک این دوران برای سرویس دهندگان بسیار دوران پرهزینه اما درآینده سودمندی است. در این دوران هزینه Education بیش از دو تا سه برابر درآمد میباشد. و هدف از این بحث تنها اطلاع رسانی و انتقال معلوماتی که در اینمورد خاص دراختیار داشتیم , بود.
از شما دوست عزیز که باعث بوجود آمدن این بحث زیبا شدید از طرف سایت IranSSL تشکر میکنم.
همچنین امیدواریم که اگر سؤالات دیگری در این باره وجود داشته باشد در پاسخگویی به آنها توانا باشیم.
با تشکر از وقتی که صرف کردید
سایت IranSSL
من هم ازت ممنونم ، اما بخش قابل توجهی از نوشته ات غیر صحیح است که ذیلا" در موردش توضیح میدم .نقل قول:
از شما دوست عزیز که باعث بوجود آمدن این بحث زیبا شدید از طرف سایت IranSSL تشکر میکنم
دقیقا" به همین دلیل ( خصوصا آن بخشی که بولد شده است ) ، الگوی جامع PKI فقط مبتنی بر راه حلهای نرم افزاری نیست . یعنی رمزنگاری در کنار گواهی الکترونیکی و تائیدیه یک شرکت ثالث نمیتواند گریز مناسبی برای این چالش باشد . تاکید میکنم ، PKI ، فقط و فقط اعتماد متقابل را محور ایمن سازی کانال های ارتباطی قرار میدهد . یعنی نه راه حل نرم افزاری قابل اعتماد است به تنهائی ، نه نام و آوازه شرکت توسعه گر گواهی های الکترونیکی ، و نه حتی مورد تائید بودن آن توسط مایکروسافت یا امثالهم . با مطالعهء آنچه نوشتی ، ممکنه برای یک کاربر کم تجربه این سوال پیش بیاد که آیا به واقع کاربرد صحیح و کامل SSL بر فراز یک الگوی PKI در انحصار چند شرکت خاص و محدودیت پذیر است ؟ یا بالفرض در صورت وجود یک شبکه گسترده داخلی نمیتوان از SSL استفاده نمود ؟ یا اصولا" ذات اینترنت - به دور از هیاهو های فنی - اجازه میدهد ، موجودیتی در انحصار فردی باشد ؟ جواب تمام این سوالات منفی است .نقل قول:
باید به شما بگویم که Certification دقیقا یک مفهوم یکتا است. و اگر هویت سایتی یا شخصی یا بطور کلی هویت در سیستم PKI یکتا نباشد , پس چه نیازی به تایید هویت به صورت الکترونیکی است و در دنیای Cyber هر کسی میتواند خودش را بجای کس دیگر و هر سروری بجای سرور دیگر جا بزند. پس با این فرض که تایید هویت یک امر یکتا نباشد بنظر میرسد که تکنولوژی PKI و گواهینامه های دیجیتالی بازیچه ای بیش نیستند.؟!؟!؟! نه دوست من اینگونه نیست.
همانطوری که حتما" میدونید ، PKI موظف است ، احراز هویت خادم و مشتری ( هر دو ) و اعتماد سازی در مسیر انتقال اطلاعات و راهکارهای بررسی صحت دادهء منتقل شده را حمایت کند . SSL و TLS ( که هر دو مورد تائید IETF هستند و دقیقا" همین اسم میتونه من رو متقاعد کنه بقیه این نوشته رو نخونم و یک ضرب برم به خط آخرش ) در مرحلهء احراز هویت خادم و مشتری از گواهینامه های الکترونیکی استاندارد X.509 استفاده میکنند که شامل :
- - زمان اعتبار
- کلید عمومی
- یک شماره سریال ( مخصوص همین گواهی )
- امضای دیجیتال صادر کنندهء گواهی
است که برای تحقق SSL ، باید این گواهی به طور مرتب با برای مدت خاصی دریافت شود و معتبر باشد . صدور این گواهی به عهدهء CA است که به عنوان یک طرف قابل اعتماد برای توسعه گران کسب و کاری که دنبال امنیت هستند ، صادر میشود . نه در چهارچوب PKI و نه در قالب SSL ، هیچ ، تاکید میکنم "هیچ" انحصار و محدودیت پذیری وجود ندارد . تولید گواهی دیجیتال و استفاده از آن ، با هر سیستم عامل ، هر مرورگر ( SSL فقط محدود به تراکنشهای وب نیست ! ) و هر نرم افزار خدمتگزار و کاربر شبکه ، چه در فضای اینترنت ، چه در فضای شبکه های خصوصی ، کاملا" آزاد و قابل توسعه است . یعنی به عنوان یک مثال ملموس ، هر کسی میتواند با ایجاد یک Certificate Authority توسط ویندوز 2003 ، پیکره بندی سیاست امنیتی مناسب برای تولید جفت کلیدها و گواهی نامه های اعتباری اقدام به صدور گواهی نامه اعتباری برای یک کاربر یا سازمان ، یا یک ارتباط کاربر-سازمان ، نماید ، بدون اینکه لازم باشه از جائی تائیدیه یا اجازه بگیره . Certification ، در انحصار هیچ شرکت ، سازمان یا سیستم عاملی نیست و دارای یک مفهوم یکتا نمیباشد. یعنی در صورت وجود اعتماد ، IranSSL همانقدر معتبر است که VeriSign معتبر است ( در مورد بدنهء فنی این سناریو بعدا" حرف میزنیم ، فعلا" موضوع منطق "اعتماد" است نه مباحث فنی ) و در صورت وجود اعتماد بانک مرکزی به InpyCA ( یا CAی فرضی که من راه میندازم ) ، ارتباط مشتریان بانک مرکزی با سرورهای بانک ، با استفاده از گواهی های یکتا و قابل اعتماد InpyCA ، همانقدر امن است که ارتباط مشتریان VeriSign امن است . خادم میتواند یک نرم افزار خاص منظور تولید ساعت و تاریخ باشد و مشتری هم یک برنامه کنسولی ساده برای دریافت این اطلاعات و سیستم عامل هم میتواند هر سیستم عاملی باشد ، از ویندوز گرفته تا کلیه توزیعات یونیکس / لینوکس و حتی سایر سیستمهای عامل . قبل از وارد شدن به بخش اصلی بحث دعوت میکنم به تعریف یک CA معتبر توسط مایکروسافت توجه کنید ( MSDN ) :
<span dir=ltr></span>
- A CA is a mutually trusted third party that confirms the identity of a certificate requestor (usually a user or computer), and then issues the requestor a certificate. The certificate binds the requestors identity to a public key. CAs also renew and revoke certificates as necessary. For example, if a client is presented with a servers certificate, the client computer might try to match the servers CA against the clients list of trusted CAs. If the issuing CA is trusted, the client will verify that the certificate is authentic and has not been tampered with. Finally, the client will accept the certificate as proof of identity of the server
سناریوهای احراز هویت :
- یک طرفه : در یک سناریوی متداول ، صرفا" خادم خود را معرفی میکند . به عنوان مثال هنگام خرید از یک فروشگاه الکترونیکی ، اغلب فقط لازم است سرور معتبر و حقیقی باشد تا حملاتی نظیر Man - in - The - Middle و sniffing ( خصوصا روی مسیریابهای آی اس پی ) نا کام بمانند . در این سناریو ، سرویس دهنده برای کاربر یک گواهی الکترونیکی ارسال میکند تا کاربر با بررسی محتویات آن اطمینان حاصل کند ، ارسال کننده ء گواهی همان سرور حقیقی است . اگر خادم از یکی از Root CA ها گواهی دریافت کرده باشد ، بخاطر توافقات قبلی بین این CA ها و توسعه گران سیستم عاملهائی مثل ویندوز ، اعتبار یا عدم عتبار گواهی بصورت خودکار توسط سیستم عامل یا نرم افزار دیگری به همین منظور بررسی میشود ( هر چند کاربر کماکان امکان دارد به این CA مفروض ، اعتماد نکند و گواهی آن را حذف کند ) و در صورت عدم استفاده از یک Root CA ، کاربر باید خود ، گواهی را بشناسد ( و دقیقا همین نقطه ، نقطهء قوت PKI است . اگر قرار بود همه چیز فقط و فقط مبتنی بر توافقات بین توسعه گر سیستم عامل و تعدادی CA خاص و محدود باشد ، با نقض امنیت یکی از این CA ها تمام تبادلات امن موجود در فضای اینترنت مورد تهدید قرار میگرفت ، یا با انحصاری کردن مفهوم Certification ، تمام سازمانها ، فارغ از نوع و ماهیت بیزینس ، باید مشتری تعداد خاصی CA میشدند که خودش باعث نقض اصل Confidentiality است ) . روند این فرآیند به این شکل است :
- - نرم افزار مشتری ( مثلا" مرورگر اینترنت ) یک Hello Message برای سرور ارسال میکند که در ان اطلاعاتی در مورد پروتکلهای مورد حمایتش و ... وجود دارد و البته یک Session ID .
- نرم افزار خادم نیز یک Hello Message برای کاربر ارسال میکند که شامل اطلاعاتی در مورد پروتکلهای مورد حمایت است به همراه یک عدد ترکیبی که از یک عدد تصادفی و عدد جلسهء کاربر تشکیل شده است .
- نرم افزار خادم گواهی دیجیتالی خود را ارسال میکند . کاربر از کلید عمومی موجود در این گواهی برای رمزنگاری استفاده میکند و از نام سرور و امضای دیجیتالی آن خواهد فهمید آیا به سرور حقیقی متصل شده است یا خیر . CA گواهی الکترونیکی را چنان صادر میکند ( RSA ) که جزئیات مختلفی از مشخصات سرور را در خود داشته باشد . برخی نرم افزارهای مشتری مانند IE بصورت خودکار بررسی هائی روی این گواهی انجام میدهند و در صورت وجود اشکال ، آن را اطلاع میدهند و البته خود کاربر هم میتواند گواهی را بررسی کند و سر انجام پذیرفتن یا نپذیرفتن گواهی به عهدهء کاربر است .
( این تصویر را احتمالا" بارها دیده اید ، که متعلق به IE است . این سازو کار نشان میدهد ، فقط اعتماد کاربر به امضا کنندهء گواهی میتواند متضمن ایمنی باشد ، نه چیز دیگر )
http://www.visualwin.com/SelfSSL/ssl-warning.png
- سرور یک پیام Finished Message برای مشتری ارسال میکند به این معنی و مفهوم که وظیفهء اون خاتمه پیدا کرده است.
- نرم افزار کاربر یک کلید موقت تولید میکند ( بصورت تصادفی یا بر اساس سیاست امنیتی داخل دامنه ) و آن را با کلید عمومی داخل گواهی سرور رمزنگاری نموده و برای سرور ارسال میکند . اگر سرور بتواند این پیام را رمزگشائی کند ، SSL محقق شده است ، زیرا حتما" سرور دارای Private Key بوده است .
- ارتباط برقرار میشود و الا یک پیام اخطار به مضمون عدم توانائی در برقراری ارتباط با سرور برخواهد گشت و اتصال قطع میشود .
نقشی که یک CA در این سناریو ایفا میکند ، تولید یک جفت کلید و گواهی مربوط به آن برای سرویس دهنده است . این گواهی و جفت کلید توسط هر نرم افزاری که با پروتکلهای مربوطه سازگار باشد ، مانند Certificate Authority در ویندوز 2000 و 2003 قابل تولید و استفاده است . سرور فرضی مذکور ، بسته به حساسیت و نوع و ماهیت داده های قابل مبادله اش ، به یک CA مراجعه میکند و گواهی درخواست میکند . "تنها" عاملی که دارای نقش حیاتی و کلیدی در این سناریو است ، اعتماد به CA است . اینکه این CA مورد تائید توسعه گران سیستم عامل یا سایر نرم افزار ها ( مانند مرورگر ) هست یا نیست ، اهمیتی ندارد . ماهیت الگوریتمهای دو طرفه رمزنگاری در کنار گواهی های الکترونیکی و اعتماد به یک CA ، به گونه ای است که فقط و فقط در صورت وجود اعتماد به CA ، بقیه اجزاء به نحو احسن از امنیت حفاظت خواهند کرد .
http://www.domainnamecom.com/images/ssl.gif
نتیجه : در سناریو های یک طرفه ، وجود "اعتماد" به CA تنها عامل اعتباری CA است . Certification توسط هر مجموعه امنیتی قابل اعتماد امکان پذیر است و این دو مفهوم انحصاری نیستند
- دو طرفه : در این سناریو ، مشتری و خادم ، هر دو باید خود را معرفی کنند . این سناریو اغلب برای دسترسی های راه دور به نرم افزارها یا منابع محرمانه ، دسترسی به بانکهای اطلاعاتی و تبادل نامه های الکترونیکی استفاده میشه . پروتکل Schannel که باید مورد حمایت نرم افزار مشتری باشد ، کمک میکند گواهی الکترونیکی مشتری ( که مانند گواهی الکترونیکی خادم ، از طریق یک CA قابل اعتماد تهیه شده ) به خادم ارسال شود و به این ترتیب هر دو طرف میتوانند از هویت یکدیگر مطلع شده ، کلیدهای عمومی و کلید جلسه را برای ایجاد یک اتصال رمز شده مبتنی بر Asymmetric Crypto ایجاد شود . اینجا هم نقش CA ، ایجاد گواهی الکترونیکی و امضای آن برای ثبت هویت است و فقط و فقط وجود اعتماد به یک CA ( موجودی که بتواند گواهی صادر کند ، امضا کند ، کلیدهای ان را مدیریت کند ، و از کلیدهای نگهداری کند و ... ) است و لا غیر .
با توجه به این مطالب مقدماتی ، شما میتونید در بستر هر شبکه ای با وجود مفاهیم مشتری - خادم و CA ، یک الگوی کامل PKI داشته باشید ، بدون نیاز به اخذ تائیدیه از فلان سازمان یا فلان شرکت .
نتیجه :
الف. CA باید مورد اعتماد باشد
ب. علیرغم وجود سیستم قدرتمند رمزنگاری بر فراز PKI ، عامل حیاتی تصدیق امنیت ، امضای دیجیتالی گواهی امنیتی است .
ج. این امضای دیجیتالی صرفا" وظیفه اعتماد سازی را بر عهده دارد .
د. این امضای دیجیتال انحصاری نیست و قابل تحریم نمیباشد .
هـ. PKI از قانون Muttualy Trust تبعیت میکند . این قانون میگوید فقط به کسی اعتماد کن که او را میشناسی .
و. بنا بر Mutually Trust ، چیزی که عامل ایجاد اعتماد است ، توسط فرد ایجاد میشود نه نرم افزار . وجود Root CA هائی که مورد حمایت توسعه گران سیستم عامل هستند و حمایت پیش فرض فلان مرورگر از این CA به معنا و مفهوم لغو امکان ایجاد CA های خصوصی نیست .
شما براحتی میتونید از طریق ویزاردهای IIS یک گواهی دیجیتالی از CA خودتان روی شبکه محلی تان درخواست کنید و سپس این گواهی را به کاربر ارائه کنید . اگر او به CA شما اعتماد دارد ، حالا شما یک اتصال ایمن دارید . در PKI ایمنی یک مفهوم مجرد یا بقول کفار ابسترکت است . هیچ کس نمیتواند یک نسخهء انحصاری برای شما بپیچد و به تعبیر غلطی که گویا خیلی هم متداول شده ، SSL یا گواهی های آن را تحریم کند . شما میتوانید گواهی های خودتان را داشته باشید ، تا وقتی که به CA اعتماد وجود دارد . ضمن آنکه هر خطری که سایر CA ها را تهدید میکند ، CA شما را نیز تهدید میکند . شاید وجود پیش فرض تائیدیه برخی Root CA ها در یک نرم افزار مثل IE گاهی غلط انداز باشد ، گویا فقط این منابع میتوانند گواهی معتبر ایجاد کنند در حالیکه این تائیدیه ها با فرض اعتبار بین المللی منابع آنها ، مورد وثوق توسعه گران سیستم عامل قرار گرفته اند . این به آن معنی نیست که دیگر هیچ CA ای نمیتواند وجود داشته باشد ، هیچ کس نمیتواند گواهی امضا کند و ایجاد یک کانال امن مبتنی بر SSL در انحصار است . امیدوارم به تفاوت این مفاهیم توجه بشه
نکته : مرورگر وب تنها نرم افزاری نیست که از SSL بهره مند است . سایر نرم افزارها هم میتونن براحتی از مزایای SSL استفاده کنند . کافی است یک گواهی قابل اعتماد و یک محل صدور گواهی موثق وجود داشته باشه .
سوال : آیا گواهی ها قابل جعل هستند ؟ بله . هستند . چه گواهی توسط یک Root CA منتشر شده باشه چه توسط یک Sub-Root CA یا Local CA میتوان یک گواهی را جعل نمود . نکته اینجاست که وجود اصل "اعتماد" باعث میشه کاربر بتونه قبل از ایجاد کانال ، جعلی بودن گواهی رو کشف کنه . چون یک کانال زمانی امن است که کاربر گواهی رو بشناسه و امضا کننده ء اون رو تائید کنه .
نکات پایانی :
Certification یک مفهوم است که اعتماد را به همراه دارد . دقت کنید ، بنا و اساس PKI بر اعتماد طرفین مبادله پیام است نه وجود TrustLogo از فلان شرکت معتبر . یعنی مهم این است که شما شرایط اعتماد را چه بدانید و مایل باشید چگونه گواهی تولید کنید و چگونه امضا کنید و چگونه منتشر کنید و ... ، PKI به تائید شده بودن امضا کنندهء گواهی توسط شرکتهای معتبر توجه نمیکند ، زیرا شاید شما اصلا" به آن احتیاج نداشته باشید یا حتی همین مساله بتواند "سیاست امنیتی" سازمان شما را ( فرضا" یک سازمان نظامی ) خدشه دار کند . شما میتونید خودتون CA باشید ، خودتون گواهی تولید کنید ، خودتون بهش اعتماد کنید و مبادله اطلاعاتتون رو امن بدونید ، تا وقتی که به گواهی و امضای اون دقت میکنید و از نرم افزارهائی استفاده میکنید که توانائی مقایسه اطلاعات مربوط به شروع جلسه HTTP و دریافت وگواهی و مقایسه داده ها و ایجاد کانال HTTPS ( فرضا" ) رو داشته باشند . نه لازم است از VersiSign و امثال آن تائیدیه داشته باشید ، نه لازم است گواهی های شما مورد تائید Root CA ها باشد و نه لازم است به عنوان مثال مرورگر شما به صورت پیش فرض از CA شما حمایت کند چون نهایتا" این شما هستید که اعتماد میکنید یا اعتماد نمیکنید .نقل قول:
اساسا دلیل وجود Certification و امکاناتی نظیر TrustLogo تنها جهت جلوگیری از خطای کاربران کم اطلاع است
این نکته دقیقا" مطلبی است که یکبار بنده عرض کردم . شناخت سازمان مقابل یا CA آن سازمان ، چه برای مبادله های B2C چه برای مبادله های B2B ، فقط مبتنی بر اعتماد است . یعنی باید C ها به B و CA آن اعتماد کنند . این اعتماد "باید" همراه با شناخت باشد تا گواهی قابل بررسی باشه . البته اگر CA موسسه شناخته شده ای مثل VeriSign باشه ، حرفی باقی نمیمونه ، اما اگر اینطور نیست باید این اعتماد ، بوجود بیاید . "معنی" PKI همین است .نقل قول:
مسلما C هایی هم هستند که CA را نمیشناسند. دراینجا یک عامل و شخصیت دیگری مورد نیاز است. سیستمی که بتواند اعتمادی از طرف تمامی Cها به طرف یک B جلب کند
<span dir=ltr></span>
- PKI : Short for public key infrastructure, a system of digital certificates, Certificate Authorities, and other registration authorities that verify and authenticate the validity of each party involved in an Internet transaction
Certificate Authority : The CA issues an encrypted digital certificate containing the applicant's public key and a variety of other identification information. The CA makes its own public key readily available through print publicity or perhaps on the Internet
این بخش واقعا" برام عجیب بود ! :roll:نقل قول:
اما شما واقعا به چه کسی اعتماد کرده اید ؟
جواب : به سیستم عامل خود و در رأس آن به مرورگر اینترنت خود. در ویندوز این معتمد شما میتواند IE باشد.
شاید بطور عادی اغلب اینطور است که شما وارد یک کانال امن میشوید و خادم از گواهی های یک Root CA استفاده میکند که بصورت پیش فرض و طبق توافق قبلی مورد تائید مایکروسافت است و IE آن را معتبر میشناسد . اما آیا این به این معناست که راه بر استفاده از سایر CA ها بسته است ؟ یقینا" اینطور نیست . با یک نگاه ساده میتونید ببینید براحتی میشه برای IE یک یا بیشمار CA "مورد اعتماد" جدید تعریف کرد تا گواهی های آنها بصورت داخلی تائید شود . ( بروید به بخش Content بعد از آن بخش Certificates را ببینید و روی کلید Publisher کلیک کنید . اینجا میتوانید یک یا لیستی از CA های مورد اعتمادتان را وارد نمائید . اینجا نه تائید مایکروسافت اهمیت دارد نه چیز دیگر . فقط اعتماد شما مهم است ، ضمن آنکه این فقط IE نیست که از SSL بهره میبرد . هر نرم افزار دیگری نیز میتواند دارای چنین قابلیتی باشد )
همانطور که منطق PKI را خواندیم و به عنوان نمونه IE را دیدیم ، مشخص میشه این مفهوم غلطه ، PKI فقط بر مبنای اعتماد کار میکنه و Certification هیچ معنای یکتای قابل انحصاری نداره . این الفبای ادبیات اینترنت است . هر کسی میتواند به هر چیزی که میخواهد اعتماد کند . این مشکل خود اوست . لازم نیست کس دیگری تصمیم بگیرد فلان چیز معتبر است یا نیست . "اعتبار" ( همانطور که سه بار گفتم ) فقط بر مبنای "اعتماد" است و لا غیر .نقل قول:
پس در اینجا درمیابیم که اولا اعتماد شما به CA و همینطور اعتماد کاربران به CA اصلا ملاک نیست و ثانیا Certification یک مفهوم یکتا است.
- مورد الف کاملا" غیر صحیح است . قبول کردن نصب پیش فرض گواهی های چند شرکت به معنای لغو قابلیت ایجاد گواهی های دیگر نیست . ر-ک توضیحات بالانقل قول:
جالب است بدانید که یکی از دلایل عملی نبودن طرح CA ملی همین است که آنها نمیتوانند یک اعتماد مطلق و 100% را برقرار کنند. چون برای اینکار باید یکی از سه راه زیر را انتخاب کرده و انجام دهند :
1) از شرکتهایی نظیر Microsoft بخواهند که نام آنها را در لیست خود اضاف کنند.
این راه به دلیل تحریمها به هیچ عنوان عملی نیست .
2) یک Patch به تمام کاربران خود بدهند و ازآنها بخواهند (یا آنها را مجبور کنند) که این Patch را بر روی سیستم خود نصب کنند.
(من شخصا به عنوان یک کاربر معمولی اینترنت به هیچ Patch بدون امضایی اعتماد نخواهم کرد)
3) گواهینامه های خود را به همراه سیستم عامل ملی ارائه دهند که خود سیستم عامل ملی هنوز بسیار بحث برانگیز است.
- هیچ Patch ای لازم نیست . میتوان براحتی یک CA ایجاد کرد ، به لحاظ قواعد و قوانین حقوقی شرایط و بستر لازم برای اعتماد سازی را ایجاد نمود ( مثلا" همان کاری که IranSSL تا حدی انجام داده است ) و سپس از کاربران خاص گواهی را به نرم افزارهای خود اضافه کنند. به همین راحتی !
بستگی داره به چه چیزی بگیم تفاوت . گواهی های داخلی یک شرکت الزاما" مورد اعتماد سایر شرکتها و سازمانها نیست ؛ در این صورت ، یک سمت سوم قابل اعتماد مانند IranSSL که دارای یک Security Policy مدون و مشخص است میتونه مورد اعتماد قرار بگیره . اما این "به این معنی نیست" که دیگه نمیشه هیچ گواهی صادر کرد ، نمیشه اون گواهی رو پذیرفت و نمیشه بر مبنای اون یک ارتباط SSL-Based ایجاد کرد . طبیعیه که اگر این اتفاق درون سازمانی بیفته ، عموما" توسط همان سازمان قابل اعتماد است و برای رویکردهای B2B باید از یک مرجع ثالث قابل اعتماد استفاده کرد که این مرجع انحصاری نیست . ر-ک توضیحات بالانقل قول:
گواهینامه هایی که سایت IranSSL یا Verisign یا Thawte صادر میکنند با گواهینامه ای که یک شرکت برای خودش صادر کند بسیار متفاوت است.
و هست . :)نقل قول:
هدف از این بحث تنها اطلاع رسانی و انتقال معلوماتی که در اینمورد خاص دراختیار داشتیم , بود
با توجه به اینکه اغلب خوانندگان این بحث با فضا و فرهنگ حاکم بر ویندوز آشنائی بیشتری دارند تا معادلهای آن در خانوادهء یونیکس ، دعوت میکنم برای کسب اطلاعات فنی تر ، منطبق با اونچه عرض کردم ، صفحهء اختصاصی امنیت در ویندوز رو تو سایت مایکروسافت ببینید :
http://www.microsoft.com/technet/pro...y/default.mspx
اگر ابهام دیگری وجود داره در خدمت هستم .
خوش و موفق باشید :)
قبل از ادامه بحث باید به دوستانی که از این مبحث بازدید میکنند بگم که توضیحات فنی پیرامون نحوه عملکرد PKI و تایید هویت کاربران و سرورها در پست قبلی Inprise یک توضیح کامل و جامع و در عین حال فنی است که به علاقمندان به این بحث مطالعه آنها توصیه میشود. تنها عاملی که البته کمی مبهم است بحث اعتبار و اعتماد است که در این پست توضیح میدهم.
دوست عزیز
بازهم از توضیحات فنی شما و وقتی که صرف کردید متشکرم.
در این بحث نکاتی بین ما و شما مشترک است که به دلیل تفاوت در نوع بیان باعث ابهام شده است.
همه ما میدانیم که تکنولوژی PKI و SSL به هیچ عنوان یک تکنولوژی تحریم شده نیست و اساسا غیر قابل تحریم است. و کلمه تحریم زمانی استفاده میشود که Known Root CA ها به ایرانیان گواهینامه نمیفروشند و لذا میگوییم "ما را تحریم کرده اند". بازهم تاکید میکنم این به معنی تحریم تکنولوژی PKI و SSL نیست.
اما , تکنولوژِی که تحریم نیست و نرم افزارهای CA هم که موجود است و ما میتوانیم به راحتی خودمان یک CA راه اندازی کنیم و گواهینامه صادر کنیم, و آنها هم این مطلب را میدانند. پس چرا ما را تحریم میکنند و گواهینامه های صادر شده توسط خودشان را به ما نمیفروشند ؟ باید دلیل خوبی داشته باشند وگرنه احتمالا از پول ما خوششان نمی آید.
خواهش میکنم توجه کنید که ما در مورد اینترنت صحبت میکنیم نه اینترانت. اینترانت و شبکه های داخلی به طور کلی میتوانند قواعد خاص خود را داشته باشند و تمامی Clientها در این Intranet فرضی میتوانند به یک CA داخلی اطمینان کنند. اما وقتی در مورد اینترنت بحث میکنیم , بحث ما شکل جامع و کلانی به خود میگیرد. دیگر نمیتوان گفت که هر کاربری در محیط اینترنت باید CA را بشناسد و خودش اطمینان کند ( کما اینکه در تعاریف PKI اینگونه است) , زیرا عملی نیست و باید از شخص ثالثی پرسیده شود و در اصطلاح یک Certificate Verification انجام شود. اینکار توسط سیستم عامل انجام میگیرد (به صورت اتوماتیک) و البته کاربر مختار است که CAیی را از لیست CAهای قابل اطمینان حذف کند و یا به آن لیست اضاف کند. اما آیا به نظر شما در دنیای اینترنت عملی است که به هرکاربری بگوییم :" لطفا تمام CA ها را از Trusted List خود حذف کن ( در این حالت Certificate Verification برای گواهینامه های صادر شده توسط Verisign و InpyCA و IranSSL یکسان عمل میکند و هیچکدام را نمیشناسد) خوب حالا از این به بعد شما باید خودتان تشخیص دهید که کدام CA معتبر است و دیگر سیستم عامل به شما کمکی نمیکند" ؟؟؟؟؟ آیا این حرف عملی است ؟
لطفا دقت کنید که فضای اینترنت ایران یک اینترانت نیست و باید با دید کلان به آن نگاه کرد.
از شما میپرسم :
چه تفاوتی میان CAیی که در هیچکدام از Trusted List ها نیست با CAیی که در تمام Trusted List ها هست وجود دارد ( نه از لحاظ فنی بلکه از لحاظ اعتباری) ؟
احتمالا پاسخ شما اینگونه خواهد بود :
"از لحاظ فنی هیچ تفاوتی وجود ندارد , از لحاظ اعتباری هم اگر کاربر به هردو اعتماد داشته باشد بازهم تفاوتی ندارد , اما یک نکته وجود دارد و آن اینکه جعل گواهینامه ای که در Trusted Listها نیست بسیار ساده است , زیرا میشود که گواهینامه ای با همان مشخصات CA صادر کرد و کاربر هم که برای هردو پیام خطا را میبیند پس چه فرقی میکند و عملی هم نیست که از تمام کاربران بخواهیم که لطفا گواهینامه اصلی را در لیست خود نصب کنید , اما CAیی که در Trusted List ها ثبت شده است قابل جعل نیست , زیرا برفرض اینکه شما تمامی اطلاعات را عینا در یک گواهینامه جعلی ایجاد کنید نمیتوانید کد یکتای گواهینامه (Serial Number) را همانند کنید و آنرا به ثبت برسانید , لذا Certificate Verification در برخود با گواهینامه شما به کاربر میگوید که CA را نمیشناسد با اینکه تمام اطلاعات ظاهری دقیقا یکسان است. پس این باعث میشود که کاربر با گواهینامه ای که از نظر سیستم عامل معتبر است راحت تر کار کند و دردسر کمتری داشته باشد و امکان فریب خوردن وی به حد صفر برسد و لذا این گواهینامه که در تمام Trusted Listها ثبت شده است معتبرتر است."
اگر جواب شما مطابق فوق باشد کاملا صحیح است.
این بدان معنی نیست که اگر سیستم عامل هویت صادرکننده ای را تایید نکرد آن صادر کننده غیر قانونی است و میخواهد جعلی انجام دهد , به عنوان مثال اگر شما یک ویندوز خام XP نصب کنید و برروی سایت Global Sign بروید مرورگر به شما خواهد گفت که صادرکننده گواهینامه را نمیشناسد , علیرغم اینکه Global Sign یک CA معتبر است اما اخیرا وارد گردونه CAها شده است ولی پس از 10 تا 15 دقیقه که شما به اینترنت متصل باشید ویندوز به صورت اتوماتیک نام Global Sign را در لیست خود اضاف میکند , بنابر این تایید سیستم عامل (همان Certificate Verification) شاهدی بسیار معتبر بر احزار هویت صادرکننده گواهینامه یا CA میباشد. آیا اینگونه نیست ؟
لطفا به متن زیر که در مقاله Microsoft Windows 2000 Public Key Infrastructure درج شده است توجه کنید :
<p dir=ltr><span dir=ltr>Trust
The principal client trust concern when using PK-based functionality is the trust associated with certificate verification. This is generally based on the trust associated with the CA that issued the certificate. As discussed, the PKI assumes a rooted CA hierarchy in which the control of trust is based on decisions concerning root CAs. If a specified end-entity certificate can be shown to chain to a known trusted root CA, and if the intended certificate usage is consistent with the application context, it is considered valid. If either of these conditions is not present, it is considered invalid.
Within the PKI, users may make trust decisions that affect only themselves. They do this by installing or deleting trusted root CAs and configuring associated usage restrictions with the certificate-management administrative tools. This should be the exception, rather than the rule. These trust relationships should be established as part of the enterprise policy (See the following section, PK Security Policy in Windows 2000.) Trust relationships established by policy are automatically propagated to Windows 2000–based client computers.</span></p>
درپاراگراف اول کاملا مشخص است که در صورتیکه از نظر Certificate Verification صادر کننده گواهینامه شناخته شده بود (Known CA) آنگاه به او مارک Is Valid میدهد و در صورتیکه صادرکننده گواهینامه عضو Known CA ها نبود آنگاه به او مارک Not Valid میدهد. و البته در پاراگراف بعدی اشاره شده است که کاربر میتواند تنها در مواردی خودش در مورد یک CA تصمیم بگیرد که تنها نتیجه تاثیر تصمیم وی تنها متوجه خودش باشد و متوجه دیگران نشود. و باز در پاراگراف دوم گفته شده است که اعمال نظر کاربر به حذف و اضافه CA از و به لیست Trusted List یک استثنا (Exeption) است ... که میتواند از طریق Policy ویندوز در Clientهای زیر مجموعه اعمال شود (لطفا به اینترانت بودن این قضیه توجه کنید)
در ادامه توجه شما را به متنی که آقایان Lincoln Stein و John Stewart در سایت w3.org منتشر کرده اند که بحث وسیعی در مورد PKI دارد, جلب میکنم :
<p dir=ltr><span dir=ltr>Q4: When I try to view a secure page, the browser complains that it doesn't recognize the authority that signed its certificate and asks me if I want to continue. Should I?
Web browsers come with a preinstalled list of certifying authorities that they trust to vouchsafe the identity of Web sites. A few years ago there was only one certifying authority, the VeriSign corporation, but now there are dozens. You can view the certifying authorities that your browser trusts by:
In Netscape Navigator 1.0-3.02, choosing Options->Security Preferences->Site Certificates
In Netscape Navigator 4.X, clicking the Security icon.
In Internet Explorer 4.5-, choosing View->Options->Security->Sites...
In Internet Explorer 5+, choosing Tools->Internet Options->Content->Certificates->Trusted Root CA
The browser will display a scrolling list of CA certificates -- the master certificates that certifying authorities use to sign the certificates of individual Web sites. Both the Netscape and Microsoft browsers allow you to view the contents of certificates, activate and deactivate them, install new certificates, and delete old ones.
When a Web site presents your browser with a certificate signed by some authority, the browser will look up the authority's signature in its predefined list. If the browser finds the signature, it will allow the SSL connection to continue. Otherwise it complains that it doesn't recognize the certifying authority.
When this happens, the options available to you depend on the browser you are using. If you are using a Netscape browser, the software offers you the option of reviewing the site's certificate and the signature of the certifying authority. If you decide to proceed, you can recognize the validity of the certificate, either for this one session, or for future sessions. If you accept the certificate, it will be installed in the browser among the CA certificates, and the SSL connection will be completed. Internet Explorer does not give you this option. In order to connect to the site, you will need to obtain a copy of the certifying authority's certificate and install it. This is discussed below</span>. </p>
در ادامه آمده است :
<p dir=ltr><span dir=ltr>Is it safe to accept a site certificate signed by an unknown certifying authority?
If you have an older browser, it is likely that the certifying authority is legitimate but entered the business after the browser software was released. Another real possibility, however, is that the certificate is signed by a rogue CA -- there's nothing to prevent a site from obtaining public domain certificate software and creating its own signed certificates. Never accept a site certificate blindly. Review it first, and contact the certifying authority directly (by phone) if you have any questions as to its legitimacy. If you can't easily determine how to contact the certifying authority, chances are that it isn't legitimate.
It is possible to install new certifying authorities in the browser. You do this by opening a URL that points to the certifying authority's certificate. The browser will present a warning dialog telling you that you are about to install a new CA certificate and giving you a chance to abort. If you proceed, the certificate will be installed and the CA will appear on the list of trusted authorities. All sites bearing certificates signed by this CA will now be trusted to initiate SSL connections.
Because of its security implications, you should be very careful before installing a new CA certificate. Never accept a CA certificate unless you know exactly what you are doing and have a priori evidence that the CA is to be trusted. For example, many companies are now establishing internal certifying authorities to sign the certificates of intranet servers. If your employer gives you a floppy disk with instructions for installing the certificate contained within it, you can feel pretty safe accepting the certificate. If, however, the CA installation dialog ever appears unexpectedly while you're browsing the Internet, be sure to cancel immediately and complain to the remote site's Webmaster. </span></p>
لطفا دو گواهینامه زیر را دانلود کنید و آنها را مشاهده نمایید. هر دو این گواهینامه ها توسط سایت IranSSL صادر شده اند , یکی با استفاده از IranSSL Root CA که در Trusted Root List ها ثبت نشده است , و دیگری گواهینامه معمول IranSSL است که توسط GTE Trust Root CA معتبر شده است که GTE در لیست Trusted Root CA ها وجود دارد. سپس به سؤالات زیر پاسخ دهید :
<p dir=ltr><span dir=ltr>http://www.IranSSL.com/IranSSLCA.cer
http://www.IranSSL.com/GTE_CA.cer</span></p>
1) هر دو این گواهینامه ها توسط یک شرکت صادر شده اند , اما شما به کدام یک اعتماد میکنید ( یا لااقل بیشتر اعتماد میکنید ) ؟
2) امکان جعل کدام گواهینامه بیشتر است و کدام گواهینامه را نمیشود جعل کرد ؟
3) از کدام گواهینامه در فضای اینترنت راحت تر میتوان استفاده کرد ؟
4) کدام گواهینامه بجز برای شما , برای اشخاص دیگر و بغیر از ایرانیان در تمام دنیا هم معتبر است ؟
5) دلیل این اعتبار چیست ؟ و چه شاهدی (شخص ثالثی) این اعتبار را به صورت بین المللی تصدیق کرده است ؟
لطفا به این مثال ملموس توجه کنید :
شما در پوزیسیون معامله با شخصی قرارمیگیرید که نسبتا هم اورا میشناسید و میخواهید چک سنگینی از او دریافت کنید, بااینکه اورا میشناسید اما به بانک وی تماس میگیرید و از نوع اعتبار وی در بانک سؤال میکنید. پس از اینکه بانک به شما میگوید که تاکنون چک فرم خورده ای نداشته و در بانک ما معتبر است شما معامله را انجام میدهید. اما اگر بانک به شما بگوید که تاکنون یک چک ایشان بدون دردسر پاس نشده و موجودی حسابش تا کنون از صدهزار تومان بالانرفته آیا بازهم با او معامله میکنید ؟ (حتی اگر شناختی روی آن شخص داشته باشید). در اینجا بانک به عنوان یک شخص ثالث و قابل اطمینان برای طرفین معامله, نظر خود را در مورد اعتبار سنجی شخص اعلام میکند. این روال در تجارت های کلان در دنیا نیز به همین صورت البته پیشرفته تر انجام میشود. و اگر قرار بود در تجارت جهانی هر دو طرف معامله خودشان همدیگر را Validate کنند , تجارت امری بسیار سخت و دربرخی مواقع غیرممکن میشد.
مثال دیگر اینکه : فرض کنید کسی با استفاده از گواهینامه ای که توسط CA ملی صادر شده است نامه یا مدرکی را امضا کرده و برای شما میفرستد , این صادر کننده در لیست Trusted Root CAها نیست و شما در New York هستید. امضا کننده نامه منکر امضای خود میشود و کار به دادگاه New York کشیده میشود , قاضی گواهینامه فرد را روی سیستم خود (که احتمالا ویندوز , لینوکس , مک و یا هر سیستم دیگری است) باز میکند سیستم عامل شروع به Verification میکند و آنگاه پیام Certificate is not Valid را میدهد , قاضی به شما خواهد گفت : این شخص راست میگوید , این گواهینامه او نیست. و شما دیگر هیچ ادعایی نمیتوانید بکنید. زیرا از روز اول به صادر کننده ای اعتماد کرده اید که فقط برای ایرانیان (یا بخشی از ایرانیان ) شناخته شده است و قاضی آمریکایی آنرا نمیشناسد. پس درمیابیم که استفاده از گواهینامه های مراکز غیر معتبر (به صورت بین المللی) هیچ ارزش حقوقی ندارد.
در نحوه عملکرد گواهینامه های دیجیتالی نیز در پروتکل SSL , سیستم عامل حکم یک شاهد بسیار معتبر را دارد.
حال با توجه به نکات فوق و این مطلب که سیستم عاملها که به صورت اصلی Realease میشوند گواهینامه CAای را که ما خودمان درست کنیم در لیستشان اضاف نمیکنند (اجازه این کار را ندارند) و ضمنا گواهینامه هایی را هم که از Known Root CA ها منشعب شده است به ما نمیفروشند لذا میگوییم "ما را تحریم کرده اند"برای اینکه در این حالت امکان استفاده از گواهینامه های معتبر جهانی دیگر وجود نخواهد داشت.
اما اکنون با استفاده از گواهینامه های IranSSL شما میتوانید گواهینامه ای معتبر از نظر بین المللی داشته باشید و شاهد این اعتبار Microsoft , Netscape , Opera و سایر ارائه دهندگان سیستم عاملها و مرورگرهای معروف میباشند. (که آنها مجموعه هایی شناخته شده و معتبر و همچنین قابل اطمینان از طرف کاربران هستند)
بازهم تاکید میکنم : تکنولوژی PKI و SSL اصولا قابلیت تحریم شدن ندارد و هرشخص و شرکتی میتواند خودش یک CA راه بیاندازد , اما آن CA تا زمانیکه در لیست Trusted Root CAها قرارنگیرد از لحاظ بین المللی و کاربران اینترنت یک گواهینامه غیر معتبر است.
نتیجه اینکه :
- تکنولوژِی SSL و PKI تحریم پذیر نیست.
- CAیی که نام او در Trustet List ها نباشد تنها برای مراکز Intranet کاربرد دارد و جنبه رسمی و حقوقی و بین المللی ندارد.
- به دلیل اینکه CA ملی نمیتواند نام خود را در لیست Trusted Root CAها به صورت فراگیر ثبت کند , عملکرد وی به بخشی از کاربران اینترنت ( یک اینترانت بزرگ) محدود میشود و اعتبار آن جنبه رسمی و عمومی و حقوقی و بین المللی ندارد)
از حوصله ای که برای مطالعه این پست خرج کرده اید ممنونم.
سلام؛
از جواب و وقتی که مصروفش کردی ممنونم . بخش قابل توجهی از نوشته ات کاملا" صحیح و مفید است ، در مورد بخشیش چند خطی نظر شخصی دارم که عرض میکنم :
عملی هست اما طبیعتا" خیلی جالب نیست . عمومیت کاربران تکنولوژی ، افراد کم سوادی هستند که بهترین چیز را ، Easy-to-use ترین چیز میدانند و طبیعیه اگر سیستم عامل در یک نگرش کلان ، وظیفهء تصدیق اعتبار ( بوسیلهء سنجش میزان اعتماد ) را هم بر عهده بگیرد ، خوشحالتر خواهند شد . مطالب من صرفا" ناظر بر وجه پرکتیکال ماجرا بود ، به این معنی که حتی اگر فردا صبح ، بنده یک CA در منزلم و با یک خط مودم 56K و یک پی سی معمولی ، راه اندازی کنم و آقای کرامتی ، مدیر این سایت هم به من اعتماد کند ، من گواهی میدهم ، او استفاده میکند ، کاربران هم تائید میکنند و بقول کفار everybody wins . :) فی الواقع نه من نه هیچ صاحب عقل سلیمی نمیتونه نقش مفید و مؤثر وجود یک Root CA رو نادیده بگیره ، هر چند پر رنگ بودن نقش Root CA ها نمیتونه "ارزش واقعی" سایر CA ها رو کاهش بده ایضا" طبیعیه که وقتی حرف از قوانین بین الملل و اعتبار فرا ملی به میون میاد ، این مفاهیم فنی جای خودش رو به قواعد بین المللی میده که درش جای بحث نیست .نقل قول:
آیا به نظر شما در دنیای اینترنت عملی است که به هرکاربری بگوییم :" لطفا تمام CA ها را از Trusted List خود حذف کن ( در این حالت Certificate Verification برای گواهینامه های صادر شده توسط Verisign و InpyCA و IranSSL یکسان عمل میکند و هیچکدام را نمیشناسد) خوب حالا از این به بعد شما باید خودتان تشخیص دهید که کدام CA معتبر است و دیگر سیستم عامل به شما کمکی نمیکند" ؟؟؟؟؟ آیا این حرف عملی است ؟
لازمه این توضیح رو اضافه کنم که Valid نبودن یک گواهی دیجیتالی در ادبیات مرورگرهای وب ( به عنوان مثال ) به معنا و مفهوم "نا معتبر" بودن اون گواهی نیست ، بلکه صرفا" نشان دهنده این مطلب است که گواهی یا امضای دیجیتال گواهی ، محصول یک Root CA نیست و حالا اعتماد به آن بر عهدهء خود کاربر است . استفاده از SSL محدود به وب نیست ، نرم افزارهای متعددی برای تراکنشهای بین سازمانی از SSL استفاده میکنند که گواهی دیجیتال برای آنها فقط و فقط عاملی برای احراز هویت و تصدیق اعتبار است ، فارغ از اینکه این اعتبار توسط کدام مرکز اعتماد ساز ، تولید شده است ، خواه InpyCA باشد خواه IranSSL ، به عنوان یک نمونه رویکرد اصلی SAP در توسعهء MySAP اتکاء کاملا" درون سازمانی به مفهوم احراز هویت است که برای تراکنشهای اصلی اش از SSL به ضمیمه یک Authorityی داخلی تغذیه میکند و قس علی هذا . طی هفته اخیر مطالب متعددی روی برخی سایتها و یک نشریه درون سازمانی دیدم که به غلط این تصور رو اشاعه میداد که SSL ( و فناوری هائی از این دست ) "تحریم" شده است و باید به فکر "یک چیز دیگر" (!) برای حراست از محرمانگی اطلاعات بود ، تلاش حقیر در دو نوشته قبلی این بود که به صراحت مشخص بشه ، چیزی بنام تحریم در این حوزه معنا و مفهوم نداره و هر کسی هر جای دنیا میتونه براحتی از یک CA شخصی برای تبادلات ایمن استفاده کنه ، خواه مبادله مبتنی بر وب باشه ، خواه یک مسنجر اختصاصی یا حتی یک *** ، بدون اینکه نیاز باشد از "آمریکای جهانخوار" ( :wink: ) و اعوان و انصار و اذناب صهیونیسم بین الملل برای این مهم ، کسب تکلیف کنه :) 8-)
برای توضیحات خوبت ازت ممنونم و امیدوارم جاهای دیگه این سایت هم فعالیت کنی .
خوش باشید .
Inprise , Excellence endures
پس به صورت خلاصه میشود کار SSL را تائید هویت سرور و رمزنگاری داده های ارسالی بیان کرد؟
بنا براین دزدیدن داده های بین راه غیر ممکن است؟
اگر من برای صفحات حساس نرم افزار تحت وبی که دارم از OpenSSL استفاده کنم هیچ کاربری با هیچ سیستم عاملی و مرورگری مشکل نخواهد داشت.؟
ممکن است شخص دیگری هم یک CA بر روی شبکه راه اندازی کند و دقیقا همان اطلاعات مربوط به CA من را به کاربر بفرستد و حالا با تکنیک هایی مثل dnsspoof باعث گمراهی کاربر شود.
من چگونه می توانم جلوی این قضیه رابگیرم.
ُSSL چکونه داده های ارسالی را رمز نگاری می کند که قابل شکستن نباشند؟و به صورت Cleartext انتقال یابند؟
چیری که من برداشت کردم اینه که سرور و مشتری بر اساس قوانین رمز نگاری نامتقارن یک کلید برای دیکود کردن رمز ها به صورت تصادفی اختیار می کنند که سبب جلوگیری ازلو رفتن داده ها در Sniffing می گردد.