🥇როგორ დავაკავშირეთ ZeroTech-ში Apple Safari და კლიენტის სერთიფიკატები ვებსოკეტებით

სტატია სასარგებლო იქნება მათთვის, ვინც:

იცის რა არის Client Cert და ესმის, რატომ სჭირდება მას ვებსოკეტები მობილური Safari-ზე;
მსურს ვებ სერვისების გამოქვეყნება ადამიანთა შეზღუდულ წრეზე ან მხოლოდ საკუთარ თავს;
ფიქრობს, რომ ყველაფერი უკვე გაკეთებულია ვიღაცის მიერ და სურს სამყარო ცოტა უფრო მოსახერხებელი და უსაფრთხო გახადოს.

ვებსოკეტების ისტორია დაახლოებით 8 წლის წინ დაიწყო. ადრე გამოიყენებოდა ისეთი მეთოდები, როგორიცაა გრძელი http მოთხოვნები (რეალურად პასუხები): მომხმარებლის ბრაუზერი უგზავნიდა მოთხოვნას სერვერს და ელოდა მის პასუხს, პასუხის შემდეგ ისევ დაუკავშირდა და დაელოდა. მაგრამ შემდეგ გამოჩნდა ვებსოკეტები.

რამდენიმე წლის წინ ჩვენ შევიმუშავეთ ჩვენი საკუთარი იმპლემენტაცია სუფთა PHP-ში, რომელიც ვერ იყენებს https მოთხოვნებს, რადგან ეს არის ბმულის ფენა. არც ისე დიდი ხნის წინ, თითქმის ყველა ვებ სერვერმა ისწავლა მარიონეტული მოთხოვნები https-ზე და მხარდაჭერა კავშირი: განახლება.

როდესაც ეს მოხდა, ვებსოკეტები გახდა თითქმის ნაგულისხმევი სერვისი SPA აპლიკაციებისთვის, რადგან რამდენად მოსახერხებელია მომხმარებლისთვის შინაარსის მიწოდება სერვერის ინიციატივით (მესიჯის გადაცემა სხვა მომხმარებლისგან ან ჩამოტვირთეთ სურათის, დოკუმენტის, პრეზენტაციის ახალი ვერსია. რომელსაც სხვა ამჟამად არედაქტირებს) .

მიუხედავად იმისა, რომ კლიენტის სერთიფიკატი საკმაოდ დიდი ხანია არსებობს, ის მაინც ცუდად არის მხარდაჭერილი, რადგან უამრავ პრობლემას ქმნის მის გვერდის ავლით. და (შესაძლოა :slightly_smiling_face: ) ამიტომ IOS ბრაუზერებს (ყველა Safari-ს გარდა) არ სურთ მისი გამოყენება და მოითხოვონ ადგილობრივი სერტიფიკატების მაღაზიიდან. სერთიფიკატებს ბევრი უპირატესობა აქვთ შესვლის/გავლის ან ssh კლავიშებთან ან საჭირო პორტების დახურვასთან შედარებით Firewall-ის საშუალებით. მაგრამ ეს არ არის ის, რაც ეხება.

iOS-ზე სერთიფიკატის დაყენების პროცედურა საკმაოდ მარტივია (კონკრეტიკის გარეშე არ არის), მაგრამ ზოგადად ეს კეთდება ინსტრუქციების მიხედვით, რომელთაგან ბევრია ინტერნეტში და რომელიც ხელმისაწვდომია მხოლოდ Safari ბრაუზერისთვის. სამწუხაროდ, Safari-მ არ იცის როგორ გამოიყენოს Client Сert ვებ-სოკეტებისთვის, მაგრამ ინტერნეტში არის მრავალი ინსტრუქცია, თუ როგორ უნდა შექმნათ ასეთი სერტიფიკატი, მაგრამ პრაქტიკაში ეს მიუღწეველია.

ვებსოკეტების გასაგებად, ჩვენ გამოვიყენეთ შემდეგი გეგმა: პრობლემა/ჰიპოთეზა/გადაწყვეტა.

პრობლემა: არ არსებობს ვებ-სოკეტების მხარდაჭერა რესურსებზე მოთხოვნების პროქსირებისას, რომლებიც დაცულია კლიენტის სერთიფიკატით Safari მობილური ბრაუზერში IOS-ისთვის და სხვა აპლიკაციებისთვის, რომლებსაც აქვთ სერთიფიკატის მხარდაჭერა.

ჰიპოთეზები:

შესაძლებელია ასეთი გამონაკლისის კონფიგურაცია, რათა გამოიყენოს სერთიფიკატები (ვიცოდეთ, რომ არ იქნება) შიდა/გარე პროქსიული რესურსების ვებსოკეტებში.
ვებსოკეტებისთვის შეგიძლიათ შექმნათ უნიკალური, უსაფრთხო და დაცული კავშირი დროებითი სესიების გამოყენებით, რომლებიც წარმოიქმნება ბრაუზერის ჩვეულებრივი (არავებსოკეტის) მოთხოვნის დროს.
დროებითი სესიების განხორციელება შესაძლებელია ერთი პროქსი ვებ სერვერის გამოყენებით (მხოლოდ ჩაშენებული მოდულები და ფუნქციები).
დროებითი სესიის ტოკენები უკვე დანერგილია როგორც მზა Apache მოდულები.
დროებითი სესიის ნიშნები შეიძლება განხორციელდეს ურთიერთქმედების სტრუქტურის ლოგიკური დიზაინით.

