أتفق معك أن الخطأ البشري لازال مطلوبا، بالطبع البرنامج لا يستطيع تزوير نسخة طبق الأصل عن الشهادة، فهو لا يملك المفتاح الخاص لسلطة الشهادات و بالتالي لا يستطيع تزوير هذه الحقل، ولكن تزوير باقي الحقول ممكن باستخدام مفتاح خاص آخر، ما يحدث هو أن المستخدم يتلقى رسالة تنبيه عن شهادة خاصة بنفس الموقع الذي يزوره (أي حقل الـhost) مطابق، ولكن سلطة الشهادات مجهولة، معظم الناس ستفترض بأن الشهادة صحيحة بما أن عنوان الموقع صحيح. أو أنها لن تملك خيار رفض الشهادة إذا كان مزور الخدمة يسخدم SSL Proxy، إذ أن الرفض يعني عدم الدخول للموقع. القصد من مشاركتي أن مجرد وجود HTTPS أو قفل قرب العنوان لا يعني أن الاتصال آمن بالضرورة. التالي من ملفات دعم البرنامج:

While performing the SSL mitm attack, ettercap substitutes the real ssl certificate with its own. The fake certificate is created on the fly and all the fields are filled according to the real cert presented by the server. Only the issuer is modified and signed with the private key contained in the 'etter.sll.crt' file. If you want to use a different private key you have to regenerate this file.

بالمناسبة أنا استخدم Customize Google لضما استخدام HTTPS مع Gmail و هي تعمل بشكل جيد.

أهلا شادي، في الواقع هناك برامج قادرة على توليد شهادات قريبة جدا من الأصل بشكل ديناميكي، لتظهر و كأنها من الموقع المقصود فعلا، (باستثناء حقل سلطة الشهادات المصدر Cert Authority). بالنسبة لغالبية الناس، فإن شهادة ذات معلومات صحيحة عن الموقع المقصود (خاصة الـhost name) كافية للموافقة عليها. بامكانك الاطلاع على برنامج Ettercap للمزيد عن هذه الامكانية: http://ettercap.sourceforge.net/

- اربط نطاقاتك مع حساب بريد الكتروني خاص غير الحساب الذي تفتحه بشكل يومي، ولا تفتح هذا الحساب إلا عبر وصلة آمنة، وتأكد من وجود https وليس http في شريط العنوان إذا كنت تفتح البريد عبر المتصفح، أما إذا كنت تستخدم برنامجا خاصا للبريد الالكتروني مثل Outlook أو Thunderbird فتأكد أن وصلتك مع المخدم تستخدم تشفير SSL.

بالمناسبة، حتى استخدام HTTPS عند التصفح لا يضمن أن يكون الاتصال آمنا، فقد يستخدم مزود الخدمة SSL Proxy يقوم بدور وسيط بين المستخدم و الموقع الهدف (ما يعرف بـMan in the middle)، يقوم هذا النوع من الـproxy بفك تشفير المعلومات المرسلة، تطبيق سياسة الرقابة عليها، ثم تشفيرها و إعادة إرسالها: http://en.wikipedia.org/wiki/Proxy_server#SSL_proxies يتمكن هذا النوع من الـproxy من فك تشفير بيانات المستخدم لأنه يرسل مفتاحه العام للمستخدم و يحتفظ بالمفتاح العام للموقع الهدف لنفسه. على كل يبقى HTTPS أكثر أمنا من HTTP بمراحل، فالخطر الوحيد المحتمل على البيانات هو عند مزود الخدمة. شكرا على النصائح :)

أنا لا أحمل BulkBuster المسؤولية، النظام الجديد الذي أطلقه ICANN ينطبق على جميع مسجلي نطاقات .com، و قد تحدثت عنه مرارا في تعليقاتي و اقتبست من موقعهم ما يوافق ذلك. على أي حال، لكل منا وجهة نظره، و أعتقد أن كلانا قد فهم وجهة نظر الآخر الآن.

