امن كردن وب‌سايت با استفاده از SSL‌/‌TLS (در nginx)

 

خدمت‌رساني از طريق HTTPS به اين معني نيست كه ترافيك داده‌ها رمزگذاري شده‌ است، رمزگذاري تنها نيمي از ماجراست و بدون احراز هويت بي‌فايده خواهد بود. اگر رمزگذاري بين دوطرف انجام شود اما ندانيم طرف ديگر چه كسي است، چه اهميتي دارد؟ بنابراين براي استفاده از ترافيك HTTPS بايد مدركي رمزبندي‌شده داشته باشيم تا هويتمان را نشان دهد. دريافت چنين مدركي مستلزم اين است كه هويت وب‌سايت توسط يكي از Certificate Authorityها تائيد شود.ظاهر امر، ترسناك‌تر از كاري است كه بايد انجام دهيم. بيشتر CAهاي مشهور براي احراز هويت و اهداي گواهي هزاران دلار پول درخواست مي‌كنند. اگر كار وب‌سايت شامل e-commerce هم مي‌شود، شايد منطقي باشد كه براي دريافت آن گواهي اقدام كرد، اما اگر سايت كوچكي است يا واقعا هزاران دلار پول نداريم، چنين خرجي نه منطقي است و نه لازم.

SSL‌/‌TLS به‌طور خلاصه

SSL مخفف عبارت Secure Sockets Layer است. هر چند خود SSL امروزه كمتر استفاده مي‌شود و به‌جاي آن روش پيچيده‌تر و امن‌تري به نام Transport Layer Security مورد استفاده قرار مي‌‌گيرد. عبارت SSL بيشتر به‌ اين دليل استفاده مي‌شود كه شناخته شده است و در طول اين مقاله، از اين مبحث با نام SSL‌/‌TLS ياد خواهيم كرد.SSL‌/‌TLS تركيبي از فناوري‌هاي مختلف است اما روش كاركرد آن، مشابه همان مفهوم كليدهاي رمزگذاري عمومي و خصوصي است. يك سرور وب، يك جفت كليد عمومي و خصوصي توليد مي‌كند. وقتي كلاينت مي‌خواهد يك Session از نوع HTTPS ايجاد كند، گواهي سرور را درخواست مي‌كند. اين اقدام از طريق يكي از مقامات تحت وب مدارك انجام مي‌شود تا آدرس درخواستي معتبر شود و نشان دهد گواهي دارنده وب‌سايت منقضي يا باطل نشده باشد. (در اين زمان است كه بيشتر هشدارهاي مرورگرها نشان داده مي‌شود؛ چرا كه مرورگر در اين مرحله است كه تصميم مي‌گيرد مدرك گواهي وب‌سايت را قبول كند يا نه.)كلاينت سپس آيتم رمزگذاري‌شده‌اي را با عنوان pre-master secret انتخاب و آن را با كليد عمومي سرور رمزگذاري مي‌كند و به سمت سرور مي‌فرستد. به‌دليل طبيعت رمزگذاري كليدهاي عمومي، چيزي كه با كليد عمومي رمزگذاري شده باشد، تنها از طريق كليدهاي خصوصي مرتبط با آن مي‌تواند خوانده شود. اگر سرور بتواند pre-master secret را رمزگشايي كند، در نتيجه كليد خصوصي فعلي در اختيار سرور است و ارتباط برقرار مي‌شود.رمزگشايي غيرهمزمان (Asymmetric) كند است و سرور و كلاينت خيلي از آن استفاده نخواهد كرد. در حقيقت آنها از سري مراحلي پيروي كرده كه pre-master secret را بهmaster secret تبديل مي‌كند و در نتيجه يك كليد Session توليد مي‌شود. اين كليدي همزمان است كه براي رمزگذاري و رمزگشايي در دو طرف ارتباط استفاده مي‌شود.

آيا به مدركي واقعي نياز داريم؟

