یکی از تکنولوژی هایی که برای ارتباط کدگذاری شده بین کلاینت و سرور از آن استفاده میشود، SSL (مخفف Secure Sockets Layer) است که امروزه از لحاظ تکنیکی به عنوان TLS (مخفف Transport Layer Security) شناخته میشود. اما این تفکر که استفاده از این تکنولوژی امنیت کامل را برقرار میکند اشتباه است. گاهی اوقات استفاده نادرست از SSL باعث میشود داده های اپلیکیشن شما هنگام انتقال روی شبکه دستکاری شود.
برای این که مطمئن شوید این اتفاق برای اپلیکیشن شما رخ نمیدهد، در این نوشته از بلاگ برنامه چی اشتباهات رایجی که در هنگام استفاده از SSL و HTTPS در اپلیکیشن اندروید به وجود می آید را بررسی میکنیم. همچنین درباره نگرانی هایی که برای استفاده از Public-Key Infrastructure یا PKI وجود دارد هم مطالبی گفته میشود. فهرست تیتر های این مقاله را میتوانید در کادر زیر مشاهده کنید.
برای این که مطمئن شوید این اتفاق برای اپلیکیشن شما رخ نمیدهد، در این نوشته از بلاگ برنامه چی اشتباهات رایجی که در هنگام استفاده از SSL و HTTPS در اپلیکیشن اندروید به وجود می آید را بررسی میکنیم. همچنین درباره نگرانی هایی که برای استفاده از Public-Key Infrastructure یا PKI وجود دارد هم مطالبی گفته میشود. فهرست تیتر های این مقاله را میتوانید در کادر زیر مشاهده کنید.
نحوه کار با SSL و HTTPS چگونه است؟
در یک سناریوی عادی برای استفاده از SSL، سرور با استفاده از یک گواهینامه که شامل کلید عمومی و کلید خصوصی است، کانفیگ میشود. وقتی که میخواهیم اطلاعات را بین کلاینت و سرور جابجا کنیم، سرور با استفاده از Public-Key Cryptography گواهینامه خود را رمز گذاری میکند تا ثابت کند که کلید خصوصی را در اختیار خودش دارد. یعنی کلید خصوصی و کلید عمومی یک جفت هماهنگ باهم هستند.
اما هرکسی میتواند گواهینامه و کلید خصوصی دلخواهی برای خودش بسازد. پس یک ارسال اطلاعات ساده (Handshake) هیچ چیزی را درباره هویت و اعتبار سرور ثابت نمیکند. به جز این مورد که سرور، کلید خصوصی هماهنگ با کلید عمومی گواهینامه را دارد. اما از کجا بدانیم این گواهینامه ها قابل اعتماد هستند یا نه و از کجا بدانیم باید از یک سرور خاص استفاده بکنیم یا نکنیم؟
یکی از راه حل های این مشکل، این است که کلاینت باید یک مجموعه از گواهینامه های قابل اعتماد را پیش خودش داشته باشد. اگر گواهینامه سرور در میان این مجموعه نبود، پس سرور غیر قابل اعتماد است و نباید از آن استفاده کنیم.
اما اگر کمی درباره این راه حل ساده فکر کنیم، متوجه میشویم اشکالاتی ممکن است برای پروژه ما به وجود بیاورد. سرور ها باید توانایی آپگرید شدن داشته و کلید های قدرتمند تری را در طول زمان استفاده کنند (به این عملیات Key Rotation گفته میشود). این کار، کلید عمومی موجود در گواهینامه سرور را تغییر میدهد و با یک کلید جدید جایگزین میکند. در این سناریو، کلاینت نیز باید به دلیل تغییرات کانفیگ سرور آپدیت شود تا بتواند ارتباط با سرور را حفظ کند. یعنی با هر بار تغییرات سرور، باید کلاینت را هم تغییر بدهیم و این کار، راه حل مناسبی نیست.
این مشکل زمانی جدی تر میشود که سرور تحت کنترل توسعه دهنده اپلیکیشن نباشد. مثلا از یک وب سرویس (سرور) دیگر برای اپلیکیشن خودمان استفاده کرده باشیم. در این حالت، ممکن است سرور بدون اطلاع توسعه دهنده تغییرات کانفیگ داشته باشد و ارتباط اپلیکیشن ما با سرور قطع شود. این قطعی میتواند بسیاری از مشکلات بزرگ و کوچک برای ما به وجود بیاورد.
برای حل این مشکل، سرور ها معمولا با استفاده از گواهینامه هایی که توسط صادر کننده های معروف و معتبر تولید شده اند، کانفیگ میشوند. به این صادر کننده ها Certificate Authorities یا CA گفته میشود. معمولا پلتفرم های میزبان (همان کلاینت ها) یک لیست از CA های قابل اعتماد درون خود دارند. کلاینت ها از این لیست برای اعتبار سنجی هویت سرور ها استفاده میکنند. بعد از اندروید 8.0 (Noughat)، سیستم عامل اندروید بیش از 100 عدد CA را درون خود لیست کرده که با هر نسخه جدید، به روز رسانی میشوند و از دستگاهی به دستگاه دیگر تغییر نمیکنند.
در حقیقت CA شبیه یک سرور عمل میکند. یعنی CA یک گواهینامه و یک کلید خصوصی برای خودش دارد. وقتی که گواهینامه ای برای یک سرور صادر میشود، CA با استفاده از کلید خصوصی خودش این گواهینامه را رمزگذاری میکند. سپس همین گواهینامه برای کلاینت ارسال خواهد شد. بعد از این کار کلاینت میتواند تایید کند که گواهینامه سرور از طرف یکی از CA های مورد اعتماد خودش صادر شده است.
بعضی وقت ها استفاده از CA مشکلات جدیدی به پروژه ما اضافه میکند. چون معمولا CA ها گواهینامه های زیادی برای سرور های مختلف صادر میکنند، ممکن است اشتباهاتی در ارتباط با سرور ها به وجود بیاید. برای اینکه مطمئن شویم با سرور مورد نظر خودمان ارتباط برقرار کردیم باید یک سری کارهای دیگر هم انجام بدهیم. برای حل این مشکل گواهینامه ای که توسط CA صادر شده است، سرور را با یک نام خاص مانند barnamechi.com یا ساب دامنه هایی مانند *.barnamechi.com تعریف میکند.
مثال زیر شاید این روند را مقداری روشن تر کند. تکه کد زیر با استفاده از ابزار openssl و دستور s_client اطلاعات گواهینامه سایت ویکی پدیا را دریافت میکند. اگر به کد دقت کنید، پورت 443 استفاده شده است. زیرا پورت پیشفرض پروتکل HTTPS است. این دستور، خروجی openssl s_client را به opensl x509 ارسال میکند. این دستور اطلاعات مربوط به گواهینامه ها را با استاندارد X.509 فرمت میکند. علاوه بر اینها، این دستورات برای subject درخواست ارسال میکنند، متغیر subject اطلاعات نام سرور را درون خود نگهداری میکند. متغیر issuer هم CA را درون خود ذخیره کرده است.
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
میتوانید مشاهده کنید که گواهینامه سرور های *.wikipedia.com توسط RapidSSL CA صادر شده اند.
یک مثال برای HTTPS
فرض کنید ما یک سرور اینترنتی با گواهینامه ای که از یک CA شناخته شده صادر شده است، داریم. شما میتوانید با یک تکه کد مانند زیر، به راحتی با این سرور ارتباط برقرار کنید.
URL url = new URL("https://wikipedia.org");
URLConnection urlConnection = url.openConnection();
InputStream in = urlConnection.getInputStream();
copyInputStreamToOutputStream(in, System.out);
بله، برقراری ارتباط با HTTPS همینقدر ساده است. اگر میخواهید از پروتکل HTTP استفاده کنید، میتوانید کلاس HttpURLConnection را به کار ببرید. البته شما باید برای ارسال درخواست های مختلف از طریق این کلاس و مدیریت ارتباط با سرور، خودتان جستجو کنید یا داکیومنتیشن های رسمی اندروید را بخوانید.
یک نکته مهم که درباره جزئیات تایید گواهینامه ها و نام هاست ها باید بدانید این است که همه کارهای ارتباط با سرور و تایید گواهینامه ها بصورت اتوماتیک توسط سیستم عامل اندروید با استفاده از API های خاص خودش انجام میشود. پس نیازی نیست برای مرحله های ریز و جزئی این روند نگرانی داشته باشید. در ادامه تعدادی دیگر از ملاحظاتی که باید در نظر گرفته بشوند را مشاهده میکنیم.
اشکالات رایج در تایید گواهینامه های سرور
متد getInputStream جریان ورودی محتوای اپلیکیشن را به ما برمیگرداند که میتوانیم همه عملیات هایی که نیاز داریم را روی این داده های دریافتی انجام بدهیم. اما فرض کنید از این متد برای دریافت اطلاعات از یک سرور استفاده کنیم ولی به جای دریافت محتوا از getInputStream یک exception مانند زیر در اپلیکیشن پرتاب شود:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
at org.apache.harmony.xnet.provider.jsse.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:374)
at libcore.net.http.HttpConnection.setupSecureSocket(HttpConnection.java:209)
at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.makeSslConnection(HttpsURLConnectionImpl.java:478)
at libcore.net.http.HttpsURLConnectionImpl$HttpsEngine.connect(HttpsURLConnectionImpl.java:433)
at libcore.net.http.HttpEngine.sendSocketRequest(HttpEngine.java:290)
at libcore.net.http.HttpEngine.sendRequest(HttpEngine.java:240)
at libcore.net.http.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:282)
at libcore.net.http.HttpURLConnectionImpl.getInputStream(HttpURLConnectionImpl.java:177)
at libcore.net.http.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:271)
این خطا میتواند چند دلیل داشته باشد:
- گواهینامه سرور از طرف یک CA ناشناخته صادر شده است.
- گواهینامه سرور توسط یک CA کدگذاری نشده، بصورت شخصی کدگذاری شده است.
- کانفیگ سیستم فاقد یک CA میانی است.
در بخش های بعدی راه حل هرکدام از این مشکلات را با هم بررسی میکنیم تا بتوانیم مشکل را حل کرده و همچنان ارتباط اپلیکیشن و سرور را ایمن نگه داریم.
مشکل اول: گواهینامه ناشناس
در این حالت، SSLHandshakeException اتفاق می افتد. زیرا CA شما توسط سیستم شناخته شده نیست. معمولا دلیل این مشکل این است که شما از یک CA جدید استفاده میکنید که هنوز توسط سیستم عامل اندروید شناخته نشده است. همچنین امکان دارد که سرور شما از نسخه های قدیمی باشد که فاقد CA هستند. بیشتر اوقات CA ها به این دلیل ناشناخته هستند که بصورت عمومی عرضه نشده اند. این گونه موارد توسط دولت ها، شرکت ها یا موسسه های آموزشی برای مصارف درونی خودشان تولید میشوند.
خوشبختانه برای این مشکل راه حل وجود دارد. شما میتوانید با تنظیم کردن Network Security Config به اپلیکیشن خودتان یاد بدهید که به یک CA خاص اعتماد کند. انجام دادن این کار نیازی به تغییرات در کدهای اپلیکیشن شما ندارد.
هشدار: بسیاری از وبسایت ها از یک راه حل جایگزین ضعیف استفاده میکنند. این راه حل، نصب یک TrustManager است که در حقیقت کار خاصی نمیکند. اگر شما این کار را بکنید احتمالا باید قید کدگذاری ارتباطات خودتان را بزنید. زیرا هر کسی میتواند با استفاده از یک شبکه عمومی WiFi و انجام حقه های DNS، به کاربران شما حمله کرده و ترافیک آنها را از طریق پروکسی به سرورهای خودش منتقل کند در حالیکه وانمود میکند اطلاعات به سرور شما منتقل میشوند. بعد از اینکار حمله کننده ها میتوانند اطلاعات حساس مانند رمز های عبور و دیگر اطلاعات شخصی را ضبط کنند.
این کار کاملا امکان پذیر است. زیرا حمله کننده ها میتوانند یک گواهینامه تولید کنند و اپلیکیشن شما با استفاده از این گواهینامه های جعلی، ممکن است با هرکسی ارتباط برقرار کند (در صورتی که اگر TrustManager وجود نداشت، اپلیکیشن بررسی میکرد که گواهینامه از طرف منبع معتبری صادر شده است یا نه). پس هیچوقت، حتی بصورت موقت، این کار را انجام ندهید. شما همیشه میتوانید کاری کنید که اپلیکیشن به صادر کننده های معتبر گواهینامه اعتماد کند، و بهتر است همیشه همین کار را انجام بدهید.
مشکل دوم: گواهینامه های شخصی یا self-signed
مورد دیگری که میتواند باعث به وجود آمدن SSLHandshakeException شود، گواهینامه های self-signed هستند. یعنی گواهینامه هایی که ممکن است خود برنامه نویس آنها را به وجود بیاورد و در هیچ مرجع معتبری ثبت نشده باشد.
اگر دقیق تر به این موضوع کنید، در این حالت سرور خودش به عنوان CA صادر کننده گواهینامه برای خودش عمل میکند. پس یعنی شرایط دقیقا مانند گزینه قبلی، یعنی وجود یک CA ناشناخته میباشد. بنابراین میتوانید از راه حل بخش قبلی برای این مورد استفاده کنید. برای اینکه به اپلیکیشن یاد بدهید به گواهینامه ای که خودتان تولید کرده اید اعتماد کند، میتوانید Network Security Config اپلیکیشن خودتان را تنظیم کنید.
مشکل سوم: نبودن CA میانی
سومین مشکلی که باعث به وجود آمدن SSLHandshakeException میشود، نبودن یک CA میانی میباشد. بیشتر CA های عمومی گواهینامه های سرور را به صورت مستقیم کدگذاری نمیکنند. به جای این کار، آنها از گواهینامه CA اصلی خودشان که به نام root CA شناخته میشود برای کدگذاری CA های میانی استفاده میکنند. دلیل انجام این کار این است که root CA میتواند به صورت آفلاین ذخیره شود و خطرات احتمالی را کاهش بدهد.
اکثر سیستم عامل ها مانند اندروید، معمولا فقط به همین root CA بصورت مستقیم اعتماد میکنند. این کار باعث به وجود آمدن یک شکاف کوچک بین گواهینامه سرور (که توسط CA میانی کدگذاری شده) و تایید کننده گواهینامه میشود که همان root CA است. برای حل این مشکل، سرور در طول عملیات SSL Handshake فقط گواهینامه خودش را برای کلاینت ارسال نمیکند، بلکه یک زنجیره از گواهینامه ها از CA سرور تا همه CA های میانی که برای رسیدن به یک root CA قابل اعتماد مورد نیاز هستند را ارسال میکند.
برای اینکه دقیقا متوجه بشوید در واقعیت چه اتفاقی رخ میدهد، میتوانید زنجیره گواهینامه های وبسایت را با استفاده از دستور openssl s_client مشاهده کنید.
$ openssl s_client -connect mail.google.com:443 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=mail.google.com i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority ---
همانطور که در این مثال مشخص است، سرور یک گواهینامه را برای mail.google.com ارسال میکند که توسط Thawte SGC CA (یک CA میانی) صادر شده است. یک گواهینامه دوم هم برای برای Thawte SGC CA توسط Verisign CA (یک CA اولیه که برای اندروید قابل اعتماد است) صادر شده است.
اما با همه این توضیحات، خیلی اوقات سرور ها اینطور کانفیگ میشوند که فاقد CA میانی باشند. به عنوان مثال، در ادامه یک سرور را مشاهده میکنید که میتواند باعث به وجود آمدن ارور در مرورگر اندروید یا Exception در اپلیکیشن های اندروید بشود.
$ openssl s_client -connect egov.uscis.gov:443 --- Certificate chain 0 s:/C=US/ST=District Of Columbia/L=Washington/O=U.S. Department of Homeland Security/OU=United States Citizenship and Immigration Services/OU=Terms of use at www.verisign.com/rpa (c)05/CN=egov.uscis.gov i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3 ---
یک نکته جالب برای این سرور ها وجود دارد. مشاهده این وبسایت ها از طریق مرورگر های دسکتاپ باعث به وجود آمدن ارور هایی مانند “یک CA ناشناخته” یا “کدگذاری شده بصورت شخصی” نمیشود. دلیل این اتفاق است که بیشتر مرورگر های دسکتاپ، CA های میانی مورد اعتماد را در طول زمان ذخیره (کش) میکنند. یعنی وقتی که مرورگر وارد یک وبسایت میشود و درباره یک CA میانی اطلاعات را ذخیره میکند، برای دفعه های بعدی (و حتی سایت های دیگر) نیاز به CA میانی در زنجیره گواهینامه های سرور ندارد.
بعضی از وبسایت ها این کار را برای وب سرور های دوم، که وظیفه تامین منابع را دارند، انجام میدهند. مثلا، فرض کنید یک سایت صفحه اول خودش که با HTML نوشته شده است را روی یک سرور با زنجیره گواهینامه کامل قرار داده است. اما برای منابع دیگر مانند تصاویر، ویدئو ها و فایل های CSS، از سرور دومی استفاده میکند که در CA وجود ندارند (معمولا این کار برای صرفه جویی در ترافیک وبسایت انجام میشود). گاهی اوقات این سرور های دوم ممکن است وب سرویس هایی را ارائه بدهند که شما سعی دارید با استفاده از اپلیکیشن اندروید خودتان به آنها متصل بشوید. اینجاست که ارور اتفاق می افتد.
برای حل این مشکل، باید سرور را طوری کانفیگ کنید که CA میانی را درون زنجیره سرور قرار بدهد. بیشتر CA ها داکیومنتیشن هایی دارند که نحوه انجام این کار را به شما آموزش میدهند.
هشدار درباره استفاده SSLSocket بصورت مستقیم
تا اینجای کار، درباره استفاده از HTTPS توسط کلاس HttpsURLConnection صحبت کردیم. گاهی اوقات اپلیکیشن ما نیاز دارد که از SSL و HTTPS بصورت جداگانه استفاده کند. به عنوان مثال اپلیکیشن ایمیل ممکن است از انواع SMTP، POP3 یا IMAP برای SSL استفاده کند. در این سناریو ها، اپلیکیشن ممکن است نیاز داشته باشد که بصورت مستقیم از SSLSocket استفاده کند. یعنی همان کاری که درون کلاس HttpsURLConnection اتفاق می افتد، اما این بار با HTTPS کاری ندارد.
تکنیک هایی که تا اینجا برای سر و کله زدن با مسائل و مشکلات تایید گواهینامه گفتیم، در مورد SSLSocket نیز قابل استفاده هستند. در حقیقت وقتی که از TrustManager استفاده میکنیم، چیزی که به HttpsURLConnection ارسال میشود، یک آبجکت از SSLSocketFactory است. یعنی اگر میخواهید یک TrustManager شخصی سازی شده را به همراه یک SSLSocket به کار ببرید، همان مراحلی که برای استفاده از SSLSocketFactory انجام میدهید را برای ساخت SSLSocket دوباره انجام بدهید.
هشدار: کلاس SSLSocket تایید نام هاست را انجام نمیدهد. این وظیفه به عهده اپلیکیشن شما میباشد که میتوانید با صدا زدن متد getDefaultHostnameVerifier برای نام هاست مورد نظر، این کار را پیش ببرید. این نکته را هم در نظر داشته باشید که HostnameVerifier.verify هیچ ارور یا Exception خاصی ایجاد نمیکند. به جای آن یک مقدار Boolean برمیگرداند که باید خودتان آن را چک کنید.
Denylist کردن
تعریف Denylisting: این مفهوم یک مکانیزم پایه ای برای کنترل دسترسی است که به همه المنت ها اجازه دسترسی به شبکه را میدهد، به جز آن مواردی که بصورت صریح در لیست با عنوان “deny” تعریف شده باشند. همه آیتم هایی که در لیست Deny باشند از دسترسی به شبکه محروم میشوند.
SSL کاملا به CA ها در مورد صادر کردن گواهینامه برای صاحبان معتبر سرور ها و دامین ها تکیه میکند. در یک سری موارد کمیاب، CA ها فریب خورده یا هک میشوند (مانند Comodo و DigiNotar). نتیجه این اتفاق اینطور میشود که گواهینامه های یک hostname برای افرادی غیر از صاحبان سرور ها و دامنه ها صادر میشوند.
برای کم کردن این ریسک امنیتی، اندروید این قابلیت را دارد که گواهینامه های قطعی یا حتی کل CA هایی که ایراد دارند را به یک Denylist اضافه کند. این لیست از ابتدا درون اندروید وجود داشته است اما بعد از اندروید 4.2 میتوانید این لیست را از راه دور کنترل کنید که ریسک خطرات احتمالی بعدی را نیز کاهش بدهید.
Pin کردن
هشدار: Pin کردن گواهینامه ها در اپلیکیشن اندروید اصلا پیشنهاد نمیشود. زیرا ممکن است کانفیگ سرور در آینده تغییر پیدا کند. در این حالت اپلیکیشن بدون آپدیت شدن نمیتواند با سرور ارتباط برقرار کند.
اگر میخواهید اپلیکیشن خودتان را Pin کنید، داشتن چند Pin مختلف بصورت بکاپ بسیار ضروری است. دقت کنید که حتما یکی از این کلید ها باید کاملا تحت کنترل خودتان باشد و یک دوره انقضای کوتاه برای جلوگیری از به وجود آمدن مشکلات در اپلیکیشن. میتوانید از Network Security Config برای Pin کردن با این ویژگی ها استفاده کنید.
گواهینامه های کلاینت
این مقاله روی ایمن سازی ارتباط بین کاربر SSL و سرور تمرکز داشت. اما SSL همچنین از گواهینامه های کلاینت پشتیبانی میکند که با استفاده از آنها، سرور میتواند هویت یک کلاینت را تایید کند. هرچند این کار از بحث های مربوط به این مقاله خارج است، ولی برای این کار میتوانید از تکنیک های ساخت یک TrustManager شخصی سازی شده استفاده کنید.
ابزار Nogotofail برای تست امنیت ترافیک شبکه
Nogotofail ابزاری است که با استفاده از آن میتوانید به راحتی بررسی کنید که اپلیکیشن شما در برابر خطرات شناخته شده و پیکربندی های اشتباه TLS/SSL ایمن هست یا نه. Nogotofail یک ابزار اتوماتیک، قدرتمند و مقیاس پذیر برای تست کردن اشکالات شبکه روی هر دستگاهی که ترافیک از آن عبور میکند میباشد. این ابزار برای سه کاربرد اصلی زیر به کار میرود:
- پیدا کردن باگ ها و آسیب پذیری ها
- تایید تعمیرات انجام شده و نظارت برای برگشت نتیجه
- فهمیدن اینکه کدام اپلیکیشن و کدام دستگاه در حال تولید کدام ترافیک روی شبکه است
Nogotofail روی اندروید، لینوکس، iOS، ویندوز، Chrome OS و OSX یا در حقیقت هر دستگاهی که به اینترنت متصل میشود قابل استفاده است. همچنین یک کلاینت ساده برای کانفیگ کردن تنظیمات و دریافت ناتیفیکشن روی اندروید و لینوکس وجود دارد. همچنین Attack Engine آن میتواند به تنهایی به عنوان یک روتر، سرور VPN یا پراکسی به کار برده شود.
سوالی دارید؟
در این مقاله درباره امنیت در استفاده از SSL و HTTPS در اپلیکیشن های اندروید، و همچنین مشکلات رایجی که ممکن است در این راه برای ما به وجود بیاید صحبت کردیم. اگر سوالی در ذهن شما وجود دارد یا میتوانید نکته دیگری به این نوشته اضافه کنید، آن را در قسمت نظرات (همین پایین) بنویسید تا این مقاله آموزشی را کامل تر کنید.
منابع بیشتر برای مطالعه
میتوانید از منابع زیر برای مطالعه بیشتر درباره HTTPS و SSL استفاده کنید:
خیلی ممنون از توضیحاتتون. واقعا در مورد ssl ها ابهام داشتم، مطالب بالا خیلی کمک کرد
سلام دوست عزیز.
ممنونم از نظر خوبتون و خوشحالم که براتون مفید بوده