حسب ما ذكرت في مشاركاتي السابقة، أصبح نقل النطاق ممكنا إذا لم يقم الـregistrar الأصلي برفض طلب النقل صراحة، أي أن عدم الإيجابة هو موافقة ضمنية، هذا التغيير أصبح ساري المفعول منذ عام 2004، و الموضوع مشروح بالتفصيل على هذه الصفحة (أعتقد أن موقع Netcraft مصدر موثوق للمعلومات). بالمناسبة، وجدت أن تحليلي للحادثة يناقش على القوائم البريدية لـICANN، و يبدو أن المشاركين يجدون تحليلي ممكنا جدا: http://gnso.icann.org/mailing-lists/archives/ga/msg04407.html أعتقد أن هذا كافي بالنسبة لي لأقتنع أن تحليلي ممكن على أرض الواقع، لا داعي للتجريب و تناقل النطاقات بيننا :)

عملية نقل النطاق قد تستغرق أياما أو ساعات حسب تعاون الـregistrar الأصلي، لم أرد أخذ الحد الأدنى في تحليلي، لأنه أقل حدوثا من القيم الأعلى.

ولكن المهم هنا أن BulkRegister يرسل رسالة تنبيه إضافية إلى الحساب الذي يتم السحب منه، وتمكن هذه الرسالة مدير الحساب من رفض العملية، ولكن يبدو أن مدير الحساب لم ينتبه إليها في الوقت المناسب.

هذه هي النقطة التي أتحدث عنها، أعتقد أن BulkRegister أرسل رسالة فعلا ولكن لم ينتبه عليها مالك النطاق أو اعتبرت spam.

بعدين اللي بيعرف كلمة السر لحساب الموزع، بإمكانه أن يزيل قفل النطاق، يعني حتى لو كان مقفلا، فلن يكون هذا قادرا على حمايتهم

بالتأكيد، ولكن ما تظهره السجلات هو أن القفل كان مزال أصلا، و لذلك لا حاجة لمعرفة كلمة السر...

مرحبا الأيهم، تحليلك ممكن أيضا، ولكن بالنسبة لتغيير البريد الإلكتروني، يمكنك أن تلاحظ في هذه الصفحة: http://whois.webhosting.info/syria-news.com (صورة عنها هنا لأن الـcache سيتحدث قريبا حتما: http://aymanh.com/syria-news-com-whois-records?size=_original) أن عنوان البريد الإلكتروني صحيح و في الوقت نفسه فإن قفل النقل معطل، و بما أن عملية النقل ستحتاج عدة أيام (أكثر من 5على الأرجح) و على افتراض أن السجلات السابقة قد أخذت من أيام قليلة ماضية (لا أعرف تماما مدى قدمها)، لذلك لا أعتقد أن سارق النطاق قد تمكن من الحصول على كلمة السر، و إلا فإنه سيحتاج إلى أيام عديدة إضافية سيظهر فيها عنوان بريده ضمن السجلات بدلا من عنوان المالك الأصلي. المشكلة في هذه القضية كما ذكرت أنت، كثيرون يحاولون تضخيمها على أنها استهداف للموقع و سوريا، بينما في الواقع مثل هذه الأمور تحدث كتيرا و بشكل يومي، و سيريانيوز موقع ذو حركة مرتفعة جدا و هذا ما عرضه لهجمة سرقة نطاق برأيي، خاصة و أن قفل النطاق كان معطلا. شكرا لك بالمناسبة على المعلومات و المقال، سأحاول الحصول على الجريدة لقراءة رأيك بالتفصيل :)

لا أدري ماذا تقصد بكلمة المناسبة، هل تعني Authorization code؟ لأنه مطلوب في حالة TLDs أخرى مثل .org، أما .com فلا يحتاج إلى كلمات سر. أما بالنسبة للـRegistrar lock، ما قصدك بأن لا معنى له؟ الطريقة التي تحدثت عنها في موقعي أصبحت ممكنة منذ تغيير طريقة نقل transfer النطاقات في عام 2004، و التي أثارت جدلا في أوساط المهتمين بهذه المواضيع، خاصة بعد أن استغلت شركات النطاقات هذا التغيير لتسويق نفسها على أنها غير معرضة لمثل هذه المشاكل. على كل حال سأقتبس نصا من موقع سلطة النطاقات ICANN:

>Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer. In the event that a Transfer Contact listed in the Whois has not confirmed their request to transfer with the Registrar of Record and the Registrar of Record has not explicitly denied the transfer request, the default action will be that the Registrar of Record must allow the transfer to proceed. Upon denying a transfer request for any of the following reasons, the Registrar of Record must provide the Registered Name Holder and the potential Gaining Registrar with the reason for denial. The Registrar of Record may deny a transfer request only in the following specific instances: [...] 7. A domain name was already in “lock status” provided that the Registrar provides a readily accessible and reasonable means for the Registered Name Holder to remove the lock status.

> المصدر: http://icann.org/transfers/policy-12jul04.htm إذا فقفل النطاق Registrar lock هو طريقة مضمونة للتخلص من مشكلة ضرورة الرد على طلبات النقل بالرفض بدلا من المجازفة بنسيانها.

كتبت تحليلا لما أتوقع أنه جرى على موقعي: http://aymanh.com/syria-news-com-hijacked يبدو أنهم نسوا تفعيل الـTransfer lock، و أهملوا متابعة بريدهم الإلكتروني.

لا أستغرب أبدا وصول مرض أنفلونزا الطيور لعندنا، الحدود مع تركيا قريبة جدا و الطيور المهاجرة كثيرة، سمعت إشاعات قريبة مما سمعت بالمناسبة، إلا أن السياسة المتبعة عندنا ستستمر على ما يبدو بالصمت و التعتيم ثم النفي و هكذا.

خطوة ايجابية بعد التخبيص الي صار، بس اسا حقنا اكبر بكتير من هيك.

اخر مرة اتصلت مع خدمة الزبائن لشركتنا الحبيبة اريبا و سألت عن خدمة GPRS قالوا بانها غير متوفرة بعد، كان ذلك من حوالي الاسبوعين، هل حدثت اي تغييرات منذ ذلك الوقت؟ على اي حال، لست متفائلا بان تتوفر الخدمة بسعر معقول، او بشكل يمكن الاستفادة من الخدمة فعليا معه. بالمناسبة، خدمة MMS التي رافقتها حملة اعلامية كبيرة عند اطلاقها اقتصرت على الاتصال برقم معين، و طلب صورة او نغمة ليتم ارسالها لك، اي انك لا تستطيع ارسال رسائل MMS بل استقبالها من الشركة فقط، هذا بالاضافة للسعر المرتفع. لا ادري فيما اذا اصبحت خدمة MMS حقيقية الان (لا تهمني كثيرا)، ولكن خدمة GPRS من الممكن ان تكون رائعة و مفيدة جدا اذا توفرت بشكل صحيح. اما الكروت مسبقة الدفع، فقد وجدت بشكل اساسي لتستخدم من قبل السواح الذين يزورون البلد لفترة قصيرة، الا ان فترة التجديد القصيرة بشكل سخيف ادت الى اقتصار استخدامها على المواطنين عندنا، او السياح الذين لا يمانعون دفع مبالغ كبيرة و تغيير الرقم كل زيارة و لو كانت فواصل الزيارات شهرين او 3.

الموقع الانكليزي يستخدم ترميز iso-8859-1 لان القسم الاعظم من محتواه مكتوب بالانكليزية، اما اجزاء اخرى كـ http://meta.wikimedia.org و الذي يجري فيه التنسيق بين مختلف الاقسام و يحتاج لاستخدام مختلف اللغات، يستخدم utf-8. اما ظهور الاحرف العربية(وغيرها) بشكل صحيح على الموقع الانكليزي، فهو نتيجة استخدام HTML entities، التي اشرت لها في المقال. و هي على الرغم من انها تؤدي المطلوب، الا انها تأخذ مساحة تخزين اكبر بدلا من بايتين في يونيكود، كما ان تحرير هذه النصوص قد يكون اصعب (نتيجة لظهور التركيبة بدلا من الحرف الموافق) مقارنة مع استخدام يونيكود. حاول مثلا تعديل كلمة "العربية" على الموقع الانكليزي من خلال زر Edit (او view source) اعلى الصفحة، مقارنة مع تعديلها على Meta. مشكلة يونيكود هي عدم دعم جزء من البرامج له، الا ان استخدام يونيكود بشكل كامل اثناء تصميم البرنامج يجعل من اضافة دعم لغات غير لاتينية له امر ممكن او يسهل الامور كثيرا مقارنة مع استخدام ترميز احادي البايت.

