എങ്ങനെയാണ് ഞങ്ങൾ ZeroTech-ൽ Apple Safari, ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകൾ എന്നിവ വെബ്‌സോക്കറ്റുകളുമായി ബന്ധിപ്പിച്ചത്

ഇനിപ്പറയുന്നവർക്ക് ലേഖനം ഉപയോഗപ്രദമാകും:

• ക്ലയന്റ് സെർട്ട് എന്താണെന്ന് അറിയുകയും അതിന് മൊബൈൽ സഫാരിയിൽ വെബ്‌സോക്കറ്റുകൾ ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ടാണെന്ന് മനസ്സിലാക്കുകയും ചെയ്യുന്നു;
• പരിമിതമായ ആളുകൾക്ക് അല്ലെങ്കിൽ എനിക്ക് മാത്രമായി വെബ് സേവനങ്ങൾ പ്രസിദ്ധീകരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു;
• എല്ലാം ഇതിനകം ആരെങ്കിലും ചെയ്തിട്ടുണ്ടെന്ന് കരുതുന്നു, ലോകത്തെ കുറച്ചുകൂടി സൗകര്യപ്രദവും സുരക്ഷിതവുമാക്കാൻ ആഗ്രഹിക്കുന്നു.

വെബ്‌സോക്കറ്റുകളുടെ ചരിത്രം ആരംഭിച്ചത് ഏകദേശം 8 വർഷം മുമ്പാണ്. മുമ്പ്, ദൈർഘ്യമേറിയ http അഭ്യർത്ഥനകളുടെ രൂപത്തിലാണ് രീതികൾ ഉപയോഗിച്ചിരുന്നത് (യഥാർത്ഥത്തിൽ പ്രതികരണങ്ങൾ): ഉപയോക്താവിന്റെ ബ്രൗസർ സെർവറിലേക്ക് ഒരു അഭ്യർത്ഥന അയയ്ക്കുകയും എന്തെങ്കിലും ഉത്തരം നൽകുന്നതിനായി കാത്തിരിക്കുകയും ചെയ്തു, പ്രതികരണത്തിന് ശേഷം അത് വീണ്ടും ബന്ധിപ്പിച്ച് കാത്തിരിക്കുന്നു. എന്നാൽ പിന്നീട് വെബ്‌സോക്കറ്റുകൾ പ്രത്യക്ഷപ്പെട്ടു.



കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്, ഇത് ലിങ്ക് ലെയറായതിനാൽ https അഭ്യർത്ഥനകൾ ഉപയോഗിക്കാൻ കഴിയാത്ത ശുദ്ധമായ PHP-യിൽ ഞങ്ങൾ സ്വന്തമായി നടപ്പിലാക്കൽ വികസിപ്പിച്ചെടുത്തു. അധികം താമസിയാതെ, മിക്കവാറും എല്ലാ വെബ് സെർവറുകളും https വഴി അഭ്യർത്ഥനകൾ പ്രോക്സി ചെയ്യാനും പിന്തുണ കണക്ഷൻ:അപ്ഗ്രേഡ് ചെയ്യാനും പഠിച്ചു.