براي خدمت‌رساني از طريق HTTPS به يك مدرك توليدشده از سوي CAها نيازي نداريم. هرچند داشتن يك مدرك واقعي (به‌جاي آن كه خودمان توليد كرده‌ايم) مي‌تواند هشداري را كه كاربران هنگام باز كردن صفحه مي‌بينند، حذف كند. (هشداري كه ممكن است كاربران را فراري بدهد.)استفاده از مدارك خودامضا و خودتوليد براي تست و استفاده‌ در سايت‌هاي داخلي كار صحيحي است، اما استفاده از همين مدارك در فضاي اينترنت نه‌تنها مفيد نيست بلكه يكي از دو مولفه اصلي استفاده از HTTPS را زير سوال مي‌برد. مدركي كه توسط يك CA شناخته شده امضا شود به‌اين معني است كه شما (وب‌سايت) همان كسي هستيد كه خود را معرفي مي‌كنيد. حتي مهم‌تر از آن، وب‌سايت‌هاي اينچنيني بيشتر در معرض خطر تهديد قرار خواهد گرفت؛ زيرا كاربران بسادگي آنها را رد خواهد كرد. بنابراين، بله، به مدرك واقعي نياز داريم.

انواع مدارك

CAهاي مختلف، مدارك مختلفي عرضه مي‌كنند و معمولا براي كلاس‌هاي بالاتر، هزينه‌هاي بيشتري دارند. اما تقريبا در همه موارد، ميزان رمزبندي اين مدرك برابر است و ميزان كارهايي كه براي معتبرسازي صفحه انجام مي‌شود، متفاوت خواهد بود.وقتي به سايت‌هاي مختلف CA سر بزنيم، متوجه خواهيم شد رفرنس‌هايي به كلاس 1/2 يا 3 داده مي‌شود. همچنين مداركي با عنوان‌هاي wildcard يا extended نيز وجود دارد. هر چند از نظر قدرت كليد رمزبندي، كلاس1 از كلاس2 امن‌تر نيست، اما كلاس2 به‌دليل مرحله معتبرسازي هويت، كمي مطمئن‌تر است. بسته به عرضه كننده SSL، كلاس‌هاي مختلف زيادي وجود خواهد داشت.مدرك extended validation يا EV به يك استاندارد تبديل شده است و در مرورگرهاي مدرن، به شيوه بهتري نشان داده مي‌شود و به رنگ سبز خواهد بود.مدارك EV را معمولا خود CAها در وب‌سايت‌هايشان استفاده مي‌كنند. وب‌سايت‌هايي كه مستقيما براي خريد و فروش استفاده مي‌شود نيز معمولا از EV استفاده مي‌كنند. اين نوع مدارك از بقيه گران‌تر بوده و دريافت ‌آنها نيز بسيار دشوار است؛ زيرا كارهاي زيادي براي احراز هويت وب‌سايت انجام مي‌شود.اما وب‌سايت‌هاي معمولي نيازي به EV ندارند. حتي افزونه‌هايي كه اغلب CAها تبليغ مي‌كنند نيز الزامي نيست.به مدارك wildcart (نوع خاصي از SSL‌/‌TLS كه براي سرورهاي مختلف در يك دومين استفاده مي‌شود) نيز نيازي نيست. در حقيقت براي يك وب‌سايت شخصي بجز يك مدرك ساده SSL‌/‌TLS به چيز ديگري نياز نداريم.براي دريافت يك مدرك SSL‌/‌TLS، به يك چيز نياز داريم. سرور وب بايد نام داشته باشد. نام سرور چيزي است كه به‌عنوان بخشي از هويت آن شناسايي خواهد شد. اگر دامنه.com يا.org را ثبت نكرده‌ايد، بايد ابتدا اين كار را انجام دهيم.سريع‌ترين كار براي ثبت آن، استفاده از گوگل است. گوگل با هزينه هشت دلار مي‌تواند اينترفيسي شبيه گوگل دراختيار كاربر قرار دهد و تا ده كاربر نيز مي‌تواند از آن استفاده كند.براي دريافت SSL‌ بعد از انجام كارهاي فوق، به نشاني زير برويد تا اطلاعات بيشتري از شيوه و چگونگي به دست آوردن مدرك SSL كسب كنيد:

http://arstechnica.com/security/2009/12/how-to-get-set-with-a-secure-sertificate-for-free/

بعد از اين كه كليد را به دست آورديد، با اجراي دستورهاي زير در سرور مي‌توانيم كليدها را به سرور وصل كنيم.

scp ssl.key yourname@webserver:~

