কিভাবে আমরা ZeroTech এ Apple Safari এবং ক্লায়েন্ট সার্টিফিকেটকে ওয়েবসকেটের সাথে সংযুক্ত করেছি

নিবন্ধটি তাদের জন্য দরকারী হবে যারা:

• ক্লায়েন্ট শংসাপত্র কী তা জানে এবং কেন মোবাইল সাফারিতে ওয়েবসকেটের প্রয়োজন তা বোঝে;
• আমি একটি সীমিত বৃত্তের কাছে বা শুধুমাত্র নিজের কাছে ওয়েব পরিষেবা প্রকাশ করতে চাই;
• মনে করে যে সবকিছু ইতিমধ্যেই কেউ করেছে, এবং বিশ্বকে একটু বেশি সুবিধাজনক এবং নিরাপদ করতে চায়।

ওয়েবসকেটের ইতিহাস প্রায় 8 বছর আগে শুরু হয়েছিল। পূর্বে, পদ্ধতিগুলি দীর্ঘ HTTP অনুরোধের আকারে ব্যবহার করা হয়েছিল (আসলে প্রতিক্রিয়া): ব্যবহারকারীর ব্রাউজার সার্ভারে একটি অনুরোধ পাঠিয়েছিল এবং কিছু উত্তর দেওয়ার জন্য অপেক্ষা করেছিল, প্রতিক্রিয়ার পরে এটি আবার সংযুক্ত হয়েছিল এবং অপেক্ষা করেছিল। কিন্তু তারপর ওয়েবসকেট হাজির।



কয়েক বছর আগে, আমরা বিশুদ্ধ পিএইচপি-তে আমাদের নিজস্ব বাস্তবায়ন তৈরি করেছি, যা https অনুরোধগুলি ব্যবহার করতে পারে না, যেহেতু এটি লিঙ্ক স্তর। খুব বেশিদিন আগে, প্রায় সব ওয়েব সার্ভার https এর মাধ্যমে প্রক্সি রিকোয়েস্ট এবং কানেকশন সমর্থন করতে শিখেছে:আপগ্রেড।

যখন এটি ঘটেছিল, ওয়েবসকেটগুলি এসপিএ অ্যাপ্লিকেশনগুলির জন্য প্রায় ডিফল্ট পরিষেবা হয়ে ওঠে, কারণ সার্ভারের উদ্যোগে ব্যবহারকারীকে সামগ্রী সরবরাহ করা কতটা সুবিধাজনক (অন্য ব্যবহারকারীর কাছ থেকে একটি বার্তা প্রেরণ বা একটি চিত্র, নথি, উপস্থাপনার একটি নতুন সংস্করণ ডাউনলোড করুন যে অন্য কেউ বর্তমানে সম্পাদনা করছে)।

যদিও ক্লায়েন্ট শংসাপত্রটি বেশ কিছুদিন ধরে আছে, তবুও এটি এখনও খারাপভাবে সমর্থিত রয়ে গেছে, কারণ এটি বাইপাস করার চেষ্টা করার সময় এটি অনেক সমস্যা তৈরি করে। এবং (সম্ভবত :slightly_smiling_face: ) সেই কারণেই IOS ব্রাউজারগুলি (সাফারি ছাড়া) এটি ব্যবহার করতে চায় না এবং স্থানীয় শংসাপত্রের দোকান থেকে এটির জন্য অনুরোধ করে। লগইন/পাস বা ssh কী বা ফায়ারওয়ালের মাধ্যমে প্রয়োজনীয় পোর্ট বন্ধ করার তুলনায় সার্টিফিকেটের অনেক সুবিধা রয়েছে। কিন্তু যে এই সম্পর্কে কি না.

আইওএস-এ, একটি শংসাপত্র ইনস্টল করার পদ্ধতিটি বেশ সহজ (নির্দিষ্টভাবে নয়), তবে সাধারণভাবে এটি নির্দেশাবলী অনুসারে করা হয়, যার মধ্যে ইন্টারনেটে অনেকগুলি রয়েছে এবং যা শুধুমাত্র সাফারি ব্রাউজারের জন্য উপলব্ধ। দুর্ভাগ্যবশত, Safari ওয়েব সকেটের জন্য ক্লায়েন্ট Сert কীভাবে ব্যবহার করতে হয় তা জানে না, তবে কীভাবে এই ধরনের শংসাপত্র তৈরি করতে হয় সে সম্পর্কে ইন্টারনেটে অনেক নির্দেশাবলী রয়েছে, কিন্তু বাস্তবে এটি অপ্রাপ্য।

ওয়েবসকেট বোঝার জন্য, আমরা নিম্নলিখিত পরিকল্পনা ব্যবহার করেছি: সমস্যা/অনুমান/সমাধান।

