ZeroTech वर आम्ही Apple Safari आणि क्लायंट प्रमाणपत्रांना वेबसॉकेटसह कसे जोडले

लेख त्यांच्यासाठी उपयुक्त ठरेल जे:

• क्लायंट प्रमाणपत्र काय आहे हे माहित आहे आणि मोबाइल सफारीवर वेबसॉकेट्सची आवश्यकता का आहे हे समजते;
• मी लोकांच्या मर्यादित वर्तुळासाठी किंवा फक्त माझ्यासाठी वेब सेवा प्रकाशित करू इच्छितो;
• असे वाटते की सर्व काही आधीच कोणीतरी केले आहे आणि जगाला थोडे अधिक सोयीस्कर आणि सुरक्षित बनवू इच्छितो.

वेबसॉकेटचा इतिहास सुमारे 8 वर्षांपूर्वी सुरू झाला. पूर्वी, पद्धती लांब HTTP विनंत्या (प्रत्यक्षात प्रतिसाद) स्वरूपात वापरल्या जात होत्या: वापरकर्त्याच्या ब्राउझरने सर्व्हरला विनंती पाठवली आणि काहीतरी उत्तर देण्याची प्रतीक्षा केली, प्रतिसादानंतर ते पुन्हा कनेक्ट झाले आणि प्रतीक्षा केली. पण नंतर वेबसॉकेट्स दिसू लागल्या.



काही वर्षांपूर्वी, आम्ही शुद्ध PHP मध्ये आमची स्वतःची अंमलबजावणी विकसित केली आहे, जी https विनंत्या वापरू शकत नाही, कारण हा दुवा स्तर आहे. काही काळापूर्वी, जवळपास सर्व वेब सर्व्हरने https आणि सपोर्ट कनेक्शन:अपग्रेडवर प्रॉक्सी विनंत्या शिकल्या आहेत.

जेव्हा हे घडले तेव्हा, SPA ऍप्लिकेशन्ससाठी वेबसॉकेट्स जवळजवळ डीफॉल्ट सेवा बनली, कारण सर्व्हरच्या पुढाकाराने वापरकर्त्यास सामग्री प्रदान करणे किती सोयीचे आहे (दुसर्या वापरकर्त्याकडून संदेश प्रसारित करा किंवा प्रतिमा, दस्तऐवज, सादरीकरणाची नवीन आवृत्ती डाउनलोड करा. की सध्या कोणीतरी संपादित करत आहे).

जरी क्लायंट प्रमाणपत्र बर्याच काळापासून आहे, तरीही ते असमाधानकारकपणे समर्थित आहे, कारण ते बायपास करण्याचा प्रयत्न करताना अनेक समस्या निर्माण करतात. आणि (शक्यतो :slightly_smiling_face: ) म्हणूनच IOS ब्राउझर (सफारी सोडून) ते वापरू इच्छित नाहीत आणि स्थानिक प्रमाणपत्र स्टोअरकडून विनंती करू इच्छित नाहीत. लॉगिन/पास किंवा ssh की किंवा फायरवॉलद्वारे आवश्यक पोर्ट बंद करण्याच्या तुलनेत प्रमाणपत्रांचे बरेच फायदे आहेत. पण हे त्याबद्दल नाही.

iOS वर, प्रमाणपत्र स्थापित करण्याची प्रक्रिया अगदी सोपी आहे (विशिष्ट गोष्टींशिवाय नाही), परंतु सर्वसाधारणपणे ते सूचनांनुसार केले जाते, ज्यापैकी इंटरनेटवर बरेच काही आहेत आणि जे फक्त सफारी ब्राउझरसाठी उपलब्ध आहेत. दुर्दैवाने, वेब सॉकेटसाठी क्लायंट Сert कसे वापरावे हे सफारीला माहित नाही, परंतु असे प्रमाणपत्र कसे तयार करावे याबद्दल इंटरनेटवर अनेक सूचना आहेत, परंतु व्यवहारात हे अप्राप्य आहे.

वेबसॉकेट समजून घेण्यासाठी, आम्ही खालील योजना वापरली: समस्या/ गृहीतक/ उपाय.

समस्या: IOS आणि सर्टिफिकेट सपोर्ट सक्षम केलेल्या इतर ऍप्लिकेशन्ससाठी Safari मोबाइल ब्राउझरवरील क्लायंट प्रमाणपत्राद्वारे संरक्षित केलेल्या संसाधनांसाठी विनंती प्रॉक्सी करताना वेब सॉकेटसाठी कोणतेही समर्थन नाही.

