امن کردن وب‌سایت با استفاده از 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;
}
محمدرضا قربانی
تازه ها
پیشنهاد سردبیر
سید رضا صدرالحسینی در یادداشتی اختصاصی برای جام جم آنلاین مطرح کرد
جنگ تبلیغاتی رژیم صهیونیستی و تکرار حرف‌های بدون پشتوانه
در گفتگو با جام جم آنلاین مطرح شد
سناریوی رژیم صهیونیستی برای تحریک ترامپ
سید رضا صدرالحسینی در یادداشتی اختصاصی برای جام جم آنلاین مطرح کرد