সমস্যা: IOS এর জন্য Safari মোবাইল ব্রাউজারে একটি ক্লায়েন্ট শংসাপত্র দ্বারা সুরক্ষিত সংস্থানগুলির অনুরোধ প্রক্সি করার সময় ওয়েব সকেটগুলির জন্য কোনও সমর্থন নেই এবং শংসাপত্র সমর্থন সক্ষম করা অন্যান্য অ্যাপ্লিকেশনগুলির জন্য।

অনুমান:

1. অভ্যন্তরীণ/বাহ্যিক প্রক্সি রিসোর্সের ওয়েবসকেটগুলিতে সার্টিফিকেট ব্যবহার করার জন্য (কোনোটিই থাকবে না জেনে) এই ধরনের ব্যতিক্রম কনফিগার করা সম্ভব।
2. ওয়েবসকেটের জন্য, আপনি অস্থায়ী সেশনগুলি ব্যবহার করে একটি অনন্য, সুরক্ষিত এবং প্রতিরক্ষাযোগ্য সংযোগ তৈরি করতে পারেন যা একটি সাধারণ (নন-ওয়েবসকেট) ব্রাউজার অনুরোধের সময় তৈরি হয়।
3. একটি প্রক্সি ওয়েব সার্ভার ব্যবহার করে অস্থায়ী সেশন প্রয়োগ করা যেতে পারে (শুধুমাত্র অন্তর্নির্মিত মডিউল এবং ফাংশন)।
4. অস্থায়ী সেশন টোকেনগুলি ইতিমধ্যে প্রস্তুত-তৈরি Apache মডিউল হিসাবে প্রয়োগ করা হয়েছে৷
5. অস্থায়ী সেশন টোকেনগুলি যুক্তিযুক্তভাবে মিথস্ক্রিয়া কাঠামো ডিজাইন করে প্রয়োগ করা যেতে পারে।

বাস্তবায়নের পর দৃশ্যমান অবস্থা।

কাজের লক্ষ্য: পরিষেবা এবং পরিকাঠামোর ব্যবস্থাপনা অতিরিক্ত প্রোগ্রাম (যেমন VPN), ইউনিফাইড এবং সুরক্ষিত ছাড়া 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 প্রোটোকলে। এটি এখনও খসড়ায় রয়েছে, এবং ব্রাউজার নির্মাতারা জানেন না কিভাবে এটি বাস্তবায়ন করতে হয় #info about tls1.3 http2 পোস্ট হ্যান্ডশেক (এখন কাজ করছে না) RFC 8740 প্রয়োগ করুন "HTTP/1.3 এর সাথে TLS 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"

এসএসএল সম্পর্কে নিবন্ধে আরও বিশদ তথ্য পাওয়া যাবে: অ্যাপাচি সার্ভার ক্লায়েন্ট সার্টিফিকেট প্রমাণীকরণ

উভয় বিকল্পই পরীক্ষা করা হয়েছিল, বিকল্প "b" বেছে নেওয়া হয়েছিল এর বহুমুখিতা এবং HTTP2 প্রোটোকলের সাথে সামঞ্জস্যের জন্য।

এই অনুমানটির যাচাইকরণ সম্পূর্ণ করতে, এটি কনফিগারেশনের সাথে অনেক পরীক্ষা নিরীক্ষা করেছে; নিম্নলিখিত ডিজাইনগুলি পরীক্ষা করা হয়েছিল:

if = প্রয়োজন = পুনর্লিখন

• অ্যাপাচি মূল বৈশিষ্ট্য
• 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 এর অনেকগুলি মূল কার্যকারিতা রয়েছে যা আপনাকে শর্তসাপেক্ষ গঠন তৈরি করতে দেয়। যাইহোক, ব্যবহারকারীর ব্রাউজারে থাকাকালীন আমাদের তথ্য সুরক্ষিত করার জন্য আমাদের প্রয়োজন, তাই আমরা কী সঞ্চয় করব এবং কেন করব এবং আমরা কী বিল্ট-ইন ফাংশন ব্যবহার করব তা নির্ধারণ করি:

• আমাদের একটি টোকেন দরকার যা সহজে ডিকোড করা যায় না।
• আমাদের এমন একটি টোকেন দরকার যার মধ্যে অপ্রচলিততা রয়েছে এবং সার্ভারে অপ্রচলিততা পরীক্ষা করার ক্ষমতা রয়েছে।
• আমাদের একটি টোকেন দরকার যা শংসাপত্রের মালিকের সাথে যুক্ত হবে৷

