บทความนี้จะเป็นประโยชน์สำหรับผู้ที่:
- รู้ว่า Client Cert คืออะไร และเข้าใจว่าทำไมจึงต้องมี websockets บน Safari บนมือถือ
- ฉันต้องการเผยแพร่บริการทางเว็บไปยังกลุ่มคนจำนวนจำกัดหรือเฉพาะกับตัวเองเท่านั้น
- คิดว่าทุกอย่างมีคนทำไปแล้ว และอยากจะทำให้โลกนี้สะดวกสบายและปลอดภัยขึ้นอีกหน่อย
ประวัติความเป็นมาของเว็บซ็อกเก็ตเริ่มต้นเมื่อประมาณ 8 ปีที่แล้ว ก่อนหน้านี้มีการใช้วิธีการในรูปแบบของคำขอ http แบบยาว (จริง ๆ แล้วตอบสนอง): เบราว์เซอร์ของผู้ใช้ส่งคำขอไปยังเซิร์ฟเวอร์และรอให้มันตอบอะไรบางอย่าง หลังจากการตอบกลับก็เชื่อมต่ออีกครั้งและรอ แต่แล้วเว็บซ็อกเก็ตก็ปรากฏขึ้น
ไม่กี่ปีที่ผ่านมา เราได้พัฒนาการใช้งานของเราเองใน PHP ล้วนๆ ซึ่งไม่สามารถใช้คำขอ https ได้ เนื่องจากนี่คือเลเยอร์ลิงก์ ไม่นานมานี้ เว็บเซิร์ฟเวอร์เกือบทั้งหมดเรียนรู้เกี่ยวกับคำขอพร็อกซีผ่าน https และรองรับการเชื่อมต่อ:อัปเกรด
เมื่อสิ่งนี้เกิดขึ้น websockets เกือบจะกลายเป็นบริการเริ่มต้นสำหรับแอปพลิเคชัน SPA เนื่องจากความสะดวกในการจัดหาเนื้อหาให้กับผู้ใช้ตามความคิดริเริ่มของเซิร์ฟเวอร์ (ส่งข้อความจากผู้ใช้รายอื่นหรือดาวน์โหลดรูปภาพเอกสารการนำเสนอเวอร์ชันใหม่ ที่คนอื่นกำลังแก้ไขอยู่) .
แม้ว่าใบรับรองไคลเอ็นต์จะมีมาระยะหนึ่งแล้ว แต่ก็ยังได้รับการรองรับที่ไม่ดี เนื่องจากจะสร้างปัญหามากมายเมื่อพยายามเลี่ยงผ่าน และ (อาจเป็นไปได้ :slightly_smiling_face: ) นั่นคือสาเหตุที่เบราว์เซอร์ IOS (ทั้งหมดยกเว้น Safari) ไม่ต้องการใช้และขอจากที่เก็บใบรับรองในเครื่อง ใบรับรองมีข้อดีหลายประการเมื่อเปรียบเทียบกับคีย์ล็อกอิน/พาสหรือ ssh หรือการปิดพอร์ตที่จำเป็นผ่านไฟร์วอลล์ แต่นั่นไม่ใช่สิ่งที่เกิดขึ้น
บน iOS ขั้นตอนการติดตั้งใบรับรองนั้นค่อนข้างง่าย (ไม่เฉพาะเจาะจง) แต่โดยทั่วไปแล้วจะทำตามคำแนะนำซึ่งมีอยู่มากมายบนอินเทอร์เน็ตและใช้ได้เฉพาะกับเบราว์เซอร์ Safari เท่านั้น น่าเสียดายที่ Safari ไม่ทราบวิธีใช้ Client Сertสำหรับซ็อกเก็ตเว็บ แต่มีคำแนะนำมากมายบนอินเทอร์เน็ตเกี่ยวกับวิธีสร้างใบรับรองดังกล่าว แต่ในทางปฏิบัติสิ่งนี้ไม่สามารถทำได้
เพื่อทำความเข้าใจเว็บซ็อกเก็ต เราใช้แผนต่อไปนี้: ปัญหา/สมมติฐาน/แนวทางแก้ไข
ปัญหา: ไม่มีการรองรับซ็อกเก็ตเว็บเมื่อส่งคำขอพร็อกซีไปยังทรัพยากรที่ได้รับการป้องกันโดยใบรับรองไคลเอ็นต์บนเบราว์เซอร์มือถือ Safari สำหรับ IOS และแอปพลิเคชันอื่น ๆ ที่เปิดใช้งานการสนับสนุนใบรับรอง
สมมติฐาน:
- คุณสามารถกำหนดค่าข้อยกเว้นดังกล่าวเพื่อใช้ใบรับรอง (โดยรู้ว่าจะไม่มี) กับเว็บซ็อกเก็ตของทรัพยากรพร็อกซีภายใน/ภายนอก
- สำหรับ websockets คุณสามารถสร้างการเชื่อมต่อที่ไม่ซ้ำใคร ปลอดภัย และป้องกันได้โดยใช้เซสชันชั่วคราวที่สร้างขึ้นระหว่างคำขอเบราว์เซอร์ปกติ (ไม่ใช่ websocket)
- เซสชันชั่วคราวสามารถใช้งานได้โดยใช้พร็อกซีเว็บเซิร์ฟเวอร์เดียว (โมดูลและฟังก์ชันในตัวเท่านั้น)
- โทเค็นเซสชันชั่วคราวได้ถูกนำมาใช้เป็นโมดูล 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 หลังการจับมือกัน (ตอนนี้ใช้งานไม่ได้) ;
- ยังไม่ชัดเจนว่าจะรวมการประมวลผลนี้เข้าด้วยกันอย่างไร
b) ในระดับพื้นฐาน อนุญาต SSL โดยไม่มีใบรับรอง
SSLVerifyClient need => 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:
ทดสอบทั้งสองตัวเลือกแล้ว เลือกตัวเลือก "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) รายละเอียดเพิ่มเติมในเอกสารประกอบ:
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 มีฟังก์ชันหลักค่อนข้างมากที่ช่วยให้คุณสามารถสร้างโครงสร้างแบบมีเงื่อนไขได้ อย่างไรก็ตาม เราต้องการวิธีการปกป้องข้อมูลของเราในขณะที่อยู่ในเบราว์เซอร์ของผู้ใช้ ดังนั้นเราจึงกำหนดสิ่งที่ควรจัดเก็บและเหตุผล และฟังก์ชันในตัวที่เราจะใช้:
- เราต้องการโทเค็นที่ไม่สามารถถอดรหัสได้ง่าย
- เราต้องการโทเค็นที่มีความล้าสมัยในตัวและความสามารถในการตรวจสอบความล้าสมัยบนเซิร์ฟเวอร์
- เราต้องการโทเค็นที่จะเชื่อมโยงกับเจ้าของใบรับรอง
ซึ่งต้องใช้ฟังก์ชันแฮช เกลือ และวันที่ในการทำให้โทเค็นมีอายุ ขึ้นอยู่กับเอกสารประกอบ เรามีทุกอย่างที่แกะกล่อง 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 ฉันพบบทความที่น่าสนใจ:
มันอธิบายตัวอย่างของโค้ดใน Lua สำหรับ Nginx และเมื่อมันปรากฏออกมา ซ้ำตรรกะของส่วนนั้นของการกำหนดค่าที่เราได้นำไปใช้ไปแล้วอย่างมาก ยกเว้นการใช้วิธี hmac salting สำหรับการแฮช ( สิ่งนี้ไม่พบใน Apache)
เห็นได้ชัดว่า Lua เป็นภาษาที่มีตรรกะที่ชัดเจน และเป็นไปได้ที่จะทำสิ่งง่ายๆ สำหรับ Apache:
หลังจากศึกษาความแตกต่างกับ Nginx และ Apache แล้ว:
และฟังก์ชั่นที่มีให้จากผู้ผลิตภาษา Lua:
เราพบวิธีการตั้งค่าตัวแปร 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) เป็นหนึ่งเดียวและปลอดภัย
บรรลุเป้าหมาย เว็บซ็อกเก็ตใช้งานได้และมีระดับความปลอดภัยไม่ต่ำกว่าใบรับรอง
ที่มา: will.com