ഇത് സംഭവിക്കുമ്പോൾ, വെബ്‌സോക്കറ്റുകൾ SPA ആപ്ലിക്കേഷനുകളുടെ സ്ഥിരസ്ഥിതി സേവനമായി മാറി, കാരണം സെർവറിന്റെ മുൻകൈയിൽ ഉപയോക്താവിന് ഉള്ളടക്കം നൽകുന്നത് എത്ര സൗകര്യപ്രദമാണ് (മറ്റൊരു ഉപയോക്താവിൽ നിന്ന് ഒരു സന്ദേശം കൈമാറുക അല്ലെങ്കിൽ ഒരു ചിത്രം, പ്രമാണം, അവതരണം എന്നിവയുടെ പുതിയ പതിപ്പ് ഡൗൺലോഡ് ചെയ്യുക മറ്റൊരാൾ നിലവിൽ എഡിറ്റ് ചെയ്യുന്നു) .

ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് വളരെക്കാലമായി നിലവിലുണ്ടെങ്കിലും, അത് ഇപ്പോഴും മോശമായി പിന്തുണയ്ക്കുന്നു, കാരണം അത് മറികടക്കാൻ ശ്രമിക്കുമ്പോൾ ഇത് ധാരാളം പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു. കൂടാതെ (ഒരുപക്ഷേ :slightly_smiling_face: ) അതുകൊണ്ടാണ് IOS ബ്രൗസറുകൾ (സഫാരി ഒഴികെയുള്ളവ) ഇത് ഉപയോഗിക്കാനും പ്രാദേശിക സർട്ടിഫിക്കറ്റ് സ്റ്റോറിൽ നിന്ന് അഭ്യർത്ഥിക്കാനും ആഗ്രഹിക്കുന്നില്ല. ലോഗിൻ/പാസ് അല്ലെങ്കിൽ ssh കീകൾ അല്ലെങ്കിൽ ഫയർവാൾ വഴി ആവശ്യമായ പോർട്ടുകൾ അടയ്ക്കുന്നത് എന്നിവയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ സർട്ടിഫിക്കറ്റുകൾക്ക് ധാരാളം ഗുണങ്ങളുണ്ട്. എന്നാൽ ഇത് അതല്ല.

IOS-ൽ, ഒരു സർട്ടിഫിക്കറ്റ് ഇൻസ്റ്റാൾ ചെയ്യുന്നതിനുള്ള നടപടിക്രമം വളരെ ലളിതമാണ് (പ്രത്യേകതകളില്ലാതെ അല്ല), എന്നാൽ പൊതുവേ ഇത് നിർദ്ദേശങ്ങൾക്കനുസൃതമായാണ് ചെയ്യുന്നത്, അവയിൽ ഇന്റർനെറ്റിൽ ധാരാളം ഉണ്ട്, അവ സഫാരി ബ്രൗസറിന് മാത്രം ലഭ്യമാണ്. നിർഭാഗ്യവശാൽ, വെബ് സോക്കറ്റുകൾക്കായി ക്ലയന്റ് സെർട്ട് എങ്ങനെ ഉപയോഗിക്കണമെന്ന് സഫാരിക്ക് അറിയില്ല, എന്നാൽ അത്തരമൊരു സർട്ടിഫിക്കറ്റ് എങ്ങനെ സൃഷ്ടിക്കാമെന്ന് ഇൻറർനെറ്റിൽ നിരവധി നിർദ്ദേശങ്ങളുണ്ട്, പക്ഷേ പ്രായോഗികമായി ഇത് നേടാനാവില്ല.

വെബ്‌സോക്കറ്റുകൾ മനസിലാക്കാൻ, ഞങ്ങൾ ഇനിപ്പറയുന്ന പ്ലാൻ ഉപയോഗിച്ചു: പ്രശ്നം / അനുമാനം / പരിഹാരം.

പ്രശ്നം: IOS-നും സർട്ടിഫിക്കറ്റ് പിന്തുണ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുള്ള മറ്റ് ആപ്ലിക്കേഷനുകൾക്കുമായി Safari മൊബൈൽ ബ്രൗസറിലെ ഒരു ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഉപയോഗിച്ച് പരിരക്ഷിച്ചിരിക്കുന്ന ഉറവിടങ്ങളിലേക്ക് അഭ്യർത്ഥനകൾ പ്രോക്‌സി ചെയ്യുമ്പോൾ വെബ് സോക്കറ്റുകൾക്ക് പിന്തുണയില്ല.

അനുമാനങ്ങൾ:

