SSTP kaj SSL 3.0: la etikedo kontraŭ la intertraktita versio

Du homoj povas rigardi la saman SSTP-enkondukon kaj veni al kontraŭaj konkludoj. Unu legas la produktan dokumentaron, vidas la literojn SSL kaj supozas, ke la tunelo funkciigas protokolon forigitan antaŭ jaroj. La alia montras modernan manpremon kaj konkludas, ke la demando estas fermita. Ambaŭ argumentas per etikedoj, ne per la intertraktita versio, kaj nur unu el tiuj estas pruvo. La komparo inda estas inter tio, kion promesas la nomo, kaj tio, kion la servo efektive elektas.

Du respondoj al la sama demando

La etikeda argumento estas facile esprimebla: SSTP estas priskribata kiel sekura ingo-tunela protokolo, la historia nomo diras SSL, do la konekto devas esti SSL 3.0. Ĝi pluvivas ĉar la nomo vere venas el tiu linio kaj ĉar la plej multaj, kiuj ripetas ĝin, neniam rigardis manpremon. Ĝi ankaŭ pluvivas ĉar la konkludo sonas singarda, kvazaŭ supozi la plej malbonan estus la sekura elekto. Supozi la plej malbonan kaj mezuri la faktan version estas du malsamaj agoj, kaj nur unu el ili ŝanĝas ion.

La pruva argumento starigas pli mallarĝan demandon. Pri kiu protokolversio interkonsentis ĉi tiu kliento kaj ĉi tiu servilo, ĉe ĉi tiu finpunkto, en ĉi tiu momento? La respondo venas de la servo, kiu finas TLS, ne de ia merkatika paĝo nek de retumilo, kiu atingis simile nomatan retejon.

La du argumentoj malsamas en tio, kion ili povas pruvi. La etikedo ne povas distingi malnovan enkondukon de flikita, kaj la manpremo ne povas diri, kion faras ne rilata servo ĉe la sama gastiganto. Uzu la duan kaj ĉesu uzi la unuan.

Legu la version, kiun la servo efektive elektas

Komencu per nomado de la komponantoj: la klienta realigo, la servila realigo, la TLS-finpunkto kaj ĉio inter ili, kio finas kaj restarigas TLS. Ŝarĝo-distribuilo, kiu finas TLS kaj parolas simplan HTTP kun la malantaŭa sistemo, ŝanĝas, kies aparatan politikon vi devas legi.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

Notu la finpunkton kaj la tempon apud la rezulto, ĉar posta ŝanĝo de la politiko faras nedatitan observon senutila. Ripetu la provon el kliento sur la sama reta vojo kiel la uzantoj gravaj por vi, ĉar kapta aparato povas fini TLS per propraj agordoj. Se la du starpunktoj ne kongruas, vi trovis la komponanton, kiu gravas. Se ili kongruas, vi havas pruvon anstataŭ sloganon.

Apartigu la registran kampon de la intertraktado

Malmoderna versi-numero en unu kampo ne estas la sama fakto kiel SSL 3.0 seanco. RFC 7568 traktas la version de la registra tavolo kaj la intertraktitan protokolon kiel apartajn aferojn, kaj el ĝuste tiu distingo venas memfidaj malĝustaj respondoj. Legu la intertraktitan protokolon, poste la ĉifron, kaj nur poste faru konkludon pri la seanco.

La sama dokumento estas senduba pri la protokolo mem: SSL 3.0 ne devas esti uzata, kaj intertraktado aŭ retroiro al ĝi estas malpermesitaj. La kialo estas la rompita CBC-konstruo, kiun ekspluatis la atako POODLE, kaj tio estas eco de la protokolo, ne agordo de unu aplikaĵo.

Tial „ĉi tiu laborŝarĝo verŝajne estas malfacile ekspluatebla” ne estas argumento por lasi SSL 3.0 ŝaltita. La postulo estas forigi la protokolon, ne gajni debaton pri unu demonstracio.

Forigu SSL 3.0 per politiko, kiun vi povas subteni

En Windows la protokolaj agordoj de Schannel troviĝas sub la ŝlosilo Protocols kaj estas legataj aparte por la klienta kaj servila rolo, tial ŝanĝo, kiu riparas unu direkton, povas lasi la alian netuŝita. La nunajn agordojn kaj iliajn restartajn postulojn dokumentas Microsoft, kaj triaranga TLS-biblioteko ĉe la sama gastiganto tute ignoras ilin.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Ŝanĝu la politikon per la subtenata administra vojo, konfirmu, ke la posedanta servo rehavas sian agordon, kaj konservu aprobitan revenan vojon. Alglui vastan registran skripton el alia medio estas la maniero, kiel riparo de unu servo fariĝas halto por ĉiu TLS-kliento en la maŝino. La amplekso de la restarto gravas ĉi tie: agordo, kiu ŝajnas aplikita, povas ankoraŭ resti en la memoro de servo, kiu ne reŝargis ĝin.

Kunulo, kiu ankoraŭ postulas eksvalidiĝintan version, bezonas ĝisdatigon aŭ migran planon. Nedokumentita escepto, kiu silente restarigas la malnovan protokolon, ne estas kongrua strategio kaj ne postvivos la sekvan revizion.

Akceptu la ŝanĝon per novaj konektoj

Testu per novaj seancoj post la politika ŝanĝo, ĉar konekto establita antaŭ la ŝanĝo pruvas nenion pri la agordo nun valida. Konfirmu, ke la permesita protokolo sukcesas kaj ke la malpermesita malsukcesas en la rajtigita validiga procezo, poste lasu la identecon de la atestilo kaj la fido-kontrolojn ĝuste tiaj, kiaj ili estis.

Memoru, kion la manpremo ne kovras. SSTP portas PPP-aŭtentikigon post la TLS-tavolo, do moderna protokolversio diras nenion pri tio, kiu uzanto estis rajtigita aŭ al kiuj rimedoj la seanco povas atingi. Tiuj estas apartaj kontroloj kun apartaj pruvoj.

Skribu la rezulton kiel servo, malantaŭa sistemo, permesita politiko kaj observita versio. Tia registro precize respondas al la sekureca demando, kion nek la etikeda argumento nek la argumento pri ĝeno iam ajn faras.