🥇ZeroTech இல் ஆப்பிள் சஃபாரி மற்றும் கிளையன்ட் சான்றிதழ்களை வெப்சாக்கெட்டுகளுடன் எவ்வாறு இணைத்தோம்

கட்டுரை உள்ளவர்களுக்கு பயனுள்ளதாக இருக்கும்:

Client Cert என்றால் என்ன என்பதை அறிந்து, அதற்கு மொபைல் சஃபாரியில் வெப்சாக்கெட்டுகள் ஏன் தேவை என்பதைப் புரிந்துகொள்வது;
நான் வலை சேவைகளை ஒரு குறிப்பிட்ட வட்டத்திற்கு அல்லது எனக்கு மட்டும் வெளியிட விரும்புகிறேன்;
எல்லாவற்றையும் ஏற்கனவே யாரோ செய்திருக்கிறார்கள் என்று நினைக்கிறார், மேலும் உலகத்தை இன்னும் கொஞ்சம் வசதியாகவும் பாதுகாப்பாகவும் மாற்ற விரும்புகிறார்.

வெப்சாக்கெட்டுகளின் வரலாறு சுமார் 8 ஆண்டுகளுக்கு முன்பு தொடங்கியது. முன்னதாக, முறைகள் நீண்ட http கோரிக்கைகள் (உண்மையில் பதில்கள்) வடிவத்தில் பயன்படுத்தப்பட்டன: பயனரின் உலாவி சேவையகத்திற்கு ஒரு கோரிக்கையை அனுப்பியது மற்றும் அதற்கு பதிலளிக்கும் வரை காத்திருந்தது, பதிலுக்குப் பிறகு அது மீண்டும் இணைக்கப்பட்டு காத்திருந்தது. ஆனால் பின்னர் வெப்சாக்கெட்டுகள் தோன்றின.

சில ஆண்டுகளுக்கு முன்பு, இது இணைப்பு அடுக்கு என்பதால், https கோரிக்கைகளைப் பயன்படுத்த முடியாத சுத்தமான PHP இல் எங்கள் சொந்த செயலாக்கத்தை நாங்கள் உருவாக்கினோம். நீண்ட காலத்திற்கு முன்பு, கிட்டத்தட்ட எல்லா இணைய சேவையகங்களும் https மற்றும் ஆதரவு இணைப்பு:மேம்படுத்தல் மூலம் கோரிக்கைகளை ப்ராக்ஸி செய்ய கற்றுக்கொண்டன.

இது நிகழும்போது, வெப்சாக்கெட்டுகள் SPA பயன்பாடுகளுக்கான இயல்புநிலை சேவையாக மாறியது, ஏனெனில் சேவையகத்தின் முயற்சியில் பயனருக்கு உள்ளடக்கத்தை வழங்குவது எவ்வளவு வசதியானது (மற்றொரு பயனரிடமிருந்து ஒரு செய்தியை அனுப்பவும் அல்லது படம், ஆவணம், விளக்கக்காட்சியின் புதிய பதிப்பைப் பதிவிறக்கவும். தற்போது வேறு யாரோ திருத்துகிறார்கள்) .

கிளையண்ட் சான்றிதழ் சில காலமாக இருந்தாலும், அது இன்னும் மோசமாக ஆதரிக்கப்படுகிறது, ஏனெனில் அதைத் தவிர்க்க முயற்சிக்கும்போது அது நிறைய சிக்கல்களை உருவாக்குகிறது. மேலும் (சாத்தியமாக :slightly_smiling_face: ) அதனால்தான் IOS உலாவிகள் (சஃபாரி தவிர அனைத்தும்) இதைப் பயன்படுத்த விரும்பவில்லை மற்றும் உள்ளூர் சான்றிதழ் கடையில் இருந்து அதைக் கோருகின்றன. உள்நுழைவு/பாஸ் அல்லது ssh விசைகள் அல்லது ஃபயர்வால் மூலம் தேவையான போர்ட்களை மூடுவது ஆகியவற்றுடன் ஒப்பிடும்போது சான்றிதழ்கள் பல நன்மைகளைக் கொண்டுள்ளன. ஆனால் இது பற்றி அல்ல.

IOS இல், சான்றிதழை நிறுவுவதற்கான செயல்முறை மிகவும் எளிமையானது (குறிப்பிட்டவை இல்லாமல் இல்லை), ஆனால் பொதுவாக இது அறிவுறுத்தல்களின்படி செய்யப்படுகிறது, அவற்றில் இணையத்தில் நிறைய உள்ளன மற்றும் அவை சஃபாரி உலாவிக்கு மட்டுமே கிடைக்கின்றன. துரதிர்ஷ்டவசமாக, வலை சாக்கெட்டுகளுக்கு Client Сert ஐ எவ்வாறு பயன்படுத்துவது என்பது Safariக்கு தெரியாது, ஆனால் அத்தகைய சான்றிதழை எவ்வாறு உருவாக்குவது என்பது குறித்து இணையத்தில் பல வழிமுறைகள் உள்ளன, ஆனால் நடைமுறையில் இது அடைய முடியாதது.