1. ആന്തരിക/ബാഹ്യ പ്രോക്‌സിഡ് റിസോഴ്‌സുകളുടെ വെബ്‌സോക്കറ്റുകളിലേക്ക് സർട്ടിഫിക്കറ്റുകൾ (ഒന്നും ഉണ്ടാകില്ലെന്ന് അറിഞ്ഞുകൊണ്ട്) ഉപയോഗിക്കുന്നതിന് അത്തരമൊരു ഒഴിവാക്കൽ കോൺഫിഗർ ചെയ്യാൻ സാധിക്കും.
2. വെബ്‌സോക്കറ്റുകൾക്കായി, ഒരു സാധാരണ (വെബ്‌സോക്കറ്റ് ഇതര) ബ്രൗസർ അഭ്യർത്ഥനയ്‌ക്കിടെ ജനറേറ്റുചെയ്യുന്ന താൽക്കാലിക സെഷനുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് അദ്വിതീയവും സുരക്ഷിതവും പ്രതിരോധിക്കാവുന്നതുമായ ഒരു കണക്ഷൻ ഉണ്ടാക്കാം.
3. ഒരു പ്രോക്സി വെബ് സെർവർ (ബിൽറ്റ്-ഇൻ മൊഡ്യൂളുകളും ഫംഗ്ഷനുകളും മാത്രം) ഉപയോഗിച്ച് താൽക്കാലിക സെഷനുകൾ നടപ്പിലാക്കാൻ കഴിയും.
4. റെഡിമെയ്ഡ് അപ്പാച്ചെ മൊഡ്യൂളുകളായി താൽക്കാലിക സെഷൻ ടോക്കണുകൾ ഇതിനകം നടപ്പിലാക്കിയിട്ടുണ്ട്.
5. ഇന്ററാക്ഷൻ ഘടന യുക്തിസഹമായി രൂപകൽപ്പന ചെയ്തുകൊണ്ട് താൽക്കാലിക സെഷൻ ടോക്കണുകൾ നടപ്പിലാക്കാൻ കഴിയും.

നടപ്പിലാക്കിയ ശേഷം ദൃശ്യമാകുന്ന അവസ്ഥ.