ხილული მდგომარეობა განხორციელების შემდეგ.

სამუშაოს მიზანი: სერვისებისა და ინფრასტრუქტურის მართვა ხელმისაწვდომი უნდა იყოს მობილური ტელეფონიდან 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-ის დანერგვა "TLS 1.3-ის გამოყენება HTTP/2-ით";
არ არის ნათელი, თუ როგორ უნდა მოხდეს ამ დამუშავების გაერთიანება.

ბ) საბაზისო დონეზე დაუშვათ 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-ის შესახებ: Apache სერვერის კლიენტის სერთიფიკატის ავთენტიფიკაცია

ორივე ვარიანტი შემოწმდა, ვარიანტი "b" არჩეული იყო მისი მრავალფეროვნებისა და 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), დამატებითი დეტალები დოკუმენტაციაში:

Apache Module 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

დიახ, არის მზა მოდულები, მაგრამ ისინი ყველა დაკავშირებულია კონკრეტულ ქმედებებთან და აქვთ არტეფაქტები სესიის დაწყების და დამატებითი ქუქიების სახით. ანუ ცოტა ხნით არა.
ძებნას ხუთი საათი დაგვჭირდა, რამაც კონკრეტული შედეგი არ გამოიღო.

5. დროებითი სესიის ნიშნები შეიძლება განხორციელდეს ურთიერთქმედების სტრუქტურის ლოგიკური დიზაინით.

მზა მოდულები ძალიან რთულია, რადგან ჩვენ გვჭირდება მხოლოდ რამდენიმე ფუნქცია.

როგორც ითქვა, თარიღთან დაკავშირებული პრობლემა ის არის, რომ Apache-ს ჩაშენებული ფუნქციები არ იძლევა მომავლის თარიღის გენერირების საშუალებას და არ არის მათემატიკური დამატება/გამოკლება ჩაშენებულ ფუნქციებში მოძველების შემოწმებისას.

ანუ თქვენ არ შეგიძლიათ დაწეროთ:

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

შეგიძლიათ მხოლოდ ორი რიცხვის შედარება.

Safari პრობლემის გამოსავლის ძიებისას, აღმოვაჩინე საინტერესო სტატია: HomeAssistant-ის დაცვა კლიენტის სერთიფიკატებით (მუშაობს Safari/iOS-თან)
იგი აღწერს კოდის მაგალითს Lua-ში Nginx-ისთვის, და რომელიც, როგორც გაირკვა, ძალიან იმეორებს კონფიგურაციის იმ ნაწილის ლოგიკას, რომელიც ჩვენ უკვე განვახორციელეთ, გარდა ჰეშირებისთვის hmac salting მეთოდის გამოყენებისა ( ეს არ იქნა ნაპოვნი Apache-ში).

გაირკვა, რომ ლუა მკაფიო ლოგიკის მქონე ენაა და აპაჩისთვის რაღაც მარტივის გაკეთება შესაძლებელია:

Nginx-სა და Apache-სთან განსხვავების შესწავლის შემდეგ:

და ხელმისაწვდომი ფუნქციები Lua ენის მწარმოებლისგან:
22.1 - თარიღი და დრო

ჩვენ ვიპოვნეთ გზა, რომ დავაყენოთ env ცვლადები პატარა Lua ფაილში, რათა დავნიშნოთ თარიღი მომავლისგან, რათა შევადაროთ მიმდინარე.

ასე გამოიყურება მარტივი ლუას სკრიპტი:

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) კონფიგურაციაში, რადგან საბოლოოდ ყველაფერი დალაგდება მომხმარებლის მოთხოვნის თანმიმდევრობის მიხედვით, რომელიც შეესაბამება დამუშავების სქემას. ლუას სკრიპტები.

Დასრულება:

ხილული მდგომარეობა განხორციელების შემდეგ (მიზანი):
სერვისებისა და ინფრასტრუქტურის მართვა ხელმისაწვდომია მობილური ტელეფონიდან IOS-ზე დამატებითი პროგრამების (VPN) გარეშე, ერთიანი და უსაფრთხო.

მიზანი მიღწეულია, ვებ-სოკეტები მუშაობენ და აქვთ უსაფრთხოების დონე არანაკლებ სერტიფიკატი.

წყარო: www.habr.com

როგორ დავაკავშირეთ ჩვენ ZeroTech-ში Apple Safari და კლიენტის სერთიფიკატები ვებსოკეტებთან

ახალი კომენტარის დამატება

როგორ დავაკავშირეთ ჩვენ ZeroTech-ში Apple Safari და კლიენტის სერთიფიკატები ვებსოკეტებთან

ახალი კომენტარის დამატება პასუხის გასაუქმებლად

ახალი კომენტარის დამატება