এর জন্য একটি হ্যাশিং ফাংশন, একটি লবণ এবং টোকেনের বয়সের জন্য একটি তারিখ প্রয়োজন৷ ডকুমেন্টেশন উপর ভিত্তি করে 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 ওয়েব টোকেনের উপর ভিত্তি করে টোকেন ব্যবহার করে ক্লায়েন্ট প্রমাণীকরণ
• Apache টু-ফ্যাক্টর (2FA) প্রমাণীকরণ
• কিভাবে Apache এ দুই-ফ্যাক্টর প্রমাণীকরণ যোগ করবেন
• একটি সাধারণ মডিউল ইনস্টলের সাথে আপনার অ্যাপাচি উদাহরণে দ্বি-ফ্যাক্টর প্রমাণীকরণ আনুন

হ্যাঁ, রেডিমেড মডিউল আছে, কিন্তু সেগুলি সবই নির্দিষ্ট ক্রিয়াকলাপের সাথে আবদ্ধ এবং একটি সেশন এবং অতিরিক্ত কুকিজ শুরু করার আকারে আর্টিফ্যাক্ট রয়েছে৷ অর্থাৎ কিছুক্ষণের জন্য নয়।
অনুসন্ধান করতে আমাদের পাঁচ ঘন্টা সময় লেগেছে, যা একটি নির্দিষ্ট ফলাফল দেয়নি।

5. অস্থায়ী সেশন টোকেনগুলিকে যুক্তিযুক্তভাবে মিথস্ক্রিয়াগুলির কাঠামো ডিজাইন করে প্রয়োগ করা যেতে পারে।

রেডিমেড মডিউল খুব জটিল, কারণ আমাদের শুধুমাত্র কয়েকটি ফাংশন দরকার।

বলা হচ্ছে, তারিখের সাথে সমস্যা হল যে Apache-এর অন্তর্নির্মিত ফাংশনগুলি ভবিষ্যতে থেকে একটি তারিখ তৈরি করার অনুমতি দেয় না এবং অপ্রচলিততা পরীক্ষা করার সময় অন্তর্নির্মিত ফাংশনে কোনও গাণিতিক যোগ/বিয়োগ নেই।

অর্থাৎ, আপনি লিখতে পারবেন না:

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

আপনি শুধুমাত্র দুটি সংখ্যা তুলনা করতে পারেন.

সাফারি সমস্যার জন্য একটি সমাধান অনুসন্ধান করার সময়, আমি একটি আকর্ষণীয় নিবন্ধ খুঁজে পেয়েছি: ক্লায়েন্ট সার্টিফিকেট সহ হোম অ্যাসিস্ট্যান্ট সুরক্ষিত করা (সাফারি/আইওএস এর সাথে কাজ করে)
এটি Nginx-এর জন্য লুয়াতে কোডের একটি উদাহরণ বর্ণনা করে, এবং এটি যেমন দেখা গেছে, হ্যাশিংয়ের জন্য hmac সল্টিং পদ্ধতির ব্যবহার বাদ দিয়ে, আমরা ইতিমধ্যে যে কনফিগারেশনটি প্রয়োগ করেছি তার অংশটির যুক্তির পুনরাবৃত্তি করে ( এটি Apache এ পাওয়া যায়নি)।

এটা স্পষ্ট হয়ে গেল যে লুয়া হল একটি সুস্পষ্ট যুক্তিযুক্ত ভাষা, এবং অ্যাপাচির জন্য সহজ কিছু করা সম্ভব:

• LuaHookAccessChecker নির্দেশিকা
• UnsetEnv নির্দেশিকা

Nginx এবং Apache এর সাথে পার্থক্য অধ্যয়ন করে:

• মডিউল_লুয়া
• lua_load_resty_core

এবং 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 

কারণ LuaHookAccessChecker শুধুমাত্র Nginx থেকে এই তথ্যের উপর ভিত্তি করে অ্যাক্সেস চেক করার পরে সক্রিয় করা হবে।

উৎস লিঙ্ক ভাবমূর্তি.

আরও এক মুহূর্ত।

সাধারণভাবে, Apache (সম্ভবত Nginx) কনফিগারেশনে নির্দেশাবলী কোন ক্রমে লেখা হয়েছে তা বিবেচ্য নয়, যেহেতু শেষ পর্যন্ত ব্যবহারকারীর অনুরোধের আদেশের ভিত্তিতে সবকিছু সাজানো হবে, যা প্রক্রিয়াকরণের স্কিমের সাথে মিলে যায়। লুয়া স্ক্রিপ্ট।

সমাপ্তি:

বাস্তবায়নের পর দৃশ্যমান অবস্থা (লক্ষ্য):
অতিরিক্ত প্রোগ্রাম (VPN), ইউনিফাইড এবং সুরক্ষিত ছাড়া IOS-এ মোবাইল ফোন থেকে পরিষেবা এবং পরিকাঠামোর ব্যবস্থাপনা উপলব্ধ।

লক্ষ্য অর্জন করা হয়েছে, ওয়েব সকেট কাজ করে এবং একটি শংসাপত্রের চেয়ে কম নিরাপত্তার স্তর রয়েছে।

উত্স: www.habr.com