வெப்சாக்கெட்டுகளைப் புரிந்து கொள்ள, பின்வரும் திட்டத்தைப் பயன்படுத்தினோம்: பிரச்சனை/கருதுகோள்/தீர்வு.

பிரச்சனை: IOS மற்றும் சான்றிதழ் ஆதரவை இயக்கிய பிற பயன்பாடுகளுக்கான Safari மொபைல் உலாவியில் கிளையன்ட் சான்றிதழால் பாதுகாக்கப்பட்ட ஆதாரங்களுக்கான கோரிக்கைகளை ப்ராக்ஸி செய்யும் போது வலை சாக்கெட்டுகளுக்கு ஆதரவு இல்லை.

கருதுகோள்கள்:

அக/வெளிப்புற ப்ராக்ஸி ஆதாரங்களின் வெப்சாக்கெட்டுகளுக்கு சான்றிதழ்களைப் பயன்படுத்துவதற்கு (எதுவும் இருக்காது என்பதை அறிந்து) அத்தகைய விதிவிலக்கை உள்ளமைக்க முடியும்.
வெப்சாக்கெட்டுகளுக்கு, சாதாரண (வெப்சாக்கெட் அல்லாத) உலாவி கோரிக்கையின் போது உருவாக்கப்பட்ட தற்காலிக அமர்வுகளைப் பயன்படுத்தி நீங்கள் ஒரு தனித்துவமான, பாதுகாப்பான மற்றும் பாதுகாக்கக்கூடிய இணைப்பை உருவாக்கலாம்.
ஒரு ப்ராக்ஸி வலை சேவையகத்தைப் பயன்படுத்தி தற்காலிக அமர்வுகளை செயல்படுத்தலாம் (உள்ளமைக்கப்பட்ட தொகுதிகள் மற்றும் செயல்பாடுகள் மட்டும்).
தற்காலிக அமர்வு டோக்கன்கள் ஏற்கனவே தயார் செய்யப்பட்ட அப்பாச்சி தொகுதிகளாக செயல்படுத்தப்பட்டுள்ளன.
இடைவினை கட்டமைப்பை தர்க்கரீதியாக வடிவமைப்பதன் மூலம் தற்காலிக அமர்வு டோக்கன்களை செயல்படுத்தலாம்.

செயல்படுத்தப்பட்ட பிறகு தெரியும் நிலை.

குறிக்கோள்: சேவைகள் மற்றும் உள்கட்டமைப்பின் மேலாண்மை ஆகியவை 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>

அணுகல் அளவை மாற்றவும்.

இந்த முறை பின்வரும் நுணுக்கங்களைக் கொண்டுள்ளது:

ப்ராக்ஸிட் ஆதாரத்திற்கான கோரிக்கைக்குப் பிறகு சான்றிதழ் சரிபார்ப்பு நிகழ்கிறது, அதாவது கோரிக்கைக்குப் பின் கைகுலுக்கல். அதாவது, ப்ராக்ஸி முதலில் ஏற்றப்படும், பின்னர் பாதுகாக்கப்பட்ட சேவைக்கான கோரிக்கையை துண்டிக்கும். இது மோசமானது, ஆனால் விமர்சனம் அல்ல;
http2 நெறிமுறையில். இது இன்னும் வரைவில் உள்ளது, மேலும் உலாவி உற்பத்தியாளர்களுக்கு அதை எவ்வாறு செயல்படுத்துவது என்று தெரியவில்லை #tls1.3 http2 போஸ்ட் ஹேண்ட்ஷேக் (இப்போது வேலை செய்யவில்லை) RFC 8740 ஐ செயல்படுத்தவும் "TLS 1.3 ஐ HTTP/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" தேர்ந்தெடுக்கப்பட்டது.

இந்த கருதுகோளின் சரிபார்ப்பை முடிக்க, இது உள்ளமைவுடன் நிறைய சோதனைகளை எடுத்தது; பின்வரும் வடிவமைப்புகள் சோதிக்கப்பட்டன:

என்றால் = தேவை = மீண்டும் எழுது

இதன் விளைவாக பின்வரும் அடிப்படை வடிவமைப்பு உள்ளது:

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 என்ற வார்த்தைகளின்படி இதைச் செய்யும் ஆயத்த தொகுதிக்காக நாங்கள் தேடுகிறோம்

