🥇ZeroTech में हमने Apple Safari और क्लाइंट प्रमाणपत्रों को वेबसॉकेट से कैसे जोड़ा

यह लेख उन लोगों के लिए उपयोगी होगा जो:

जानता है कि क्लाइंट सर्टिफ़िकेट क्या है और समझता है कि उसे मोबाइल सफ़ारी पर वेबसॉकेट की आवश्यकता क्यों है;
मैं वेब सेवाओं को सीमित लोगों के लिए या केवल अपने लिए प्रकाशित करना चाहूंगा;
सोचता है कि सब कुछ पहले से ही किसी के द्वारा किया जा चुका है, और वह दुनिया को थोड़ा अधिक सुविधाजनक और सुरक्षित बनाना चाहेगा।

वेबसॉकेट का इतिहास लगभग 8 साल पहले शुरू हुआ था। पहले, तरीकों का उपयोग लंबे http अनुरोधों (वास्तव में प्रतिक्रियाओं) के रूप में किया जाता था: उपयोगकर्ता के ब्राउज़र ने सर्वर को एक अनुरोध भेजा और कुछ उत्तर देने के लिए इंतजार किया, प्रतिक्रिया के बाद यह फिर से जुड़ा और इंतजार किया। लेकिन फिर वेबसॉकेट सामने आए।

कुछ साल पहले, हमने शुद्ध PHP में अपना स्वयं का कार्यान्वयन विकसित किया था, जो https अनुरोधों का उपयोग नहीं कर सकता, क्योंकि यह लिंक परत है। कुछ समय पहले, लगभग सभी वेब सर्वरों ने https पर प्रॉक्सी अनुरोध करना और कनेक्शन:अपग्रेड का समर्थन करना सीख लिया था।

जब ऐसा हुआ, तो एसपीए अनुप्रयोगों के लिए वेबसॉकेट लगभग डिफ़ॉल्ट सेवा बन गई, क्योंकि सर्वर की पहल पर उपयोगकर्ता को सामग्री प्रदान करना कितना सुविधाजनक है (किसी अन्य उपयोगकर्ता से संदेश प्रसारित करना या किसी छवि, दस्तावेज़, प्रस्तुति का नया संस्करण डाउनलोड करना) जिसे कोई और वर्तमान में संपादित कर रहा है)।

हालाँकि क्लाइंट सर्टिफिकेट काफी समय से मौजूद है, फिर भी यह अभी भी खराब समर्थित है, क्योंकि इसे बायपास करने का प्रयास करते समय यह बहुत सारी समस्याएं पैदा करता है। और (संभवतः :थोड़ा_स्माइलिंग_फेस: ) इसीलिए आईओएस ब्राउज़र (सफारी को छोड़कर सभी) इसका उपयोग नहीं करना चाहते हैं और स्थानीय प्रमाणपत्र स्टोर से इसका अनुरोध करते हैं। लॉगिन/पास या एसएसएच कुंजी या फ़ायरवॉल के माध्यम से आवश्यक पोर्ट बंद करने की तुलना में प्रमाणपत्र के कई फायदे हैं। लेकिन यह वह नहीं है जिसके बारे में यह बात है।

आईओएस पर, प्रमाणपत्र स्थापित करने की प्रक्रिया काफी सरल है (विशिष्टताओं के बिना नहीं), लेकिन सामान्य तौर पर यह निर्देशों के अनुसार किया जाता है, जिनमें से इंटरनेट पर बहुत सारे हैं और जो केवल सफारी ब्राउज़र के लिए उपलब्ध हैं। दुर्भाग्य से, सफ़ारी को यह नहीं पता कि वेब सॉकेट के लिए क्लाइंट सर्ट का उपयोग कैसे किया जाए, लेकिन इंटरनेट पर ऐसे प्रमाणपत्र बनाने के तरीके के बारे में कई निर्देश हैं, लेकिन व्यवहार में यह अप्राप्य है।

वेबसोकेट को समझने के लिए, हमने निम्नलिखित योजना का उपयोग किया: समस्या/परिकल्पना/समाधान।

समस्या: IOS के लिए सफ़ारी मोबाइल ब्राउज़र और प्रमाणपत्र समर्थन सक्षम करने वाले अन्य अनुप्रयोगों पर क्लाइंट प्रमाणपत्र द्वारा संरक्षित संसाधनों के अनुरोधों को प्रॉक्सी करते समय वेब सॉकेट के लिए कोई समर्थन नहीं है।

