الیکسا کی سرفہرست سائٹس میں سے ایک (مرکزی دائرہ)، جسے HTTPS کے ذریعے محفوظ کیا گیا ہے، ذیلی ڈومینز (گرے) اور انحصار (سفید) کے ساتھ، جن میں کمزور ہیں (ڈیشڈ شیڈنگ)

آج کل، HTTPS محفوظ کنکشن کا آئیکن ایک معیاری اور یہاں تک کہ کسی بھی سنجیدہ سائٹ کا ایک ضروری وصف بن گیا ہے۔ اگر سند لاپتہ، تقریباً تمام حالیہ براؤزر ایک انتباہ دکھاتے ہیں۔ سائٹ سے کنکشن "محفوظ نہیں ہے" اور اس میں خفیہ معلومات کی منتقلی کی سفارش نہ کریں۔

لیکن یہ پتہ چلتا ہے کہ ایڈریس بار میں "لاک" کی موجودگی ہمیشہ تحفظ کی ضمانت نہیں دیتی۔ 10 سرکردہ سائٹس کی جانچ کر رہا ہے۔ درجہ بندی سے، Alexa نے ظاہر کیا کہ ان میں سے بہت سے SSL/TLS پروٹوکول میں، عام طور پر ذیلی ڈومینز یا انحصار کے ذریعے، اہم کمزوریوں کے تابع ہیں۔ مطالعہ کے مصنفین کے مطابق، جدید ویب ایپلی کیشنز کی پیچیدگی حملے کی سطح کو بہت زیادہ بڑھاتی ہے.

تحقیق کے نتائج

یہ مطالعہ یونیورسٹی آف وینس Ca' Foscari (اٹلی) اور ویانا ٹیکنیکل یونیورسٹی کے ماہرین نے کیا۔ وہ سیکیورٹی اور رازداری کے 40ویں IEEE سمپوزیم میں ایک تفصیلی رپورٹ پیش کریں گے، جو 20-22 مئی، 2019 کو سان فرانسسکو میں منعقد ہوگا۔

سب سے اوپر 10 Alexa کی فہرست HTTPS سائٹس اور 000 متعلقہ میزبانوں کی جانچ کی گئی۔ 90 میزبانوں پر کمزور کرپٹوگرافک کنفیگریشنز کا پتہ چلا، یعنی کل کا تقریباً 816%:

4818 MITM کے لیے کمزور
733 مکمل TLS ڈکرپشن کا شکار ہیں۔
912 جزوی TLS ڈکرپشن کے خطرے سے دوچار ہیں۔

898 سائٹس مکمل طور پر ہیکنگ کے لیے کھلی ہیں، یعنی وہ فریق ثالث کے اسکرپٹس کے انجیکشن کی اجازت دیتی ہیں، اور 977 سائٹس ناقص محفوظ شدہ صفحات سے مواد لوڈ کرتی ہیں جن کے ساتھ حملہ آور بات چیت کر سکتا ہے۔

محققین اس بات پر زور دیتے ہیں کہ 898 "مکمل طور پر سمجھوتہ کیے گئے" وسائل میں آن لائن اسٹورز، مالیاتی خدمات اور دیگر بڑی سائٹیں شامل ہیں۔ 660 میں سے 898 سائٹس کمزور میزبانوں سے بیرونی اسکرپٹ ڈاؤن لوڈ کرتی ہیں: یہ خطرے کا بنیادی ذریعہ ہے۔ مصنفین کے مطابق جدید ویب ایپلی کیشنز کی پیچیدگی حملے کی سطح کو بہت زیادہ بڑھا دیتی ہے۔

دیگر مسائل بھی پائے گئے: اجازت کے 10% فارموں میں معلومات کی محفوظ ترسیل میں دشواری ہے، جس سے پاس ورڈ لیک ہونے کا خطرہ ہے، 412 سائٹیں کوکیز کو روکنے اور سیشن ہائی جیکنگ کی اجازت دیتی ہیں، اور 543 سائٹس کوکی کی سالمیت (ذیلی ڈومینز کے ذریعے) پر حملوں کا نشانہ بنتی ہیں۔ .

