تبلیغات
وبلاگ شخصی رسول حسین زاده - امن کردن وب سایت با استفاده از SSL / TLS (در nginx) ...
وبلاگ شخصی رسول حسین زاده
مقالات متنوع
گروه طراحی قالب من گروه طراحی قالب من گروه طراحی قالب من گروه طراحی قالب من گروه طراحی قالب من
درباره وبلاگ


سلام دوستان عزیز
به وبلاگ خودتان خوش آمدید .
امیدوارم از این وبلاگ خوشتان آمده باشد
و ساعات خوشی را سپری کرده باشید .
در این وبلاگ مطالب متنوعی همچون
مقالات کامپیوتر ( اینترنت , شبکه
ویندوز , نرم افزار , سخت افزار
تحقیق های رشته کامپیوتر )
طنز , اس ام اس , مقالات علمی پزشکی
فلسفی ,تست های روانشناسی
تلفن همراه , عکس های جالب و ....
وجود دارد .
لطفا من را از نظرات خود بهرمند سازید .
با تشکر

r.hosseinzadeh89@yahoo.com

مدیر وبلاگ : رسول حسین زاده
نظرسنجی
نظر شما درمورد این وبلاگ چیست؟






خدمت رسانی از طریق 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/۲۰۰۹/۱۲/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 ۶۰۰ /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.class۱.server.ca.pem

سه دستور بالا، مستقیما ما را به مقصد می رساند. با کمک دستور زیر، هر سه فایل را به یک فایل تبدیل می کنیم.

sudo cat ~/ssl.crt sub.class۱.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:۱۰m;

بعد فایل virtual host خود را باز کنید. در این فایل تنها یک میزبان غیر SSL وجود دارد که در پورت ۸۰ قرار گرفته است. می خواهیم میزبان جدیدی در این فایل ایجاد کنیم که در پورت ۴۴۳ گوش می کند. بخش زیر را زیر سرور فعلی قرار دهید:

server {

listen ۴۴۳ 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 SSLv۳ TLSv۱ TLSv۱.۱ TLSv۱.۲;

ssl_ciphers ECDHE RSA AES۲۵۶ SHA۳۸۴:AES۲۵۶ SHA۲۵۶:RC۴: HIGH:!MD۵:!aNULL:!EDH:!AESGCM;

ssl_prefer_server_ciphers on;

ssl_ecdh_curve secp۵۲۱r۱;

}










نوع مطلب : اینترنت، 
برچسب ها : وب سایت، امن کردن وب سایت، SSL / TLS، امن کردن وب سایت با استفاده از SSL / TLS (در nginx)،
لینک های مرتبط :
رسول حسین زاده
چهارشنبه 22 آذر 1391
 
لبخندناراحتچشمک
نیشخندبغلسوال
قلبخجالتزبان
ماچتعجبعصبانی
عینکشیطانگریه
خندهقهقههخداحافظ
سبزقهرهورا
دستگلتفکر




پیوند روزانه
آمار وبلاگ
  • کل بازدید :
  • بازدید امروز :
  • بازدید دیروز :
  • بازدید این ماه :
  • بازدید ماه قبل :
  • تعداد نویسندگان :
  • تعداد کل پست ها :
  • آخرین بازدید :
  • آخرین بروز رسانی :
امکانات جانبی
آگهی رایگان - آگهی رایگان
به سایت ما خوش آمدید
نام و نام خانوادگی      
آدرس ایمیل      
کلیه حقوق این وبلاگ برای وبلاگ شخصی رسول حسین زاده محفوظ است