गृहीतके:

1. अंतर्गत/बाह्य प्रॉक्सी संसाधनांच्या वेबसॉकेट्सवर प्रमाणपत्रे (कोणतेही नसेल हे जाणून) वापरण्यासाठी असा अपवाद कॉन्फिगर करणे शक्य आहे.
2. वेबसॉकेटसाठी, तुम्ही सामान्य (वेबसॉकेट नसलेल्या) ब्राउझर विनंतीदरम्यान व्युत्पन्न केलेल्या तात्पुरत्या सत्रांचा वापर करून एक अनन्य, सुरक्षित आणि बचाव करण्यायोग्य कनेक्शन बनवू शकता.
3. एक प्रॉक्सी वेब सर्व्हर वापरून तात्पुरती सत्रे लागू केली जाऊ शकतात (केवळ अंगभूत मॉड्यूल आणि कार्ये).
4. तात्पुरते सत्र टोकन आधीच तयार-तयार Apache मॉड्यूल म्हणून लागू केले गेले आहेत.
5. तात्पुरते सत्र टोकन तार्किकरित्या परस्परसंवाद रचना तयार करून लागू केले जाऊ शकतात.

अंमलबजावणीनंतर दृश्यमान स्थिती.

कामाचे ध्येय: सेवा आणि पायाभूत सुविधांचे व्यवस्थापन 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 उपाय सापडले:

अ) स्तरावर

<Location sock*> SSLVerifyClient optional </Location>
<Location /> SSLVerifyClient require </Location>

प्रवेश पातळी बदला.

या पद्धतीमध्ये खालील बारकावे आहेत:

• सर्टिफिकेट पडताळणी प्रॉक्सी रिसोर्सला विनंती केल्यानंतर होते, म्हणजेच पोस्ट रिक्वेस्ट हँडशेक. याचा अर्थ असा की प्रॉक्सी प्रथम लोड होईल आणि नंतर संरक्षित सेवेची विनंती कापली जाईल. हे वाईट आहे, परंतु गंभीर नाही;
• http2 प्रोटोकॉलमध्ये. हे अद्याप मसुद्यात आहे, आणि ब्राउझर उत्पादकांना ते कसे अंमलात आणायचे हे माहित नाही #info about tls1.3 http2 पोस्ट हँडशेक (आता काम करत नाही) RFC 8740 "HTTP/1.3 सह TLS 2 वापरणे" लागू करा;
• ही प्रक्रिया कशी एकत्र करायची हे स्पष्ट नाही.

b) मूलभूत स्तरावर, प्रमाणपत्राशिवाय 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"

एसएसएल बद्दल अधिक तपशीलवार माहिती लेखात आढळू शकते: अपाचे सर्व्हर क्लायंट प्रमाणपत्र प्रमाणीकरण

दोन्ही पर्यायांची चाचणी घेण्यात आली, पर्याय "b" त्याच्या बहुमुखीपणासाठी आणि http2 प्रोटोकॉलशी सुसंगततेसाठी निवडला गेला.

या गृहितकाची पडताळणी पूर्ण करण्यासाठी, कॉन्फिगरेशनसह बरेच प्रयोग करावे लागले; खालील डिझाइनची चाचणी घेण्यात आली:

जर = आवश्यक = पुन्हा लिहा

• अपाचे मुख्य वैशिष्ट्ये
• Apache HTTP सर्व्हरमधील अभिव्यक्ती

परिणाम खालील मूलभूत डिझाइन आहे:

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 ऐवजी) उपलब्ध व्हेरिएबल्सच्या रूपात जोडावे लागले, दस्तऐवजीकरणात अधिक तपशील:

अपाचे मॉड्यूल mod_ssl

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 HTTP सर्व्हरमधील अभिव्यक्ती आमच्याकडे हे सर्व बॉक्सबाहेर 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 मॉड्यूल म्हणून लागू केले गेले आहेत.

मागील पुनरावृत्तीपासून एक महत्त्वपूर्ण समस्या राहिली - टोकन वृद्धत्व नियंत्रित करण्यास असमर्थता.

आम्ही एक रेडीमेड मॉड्यूल शोधत आहोत जे असे करते, या शब्दांनुसार: apache token json two factor auth

