السلام عليكم و رحمه الله و بركاته عليكم يا اعضاء المنتدى الكرام
اسف للتأخر فى عرض الجزء الثالث من موضوع الSSL ارجو ان اكون افدتكم بهذا الموضوع
و الان نبدأ الجزءء الثالث من الموضوع:

SSL and Stored Data :
=====================
عند وضع مستخدم داتا خاصه به فى ويب سيت محمى ب SSL , ماذا تكون حاله هذه الداتا؟ بالطبع نعتبرها فى امان.
عند مثلا وضع يوزر للرقم الكريدت كارد الخاص به فى موقع ما محمى ب SSL هذه الداتا التى وضعها تتشفر و تنتقل فى أمان فى الانترنت الى الويب سرفر حيث يجب ان تعمل هذه الداتا. و ماذا يحدث بعد ذلك لهذه الداتا؟ تنتقل هذه الداتا اى الكريدت كارد نمبر الخاص باليوزر مع بعض الداتا الاخرى مثل مثل اليوزر نيم و معلومات اليوزر الشخصيه و تخزن فى داتا بيز او ترسل الى بعض المفاتيح الماليه للمعالجه الاخرى اى عمليه الشراء. و بعدها نعود و نسأل انفسنا هل هذه الداتا فى مكان امين؟ و من الذى الذى يمكنه الاطلاع عليها فى المكان المخزنه فيه؟.
و بالرغم من ان السيت محمى ب SSL فهذا لا يعنى بالدروره ان الداتا التى وضعها اليوزر و التى تخزنت فى الموقع و الويب سرفر فى امان كامل . و لذلك فنحن نريد التوضيح بأن الSSL تحل جزء بسيط فقط مما يسمى e-commerce security problem اى مشكله امن الحركه التجاريه على الانترنت و تحلها عن طريق اعطاء المستخدم شهاده صحيحه بأن هذا هو الموقع الصحيح المطلوب لوضع الداتا الخاصه به فى امان.و لكن لا تحل مشكله مستوى الامن لمعلومات اليوزر نفسه المخزنه على السيت .
ارجو مراجعه الجزء الاول و الثانى للفهم

The Value of SSLv3 and Client-Side Certificates :
=================================================
مع تقديم ال فيرجان الثالث من ال SSL اى SSL V3 فى عام 96 فأنها تقدم دعم ل 'client-side' certificates. و هذه يعنى ان السرفر نفسه يمكن له ان يطلب يوزرز او يطلب الاجهزه التى تريد فعلا الاتصال بالسرفر لكى يعطيهم هم نفسهم شهاده الثقه الخاصه بهم اى their own digital certificates قبل ان تأخذ ال SSL مجراها فى العمل. و يسجل اليوزر بيم او الايميل الخاص باليوزر فى هذه الشهاده و يستخدمه السرفر فى مطابقته على معلومات اليوزر فى كل مره يدخل فيها الى الموقع حتى يتأكد من انه اليوزر الصحيح . و تذكر ان شهاده الزبون اى اليوزر موقعه ب Certificate Authority اى هيئه الشهادات لمقارنه معلومات اليوزر الحاليه بالمعلومات المسجله و التأكد من صحتها. و تطبيق توثيق الزبون بشكل صحيح يقدم للهاكر عقبه هائله امامه. و لكن هل يا ترى سيستسلم الهاكر لهذا؟ بالطبع لا لان المعروف عن الهاكرز هو عدم التراجع عن التحدى

SSL and Vulnerability to Attacks :
==================================
استخدام الSSL على ويب سرفر ممكن يوحى للادمنستراتور الاحساس الخاطئ بالامان. بمعنى ان ويب سرفر يستخدم الSSL ممكن ان يهاجم من اى هاكر كأى سرفر أخر و يمكن ايضا يهاجم بنفس الطريقه التى تهاجم بها السرفرات التى لا تستعمل الSSL. و للاختصار التشفير و شهاده التوثيق اى الdigital certificate الذان هما المكونان الرئيسيان للSSL لا يمكن ان يحمو السرفر من الاختراق و لكن فقط يمكنهم حمايه المعلومات عند الانتقال من و الى السرفر نفسه. و سنعرف كيف

Certification Weaknesses :
==========================
كما نلا حظ ان ال CAS العامه مثل الفيرجان غير معصومه.و من الاخطاء الشائعه بين الادمنستراتورز غالبا هى اعطاء الثقه الزياده ل CAS عام مثل فيرجان معين من برنامج معين.
فلو اعطى مثلا هذا الفيرجان شهاده تقول انى JOHN مثلا فسيقبل الادمينستراتور فورا انى JOHN. لسوء الحظ عندما تأتى لتوثيق يوزر تجد ان الهيئات التى تعتمد الشهادات العامه لا تهتم بمن يكون اليوزر مثل اهتمام الادمينستراتور.
مثلا:
فريق من الهاكرز و انا عضو فيه تحت اسم الادمنستراتور اذن الفرست نيم ادمنستراتور و الاسم الاخير تركته فارغ . الشى الاول الذى نفعله عندما يطلب منا سيت التوثيق هو تقديم شهاده الادمنستراتور و سيكون من الاحسن استخدام ال IIS اى (Internet Information Server, Microsoft's Web server that runs on Windows NT platforms) التى تحتوى على ميزه 'Client Certificate Mapping' التى تنظم و تؤكد الاسماء الموجوده فى الشهاده تحت نظام ال NT .

و يبقى لنا يا اصدقائى ثلاث نقاط فى هذا الموضوع و هم :
Brute-Forcing Certificates
Stealing Valid Certificates with Trojan Horses
SSL and IDS

و سوف نتكلم عنهم فى وقت اخر لانهم من الاشياء المهمه جداا و المثيره ايضا فأنتظرو الدرس القادم بأذن الله تعالى
اخوكم ACID BURN_EG

=================================================
جميع حقوق النشر محفوظه ل ACID BURN_EG
ACIDBURN_EG@HOTMAIL.COM
و ممنوع منعا باتا نقل هذا الموضوع خارج المنتدى او
كتابه مثله الا بعد الاستشاره.
=================================================