ZeroTech પર અમે Apple Safari અને ક્લાયન્ટ પ્રમાણપત્રોને વેબસોકેટ્સ સાથે કેવી રીતે કનેક્ટ કર્યા

લેખ તે લોકો માટે ઉપયોગી થશે જેઓ:

• ક્લાઈન્ટ પ્રમાણપત્ર શું છે તે જાણે છે અને સમજે છે કે તેને મોબાઈલ સફારી પર વેબસોકેટ્સની જરૂર કેમ છે;
• હું વેબ સેવાઓને લોકોના મર્યાદિત વર્તુળમાં અથવા ફક્ત મારા માટે પ્રકાશિત કરવા માંગુ છું;
• વિચારે છે કે બધું પહેલેથી જ કોઈ વ્યક્તિ દ્વારા કરવામાં આવ્યું છે, અને તે વિશ્વને થોડું વધુ અનુકૂળ અને સુરક્ષિત બનાવવા માંગે છે.

વેબસોકેટ્સનો ઇતિહાસ લગભગ 8 વર્ષ પહેલાં શરૂ થયો હતો. પહેલાં, પદ્ધતિઓનો ઉપયોગ લાંબી HTTP વિનંતીઓ (ખરેખર પ્રતિસાદો) ના રૂપમાં કરવામાં આવતો હતો: વપરાશકર્તાના બ્રાઉઝર સર્વરને વિનંતી મોકલે છે અને તે કંઈક જવાબ આપે તેની રાહ જોતા હતા, પ્રતિસાદ પછી તે ફરીથી કનેક્ટ થાય છે અને રાહ જુએ છે. પરંતુ પછી વેબસોકેટ્સ દેખાયા.



થોડા વર્ષો પહેલા, અમે શુદ્ધ PHP માં અમારું પોતાનું અમલીકરણ વિકસાવ્યું હતું, જે https વિનંતીઓનો ઉપયોગ કરી શકતું નથી, કારણ કે આ લિંક સ્તર છે. થોડા સમય પહેલા, લગભગ તમામ વેબ સર્વર્સે https અને સપોર્ટ કનેક્શન:અપગ્રેડ પર પ્રોક્સી વિનંતી કરવાનું શીખ્યા.

જ્યારે આ બન્યું, ત્યારે SPA એપ્લિકેશન્સ માટે વેબસોકેટ્સ લગભગ ડિફોલ્ટ સેવા બની ગઈ, કારણ કે સર્વરની પહેલ પર વપરાશકર્તાને સામગ્રી પ્રદાન કરવી કેટલું અનુકૂળ છે (બીજા વપરાશકર્તા તરફથી સંદેશ મોકલો અથવા છબી, દસ્તાવેજ, પ્રસ્તુતિનું નવું સંસ્કરણ ડાઉનલોડ કરો. કે અન્ય કોઈ હાલમાં સંપાદિત કરી રહ્યું છે).

ક્લાઈન્ટ પ્રમાણપત્ર છેલ્લા ઘણા સમયથી છે, તેમ છતાં, તે હજી પણ નબળી રીતે સમર્થિત છે, કારણ કે જ્યારે તેને બાયપાસ કરવાનો પ્રયાસ કરવામાં આવે છે ત્યારે તે ઘણી સમસ્યાઓ ઊભી કરે છે. અને (સંભવતઃ :slightly_smiling_face: ) તેથી જ IOS બ્રાઉઝર્સ (સફારી સિવાયના બધા) તેનો ઉપયોગ કરવા માંગતા નથી અને સ્થાનિક પ્રમાણપત્ર સ્ટોરમાંથી તેની વિનંતી કરવા માંગતા નથી. લોગિન/પાસ અથવા ssh કી અથવા ફાયરવોલ દ્વારા જરૂરી પોર્ટ બંધ કરવાની સરખામણીમાં પ્રમાણપત્રોના ઘણા ફાયદા છે. પરંતુ તે આ વિશે નથી.

