Как ние от ZeroTech свързахме Apple Safari и клиентски сертификати с websockets

Статията ще бъде полезна за тези, които:

• знае какво е Client Cert и разбира защо има нужда от websockets на мобилно Safari;
• Бих искал да публикувам уеб услуги за ограничен кръг хора или само за себе си;
• смята, че всичко вече е направено от някой и би искал да направи света малко по-удобен и по-безопасен.

Историята на websockets започва преди около 8 години. Преди това методите бяха използвани под формата на дълги http заявки (всъщност отговори): браузърът на потребителя изпрати заявка до сървъра и изчака той да отговори нещо, след отговора се свърза отново и изчака. Но тогава се появиха websockets.



Преди няколко години разработихме наша собствена реализация в чист PHP, която не може да използва https заявки, тъй като това е слоят за връзки. Неотдавна почти всички уеб сървъри се научиха да прокси заявки през https и поддържат връзка: надстройка.

Когато това се случи, websockets стана почти услугата по подразбиране за SPA приложения, защото колко удобно е да се предостави съдържание на потребителя по инициатива на сървъра (предаване на съобщение от друг потребител или изтегляне на нова версия на изображение, документ, презентация че някой друг в момента редактира) .

Въпреки че клиентският сертификат съществува от доста време, той все още остава слабо поддържан, тъй като създава много проблеми, когато се опитвате да го заобиколите. И (вероятно :slightly_smiling_face: ) затова браузърите на IOS (всички с изключение на Safari) не искат да го използват и го изискват от локалното хранилище за сертификати. Сертификатите имат много предимства в сравнение с login/pass или ssh ключовете или затварянето на необходимите портове през защитна стена. Но не става въпрос за това.

В iOS процедурата за инсталиране на сертификат е доста проста (не без специфики), но като цяло се извършва според инструкциите, от които има много в интернет и които са достъпни само за браузъра Safari. За съжаление Safari не знае как да използва Client Сert за уеб сокети, но в интернет има много инструкции как да създадете такъв сертификат, но на практика това е непостижимо.

За да разберем websockets, използвахме следния план: проблем/хипотеза/решение.

Проблем: няма поддръжка за уеб сокети при прокси заявки към ресурси, които са защитени от клиентски сертификат в мобилния браузър Safari за IOS и други приложения, които са активирали поддръжка на сертификати.

Хипотези:

1. Възможно е да се конфигурира такова изключение за използване на сертификати (като се знае, че няма да има) за уеб сокети на вътрешни/външни прокси ресурси.
2. За websockets можете да направите уникална, сигурна и защитима връзка, като използвате временни сесии, които се генерират по време на нормална (не-websocket) заявка на браузър.
3. Временни сесии могат да бъдат реализирани с помощта на един прокси уеб сървър (само вградени модули и функции).
4. Временните токени за сесии вече са внедрени като готови модули на Apache.
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 about tls1.3 http2 post handshake (не работи сега) Внедрете 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: Удостоверяване на клиентски сертификат на Apache Server

И двете опции бяха тествани, опция „b“ беше избрана поради своята гъвкавост и съвместимост с протокола http2.

За да завърши проверката на тази хипотеза, бяха необходими много експерименти с конфигурацията; бяха тествани следните проекти:

if = изискване = пренаписване

• Основни функции на Apache
• Изрази в 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), повече подробности в документацията:

Apache модул mod_ssl

2. За websockets можете да направите уникална, сигурна и защитена връзка, като използвате временни сесии, които се генерират по време на нормална (без websocket) заявка на браузър.

Въз основа на предишен опит, трябва да добавите допълнителен раздел към конфигурацията, за да подготвите временни токени за връзки към уеб сокет по време на обикновена заявка (не-уеб сокет).

#подготовка передача себе С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
• Внесете двуфакторно удостоверяване на вашето копие на Apache с проста инсталация на модул

Да, има готови модули, но всички те са обвързани с конкретни действия и имат артефакти под формата на стартиране на сесия и допълнителни бисквитки. Тоест не за известно време.
Отне ни пет часа търсене, което не даде конкретен резултат.

5. Временните токени за сесии могат да бъдат внедрени чрез логично проектиране на структурата на взаимодействията.

Готовите модули са твърде сложни, защото се нуждаем само от няколко функции.

Като се има предвид това, проблемът с датата е, че вградените функции на Apache не позволяват генериране на дата от бъдещето и няма математическо събиране/изваждане във вградените функции при проверка за остаряване.

Тоест не можете да напишете:

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

Можете да сравните само две числа.

Докато търсех решение за проблема със Safari, намерих интересна статия: Защита на HomeAssistant с клиентски сертификати (работи със Safari/iOS)
Той описва пример за код в Lua за Nginx и който, както се оказа, много повтаря логиката на онази част от конфигурацията, която вече сме внедрили, с изключение на използването на метода за осоляване на hmac за хеширане ( това не беше намерено в Apache).

Стана ясно, че Lua е език с ясна логика и е възможно да се направи нещо просто за Apache:

• Директива LuaHookAccessChecker
• Директива UnsetEnv

След като проучих разликата с Nginx и Apache:

• modules_lua
• lua_load_resty_core

И налични функции от производителя на езика Lua:
22.1 – Дата и час

Намерихме начин да зададем променливи env в малък Lua файл, за да зададем дата от бъдещето, която да сравним с текущата.

Ето как изглежда един прост 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), тъй като в крайна сметка всичко ще бъде сортирано въз основа на реда на заявката от потребителя, който съответства на схемата за обработка Lua скриптове.

Завършване:

Видимо състояние след внедряване (цел):
управлението на услугите и инфраструктурата е достъпно от мобилен телефон на IOS без допълнителни програми (VPN), унифицирано и сигурно.

Целта е постигната, уеб сокетите работят и имат ниво на сигурност не по-малко от сертификат.

Източник: www.habr.com