ZeroTech에서 Apple Safari와 클라이언트 인증서를 웹소켓에 연결한 방법

이 기사는 다음과 같은 사람들에게 유용할 것입니다.

• 클라이언트 인증서가 무엇인지 알고 모바일 Safari에서 웹소켓이 필요한 이유를 이해합니다.
• 나는 제한된 사람들에게만 또는 나 자신에게만 웹 서비스를 게시하고 싶습니다.
• 모든 것은 이미 누군가에 의해 이루어졌다고 생각하며, 세상을 좀 더 편리하고 안전하게 만들고 싶습니다.

웹소켓의 역사는 약 8년 전부터 시작되었습니다. 이전에는 긴 http 요청(실제 응답) 형식으로 메서드가 사용되었습니다. 사용자의 브라우저는 서버에 요청을 보내고 서버가 응답할 때까지 기다렸다가 응답 후에 다시 연결하여 기다렸습니다. 그러나 웹 소켓이 나타났습니다.



몇 년 전, 우리는 링크 레이어이기 때문에 https 요청을 사용할 수 없는 순수 PHP로 자체 구현을 개발했습니다. 얼마 전까지만 해도 거의 모든 웹 서버는 https를 통해 요청을 프록시하고 연결:업그레이드를 지원하는 방법을 배웠습니다.

이런 일이 발생했을 때 웹 소켓은 SPA 애플리케이션의 거의 기본 서비스가 되었습니다. 서버 주도로 사용자에게 콘텐츠를 제공하는 것이 얼마나 편리했기 때문입니다(다른 사용자로부터 메시지를 전송하거나 이미지, 문서, 프리젠테이션의 새 버전을 다운로드). 다른 사람이 현재 편집 중인 내용).

클라이언트 인증서가 나온 지 꽤 됐지만, 우회하려고 할 때 많은 문제가 발생하기 때문에 여전히 지원이 부족합니다. 그리고 (아마도 :slightly_smiling_face: ) 이것이 IOS 브라우저(Safari를 제외한 모든 브라우저)가 이를 사용하고 싶지 않고 로컬 인증서 저장소에서 요청하는 이유입니다. 인증서는 로그인/패스 또는 SSH 키나 방화벽을 통해 필요한 포트를 닫는 것에 비해 많은 장점이 있습니다. 그러나 이것은 이것에 관한 것이 아닙니다.

iOS에서 인증서를 설치하는 절차는 매우 간단하지만(구체적인 사항 없이는 아님) 일반적으로 인터넷에 많은 내용이 있고 Safari 브라우저에서만 사용할 수 있는 지침에 따라 수행됩니다. 불행하게도 Safari는 웹 소켓용 Client Cert를 사용하는 방법을 모르지만 그러한 인증서를 생성하는 방법에 대한 인터넷 지침이 많이 있지만 실제로는 이를 달성할 수 없습니다.

웹소켓을 이해하기 위해 다음 계획을 사용했습니다. 문제/가설/해결책.

문제 : 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가지 솔루션을 찾았습니다.

a) 수준에서

<Location sock*> SSLVerifyClient optional </Location>
<Location /> SSLVerifyClient require </Location>

액세스 수준을 변경합니다.

이 방법에는 다음과 같은 뉘앙스가 있습니다.

• 인증서 확인은 프록시된 리소스에 대한 요청, 즉 사후 요청 핸드셰이크 후에 발생합니다. 이는 프록시가 먼저 로드된 다음 보호되는 서비스에 대한 요청을 차단한다는 것을 의미합니다. 이는 나쁘지만 중요하지는 않습니다.
• http2 프로토콜에서. 아직 초안 단계이며 브라우저 제조업체는 이를 구현하는 방법을 모릅니다. #info about tls1.3 http2 post handshake(현재는 작동하지 않음) RFC 8740 "HTTP/1.3와 함께 TLS 2 사용" 구현;
• 이 처리를 통합하는 방법은 명확하지 않습니다.