مسئلہ یہ ہے کہ SSL/TLS پروٹوکول اور سافٹ ویئر میں حالیہ برسوں میں کئی کمزوریوں کی نشاندہی کی۔: POODLE (CVE-2014-3566)، BEAST (CVE-2011-3389)، جرم (CVE-2012-4929)، BREACH (CVE-2013-3587)، اور Heartbleed (CVE-2014-0160)۔ ان کے خلاف حفاظت کے لیے، سرور اور کلائنٹ کی طرف پرانے کمزور ورژنز کے استعمال سے بچنے کے لیے متعدد سیٹنگز درکار ہیں۔ لیکن یہ ایک غیر معمولی طریقہ کار ہے، کیونکہ اس طرح کی ترتیبات میں سائفرز اور پروٹوکولز کے ایک وسیع سیٹ سے انتخاب کرنا شامل ہے، جسے سمجھنا کافی مشکل ہے۔ یہ ہمیشہ واضح نہیں ہوتا ہے کہ کون سے سائفر سویٹس اور پروٹوکولز کو "کافی محفوظ" سمجھا جاتا ہے۔

منظور کردہ ترتیبات

تجویز کردہ HTTPS ترتیبات کی فہرست پر باضابطہ طور پر کوئی منظور شدہ اور متفق نہیں ہے۔ تو، موزیلا ایس ایس ایل کنفیگریشن جنریٹر تحفظ کی مطلوبہ سطح پر منحصر کئی ترتیب کے اختیارات پیش کرتا ہے۔ مثال کے طور پر، یہاں ایک nginx 1.14.0 سرور کے لیے تجویز کردہ ترتیبات ہیں:

جدید موڈ

پرانے معاون کلائنٹس: Windows 27، Edge، Opera 30، Safari 11، Android 7، اور Java 17 پر Firefox 9، Chrome 5.0، IE 8

server {
listen 80 default_server;
listen [::]:80 default_server;

# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;


# modern configuration. tweak to your needs.
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver <IP DNS resolver>;

....
}

درمیانے درجے کی حمایت

پرانے معاون کلائنٹس: Firefox 1, Chrome 1, IE 7, Opera 5, Safari 1, Windows XP IE8, Android 2.3, Java 7

server {
listen 80 default_server;
listen [::]:80 default_server;

# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /path/to/dhparam.pem;

# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver <IP DNS resolver>;

....
}

پرانا سہارا

پرانے معاون کلائنٹس: ونڈوز ایکس پی IE6، جاوا 6

server {
listen 80 default_server;
listen [::]:80 default_server;

# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /path/to/dhparam.pem;

# old configuration. tweak to your needs.
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP';
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver <IP DNS resolver>;

....
}

یہ تجویز کیا جاتا ہے کہ آپ ہمیشہ مکمل سائفر سویٹ اور OpenSSL کا تازہ ترین ورژن استعمال کریں۔ سرور کی ترتیبات میں سائفر سویٹ اس ترجیح کی وضاحت کرتا ہے جس میں وہ استعمال کیے جائیں گے، کلائنٹ کی ترتیبات پر منحصر ہے۔

تحقیق سے پتہ چلتا ہے کہ صرف HTTPS سرٹیفکیٹ انسٹال کرنا کافی نہیں ہے۔ "اگرچہ ہم کوکیز کو ہینڈل نہیں کرتے جیسا کہ ہم نے 2005 میں کیا تھا، اور 'مہذب TLS' عام ہو گیا ہے، یہ پتہ چلتا ہے کہ یہ بنیادی چیزیں حیرت انگیز طور پر بہت زیادہ مقبول سائٹس کو محفوظ کرنے کے لیے کافی نہیں ہیں،" کہنا کام کے مصنفین. سرور اور کلائنٹ کے درمیان چینل کو قابل اعتماد طریقے سے بچانے کے لیے، آپ کو اپنے اپنے ذیلی ڈومینز اور فریق ثالث میزبانوں کے بنیادی ڈھانچے کی احتیاط سے نگرانی کرنے کی ضرورت ہے جہاں سے سائٹ کے لیے مواد فراہم کیا جاتا ہے۔ ہو سکتا ہے کہ کسی فریق ثالث کمپنی سے آڈٹ کا آرڈر دینا سمجھ میں آئے جو معلومات کی حفاظت میں مہارت رکھتی ہو۔

ماخذ: www.habr.com

HTTPS ہمیشہ اتنا محفوظ نہیں ہوتا جتنا لگتا ہے۔ 5,5% HTTPS سائٹس میں کمزوریاں پائی گئیں۔

تحقیق کے نتائج

منظور کردہ ترتیبات

جدید موڈ

درمیانے درجے کی حمایت

پرانا سہارا