SSTP inashindwa mahali HTTPS ya kivinjari inafanikiwa: kwa nini
SSTP hufanya kazi ndani ya TLS kwenye bandari 443, lakini si ombi la wavuti. Jaribu TCP, utambulisho wa TLS, mabadilishano ya SSTP na uthibitishaji wa PPP kama hatua tofauti.
Kivinjari hufungua jina la mwenyeji wa VPN kwa HTTPS bila malalamiko, na mteja wa SSTP bado anakataa kuunganishwa. Hakuna kitu kinachopingana katika jozi hilo. SSTP hutumia TLS kama usafirishaji wa nje kisha huendesha ombi lake mwenyewe na mzigo wa PPP ndani ya muunganisho huo, kwa hiyo upakiaji wa ukurasa uliofanikiwa unathibitisha jambo moja jembamba tu: mwenyeji anajibu GET kwenye bandari 443. Mteja anauliza swali lingine, na seva inaweza kulijibu vibaya.
Ukurasa hupakia na handaki haipaki
Watu huelekea jaribio la kivinjari kwa sababu ni la haraka, kisha huchukua matokeo kama ushahidi kwamba seva inafikiwa na imesanidiwa. Ni ushahidi kuhusu GET kwenye njia ambayo upau wa anwani ulifungua, si zaidi. Mazungumzo ya VPN huanza baada ya kupeana mkono sawa wa TLS, lakini hutuma mbinu na njia ambayo ukurasa wa wavuti hautumii kamwe. Kwa hiyo jibu la 200 kwa kivinjari halisemi chochote kuhusu kama kiishio cha SSTP kipo.
Tenganisha uchunguzi huo miwili na utafutaji unakuwa mfupi. Usafirishaji na mnyororo wa vyeti hufanya kazi, na kitu katika mabadilishano ya itifaki juu yao hakifanyi kazi. Hii ni uchunguzi tofauti na bandari iliyovunjika au cheti kilichoisha muda, na unahitaji ushahidi tofauti.
Mteja wa SSTP hutuma nini kwa kweli
Mteja hutuma ombi la HTTP kwa mbinu ya SSTP_DUPLEX_POST kwenye njia /sra_{GUID}/, kisha huweka mwili wa muunganisho wazi kama mkondo wa pande mbili unaobeba fremu za PPP. Seva inayotii hujibu HTTP/1.1 200 na huacha kujifanya kama seva ya wavuti. Kitu kingine chochote ni sahihi: 405 au 404 inamaanisha kiishio hakipo, 301 au 302 inamaanisha kitu kinaelekeza ombi mahali pengine, na FIN ya papo hapo inamaanisha proksi au seva ilifunga mkondo.
Ndiyo sababu lengo lazima liwe seva ya SSTP na si seva ya wavuti iliyobandikwa cheti cha TLS. Mbinu, njia na mwili wa muda mrefu ni mahitaji ya itifaki, kwa hiyo proksi ya kinyume haiwezi kuziongeza kwa usanidi pekee. Proksi inayopeleka HTTPS ya kawaida kikamilifu bado inaweza kukataa mbinu ambayo haijui.
Mahali proksi au seva ya wavuti inapovunja mkondo
Mpatanishi hukagua mstari wa ombi la HTTP kabla ya kupeleka kitu chochote, na mbinu maalum yenye njia isiyo ya kawaida inaweza kushindwa katika kanuni zake. Baadhi ya vifaa huwasilisha ukurasa wa kawaida huku vikikataa au kukatiza handaki, kwa hiyo mteja huripoti muunganisho unaoanza kisha kufa badala ya kukataliwa safi. Vingine hukubali ombi, kisha hutumia muda wa mwili au kutokuwa na shughuli ambao keepalive za PPP haziwezi kustahimili. Zote mbili zinaonekana sawa kutoka upande wa mteja, ndiyo sababu hatua iliyoshindwa ni muhimu zaidi kuliko maandishi ya hitilafu.
Kushiriki bandari 443 kati ya tovuti na SSTP ni uchaguzi wa uelekezaji, si ahadi kwamba kila hatua itashughulikia mazungumzo yote mawili kwa njia moja. Ikiwa kipo kwenye njia kipimo cha mzigo, ukuta wa moto au kimaliza TLS, kiongeze kwenye orodha ya washukiwa kabla ya kugusa usanidi wa VPN.
Jaribu hatua tofauti
Endesha ukaguzi kwa mpangilio na usimame kwenye kushindwa kwa kwanza, kwa sababu kila hatua huondoa tabaka tofauti. Kichunguzi cha TLS hapa chini hutenganisha utambulisho wa cheti na kila kitu ambacho SSTP hufanya. Badilisha jina la mwenyeji na kiishio chako na usome subject na mnyororo inaoichapisha.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comKisha linganisha ushahidi uliobaki na hatua badala ya kukisia kutoka hitilafu ya mteja. Jedwali hapa chini ni orodha ya ukaguzi ya kunukuu kwenye tiketi, pamoja na sahihi inayotenganisha kushindwa moja na inayofuata.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Rekodi hatua ya mwisho iliyofanikiwa kwenye tiketi badala ya kuandika "haiwezi kuunganisha". Vipimo vya MS-SSTP huandika ombi na mabadilishano ya PPP yanayofuata kupeana mkono wa TLS, na ni rejeleo la kwa nini jaribio la kivinjari haliwezi kuchukua nafasi ya yoyote kati yao.
Kwanza utambulisho, kisha PPP
Utambulisho wa TLS na uthibitishaji wa PPP hufuatana, si mbadala, na kuchanganya kwao huwapeleka watu kwenye mpangilio mbaya wa seva. Mteja huthibitisha kwanza cheti cha seva na madhumuni yake yaliyokusudiwa, kisha PPP hujadili hali yake mwenyewe na kumthibitisha mtumiaji kwa mbinu ya changamoto-jibu au EAP. Tatizo la cheti hutoa hitilafu tofauti na nenosiri lililokataliwa, na hakuna hitilafu inayoelezea hatua ambayo nyingine inashughulikia.
Kubadilisha jina la mwenyeji na anwani, au kubofya kupita onyo la cheti, huondoa ukaguzi ambao ungegundua hatua inayoshindwa badala ya kuirekebisha. Weka onyo na ulisome. Pia usiweke upya nenosiri la PPP wakati mabadilishano ya HTTP hayakufikia tabia ya SSTP, kwa sababu vitambulisho havikuwahi kuombwa.