scp ssl.crt yourname@webserver:~

در دستور بالا، فايل كليد با نام ssl.key و فايل مدرك با نام ssl.crt مشخص شده است. شناسه كاربري و نام سرور را در بخش webserver و username قرار دهيد.

بعد از اين كه كليد و مدرك كپي شد، بايد كليد را رمزگشايي كنيم. براي اين كار، دستور زير را اجرا كنيد:

sudo openssl rsa -in ssl.key -out /etc/nginx/conf/ssl.key

نخستين بار كه اين دستور اجرا مي‌شود، شناسه و رمز عبورتان درخواست مي‌شود. openssl يك كپي رمزگشايي شده از كليد خصوصي‌را در مسير ‌/‌etc‌/‌nginx‌/‌conf قرار مي‌دهد. (به‌همين دليل از sudo استفاده شد، چرا كه كاربر با دسترسي عادي نمي‌تواند فايل در آن محل قرار دهد)حفظ اين كليد بسيار مهم است، چرا كه پايه هويت سرور را تشكيل مي‌دهد و هر كسي به آن دست پيدا كند مي‌تواند از نظر رمزگذاري، هويت سرور را از آن خود كند. بنابراين بهتر است به Nginx و پروسس‌هاي آن دست پيدا كنند.

sudo chown www-data:www-data /etc/nginx/conf/ssl.key

sudo chmod 600 /etc/nginx/conf/ssl.key

دستور اول، فايل را در اختيار www-data قرار مي‌دهد. دستور دوم سطوح دسترسي آن را طوري تعيين مي‌كند كه تنها صاحب آن بتواند آن را خوانده يا در آن بنويسد.بعد بايد بايد مدارك intermediate و root را ازCA‌ دريافت كرده و آنها را با مدرك سرور يكي كنيم و در يك زنجير بزرگ‌تر قرار دهيم. اين موضوع علاوه بر اين‌كه درك هويت از سوي مرورگر را راحت‌تر مي‌كند، ساده‌ترين روش ممكن در پياده‌سازي گواهي SSL در Nginx هم هست.

cd /etc/nginx/conf

sudo wget http://www.startssl.com/certs/ca.pem

sudo wget http://www.startssl.com/certs/sub.class1.server.ca.pem

سه دستور بالا، مستقيما ما را به مقصد مي‌رساند. با كمك دستور زير، هر سه فايل را به يك فايل تبديل مي‌كنيم.

sudo cat ~/ssl.crt sub.class1.server.ca.pem ca.pem » /etc/nginx/conf/ssl-unified.crt

فايل‌هاي گواهي به‌صورت متني است و بسادگي با دستور cat آنها را يكي مي‌كنيم.

اتصال به nginx

حالا كه فايل‌هاي كليد را باز كرده و مدركمان آماده است، بايد به nginx بگوييم چطور از آنها استفاده كند. دو فايل را براي انجام اين كار بايد ويرايش كنيم. نخست فايل اصلي nginx.conf و بعد فايل Vitrual Host. اگر چند وب‌سايت و فايل Virtual Host داريد، بايد يكي يكي آنها را ويرايش كنيد. فرض مي‌گيريم تنها يك Virtual Host داريد.

فايل nginx.conf را باز كرده و دستور زير را در انتهاي آن وارد كنيد:‌

ssl_session_cache shared:SSL:10m;

بعد فايل virtual host خود را باز كنيد. در اين فايل تنها يك ميزبان غير SSL وجود دارد كه در پورت 80 قرار گرفته است. مي‌خواهيم ميزبان جديدي در اين فايل ايجاد كنيم كه در پورت 443 گوش مي‌كند. بخش زير را زير سرور فعلي قرار دهيد:

server {

listen 443 ssl;

root /usr/share/nginx/html;

index index.html index.htm;

server_name your-server-name;

ssl on;

ssl_certificate /etc/nginx/conf/ssl-unified.crt;

ssl_certificate_key /etc/nginx/conf/ssl.key;

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4: HIGH:!MD5:!aNULL:!EDH:!AESGCM;

ssl_prefer_server_ciphers on;

ssl_ecdh_curve secp521r1;

}






تاريخ : سه شنبه 21 آذر 1391برچسب:, | | نویسنده : مقدم |