b) 기본 수준에서는 인증서 없이 SSL을 허용합니다.

SSLVerifyClient require => 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 서버 클라이언트 인증서 인증

두 옵션 모두 테스트되었으며 http2 프로토콜과의 호환성 및 호환성을 위해 옵션 "b"가 선택되었습니다.

이 가설의 검증을 완료하기 위해 구성에 대한 많은 실험이 필요했으며 다음 디자인이 테스트되었습니다.

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>

목표는 달성했지만 서버 노후화 문제가 있습니다(XNUMX년 된 쿠키를 사용할 수 있음). 이는 토큰이 내부 사용에는 안전하지만 산업용(대량) 사용에는 안전하지 않음을 의미합니다.

4. 임시 세션 토큰은 이미 기성 Apache 모듈로 구현되었습니다.

이전 반복에서 한 가지 중요한 문제가 남아 있었습니다. 즉, 토큰 노화를 제어할 수 없다는 것입니다.

우리는 다음 단어에 따라 이 작업을 수행하는 기성 모듈을 찾고 있습니다. Apache 토큰 json XNUMX단계 인증

• JSON 웹 토큰 기반 토큰을 사용한 클라이언트 인증
• Apache 2단계(XNUMXFA) 인증
• Apache에 XNUMX단계 인증을 추가하는 방법
• 간단한 모듈 설치로 Apache 인스턴스에 XNUMX단계 인증을 적용하세요.

예, 기성 모듈이 있지만 모두 특정 작업과 연결되어 있으며 세션 시작 및 추가 쿠키 형태의 아티팩트가 있습니다. 즉, 한동안은 아닙니다.
검색하는 데 XNUMX시간이 걸렸지만 구체적인 결과는 나오지 않았습니다.

5. 임시 세션 토큰은 상호 작용의 구조를 논리적으로 설계하여 구현할 수 있습니다.

기성 모듈은 몇 가지 기능만 필요하기 때문에 너무 복잡합니다.

즉, 날짜의 문제점은 Apache의 내장 함수가 미래의 날짜 생성을 허용하지 않으며, 더 이상 사용되지 않는지 확인할 때 내장 함수에 수학적 덧셈/뺄셈이 없다는 것입니다.

즉, 다음과 같이 작성할 수 없습니다.

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

두 숫자만 비교할 수 있습니다.

Safari 문제에 대한 해결 방법을 검색하던 중 흥미로운 기사를 발견했습니다. 클라이언트 인증서로 HomeAssistant 보호(Safari/iOS에서 작동)
이는 Nginx용 Lua의 코드 예를 설명하며, 해싱을 위한 hmac 솔팅 방법을 사용하는 것을 제외하고는 이미 구현한 구성 부분의 논리를 매우 많이 반복합니다( 이는 Apache에서는 발견되지 않았습니다).

Lua는 논리가 명확한 언어이며 Apache에 대해 간단한 작업을 수행할 수 있다는 것이 분명해졌습니다.

• LuaHookAccessChecker 지시어
• UnsetEnv 지시어

Nginx와 Apache의 차이점을 연구한 결과:

• 모듈_루아
• lua_load_resty_core

그리고 Lua 언어 제조업체에서 제공하는 기능은 다음과 같습니다.
22.1 – 날짜 및 시간

우리는 현재 날짜와 비교할 미래의 날짜를 설정하기 위해 작은 Lua 파일에 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) 구성에서 지시문이 어떤 순서로 작성되는지는 중요하지 않습니다. 결국 모든 것은 처리 계획에 해당하는 사용자의 요청 순서에 따라 정렬되기 때문입니다. 루아 스크립트.

완성:

구현 후 표시되는 상태(목표):
추가 프로그램(VPN) 없이 통합되고 안전하게 IOS의 휴대폰에서 서비스 및 인프라 관리가 가능합니다.

목표는 달성되었으며 웹소켓은 작동하며 인증서 이상의 보안 수준을 갖습니다.

출처 : habr.com