iOS પર, પ્રમાણપત્ર ઇન્સ્ટોલ કરવાની પ્રક્રિયા એકદમ સરળ છે (વિશિષ્ટતા વિના નહીં), પરંતુ સામાન્ય રીતે તે સૂચનાઓ અનુસાર કરવામાં આવે છે, જેમાંથી ઇન્ટરનેટ પર ઘણું બધું છે અને જે ફક્ત સફારી બ્રાઉઝર માટે ઉપલબ્ધ છે. કમનસીબે, સફારી વેબ સોકેટ્સ માટે ક્લાયંટ Сert નો ઉપયોગ કેવી રીતે કરવો તે જાણતું નથી, પરંતુ આવા પ્રમાણપત્ર કેવી રીતે બનાવવું તે અંગે ઇન્ટરનેટ પર ઘણી સૂચનાઓ છે, પરંતુ વ્યવહારમાં આ અગમ્ય છે.

વેબસોકેટ્સને સમજવા માટે, અમે નીચેની યોજનાનો ઉપયોગ કર્યો: સમસ્યા/ધારણા/ઉકેલ.

સમસ્યા: IOS માટે સફારી મોબાઇલ બ્રાઉઝર પર ક્લાયંટ સર્ટિફિકેટ દ્વારા સુરક્ષિત હોય તેવા સંસાધનોની વિનંતીઓ પ્રોક્સી કરતી વખતે વેબ સોકેટ્સ માટે કોઈ સપોર્ટ નથી અને પ્રમાણપત્ર સપોર્ટ સક્ષમ કરેલ હોય તેવી અન્ય એપ્લિકેશનો.

પૂર્વધારણાઓ:

1. આંતરિક/બાહ્ય પ્રોક્સીડ સંસાધનોના વેબસોકેટ્સમાં પ્રમાણપત્રો (એ જાણીને કે ત્યાં કોઈ નહીં હોય) નો ઉપયોગ કરવા માટે આવા અપવાદને ગોઠવવાનું શક્ય છે.
2. વેબસોકેટ્સ માટે, તમે સામાન્ય (બિન-વેબસોકેટ) બ્રાઉઝર વિનંતી દરમિયાન જનરેટ થતા અસ્થાયી સત્રોનો ઉપયોગ કરીને એક અનન્ય, સુરક્ષિત અને સંરક્ષણક્ષમ કનેક્શન બનાવી શકો છો.
3. અસ્થાયી સત્રો એક પ્રોક્સી વેબ સર્વર (બિલ્ટ-ઇન મોડ્યુલ્સ અને ફંક્શન્સ) નો ઉપયોગ કરીને અમલમાં મૂકી શકાય છે.
4. અસ્થાયી સત્ર ટોકન્સ પહેલેથી જ તૈયાર અપાચે મોડ્યુલો તરીકે લાગુ કરવામાં આવ્યા છે.
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 વિશે 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"

વધુ વિગતવાર માહિતી ssl વિશેના લેખમાં મળી શકે છે: અપાચે સર્વર ક્લાયંટ પ્રમાણપત્ર પ્રમાણીકરણ

બંને વિકલ્પોનું પરીક્ષણ કરવામાં આવ્યું હતું, http2 પ્રોટોકોલ સાથે તેની વૈવિધ્યતા અને સુસંગતતા માટે વિકલ્પ "b" પસંદ કરવામાં આવ્યો હતો.

આ પૂર્વધારણાની ચકાસણી પૂર્ણ કરવા માટે, રૂપરેખાંકન સાથે ઘણા પ્રયોગો કર્યા; નીચેની ડિઝાઇનનું પરીક્ષણ કરવામાં આવ્યું:

જો = જરૂરી = ફરીથી લખો

• અપાચે કોર ફીચર્સ
• અપાચે 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. એક પ્રોક્સી વેબ સર્વર (માત્ર બિલ્ટ-ઇન મોડ્યુલો અને કાર્યો) નો ઉપયોગ કરીને અસ્થાયી સત્રોનો અમલ કરી શકાય છે.

જેમ આપણે અગાઉ જાણ્યું તેમ, અપાચેમાં ઘણી બધી મુખ્ય કાર્યક્ષમતા છે જે તમને શરતી રચનાઓ બનાવવા માટે પરવાનગી આપે છે. જો કે, અમારી માહિતી વપરાશકર્તાના બ્રાઉઝરમાં હોય ત્યારે તેને સુરક્ષિત રાખવા માટે અમને સાધનની જરૂર છે, તેથી અમે સ્થાપિત કરીએ છીએ કે શું સંગ્રહિત કરવું અને શા માટે, અને અમે કયા બિલ્ટ-ઇન કાર્યોનો ઉપયોગ કરીશું:

