مضمون انھن لاء مفيد ٿيندو جيڪي:
- ڄاڻي ٿو ڪلائنٽ سرٽيفڪيٽ ڇا آهي ۽ سمجهي ٿو ته ان کي موبائل سفاري تي ويب ساکٽس جي ضرورت ڇو آهي؛
- مان چاهيان ٿو ويب خدمتون شايع ڪرڻ چاهيان ٿو محدود حلقن جي ماڻهن تائين يا صرف پنهنجي لاءِ؛
- سوچي ٿو ته سڀ ڪجهه اڳ ۾ ئي ڪنهن ڪري چڪو آهي، ۽ دنيا کي ٿورو وڌيڪ آسان ۽ محفوظ بڻائڻ چاهي ٿو.
ويب ساکٽس جي تاريخ اٽڪل 8 سال اڳ شروع ٿي. اڳي، طريقا استعمال ڪيا ويا ڊگھي http درخواستن جي صورت ۾ (حقيقت ۾ جواب): صارف جي برائوزر سرور ڏانهن هڪ درخواست موڪلي ۽ ان کي ڪجهه جواب ڏيڻ جو انتظار ڪيو، جواب کان پوء اهو ٻيهر ڳنڍيو ۽ انتظار ڪيو. پر پوءِ ويب ساکٽ ظاهر ٿيا.
ڪجھ سال اڳ، اسان خالص PHP ۾ پنھنجو عمل درآمد ڪيو، جيڪو https جي درخواستن کي استعمال نٿو ڪري سگھي، ڇو ته ھي لنڪ پرت آھي. گهڻو وقت اڳ نه، تقريبن سڀني ويب سرورن کي سکيو پراکسي درخواستن تي https ۽ سپورٽ ڪنيڪشن: upgrade.
جڏهن اهو ٿيو، ويب ساکٽس SPA ايپليڪيشنن لاءِ لڳ ڀڳ ڊفالٽ سروس بڻجي وئي، ڇاڪاڻ ته سرور جي شروعات تي صارف کي مواد مهيا ڪرڻ ڪيترو آسان آهي (ٻي صارف کان پيغام منتقل ڪرڻ يا تصوير، دستاويز، پيشڪش جو نئون نسخو ڊائون لوڊ ڪريو. جيڪو هن وقت ڪو ٻيو ايڊٽ ڪري رهيو آهي).
جيتوڻيڪ ڪلائنٽ سرٽيفڪيٽ ڪافي عرصي کان موجود آهي، پر اهو اڃا تائين ناقص طور تي سهڪاري رهيو آهي، ڇاڪاڻ ته ان کي بائي پاس ڪرڻ جي ڪوشش ۾ تمام گهڻا مسئلا پيدا ٿين ٿا. ۽ (ممڪن طور تي :slightly_smiling_face: ) اهو ئي سبب آهي ته IOS برائوزر (سڀني سفاري کانسواءِ) ان کي استعمال ڪرڻ نٿا چاهين ۽ مقامي سرٽيفڪيٽ اسٽور کان ان جي درخواست ڪن ٿا. لاگ ان/پاس يا ssh ڪيز جي مقابلي ۾ سرٽيفڪيٽن جا ڪيترائي فائدا آھن يا ضروري بندرگاھن کي فائر وال ذريعي بند ڪرڻ. پر اهو نه آهي ته اهو ڇا آهي.
iOS تي، سرٽيفڪيٽ کي نصب ڪرڻ جو طريقو بلڪل سادو آهي (خاص طور تي نه)، پر عام طور تي اهو هدايتن جي مطابق ڪيو ويو آهي، جن مان انٽرنيٽ تي تمام گهڻو آهن ۽ جيڪي صرف سفاري برائوزر لاء موجود آهن. بدقسمتي سان، سفاري کي خبر ناهي ته ڪلائنٽ سرٽيفڪيشن ويب ساکٽس لاءِ ڪيئن استعمال ڪجي، پر انٽرنيٽ تي ڪيتريون ئي هدايتون آهن ته اهڙي سرٽيفڪيٽ ڪيئن ٺاهجي، پر عملي طور تي اهو حاصل ڪرڻ ناممڪن آهي.
Websockets کي سمجھڻ لاء، اسان ھيٺ ڏنل منصوبو استعمال ڪيو: مسئلو/مفروضو/حل.
مسئلو ويب ساکٽس لاءِ ڪو به سهڪار نه آهي جڏهن وسيلن ڏانهن درخواستن جي پروڪسنگ ڪئي وئي آهي جيڪي ڪلائنٽ سرٽيفڪيٽ طرفان محفوظ آهن سفاري موبائل برائوزر تي IOS ۽ ٻين ايپليڪيشنن لاءِ جيڪي سرٽيفڪيٽ سپورٽ کي فعال ڪيون آهن.
مفروضا:
- اهو ممڪن آهي ته اهڙي استثنا کي ترتيب ڏيڻ لاءِ سرٽيفڪيٽن کي استعمال ڪرڻ لاءِ (ڄاڻجي ته اتي ڪو به نه هوندو) اندروني/بيروني پراڪسائيڊ وسيلن جي ويب ساکٽس ۾.
- ويب ساکٽس لاءِ، توهان عارضي سيشن استعمال ڪندي هڪ منفرد، محفوظ ۽ دفاعي ڪنيڪشن ٺاهي سگهو ٿا جيڪي عام (غير ويب ساکٽ) برائوزر جي درخواست دوران ٺاهيا ويندا آهن.
- عارضي سيشن هڪ پراکسي ويب سرور استعمال ڪندي لاڳو ڪري سگھجن ٿا (صرف بلٽ ان ماڊلز ۽ افعال).
- عارضي سيشن ٽوڪن اڳ ۾ ئي تيار ڪيل اپاچي ماڊلز جي طور تي لاڳو ڪيا ويا آهن.
- عارضي سيشن ٽوڪن کي منطقي طور تي رابطي جي جوڙجڪ کي ترتيب ڏيڻ سان لاڳو ڪري سگهجي ٿو.
لاڳو ٿيڻ کان پوء ڏسڻ واري حالت.
ڪم جو مقصد: خدمتن ۽ انفراسٽرڪچر جو انتظام IOS تي موبائيل فون کان بغير اضافي پروگرامن (جهڙوڪ VPN)، متحد ۽ محفوظ هجڻ گهرجي.
اضافي مقصد: وقت ۽ وسيلن/فون ٽرئفڪ جي بچت (ڪجهه خدمتون بغير ويب ساکٽ جي غير ضروري درخواستون پيدا ڪن ٿيون) موبائيل انٽرنيٽ تي مواد جي تيز ترسيل سان.
ڪئين چيڪ ڪجي؟
1. کليل صفحا:
— например, https://teamcity.yourdomain.com в мобильном браузере Safari (доступен также в десктопной версии) — вызывает успешное подключение к веб-сокетам.
— например, https://teamcity.yourdomain.com/admin/admin.html?item=diagnostics&tab=webS…— показывает ping/pong.
— например, https://rancher.yourdomain.com/p/c-84bnv:p-vkszd/workload/deployment:danidb:ph…-> viewlogs — показывает логи контейнера.2. يا ڊولپر ڪنسول ۾:
مفروضو جاچ:
1. اهڙي استثناءَ کي ترتيب ڏيڻ ممڪن آهي سرٽيفڪيٽن کي استعمال ڪرڻ لاءِ (ڄاڻڻ ته اتي ڪو به نه هوندو) اندروني/بيروني پراڪسائيڊ وسيلن جي ويب ساکٽس تي.
2 حل هتي مليا آهن:
a) سطح تي
<Location sock*> SSLVerifyClient optional </Location>
<Location /> SSLVerifyClient require </Location>
رسائي جي سطح کي تبديل ڪريو.
هن طريقي ۾ هيٺيان nuances آهن:
- سرٽيفڪيٽ جي تصديق ٿيندي آهي هڪ درخواست کان پوءِ پراڪسائيڊ وسيلن جي، يعني پوسٽ جي درخواست هٿ ملائڻ. هن جو مطلب اهو آهي ته پراکسي پهريون ڀيرو لوڊ ڪندي ۽ پوء محفوظ ڪيل خدمت جي درخواست کي ڪٽيندو. هي خراب آهي، پر نازڪ ناهي؛
- http2 پروٽوڪول ۾. اهو اڃا مسودو ۾ آهي، ۽ برائوزر ٺاهيندڙن کي خبر ناهي ته ان کي ڪيئن لاڳو ڪجي #info about tls1.3 http2 پوسٽ هينڊ شيڪ (هاڻي ڪم نه ڪري رهيو آهي) ;
- اهو واضح ناهي ته هن پروسيسنگ کي ڪيئن متحد ڪجي.
ب) بنيادي سطح تي، اجازت ڏيو ssl بغير سرٽيفڪيٽ.
SSLVerifyClient جي ضرورت آهي => SSLVerifyClient اختياري، پر هي پراکسي سرور جي حفاظتي سطح کي گھٽائي ٿو، ڇو ته اهڙي ڪنيڪشن کي بغير سرٽيفڪيٽ جي پروسيس ڪيو ويندو. تنهن هوندي، توهان هيٺ ڏنل هدايتن سان پراڪسڊ سروسز تائين رسائي کان وڌيڪ انڪار ڪري سگهو ٿا:
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteRule .? - [F]
ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"
وڌيڪ تفصيلي معلومات ssl بابت مضمون ۾ ملي سگهي ٿي:
ٻنهي اختيارن کي آزمايو ويو، اختيار "b" چونڊيو ويو ان جي استحڪام ۽ مطابقت لاء http2 پروٽوڪول سان.
ھن مفروضي جي تصديق کي مڪمل ڪرڻ لاءِ، ھن ٺاھ جوڙ سان ڪيترائي تجربا ڪيا؛ ھيٺين ڊيزائن کي آزمايو ويو:
جيڪڏهن = گهربل = ٻيهر لکو
نتيجو هيٺ ڏنل بنيادي ڊيزائن آهي:
SSLVerifyClient optional
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"
#websocket for safari without cert auth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
...
#замещаем авторизацию по владельцу сертификата на авторизацию по номеру протокола
SSLUserName SSl_PROTOCOL
</If>
</If>
سرٽيفڪيٽ جي مالڪ طرفان موجوده اختيار کي مدنظر رکندي، پر هڪ گم ٿيل سرٽيفڪيٽ سان، مون کي هڪ غير موجود سرٽيفڪيٽ مالڪ کي شامل ڪرڻو هو موجود متغيرن مان هڪ جي صورت ۾ SSl_PROTOCOL (SSL_CLIENT_S_DN_CN جي بدران)، دستاويز ۾ وڌيڪ تفصيل:
2. ويب ساکٽس لاءِ، توهان عارضي سيشن استعمال ڪندي هڪ منفرد، محفوظ ۽ محفوظ ڪنيڪشن ٺاهي سگهو ٿا جيڪي عام (غير ويب ساکٽ) برائوزر جي درخواست دوران ٺاهيا ويندا آهن.
پوئين تجربي جي بنياد تي، توهان کي ترتيب ۾ اضافي سيڪشن شامل ڪرڻ جي ضرورت آهي ته جيئن باقاعده (غير ويب ساکٽ) درخواست دوران ويب ساکٽ ڪنيڪشن لاءِ عارضي ٽوڪن تيار ڪرڻ لاءِ.
#подготовка передача себе Сookie через пользовательский браузер
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
Header set Set-Cookie "websocket-allowed=true; path=/; Max-Age=100"
</If>
</If>
#проверка Cookie для установления веб-сокет соединения
<source lang="javascript">
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
#check for exists cookie
#get and check
SetEnvIf Cookie "websocket-allowed=(.*)" env-var-name=$1
#or rewrite rule
RewriteCond %{HTTP_COOKIE} !^.*mycookie.*$
#or if
<If "%{HTTP_COOKIE} =~ /(^|; )cookie-names*=s*some-val(;|$)/ >
</If
</If>
</If>
ٽيسٽ ڏيکاري ٿي ته اهو ڪم ڪري ٿو. اهو ممڪن آهي ته ڪوڪيز کي صارف جي برائوزر ذريعي پاڻ ڏانهن منتقل ڪريو.
3. عارضي سيشن ھڪڙي پراکسي ويب سرور (صرف بلٽ ان ماڊلز ۽ افعال) استعمال ڪندي لاڳو ڪري سگھجن ٿا.
جيئن ته اسان اڳ ۾ ئي معلوم ڪيو آهي، Apache ۾ ڪافي بنيادي ڪارڪردگي آهي جيڪا توهان کي مشروط تعميرات ٺاهڻ جي اجازت ڏئي ٿي. تنهن هوندي، اسان کي ضرورت آهي ته اسان جي معلومات کي تحفظ ڏيڻ لاءِ جڏهن اها صارف جي برائوزر ۾ آهي، تنهنڪري اسان اهو قائم ڪريون ٿا ته ڇا ذخيرو ڪجي ۽ ڇو، ۽ ڪهڙا بلٽ ان فنڪشن استعمال ڪنداسين:
- اسان کي هڪ ٽوڪن جي ضرورت آهي جيڪا آساني سان ڊيڪوڊ نه ٿي سگهي.
- اسان کي هڪ ٽوڪن جي ضرورت آهي جيڪا ان ۾ ٺاهيل فرسوده هجي ۽ سرور تي غير معمولي جانچڻ جي صلاحيت هجي.
- اسان کي هڪ ٽوڪن جي ضرورت آهي جيڪا سند جي مالڪ سان لاڳاپيل هوندي.
ھن لاءِ ھشنگ فنڪشن، لوڻ، ۽ ٽوڪن جي عمر لاءِ تاريخ جي ضرورت آھي. دستاويز جي بنياد تي اسان وٽ اهو سڀ شيئر آف باڪس sha1 ۽ %{TIME} آهي.
نتيجو هي ٺهيل هو:
#нет сертификата, и обращение к websocket
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
SetEnvIf Cookie "zt-cert-sha1=([^;]+)" zt-cert-sha1=$1
SetEnvIf Cookie "zt-cert-uid=([^;]+)" zt-cert-uid=$1
SetEnvIf Cookie "zt-cert-date=([^;]+)" zt-cert-date=$1
#только так можно работать с переменными, полученными в env-ах в этот момент времени, более они нигде не доступны для функции хеширования (по отдельности можно, но не вместе, да и ещё с хешированием)
<RequireAll>
Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
</RequireAll>
</If>
</If>
#есть сертификат, запрашивается не websocket
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
SetEnvIf Cookie "zt-cert-sha1=([^;]+)" HAVE_zt-cert-sha1=$1
SetEnv zt_cert "path=/; HttpOnly;Secure;SameSite=Strict"
#Новые куки ставятся, если старых нет
Header add Set-Cookie "expr=zt-cert-sha1=%{sha1:salt1%{TIME}salt3%{SSL_CLIENT_S_DN_CN}salt2};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
Header add Set-Cookie "expr=zt-cert-uid=%{SSL_CLIENT_S_DN_CN};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
Header add Set-Cookie "expr=zt-cert-date=%{TIME};%{env:zt_cert}" env=!HAVE_zt-cert-sha1
</If>
</If>
مقصد حاصل ڪيو ويو آهي، پر سرور جي غير حاضري سان مسئلا آهن (توهان هڪ سال پراڻي ڪوڪي استعمال ڪري سگهو ٿا)، جنهن جو مطلب آهي ته ٽوڪن، جيتوڻيڪ اندروني استعمال لاء محفوظ آهن، صنعتي (ماس) استعمال لاء غير محفوظ آهن.
4. عارضي سيشن ٽوڪن اڳ ۾ ئي تيار ڪيل اپاچي ماڊلز طور لاڳو ڪيا ويا آهن.
هڪ اهم مسئلو اڳئين ورهاڱي کان رهي ٿو - ٽوڪن جي عمر کي ڪنٽرول ڪرڻ جي ناڪامي.
اسان هڪ تيار ڪيل ماڊل ڳولي رهيا آهيون جيڪو اهو ڪري ٿو، لفظن جي مطابق: apache token json two factor auth
ها، تيار ڪيل ماڊلز موجود آهن، پر اهي سڀئي مخصوص عملن سان جڙيل آهن ۽ سيشن شروع ڪرڻ ۽ اضافي ڪوڪيز جي صورت ۾ نمونا آهن. يعني ٿوري دير لاءِ نه.
اسان کي ڳولڻ ۾ پنج ڪلاڪ لڳا، جنهن جو ڪو به نتيجو نه نڪتو.
5. عارضي سيشن ٽوڪن کي منطقي طور تي رابطي جي جوڙجڪ کي ترتيب ڏيڻ سان لاڳو ڪري سگھجي ٿو.
تيار ٿيل ماڊل تمام پيچيده آهن، ڇاڪاڻ ته اسان کي صرف چند ڪمن جي ضرورت آهي.
اهو چيو پيو وڃي، تاريخ سان مسئلو اهو آهي ته Apache جي تعمير ٿيل افعال مستقبل کان تاريخ پيدا ڪرڻ جي اجازت نه ڏيندا آهن، ۽ تعمير ٿيل افعال ۾ ڪو به رياضياتي اضافو/ذخيرو ناهي جڏهن غير معمولي جي جانچ ڪندي.
اهو آهي، توهان نٿا لکي سگهو:
(%{env:zt-cert-date} + 30) > %{DATE}
توھان صرف ٻن نمبرن جو مقابلو ڪري سگھو ٿا.
سفاري مسئلي جي حل جي ڳولا دوران، مون کي هڪ دلچسپ مضمون مليو:
اهو Nginx لاءِ Lua ۾ ڪوڊ جو هڪ مثال بيان ڪري ٿو، ۽ جيڪو، جيئن اهو نڪتو، تمام گهڻو ورجائي ٿو ترتيب جي ان حصي جي منطق کي جيڪو اسان اڳ ۾ ئي لاڳو ڪيو آهي، هشنگ لاءِ hmac سالٽنگ جو طريقو استعمال ڪرڻ جي استثنا سان ( اهو Apache ۾ نه مليو).
اهو واضح ٿيو ته لوا هڪ ٻولي آهي واضح منطق سان، ۽ اهو ممڪن آهي ته اپاچي لاء ڪجهه سادو ڪرڻ:
Nginx ۽ Apache سان فرق جو اڀياس ڪيو:
۽ لوا ٻولي ٺاهيندڙ کان دستياب ڪارڪردگي:
اسان هڪ ننڍڙي لوا فائل ۾ env variables کي سيٽ ڪرڻ جو هڪ طريقو ڳولي لڌو مستقبل جي تاريخ مقرر ڪرڻ لاءِ موجوده سان ڀيٽ ڪرڻ لاءِ.
هي اهو آهي جيڪو هڪ سادي لوا اسڪرپٽ ڏسڻ جهڙو آهي:
require 'apache2'
function handler(r)
local fmt = '%Y%m%d%H%M%S'
local timeout = 3600 -- 1 hour
r.notes['zt-cert-timeout'] = timeout
r.notes['zt-cert-date-next'] = os.date(fmt,os.time()+timeout)
r.notes['zt-cert-date-halfnext'] = os.date(fmt,os.time()+ (timeout/2))
r.notes['zt-cert-date-now'] = os.date(fmt,os.time())
return apache2.OK
end
۽ اهو سڀ ڪجهه مجموعي طور ڪم ڪري ٿو، ڪوڪيز جي تعداد کي بهتر ڪرڻ ۽ ٽوڪن جي بدلي سان جڏهن اڌ وقت اچي ٿو ته پراڻي ڪوڪي (ٽوڪن) جي ختم ٿيڻ کان اڳ:
SSLVerifyClient optional
#LuaScope thread
#generate event variables zt-cert-date-next
LuaHookAccessChecker /usr/local/etc/apache24/sslincludes/websocket_token.lua handler early
#запрещаем без сертификата что-то ещё, кроме webscoket
RewriteEngine on
RewriteCond %{SSL:SSL_CLIENT_VERIFY} !=SUCCESS
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule .? - [F]
#ErrorDocument 403 "You need a client side certificate issued by CAcert to access this site"
#websocket for safari without certauth
<If "%{SSL:SSL_CLIENT_VERIFY} != 'SUCCESS'">
<If "%{HTTP:Upgrade} = 'websocket'">
SetEnvIf Cookie "zt-cert=([^,;]+),([^,;]+),[^,;]+,([^,;]+)" zt-cert-sha1=$1 zt-cert-date=$2 zt-cert-uid=$3
<RequireAll>
Require expr %{sha1:salt1%{env:zt-cert-date}salt3%{env:zt-cert-uid}salt2} == %{env:zt-cert-sha1}
Require expr %{env:zt-cert-sha1} =~ /^.{40}$/
Require expr %{env:zt-cert-date} -ge %{env:zt-cert-date-now}
</RequireAll>
#замещаем авторизацию по владельцу сертификата на авторизацию по номеру протокола
SSLUserName SSl_PROTOCOL
SSLOptions -FakeBasicAuth
</If>
</If>
<If "%{SSL:SSL_CLIENT_VERIFY} = 'SUCCESS'">
<If "%{HTTP:Upgrade} != 'websocket'">
SetEnvIf Cookie "zt-cert=([^,;]+),[^,;]+,([^,;]+)" HAVE_zt-cert-sha1=$1 HAVE_zt-cert-date-halfnow=$2
SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1
Define zt-cert "path=/;Max-Age=%{env:zt-cert-timeout};HttpOnly;Secure;SameSite=Strict"
Define dates_user "%{env:zt-cert-date-next},%{env:zt-cert-date-halfnext},%{SSL_CLIENT_S_DN_CN}"
Header set Set-Cookie "expr=zt-cert=%{sha1:salt1%{env:zt-cert-date-next}sal3%{SSL_CLIENT_S_DN_CN}salt2},${dates_user};${zt-cert}" env=!HAVE_zt-cert-sha1-found
</If>
</If>
SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge %{TIME} && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1
работает,
а так работать не будет
SetEnvIfExpr "env('HAVE_zt-cert-date-halfnow') -ge env('zt-cert-date-now') && env('HAVE_zt-cert-sha1')=~/.{40}/" HAVE_zt-cert-sha1-found=1
ڇو ته LuaHookAccessChecker صرف Nginx کان هن معلومات جي بنياد تي رسائي جي چڪاس کان پوء چالو ڪيو ويندو.
ذريعو ڏانهن لنڪ.
هڪ ٻي ڳالهه.
عام طور تي، اهو فرق نٿو پوي ته هدايتون ڪهڙي ترتيب ۾ لکيل آهن Apache (شايد Nginx پڻ) ترتيب ۾، ڇو ته آخر ۾ هر شي کي ترتيب ڏني ويندي صارف جي درخواست جي ترتيب جي بنياد تي، جيڪو پروسيسنگ جي منصوبي سان ملندو آهي. لوا اسڪرپٽ.
مڪمل ٿيڻ:
عمل درآمد کان پوءِ ڏسڻ واري حالت (مقصد):
خدمتن ۽ انفراسٽرڪچر جو انتظام موبائل فون مان IOS تي موجود آهي بغير اضافي پروگرامن (VPN)، متحد ۽ محفوظ.
مقصد حاصل ڪيو ويو آهي، ويب ساکٽ ڪم ڪري ٿو ۽ سيڪيورٽي جي سطح کي سرٽيفڪيٽ کان گهٽ ناهي.
جو ذريعو: www.habr.com