परिकल्पनाएँ:

आंतरिक/बाह्य प्रॉक्सी संसाधनों के वेबसोकेट में प्रमाणपत्रों का उपयोग करने के लिए (यह जानते हुए कि कोई नहीं होगा) ऐसे अपवाद को कॉन्फ़िगर करना संभव है।
वेबसॉकेट के लिए, आप सामान्य (गैर-वेबसॉकेट) ब्राउज़र अनुरोध के दौरान उत्पन्न होने वाले अस्थायी सत्रों का उपयोग करके एक अद्वितीय, सुरक्षित और रक्षात्मक कनेक्शन बना सकते हैं।
अस्थायी सत्रों को एक प्रॉक्सी वेब सर्वर (केवल अंतर्निहित मॉड्यूल और फ़ंक्शन) का उपयोग करके कार्यान्वित किया जा सकता है।
अस्थायी सत्र टोकन पहले से ही तैयार अपाचे मॉड्यूल के रूप में लागू किए जा चुके हैं।
अस्थायी सत्र टोकन को इंटरेक्शन संरचना को तार्किक रूप से डिजाइन करके कार्यान्वित किया जा सकता है।

कार्यान्वयन के बाद दृश्यमान स्थिति.

उद्देश्य: सेवाओं और बुनियादी ढांचे का प्रबंधन आईओएस पर मोबाइल फोन से अतिरिक्त कार्यक्रमों (जैसे वीपीएन) के बिना, एकीकृत और सुरक्षित होना चाहिए।

अतिरिक्त लक्ष्य: मोबाइल इंटरनेट पर सामग्री की तेज़ डिलीवरी के साथ समय और संसाधनों/फ़ोन ट्रैफ़िक की बचत (वेब सॉकेट के बिना कुछ सेवाएँ अनावश्यक अनुरोध उत्पन्न करती हैं)।

किस प्रकार जांच करें?

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 प्रोटोकॉल में. यह अभी भी ड्राफ्ट में है, और ब्राउज़र निर्माता नहीं जानते कि इसे कैसे लागू किया जाए #tls1.3 http2 पोस्ट हैंडशेक के बारे में जानकारी (अभी काम नहीं कर रहा है) आरएफसी 8740 लागू करें "HTTP/1.3 के साथ टीएलएस 2 का उपयोग करना";
यह स्पष्ट नहीं है कि इस प्रसंस्करण को कैसे एकीकृत किया जाए।

बी) बुनियादी स्तर पर, बिना प्रमाणपत्र के एसएसएल की अनुमति दें।

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"

अधिक विस्तृत जानकारी एसएसएल के बारे में लेख में पाई जा सकती है: अपाचे सर्वर क्लाइंट प्रमाणपत्र प्रमाणीकरण

दोनों विकल्पों का परीक्षण किया गया, विकल्प "बी" को 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 के बजाय) में से एक के रूप में एक गैर-मौजूद प्रमाणपत्र स्वामी को जोड़ना पड़ा, दस्तावेज़ में अधिक विवरण:

अपाचे मॉड्यूल 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. अस्थायी सत्रों को एक प्रॉक्सी वेब सर्वर (केवल अंतर्निहित मॉड्यूल और फ़ंक्शन) का उपयोग करके कार्यान्वित किया जा सकता है।

जैसा कि हमें पहले पता चला, अपाचे में बहुत सारी मुख्य कार्यक्षमताएं हैं जो आपको सशर्त निर्माण करने की अनुमति देती हैं। हालाँकि, हमें अपनी जानकारी को उपयोगकर्ता के ब्राउज़र में सुरक्षित रखने के लिए साधनों की आवश्यकता होती है, इसलिए हम यह स्थापित करते हैं कि क्या संग्रहीत करना है और क्यों, और हम किन अंतर्निहित कार्यों का उपयोग करेंगे:

हमें एक ऐसे टोकन की आवश्यकता है जिसे आसानी से डिकोड नहीं किया जा सके।
हमें एक ऐसे टोकन की आवश्यकता है जिसमें अप्रचलन अंतर्निहित हो और सर्वर पर अप्रचलन की जांच करने की क्षमता हो।
हमें एक टोकन की आवश्यकता है जो प्रमाणपत्र के स्वामी के साथ संबद्ध होगा।