• અમને એક ટોકનની જરૂર છે જે સરળતાથી ડીકોડ કરી શકાતી નથી.
• અમને એક ટોકનની જરૂર છે જેમાં અપ્રચલિતતા શામેલ હોય અને સર્વર પર અપ્રચલિતતા તપાસવાની ક્ષમતા હોય.
• અમને એક ટોકનની જરૂર છે જે પ્રમાણપત્રના માલિક સાથે સંકળાયેલ હશે.

આ માટે હેશિંગ ફંક્શન, મીઠું અને ટોકનની ઉંમર માટે તારીખની જરૂર છે. દસ્તાવેજીકરણ પર આધારિત છે અપાચે 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 token json two factor auth

• JSON વેબ ટોકન્સ પર આધારિત ટોકન્સનો ઉપયોગ કરીને ક્લાયન્ટ પ્રમાણીકરણ
• અપાચે ટુ-ફેક્ટર (2FA) પ્રમાણીકરણ
• અપાચેમાં ટુ-ફેક્ટર ઓથેન્ટિકેશન કેવી રીતે ઉમેરવું
• સરળ મોડ્યુલ ઇન્સ્ટોલ સાથે તમારા અપાચે ઇન્સ્ટન્સમાં બે-પરિબળ પ્રમાણીકરણ લાવો

હા, ત્યાં તૈયાર મોડ્યુલો છે, પરંતુ તે બધા ચોક્કસ ક્રિયાઓ સાથે જોડાયેલા છે અને સત્ર અને વધારાની કૂકીઝ શરૂ કરવાના સ્વરૂપમાં કલાકૃતિઓ ધરાવે છે. એટલે કે થોડા સમય માટે નહીં.
અમને શોધવામાં પાંચ કલાક લાગ્યા, જેનાથી કોઈ નક્કર પરિણામ મળ્યું નહીં.

5. અસ્થાયી સત્ર ટોકન્સ તાર્કિક રીતે ક્રિયાપ્રતિક્રિયાઓની રચનાને ડિઝાઇન કરીને લાગુ કરી શકાય છે.

તૈયાર મોડ્યુલ્સ ખૂબ જટિલ છે, કારણ કે અમને ફક્ત થોડા કાર્યોની જરૂર છે.

એવું કહેવાય છે કે, તારીખની સમસ્યા એ છે કે અપાચેના બિલ્ટ-ઇન ફંક્શન્સ ભવિષ્યમાંથી તારીખ જનરેટ કરવાની મંજૂરી આપતા નથી, અને અપ્રચલિતતાની તપાસ કરતી વખતે બિલ્ટ-ઇન ફંક્શન્સમાં કોઈ ગાણિતિક સરવાળો/બાદબાકી નથી.

એટલે કે, તમે લખી શકતા નથી:

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

તમે ફક્ત બે સંખ્યાઓની તુલના કરી શકો છો.

સફારી સમસ્યા માટે ઉકેલ શોધતી વખતે, મને એક રસપ્રદ લેખ મળ્યો: ક્લાયંટ પ્રમાણપત્રો સાથે હોમઆસિસ્ટન્ટને સુરક્ષિત કરવું (સફારી/iOS સાથે કામ કરે છે)
તે Nginx માટે લુઆમાં કોડના ઉદાહરણનું વર્ણન કરે છે, અને જે તે બહાર આવ્યું તેમ, હેશિંગ માટે hmac સૉલ્ટિંગ પદ્ધતિના ઉપયોગના અપવાદ સિવાય, અમે પહેલેથી જ અમલમાં મૂકેલા રૂપરેખાંકનના તે ભાગના તર્કને પુનરાવર્તિત કરે છે ( આ અપાચેમાં જોવા મળ્યું નથી).

તે સ્પષ્ટ થઈ ગયું કે લુઆ સ્પષ્ટ તર્ક સાથેની ભાષા છે, અને અપાચે માટે કંઈક સરળ કરવું શક્ય છે:

• LuaHookAccessChecker ડાયરેક્ટિવ
• UnsetEnv ડાયરેક્ટિવ

Nginx અને Apache સાથેના તફાવતનો અભ્યાસ કર્યા પછી:

• મોડ્યુલ્સ_લુઆ
• 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