ماذا تقصد بنص بالغ الجعلكة؟ :) الرمز بيونيكود يأخد بايتين، بينما يأخذ الرمز بايتا واحد في ترميزات مثل Windows 1256.

المشكلة مع الترميزات احادية البعد انه لا يمكن استخدام اكثر من مجموعة من الرموز (كالابجدية العربية و اليابانية) معا في نفس الصفحة، و هذا مطلب ضروري للمواقع متعددة اللغات، كموقع ويكيبيديا مثلا. المشكلة هنا قد تحدث عندما يغيير المستخدم يدويا ترميز صفحة الاستمارة، بحيث يستقبل البرنامج الذي يعالج البيانات المرسلة ترميزا غير الترميز المتوقع. او عندما يفترض البرنامج المعالج للبيانات ترميزا معينا، و في كلتا الحالتين، لا يمكن لوم يونيكود. في الواقع استخدام برامج تعتمد على يونيكود بشكل كامل يجعل تحقيق دعم مختلف اللغات امر اكثر سهولة، بدلا من افتراض ترميز معين و العمل على اساسه.

اذا كان مدير الاتصالات لا يريد تحقيق العدالة بين كل المشتركين لان توفير ميزة real IP لجزء قليل من المشتركين غير عادل، ما رأيه ان يوفر الميزة لجميع المشتركين مجانا و بشكل افتراضي كما هو الحال في دول العالم؟ او على الاقل توفريها لمن يريد مع رسم بسيط و بدون طلبات تعجيزية (كما كان الحال قبل قرار رفع الرسوم)، و ذلك اذا لم يمكن توفير الميزة للجميع لاسباب تقنية، كعدم توفر عناوين IP كافية، على الرغم من ان مؤسسة ارباحها بالمليارات (كما يفاخر المدير) يجب ان تكون قادرة على ذلك بسهولة. هل قصر الخدمة على مئات (او عشرات) بدلا من 8000 يحقق العدالة؟ هناك نقطة في غاية الاهمية يبدو انها تغيب عن ذهن الكثيرين عند الحديث عن real IP و هي ان الخدمة ليست فقط للاتصال الصوتي، هناك الكثير من الخدمات الاخرى الضرورية و الغير ممكن استخدامها بدون real IP، كـ Bittorrent مثلا، التي اصبحت شائعة جدا لتوزيع الاصدارات الجديدة من البرامج، و IRC كطريقة للحصول على الدعم الفني و المساعدة للكثير من البرامج، هذا بالاضافة لـFTP لنقل الملفات و POP3، IMAP، و SMTP لارسال و استقبال البريد الالكترني، اذ ان الاعتماد على الجمعية او الاتصالات في هذه الخدمة اصبح فكرة سيئة جدا، الا ان هذا موضوع اخر. اما موضوع حجب الاتصالات لاسباب امنية، من يريد استقبال او ارسال معلومات قادر على ذلك دون الاتصال الصوتي، و يكفي استخدام التشفير مع البريد الالكتروني المقدم من المزودين عندنا لنقل اي نوع من المعلومات (حتى الصوتية و المرئية) بكل سهولة و دون مقدرة اي احد سوى المستقبل على معرفة المحتوى. هل يعلم المدير ان برامج الاتصال الصوتي و الهاتفي لاتزال تعمل حتى الان؟ مع كل اجراءات المنع و الحجب، و ستبقى كذلك لما لم تتخذ المؤسسة اجراءات اكثر تعسفية بمنع كل المواقع باستثناء قائمة محددة... ان مثل هذه الاجراءات التعسفية تضر بسمعة سوريا في الخارج، عندما يظهر كل السوريين على انهم يستخدمون عنوان IP واحد، او لا يتمكنوا من استخدام ميزات كثيرة او المشاركة بمختلف النشاطات على الانترنت. ابحثوا عن real syrian ip مثلا في Google لتعرفوا قصدي.

اعتقد انه حتى اغلبية القادرين على دفع مبلغ 4000 ليرة كل شهر لن يتابعوا اشتراكهم، انا شخصيا ساشعر انني اسرق اذا دفعت 4000 ليرة مقابل ما هو امر مفروغ منه لتسمية الخدمة "انترنت" في بلاد العالم.