ജോലിയുടെ ലക്ഷ്യം: സേവനങ്ങളുടെയും അടിസ്ഥാന സൗകര്യങ്ങളുടെയും മാനേജ്‌മെന്റ് ഐഒഎസിൽ ഒരു മൊബൈൽ ഫോണിൽ നിന്ന് അധിക പ്രോഗ്രാമുകളില്ലാതെ (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>

ആക്സസ് ലെവൽ മാറ്റുക.

ഈ രീതിക്ക് ഇനിപ്പറയുന്ന സൂക്ഷ്മതകളുണ്ട്:

• പ്രോക്‌സിഡ് റിസോഴ്‌സിലേക്കുള്ള അഭ്യർത്ഥനയ്ക്ക് ശേഷമാണ് സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണം സംഭവിക്കുന്നത്, അതായത് പോസ്റ്റ് അഭ്യർത്ഥന ഹാൻഡ്‌ഷേക്ക്. ഇതിനർത്ഥം, പ്രോക്സി ആദ്യം ലോഡ് ചെയ്യുകയും തുടർന്ന് പരിരക്ഷിത സേവനത്തിലേക്കുള്ള അഭ്യർത്ഥന കട്ട് ചെയ്യുകയും ചെയ്യും. ഇത് മോശമാണ്, പക്ഷേ വിമർശനമല്ല;
• 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"

ssl നെക്കുറിച്ചുള്ള കൂടുതൽ വിശദമായ വിവരങ്ങൾ ലേഖനത്തിൽ കാണാം: അപ്പാച്ചെ സെർവർ ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണം

രണ്ട് ഓപ്ഷനുകളും പരീക്ഷിച്ചു, http2 പ്രോട്ടോക്കോളുമായുള്ള വൈവിധ്യത്തിനും അനുയോജ്യതയ്ക്കും "b" ഓപ്ഷൻ തിരഞ്ഞെടുത്തു.

ഈ സിദ്ധാന്തത്തിന്റെ സ്ഥിരീകരണം പൂർത്തിയാക്കാൻ, കോൺഫിഗറേഷനുമായി ധാരാളം പരീക്ഷണങ്ങൾ നടത്തി; ഇനിപ്പറയുന്ന ഡിസൈനുകൾ പരീക്ഷിച്ചു:

if = ആവശ്യം = തിരുത്തിയെഴുതുക

• അപ്പാച്ചെ കോർ ഫീച്ചറുകൾ
• അപ്പാച്ചെ 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 സെർവറിലെ എക്സ്പ്രഷനുകൾ ഷാ1, %{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}

നിങ്ങൾക്ക് രണ്ട് അക്കങ്ങൾ മാത്രമേ താരതമ്യം ചെയ്യാൻ കഴിയൂ.

സഫാരി പ്രശ്‌നത്തിനുള്ള പരിഹാരത്തിനായി തിരയുമ്പോൾ, രസകരമായ ഒരു ലേഖനം ഞാൻ കണ്ടെത്തി: ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകൾ ഉപയോഗിച്ച് ഹോം അസിസ്റ്റന്റ് സുരക്ഷിതമാക്കുന്നു (സഫാരി/ഐഒഎസിൽ പ്രവർത്തിക്കുന്നു)
ഇത് Nginx-നുള്ള ലുവായിലെ കോഡിന്റെ ഒരു ഉദാഹരണം വിവരിക്കുന്നു, കൂടാതെ, ഹാഷിംഗിനായി hmac ഉപ്പിടൽ രീതി ഉപയോഗിക്കുന്നത് ഒഴികെ, ഞങ്ങൾ ഇതിനകം നടപ്പിലാക്കിയ കോൺഫിഗറേഷന്റെ ആ ഭാഗത്തിന്റെ യുക്തി വളരെ ആവർത്തിക്കുന്നു ( ഇത് അപ്പാച്ചെയിൽ കണ്ടെത്തിയില്ല).

ലുവാ വ്യക്തമായ യുക്തിയുള്ള ഒരു ഭാഷയാണെന്ന് വ്യക്തമായി, അപ്പാച്ചെയ്‌ക്ക് ലളിതമായ എന്തെങ്കിലും ചെയ്യാൻ കഴിയും:

• LuaHookAccessChecker നിർദ്ദേശം
• UnsetEnv നിർദ്ദേശം

Nginx, Apache എന്നിവയുമായുള്ള വ്യത്യാസം പഠിച്ചു:

• മൊഡ്യൂളുകൾ_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 

കാരണം Nginx-ൽ നിന്നുള്ള ഈ വിവരങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ള ആക്‌സസ് പരിശോധനകൾക്ക് ശേഷം മാത്രമേ LuaHookAccessChecker സജീവമാകൂ.

ഉറവിടത്തിലേക്കുള്ള ലിങ്ക് ചിത്രം.

ഒരു കാര്യം കൂടി.

പൊതുവേ, അപ്പാച്ചെ (ഒരുപക്ഷേ Nginx) കോൺഫിഗറേഷനിൽ ഏത് ക്രമത്തിലാണ് നിർദ്ദേശങ്ങൾ എഴുതിയിരിക്കുന്നത് എന്നത് പ്രശ്നമല്ല, കാരണം അവസാനം എല്ലാം ഉപയോക്താവിൽ നിന്നുള്ള അഭ്യർത്ഥനയുടെ ക്രമത്തെ അടിസ്ഥാനമാക്കി അടുക്കും, ഇത് പ്രോസസ്സിംഗിനുള്ള സ്കീമുമായി യോജിക്കുന്നു. ലുവാ സ്ക്രിപ്റ്റുകൾ.

പൂർത്തീകരണം:

നടപ്പിലാക്കിയതിന് ശേഷം ദൃശ്യമാകുന്ന അവസ്ഥ (ലക്ഷ്യം):
അധിക പ്രോഗ്രാമുകളില്ലാതെ (VPN), ഏകീകൃതവും സുരക്ഷിതവുമായ IOS-ൽ ഒരു മൊബൈൽ ഫോണിൽ നിന്ന് സേവനങ്ങളുടെയും അടിസ്ഥാന സൗകര്യങ്ങളുടെയും മാനേജ്മെന്റ് ലഭ്യമാണ്.

ലക്ഷ്യം കൈവരിച്ചു, വെബ് സോക്കറ്റുകൾ പ്രവർത്തിക്കുന്നു, കൂടാതെ ഒരു സർട്ടിഫിക്കറ്റിൽ കുറയാത്ത സുരക്ഷയും ഉണ്ട്.

അവലംബം: www.habr.com