ProHoster > blog > Gweinyddiaeth > Sut y gwnaethom ni yn ZeroTech gysylltu Apple Safari a thystysgrifau cleientiaid Γ’ gwe-socedi
Sut y gwnaethom ni yn ZeroTech gysylltu Apple Safari a thystysgrifau cleientiaid Γ’ gwe-socedi
Bydd yr erthygl yn ddefnyddiol i'r rhai sydd:
yn gwybod beth yw Client Cert ac yn deall pam mae angen socedi gwe ar Safari symudol;
Hoffwn gyhoeddi gwasanaethau gwe i gylch cyfyngedig o bobl neu i mi fy hun yn unig;
yn meddwl bod popeth eisoes wedi'i wneud gan rywun, a hoffai wneud y byd ychydig yn fwy cyfleus a mwy diogel.
Dechreuodd hanes gwe-socedi tua 8 mlynedd yn Γ΄l. Yn flaenorol, defnyddiwyd dulliau ar ffurf ceisiadau http hir (ymatebion mewn gwirionedd): anfonodd porwr y defnyddiwr gais at y gweinydd ac aros iddo ateb rhywbeth, ar Γ΄l yr ymateb fe gysylltodd eto ac aros. Ond yna ymddangosodd websockets.
Ychydig flynyddoedd yn Γ΄l, fe wnaethom ddatblygu ein gweithrediad ein hunain mewn PHP pur, na all ddefnyddio ceisiadau https, gan mai dyma'r haen gyswllt. Ddim yn bell yn Γ΄l, dysgodd bron pob gweinydd gwe i geisiadau dirprwy dros https a chefnogi cysylltiad: uwchraddio.
Pan ddigwyddodd hyn, daeth socedi gwe bron yn wasanaeth rhagosodedig ar gyfer cymwysiadau SPA, oherwydd pa mor gyfleus yw darparu cynnwys i'r defnyddiwr ar fenter y gweinydd (trosglwyddwch neges gan ddefnyddiwr arall neu lawrlwythwch fersiwn newydd o ddelwedd, dogfen, cyflwyniad bod rhywun arall yn golygu ar hyn o bryd).
Er bod Tystysgrif Cleient wedi bod o gwmpas ers cryn amser, mae'n dal i gael ei gefnogi'n wael, gan ei fod yn creu llawer o broblemau wrth geisio ei osgoi. A (o bosibl :slightly_smiling_face : ) dyna pam nad yw porwyr IOS (pob un ac eithrio Safari) eisiau ei ddefnyddio a gofyn amdano o'r siop dystysgrif leol. Mae gan dystysgrifau lawer o fanteision o gymharu ag allweddi mewngofnodi/pasio neu ssh neu gau'r porthladdoedd angenrheidiol trwy wal dΓ’n. Ond nid dyna yw pwrpas hyn.
Ar iOS, mae'r weithdrefn ar gyfer gosod tystysgrif yn eithaf syml (nid heb fanylion), ond yn gyffredinol fe'i gwneir yn unol Γ’ chyfarwyddiadau, y mae llawer ohonynt ar y Rhyngrwyd ac sydd ar gael ar gyfer porwr Safari yn unig. Yn anffodus, nid yw Safari yn gwybod sut i ddefnyddio Cleient Π‘ert ar gyfer socedi gwe, ond mae yna lawer o gyfarwyddiadau ar y Rhyngrwyd ar sut i greu tystysgrif o'r fath, ond yn ymarferol nid yw hyn yn gyraeddadwy.
Er mwyn deall socedi gwe, defnyddiwyd y cynllun canlynol: problem/damcaniaeth/datrysiad.
Problem: nid oes unrhyw gefnogaeth i socedi gwe wrth ddirprwyo ceisiadau i adnoddau sydd wedi'u diogelu gan dystysgrif cleient ar borwr symudol Safari ar gyfer IOS a chymwysiadau eraill sydd wedi galluogi cefnogaeth tystysgrif.
Rhagdybiaethau:
Mae'n bosibl ffurfweddu eithriad o'r fath i ddefnyddio tystysgrifau (gan wybod na fydd unrhyw un) i socedi gwe o adnoddau dirprwyol mewnol/allanol.
Ar gyfer gwe-socedi, gallwch wneud cysylltiad unigryw, diogel ac amddiffynadwy gan ddefnyddio sesiynau dros dro a gynhyrchir yn ystod cais porwr arferol (nad yw'n soced gwe).
Gellir gweithredu sesiynau dros dro gan ddefnyddio un gweinydd gwe dirprwy (modiwlau a swyddogaethau adeiledig yn unig).
Mae tocynnau sesiwn dros dro eisoes wedi'u gweithredu fel modiwlau Apache parod.
Gellir gweithredu tocynnau sesiwn dros dro trwy ddylunio'r strwythur rhyngweithio yn rhesymegol.
Cyflwr gweladwy ar Γ΄l gweithredu.
Nod y gwaith: dylai rheolaeth gwasanaethau a seilwaith fod yn hygyrch o ffΓ΄n symudol ar IOS heb raglenni ychwanegol (fel VPN), unedig a diogel.
Nod ychwanegol: arbed amser ac adnoddau/traffig ffΓ΄n (mae rhai gwasanaethau heb socedi gwe yn cynhyrchu ceisiadau diangen) gyda darparu cynnwys yn gyflymach ar y Rhyngrwyd symudol.
Mae dilysu tystysgrif yn digwydd ar Γ΄l cais i'r adnodd dirprwyedig, hynny yw, ysgwyd llaw ar Γ΄l cais. Mae hyn yn golygu y bydd y dirprwy yn llwytho'r cais i'r gwasanaeth gwarchodedig yn gyntaf ac yna'n torri i ffwrdd. Mae hyn yn ddrwg, ond nid yn hollbwysig;
Yn y protocol http2. Mae'n dal i fod ar ffurf drafft, ac nid yw gweithgynhyrchwyr porwr yn gwybod sut i'w weithredu #info about tls1.3 http2 post ysgwyd llaw (ddim yn gweithio nawr) Gweithredu RFC 8740 "Defnyddio TLS 1.3 gyda HTTP/2";
Nid yw'n glir sut i uno'r prosesu hwn.
b) Ar lefel sylfaenol, caniatewch ssl heb dystysgrif.
Mae angen SSLVerifyClient => SSLVerifyClient yn ddewisol, ond mae hyn yn lleihau lefel diogelwch y gweinydd dirprwy, gan y bydd cysylltiad o'r fath yn cael ei brosesu heb dystysgrif. Fodd bynnag, gallwch chi wrthod mynediad at wasanaethau dirprwyol ymhellach gyda'r gyfarwyddeb ganlynol:
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"
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>
Gan ystyried yr awdurdodiad presennol gan berchennog y dystysgrif, ond gyda thystysgrif ar goll, bu'n rhaid i mi ychwanegu perchennog tystysgrif nad oedd yn bodoli ar ffurf un o'r newidynnau sydd ar gael SSl_PROTOCOL (yn lle SSL_CLIENT_S_DN_CN), mwy o fanylion yn y ddogfennaeth:
2. Ar gyfer gwe-socedi, gallwch wneud cysylltiad unigryw, diogel a gwarchodedig gan ddefnyddio sesiynau dros dro a gynhyrchir yn ystod cais porwr arferol (nad yw'n soced gwe).
Yn seiliedig ar brofiad blaenorol, mae angen i chi ychwanegu adran ychwanegol at y ffurfweddiad er mwyn paratoi tocynnau dros dro ar gyfer cysylltiadau soced gwe yn ystod cais rheolaidd (soced nad yw'n we).
Dangosodd profion ei fod yn gweithio. Mae'n bosibl trosglwyddo Cwcis i chi'ch hun trwy borwr y defnyddiwr.
3. Gellir gweithredu sesiynau dros dro gan ddefnyddio un gweinydd gwe dirprwy (dim ond modiwlau a swyddogaethau adeiledig).
Fel y gwelsom yn gynharach, mae gan Apache gryn dipyn o swyddogaethau craidd sy'n eich galluogi i greu lluniadau amodol. Fodd bynnag, mae angen dulliau arnom i ddiogelu ein gwybodaeth tra ei bod ym mhorwr y defnyddiwr, felly rydym yn sefydlu beth i'w storio a pham, a pha swyddogaethau adeiledig y byddwn yn eu defnyddio:
Mae arnom angen tocyn na ellir ei ddadgodio'n hawdd.
Mae arnom angen tocyn sy'n cynnwys darfodiad ynddo a'r gallu i wirio darfodiad ar y gweinydd.
Mae angen tocyn arnom a fydd yn gysylltiedig Γ’ pherchennog y dystysgrif.
Mae hyn yn gofyn am swyddogaeth stwnsio, halen, a dyddiad i heneiddio'r tocyn. Yn seiliedig ar y ddogfennaeth Mynegiadau yn Apache HTTP Server mae popeth allan o'r bocs sha1 a %{TIME}.
Mae'r nod wedi'i gyflawni, ond mae problemau gyda darfodiad gweinydd (gallwch ddefnyddio Cwci blwydd oed), sy'n golygu bod y tocynnau, er eu bod yn ddiogel ar gyfer defnydd mewnol, yn anniogel ar gyfer defnydd diwydiannol (mΓ s).
4. Mae tocynnau sesiwn dros dro eisoes wedi'u gweithredu fel modiwlau Apache parod.
Roedd un broblem sylweddol yn parhau o'r iteriad blaenorol - yr anallu i reoli heneiddio tocyn.
Rydym yn chwilio am fodiwl parod sy'n gwneud hyn, yn Γ΄l y geiriau: apache token json two factor auth
Oes, mae yna fodiwlau parod, ond maen nhw i gyd yn gysylltiedig Γ’ chamau gweithredu penodol ac mae ganddyn nhw arteffactau ar ffurf dechrau sesiwn a Chwcis ychwanegol. Hynny yw, nid am ychydig.
Cymerodd bum awr i ni chwilio, nad oedd yn rhoi canlyniad pendant.
5. Gellir gweithredu tocynnau sesiwn dros dro trwy ddylunio strwythur rhyngweithiadau yn rhesymegol.
Mae modiwlau parod yn rhy gymhleth, oherwydd dim ond cwpl o swyddogaethau sydd eu hangen arnom.
Wedi dweud hynny, y broblem gyda'r dyddiad yw nad yw swyddogaethau adeiledig Apache yn caniatΓ‘u cynhyrchu dyddiad o'r dyfodol, ac nid oes unrhyw adio/tynnu mathemategol yn y swyddogaethau adeiledig wrth wirio am ddarfodiad.
Hynny yw, ni allwch ysgrifennu:
(%{env:zt-cert-date} + 30) > %{DATE}
Dim ond dau rif y gallwch chi eu cymharu.
Wrth chwilio am ateb ar gyfer problem Safari, des i o hyd i erthygl ddiddorol: Sicrhau HomeAssistant gyda thystysgrifau cleient (yn gweithio gyda Safari/iOS)
Mae'n disgrifio enghraifft o god yn Lua ar gyfer Nginx, ac sydd, fel y digwyddodd, yn ailadrodd yn fawr iawn resymeg y rhan honno o'r cyfluniad yr ydym eisoes wedi'i weithredu, ac eithrio'r defnydd o'r dull halltu hmac ar gyfer stwnsio ( ni ddarganfuwyd hwn yn Apache).
Daeth yn amlwg bod Lua yn iaith gyda rhesymeg glir, ac mae'n bosibl gwneud rhywbeth syml i Apache:
Daethom o hyd i ffordd i osod newidynnau env mewn ffeil Lua fach er mwyn gosod dyddiad o'r dyfodol i gymharu Γ’'r un gyfredol.
Dyma sut olwg sydd ar sgript Lua syml:
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
A dyma sut mae'r cyfan yn gweithio yn gyfan gwbl, gydag optimeiddio nifer y Cwcis a disodli'r tocyn pan ddaw hanner yr amser cyn i'r hen Cwci (tocyn) ddod i ben:
Yn gyffredinol, nid oes ots ym mha drefn y mae'r cyfarwyddebau wedi'u hysgrifennu yng nghyfluniad Apache (yn Γ΄l pob tebyg hefyd Nginx), oherwydd yn y diwedd bydd popeth yn cael ei ddidoli yn seiliedig ar drefn y cais gan y defnyddiwr, sy'n cyfateb i'r cynllun prosesu Sgriptiau Lua.
Cwblhau:
Cyflwr gweladwy ar Γ΄l gweithredu (nod):
rheoli gwasanaethau a seilwaith ar gael o ffΓ΄n symudol ar IOS heb raglenni ychwanegol (VPN), unedig a diogel.
Mae'r nod wedi'i gyflawni, mae socedi gwe yn gweithio ac mae ganddynt lefel o ddiogelwch heb fod yn llai na thystysgrif.