• JSON वेब टोकनवर आधारित टोकन वापरून क्लायंट प्रमाणीकरण
• अपाचे टू-फॅक्टर (2FA) प्रमाणीकरण
• Apache मध्ये टू-फॅक्टर ऑथेंटिकेशन कसे जोडायचे
• साध्या मॉड्यूल इन्स्टॉलसह तुमच्या Apache उदाहरणामध्ये द्वि-घटक प्रमाणीकरण आणा

होय, तेथे रेडीमेड मॉड्यूल्स आहेत, परंतु ते सर्व विशिष्ट क्रियांशी जोडलेले आहेत आणि एक सत्र आणि अतिरिक्त कुकीज सुरू करण्याच्या स्वरूपात कलाकृती आहेत. म्हणजे काही काळासाठी नाही.
आम्हाला शोधण्यासाठी पाच तास लागले, ज्यामुळे ठोस परिणाम मिळाला नाही.

5. तात्पुरती सत्र टोकन तार्किकरित्या परस्परसंवादाची रचना तयार करून लागू केले जाऊ शकतात.

रेडीमेड मॉड्यूल खूप क्लिष्ट आहेत, कारण आम्हाला फक्त दोन फंक्शन्सची आवश्यकता आहे.

असे म्हटले जात आहे की, तारखेची समस्या अशी आहे की Apache ची अंगभूत फंक्शन्स भविष्यातील तारीख तयार करण्यास परवानगी देत ​​​​नाहीत आणि अप्रचलितता तपासताना अंगभूत फंक्शन्समध्ये कोणतीही गणिती बेरीज/वजाबाकी नाही.

म्हणजेच, आपण लिहू शकत नाही:

(%{env:zt-cert-date} + 30) > %{DATE}

तुम्ही फक्त दोन संख्यांची तुलना करू शकता.

सफारी समस्येसाठी उपाय शोधत असताना, मला एक मनोरंजक लेख सापडला: क्लायंट प्रमाणपत्रांसह होम असिस्टंट सुरक्षित करणे (Safari/iOS सह कार्य करते)
हे Nginx साठी लुआ मधील कोडच्या उदाहरणाचे वर्णन करते आणि ते जसे की, हॅशिंगसाठी hmac सॉल्टिंग पद्धतीचा वापर वगळता, आम्ही आधीच लागू केलेल्या कॉन्फिगरेशनच्या त्या भागाच्या तर्काची पुनरावृत्ती करते ( हे Apache मध्ये आढळले नाही).

हे स्पष्ट झाले की लुआ ही स्पष्ट तर्कशास्त्र असलेली भाषा आहे आणि अपाचेसाठी काहीतरी सोपे करणे शक्य आहे:

• LuaHookAccessChecker निर्देश
• UnsetEnv निर्देश

Nginx आणि Apache मधील फरकाचा अभ्यास केल्यावर:

• modules_lua
• lua_load_resty_core

आणि लुआ भाषा निर्मात्याकडून उपलब्ध कार्ये:
22.1 - तारीख आणि वेळ

वर्तमानाशी तुलना करण्यासाठी भविष्यातील तारीख सेट करण्यासाठी आम्हाला लहान लुआ फाइलमध्ये env व्हेरिएबल्स सेट करण्याचा मार्ग सापडला.

साधी लुआ स्क्रिप्ट अशी दिसते:

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 कडील माहितीच्या आधारे प्रवेश तपासल्यानंतरच सक्रिय केले जाईल.

स्त्रोताशी दुवा प्रतिमा.

आणखी एक गोष्ट.

सर्वसाधारणपणे, अपाचे (कदाचित Nginx देखील) कॉन्फिगरेशनमध्ये निर्देश कोणत्या क्रमाने लिहिलेले आहेत याने काही फरक पडत नाही, कारण शेवटी प्रत्येक गोष्ट वापरकर्त्याच्या विनंतीनुसार क्रमवारी लावली जाईल, जी प्रक्रिया करण्याच्या योजनेशी संबंधित आहे. लुआ स्क्रिप्ट्स.

पूर्णता:

अंमलबजावणीनंतर दृश्यमान स्थिती (ध्येय):
सेवा आणि पायाभूत सुविधांचे व्यवस्थापन मोबाइल फोनवरून IOS वर अतिरिक्त प्रोग्रामशिवाय (VPN), युनिफाइड आणि सुरक्षित उपलब्ध आहे.

उद्दिष्ट साध्य झाले आहे, वेब सॉकेट्स कार्य करतात आणि सुरक्षिततेची पातळी प्रमाणपत्रापेक्षा कमी नाही.

स्त्रोत: www.habr.com