איך אנחנו ב-ZeroTech חיברנו את Apple Safari ותעודות לקוח עם websockets

המאמר יהיה שימושי למי:

• יודע מהו Client Cert ומבין מדוע הוא זקוק ל-websockets ב-Safari נייד;
• ברצוני לפרסם שירותי אינטרנט למעגל מצומצם של אנשים או רק לעצמי;
• חושב שהכל כבר נעשה על ידי מישהו, ורוצה לעשות את העולם קצת יותר נוח ובטוח.

ההיסטוריה של websockets החלה לפני כ-8 שנים. בעבר, נעשה שימוש בשיטות בצורה של בקשות http ארוכות (למעשה תגובות): הדפדפן של המשתמש שלח בקשה לשרת וחיכה שהוא יענה על משהו, לאחר התגובה הוא התחבר שוב והמתין. אבל אז הופיעו שקעי אינטרנט.



לפני מספר שנים פיתחנו יישום משלנו ב-PHP טהור, שאינו יכול להשתמש בבקשות https, מכיוון שזו שכבת הקישור. לפני זמן לא רב, כמעט כל שרתי האינטרנט למדו בקשות פרוקסי דרך https ותומכים בחיבור:שדרוג.

כשזה קרה, websockets הפך כמעט לשירות ברירת המחדל עבור יישומי SPA, כי כמה נוח לספק תוכן למשתמש ביוזמת השרת (לשדר הודעה ממשתמש אחר או להוריד גרסה חדשה של תמונה, מסמך, מצגת שמישהו אחר עורך כרגע).

למרות שתעודת לקוח קיימת כבר די הרבה זמן, היא עדיין נתמכת בצורה גרועה, מכיוון שהיא יוצרת הרבה בעיות כאשר מנסים לעקוף אותה. ו(אולי :slightly_smiling_face: ) זו הסיבה שדפדפני IOS (כולם מלבד ספארי) לא רוצים להשתמש בו ולבקש זאת מחנות התעודות המקומית. לאישורים יתרונות רבים בהשוואה למפתחות כניסה/מעבר או ssh או סגירת הפורטים הדרושים דרך חומת אש. אבל לא על זה מדובר.

ב-iOS, הליך התקנת האישור הוא די פשוט (לא בלי פרטים), אבל באופן כללי זה נעשה על פי הוראות, מהן יש הרבה באינטרנט ואשר זמינות רק עבור דפדפן Safari. למרבה הצער, Safari לא יודע להשתמש ב-Client Сert עבור שקעי אינטרנט, אך ישנן הנחיות רבות באינטרנט כיצד ליצור תעודה כזו, אך בפועל הדבר אינו בר השגה.

כדי להבין את websockets, השתמשנו בתוכנית הבאה: בעיה/השערה/פתרון.

בעיה: אין תמיכה בשקעי אינטרנט בעת העברת בקשות לפרוקסי למשאבים המוגנים על ידי אישור לקוח בדפדפן הסלולרי של Safari עבור IOS ויישומים אחרים שאפשרו תמיכה באישורים.

השערות:

1. אפשר להגדיר חריג כזה לשימוש בתעודות (בידיעה שלא יהיו כאלה) ל-websockets של משאבי פרוקסי פנימיים/חיצוניים.
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 לחיצת יד (לא עובד עכשיו) הטמעת RFC 8740 "שימוש ב-TLS 1.3 עם HTTP/2";
• לא ברור כיצד לאחד את העיבוד הזה.

ב) ברמה בסיסית אפשר ssl ללא תעודה.

SSLVerifyClient require => SSLVerifyClient אופציונלי, אך זה מפחית את רמת האבטחה של שרת ה-proxy, מכיוון שחיבור כזה יעובד ללא אישור. עם זאת, אתה יכול עוד למנוע גישה לשירותי proxy באמצעות ההנחיה הבאה:

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

שתי האפשרויות נבדקו, אפשרות "ב" נבחרה בשל הרבגוניות שלה ותאימותה לפרוטוקול http2.

כדי להשלים את האימות של השערה זו, נדרשו הרבה ניסויים עם התצורה; העיצובים הבאים נבדקו:

אם = דורש = שכתוב

• תכונות ליבה של Apache
• ביטויים בשרת HTTP של Apache

התוצאה היא העיצוב הבסיסי הבא:

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. עבור 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>

בדיקות הראו שזה עובד. אפשר להעביר לעצמך Cookies דרך הדפדפן של המשתמש.

3. ניתן ליישם הפעלות זמניות באמצעות שרת אינטרנט פרוקסי אחד (רק מודולים ופונקציות מובנים).

כפי שגילינו קודם לכן, ל- Apache יש די הרבה פונקציונליות ליבה המאפשרת לך ליצור מבנים מותנים. עם זאת, אנו זקוקים לאמצעים כדי להגן על המידע שלנו בזמן שהוא נמצא בדפדפן של המשתמש, אז אנו קובעים מה לאחסן ולמה, ובאילו פונקציות מובנות נשתמש:

• אנחנו צריכים אסימון שלא ניתן לפענח בקלות.
• אנחנו צריכים אסימון שיש בו התיישנות מובנית ויכולת לבדוק התיישנות בשרת.
• אנחנו צריכים אסימון שישויך לבעל התעודה.

זה דורש פונקציית גיבוב, מלח ותאריך כדי ליישן את האסימון. מבוסס על התיעוד ביטויים בשרת HTTP של Apache יש לנו הכל מחוץ לקופסה 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 Web Tokens
• אימות דו-גורמי של Apache (2FA).
• כיצד להוסיף אימות דו-גורמי ל- Apache
• הבא אימות דו-גורמי למופע ה-Apache שלך ​​עם התקנת מודול פשוטה

כן, יש מודולים מוכנים, אבל כולם קשורים לפעולות ספציפיות ויש להם חפצים בצורת התחלת הפעלה וקובצי Cookie נוספים. כלומר, לא לזמן מה.
לקח לנו חמש שעות לחפש, מה שלא נתן תוצאה קונקרטית.

5. ניתן ליישם אסימוני הפעלה זמניים על ידי תכנון הגיוני של מבנה האינטראקציות.

מודולים מוכנים הם מורכבים מדי, כי אנחנו צריכים רק כמה פונקציות.

עם זאת, הבעיה עם התאריך היא שהפונקציות המובנות של Apache אינן מאפשרות ליצור תאריך מהעתיד, ואין חיבור/חיסור מתמטי בפונקציות המובנות בעת בדיקת התיישנות.

כלומר, אתה לא יכול לכתוב:

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

אתה יכול להשוות רק שני מספרים.

תוך כדי חיפוש אחר פתרון לבעיית הספארי, מצאתי מאמר מעניין: אבטחת HomeAssistant עם אישורי לקוח (עובד עם Safari/iOS)
הוא מתאר דוגמה לקוד ב-Lua עבור Nginx, ואשר, כפי שהתברר, חוזר מאוד על ההיגיון של אותו חלק בתצורה שכבר יישמנו, למעט השימוש בשיטת hmac salting עבור hashing ( זה לא נמצא באפצ'י).

התברר שלואה היא שפה עם היגיון ברור, ואפשר לעשות משהו פשוט עבור אפאצ'י:

• הנחיית LuaHookAccessChecker
• UnsetEnv Directive

לאחר שלמדתי את ההבדל עם 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

וככה הכל עובד בסך הכל, עם אופטימיזציה של מספר העוגיות והחלפת האסימון כשמחצית מהזמן מגיע לפני שה-Cookie (אסימון) הישן יפוג:

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