ஆம், ஆயத்த தொகுதிகள் உள்ளன, ஆனால் அவை அனைத்தும் குறிப்பிட்ட செயல்களுடன் பிணைக்கப்பட்டுள்ளன மற்றும் ஒரு அமர்வு மற்றும் கூடுதல் குக்கீகளைத் தொடங்கும் வடிவத்தில் கலைப்பொருட்கள் உள்ளன. அதாவது, சிறிது காலத்திற்கு அல்ல.
நாங்கள் தேட ஐந்து மணிநேரம் ஆனது, அது உறுதியான முடிவைக் கொடுக்கவில்லை.

5. இடைவினைகளின் கட்டமைப்பை தர்க்கரீதியாக வடிவமைப்பதன் மூலம் தற்காலிக அமர்வு டோக்கன்களை செயல்படுத்தலாம்.

ஆயத்த தொகுதிகள் மிகவும் சிக்கலானவை, ஏனென்றால் எங்களுக்கு இரண்டு செயல்பாடுகள் மட்டுமே தேவை.

அப்படிச் சொல்லப்பட்டால், தேதியில் உள்ள சிக்கல் என்னவென்றால், அப்பாச்சியின் உள்ளமைக்கப்பட்ட செயல்பாடுகள் எதிர்காலத்திலிருந்து ஒரு தேதியை உருவாக்க அனுமதிக்காது, மேலும் காலாவதியானதைச் சரிபார்க்கும்போது உள்ளமைக்கப்பட்ட செயல்பாடுகளில் கணிதக் கூட்டல்/கழித்தல் எதுவும் இல்லை.

அதாவது, நீங்கள் எழுத முடியாது:

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

நீங்கள் இரண்டு எண்களை மட்டுமே ஒப்பிட முடியும்.

சஃபாரி பிரச்சனைக்கு தீர்வு தேடும் போது, ஒரு சுவாரஸ்யமான கட்டுரை கிடைத்தது: கிளையன்ட் சான்றிதழ்களுடன் HomeAssistant ஐப் பாதுகாத்தல் (Safari/iOS உடன் வேலை செய்கிறது)
இது Nginx க்கான லுவாவில் உள்ள குறியீட்டின் உதாரணத்தை விவரிக்கிறது, மேலும் இது ஹாஷிங்கிற்கான hmac சால்ட்டிங் முறையைப் பயன்படுத்துவதைத் தவிர, நாங்கள் ஏற்கனவே செயல்படுத்திய உள்ளமைவின் அந்த பகுதியின் தர்க்கத்தை மீண்டும் மீண்டும் செய்கிறது ( இது அப்பாச்சியில் காணப்படவில்லை).

லுவா தெளிவான தர்க்கத்துடன் கூடிய மொழி என்பது தெளிவாகியது, மேலும் அப்பாச்சிக்கு எளிமையான ஒன்றைச் செய்ய முடியும்:

Nginx மற்றும் Apache உடன் வேறுபாட்டைப் படித்த பிறகு:

Lua மொழி உற்பத்தியாளரிடமிருந்து கிடைக்கும் செயல்பாடுகள்:
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 செயல்படுத்தப்படும்.

ஆதாரத்திற்கான இணைப்பு படத்தை.

மேலும் ஒரு விஷயம்.

பொதுவாக, Apache (அநேகமாக Nginx) உள்ளமைவில் கட்டளைகள் எந்த வரிசையில் எழுதப்பட்டுள்ளன என்பது முக்கியமல்ல, ஏனெனில் இறுதியில் அனைத்தும் பயனரின் கோரிக்கையின் வரிசையின் அடிப்படையில் வரிசைப்படுத்தப்படும், இது செயலாக்க திட்டத்திற்கு ஒத்திருக்கிறது. லுவா ஸ்கிரிப்டுகள்.

நிறைவு:

செயல்படுத்தப்பட்ட பிறகு தெரியும் நிலை (இலக்கு):
சேவைகள் மற்றும் உள்கட்டமைப்பு மேலாண்மை என்பது IOS இல் மொபைல் ஃபோனில் இருந்து கூடுதல் திட்டங்கள் (VPN) இல்லாமல், ஒருங்கிணைந்த மற்றும் பாதுகாப்பானது.

இலக்கு அடையப்பட்டது, வெப்சாக்கெட்டுகள் செயல்படுகின்றன மற்றும் ஒரு சான்றிதழுக்கு குறையாத பாதுகாப்பு நிலை உள்ளது.

ஆதாரம்: www.habr.com

ZeroTech இல் நாங்கள் ஆப்பிள் சஃபாரி மற்றும் கிளையன்ட் சான்றிதழ்களை வெப்சாக்கெட்டுகளுடன் எவ்வாறு இணைத்தோம்

கருத்தைச் சேர் Отменить ответ