|  
صفحه اصلی > فهرست مقالات > امنیت وب سایت با SSL / TLS (در nginx)
مقالات وب، شبکه
 

امنیت وب سایت با SSL / TLS (در nginx)

امنیت وب سایت با SSL / TLS خدمت رسانی از طریق 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 سر بزنیم، متوجه خواهیم شد رفرنس هایی به کلاس ۱/۲ یا ۳ داده می شود. همچنین مدارکی با عنوان های wildcard یا extended نیز وجود دارد. هر چند از نظر قدرت کلید رمزبندی، کلاس۱ از کلاس۲ امن تر نیست، اما کلاس۲ به دلیل مرحله معتبرسازی هویت، کمی مطمئن تر است. بسته به عرضه کننده 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 وجود دارد که در پورت ۸۰ قرار گرفته است. می خواهیم میزبان جدیدی در این فایل ایجاد کنیم که در پورت ۴۴۳ گوش می کند. بخش زیر را زیر سرور فعلی قرار دهید:

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;
}

منبع: http://www.aftabir.com
 
 
ارسال به دوستافزایش اندازه فونتکاهش اندازه فونت