इसके लिए एक हैशिंग फ़ंक्शन, एक नमक और टोकन की आयु निर्धारित करने की तारीख की आवश्यकता होती है। दस्तावेज़ीकरण के आधार पर अपाचे 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. अस्थायी सत्र टोकन पहले से ही तैयार अपाचे मॉड्यूल के रूप में लागू किए जा चुके हैं।

पिछले पुनरावृत्ति से एक महत्वपूर्ण समस्या बनी रही - टोकन उम्र बढ़ने को नियंत्रित करने में असमर्थता।

हम एक तैयार मॉड्यूल की तलाश कर रहे हैं जो शब्दों के अनुसार ऐसा करता है: अपाचे टोकन जेसन टू फैक्टर ऑथ

हां, तैयार मॉड्यूल हैं, लेकिन वे सभी विशिष्ट कार्यों से बंधे हैं और सत्र शुरू करने और अतिरिक्त कुकीज़ के रूप में कलाकृतियां हैं। यानी कुछ देर के लिए नहीं.
हमें खोजने में पांच घंटे लग गए, जिससे कोई ठोस नतीजा नहीं निकला।

5. अस्थायी सत्र टोकन को इंटरैक्शन की संरचना को तार्किक रूप से डिजाइन करके लागू किया जा सकता है।

रेडी-मेड मॉड्यूल बहुत जटिल हैं, क्योंकि हमें केवल कुछ कार्यों की आवश्यकता होती है।

ऐसा कहा जा रहा है कि, तारीख के साथ समस्या यह है कि अपाचे के अंतर्निहित फ़ंक्शन भविष्य से तारीख उत्पन्न करने की अनुमति नहीं देते हैं, और अप्रचलन की जांच करते समय अंतर्निहित फ़ंक्शन में कोई गणितीय जोड़/घटाव नहीं होता है।

यानी आप नहीं लिख सकते:

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

आप केवल दो संख्याओं की तुलना कर सकते हैं.

सफ़ारी समस्या के समाधान की खोज करते समय, मुझे एक दिलचस्प लेख मिला: क्लाइंट प्रमाणपत्रों के साथ HomeAssistant को सुरक्षित करना (Safari/iOS के साथ काम करता है)
यह Nginx के लिए Lua में कोड के एक उदाहरण का वर्णन करता है, और जो, जैसा कि यह निकला, कॉन्फ़िगरेशन के उस हिस्से के तर्क को बहुत दोहराता है जिसे हमने पहले ही लागू कर दिया है, हैशिंग के लिए hmac साल्टिंग विधि के उपयोग के अपवाद के साथ ( यह अपाचे में नहीं मिला)।

यह स्पष्ट हो गया कि लुआ स्पष्ट तर्क वाली एक भाषा है, और अपाचे के लिए कुछ सरल करना संभव है:

Nginx और Apache के साथ अंतर का अध्ययन करने के बाद:

और लुआ भाषा निर्माता से उपलब्ध कार्य:
22.1 - दिनांक और समय

हमें वर्तमान तारीख से तुलना करने के लिए भविष्य की तारीख निर्धारित करने के लिए एक छोटी लुआ फ़ाइल में एनवी वैरिएबल सेट करने का एक तरीका मिला।

एक साधारण लुआ स्क्रिप्ट इस प्रकार दिखती है:

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) कॉन्फ़िगरेशन में निर्देश किस क्रम में लिखे गए हैं, क्योंकि अंत में सब कुछ उपयोगकर्ता के अनुरोध के क्रम के आधार पर क्रमबद्ध किया जाएगा, जो प्रसंस्करण के लिए योजना से मेल खाता है लुआ स्क्रिप्ट.

समापन:

कार्यान्वयन के बाद दृश्यमान स्थिति (लक्ष्य):
सेवाओं और बुनियादी ढांचे का प्रबंधन आईओएस पर मोबाइल फोन से अतिरिक्त कार्यक्रमों (वीपीएन) के बिना, एकीकृत और सुरक्षित रूप से उपलब्ध है।

लक्ष्य हासिल कर लिया गया है, वेब सॉकेट काम करते हैं और सुरक्षा का स्तर किसी प्रमाणपत्र से कम नहीं है।

स्रोत: www.habr.com

ज़ीरोटेक में हमने ऐप्पल सफारी और क्लाइंट सर्टिफिकेट को वेबसॉकेट से कैसे जोड़ा

एक टिप्पणी जोड़ें उत्तर रद्द