SSTP eta SSL 3.0: etiketa negoziatutako bertsioaren aurka

Bi pertsonek SSTP inplementazio bera begiratu eta kontrako ondorioetara irits daitezke. Batek produktuaren dokumentazioa irakurtzen du, SSL hizkiak ikusten ditu eta tunela duela urteak kendutako protokolo bat exekutatzen ari dela uste du. Besteak esku-emate moderno bat seinalatzen du eta galdera itxita dagoela dio. Biek etiketetatik eztabaidatzen dute, negoziatutako bertsiotik ez, eta horietako bat soilik da froga. Egitea merezi duen alderaketa izenak agintzen duenaren eta zerbitzuak benetan hautatzen duenaren artekoa da.

Galdera berari bi erantzun

Etiketaren argudioa erraza da esateko: SSTP socket bidezko tunel protokolo seguru gisa deskribatzen da, izen historikoak SSL dio, beraz konexioak SSL 3.0 izan behar du. Bizirik irauten du izena benetan lerro horretatik datorrelako eta errepikatzen duten gehienek ez dutelako inoiz esku-emate bat begiratu. Halaber irauten du ondorioa zuhurra dirudielako, okerrena suposatzea hautapen segurua balitz bezala. Okerrena suposatzea eta benetako bertsioa neurtzea bi jarduera desberdin dira, eta haietako batek soilik aldatzen du zerbait.

Frogaren argudioak galdera estuagoa egiten du. Zein protokolo bertsiotan adostu zuten bezero honek eta zerbitzari honek, amaiera-puntu honetan, une honetan? Erantzuna TLS amaitzen duen zerbitzutik dator, ez marketin orrialde batetik ez antzeko izena duen gune batera iritsi den nabigatzaile batetik.

Bi argudioak frogatu dezaketenari dagokionez desberdinak dira. Etiketak ezin du inplementazio zaharra zuzendutako batetik bereizi, eta esku-emateak ezin du esan host bereko zerbitzu erlazionatu gabeak zer egiten duen. Erabili bigarrena eta utzi lehenengoa erabiltzeari.

Irakurri zerbitzuak benetan hautatzen duen bertsioa

Hasi osagaiak izendatzen: bezeroaren inplementazioa, zerbitzariaren inplementazioa, TLS amaiera-puntua eta haien artean TLS amaitzen eta berrezartzen duen guztia. Backend-arekin HTTP soila hitz egiten duen eta TLS amaitzen duen karga-balantzatzaileak aldatu egiten du zein gailuren politika irakurri behar duzun.

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

Idatzi amaiera-puntua eta ordua emaitzaren ondoan, politikaren geroko aldaketa batek data gabeko behaketa erabilgaitz bihurtzen baitu. Errepikatu proba zuentzat garrantzitsuak diren erabiltzaileekin sare-bide berean dagoen bezero batetik, atzemate-gailu batek TLS bere ezarpenekin amai baitezake. Bi posizioak bat ez badatoz, garrantzitsua den osagaia aurkitu duzu. Bat badatoz, froga daukazu, ez leloa.

Bereizi erregistro-eremua negoziazioetatik

Eremu batean zaharkituta dirudien bertsio-zenbaki bat ez da SSL 3.0 saio bera bezalako egitatea. RFC 7568 erregistro-geruzaren bertsioa eta negoziatutako protokoloa gai bereizitzat hartzen ditu, eta bereizketa horretatik datoz hain zuzen ere ziurrak diren erantzun okerrak. Irakurri negoziatutako protokoloa, gero zifratzea, eta orduan bakarrik atera ondorioa saioari buruz.

Dokumentu berak argi dio protokoloari berari buruz: SSL 3.0 ez da erabili behar, eta haren inguruko negoziazioa edo haren atzeranzko erorketa debekatuta dago. Arrazoia POODLE erasoak aprobetxatu zuen CBC eraikuntza hautsia da, eta hori protokoloaren ezaugarria da, ez aplikazio baten konfigurazioa.

Horregatik „karga-lan hau zaila izan daiteke aprobetxatzen” ez da SSL 3.0 gaituta edukitzeko argudio bat. Baldintza protokoloa kentzea da, ez erakustaldi bakar bati buruzko eztabaida irabaztea.

Kendu SSL 3.0 defenda dezakezun politika batekin

Windows-en Schannel protokolo-ezarpenak Protocols gakoaren pean daude eta bezero- eta zerbitzari-rolentzat bereiz irakurtzen dira, eta horregatik norabide bat konpontzen duen aldaketak bestea ukitugabe utz dezake. Uneko ezarpenak eta haien berrabiarazte-baldintzak Microsoftek dokumentatzen ditu, eta host bereko hirugarrenen TLS liburutegi batek erabat ez ditu kontuan hartzen.

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

Aldatu politika onartutako administrazio-bidetik, egiaztatu jabea den zerbitzuak konfigurazioa berreskuratzen duela eta mantendu itzultzeko bide onartua. Beste ingurune batetik erregistro-script zabal bat itsastea da zerbitzu baten konponketa makinako TLS bezero guztientzako etena bihurtzeko bidea. Berrabiaraztearen irismena garrantzitsua da hemen: aplikatuta dirudien ezarpen bat berriro kargatu ez duen zerbitzu baten memorian egon daiteke oraindik.

Oraindik bertsio zaharkitua eskatzen duen bazkideak eguneratze bat edo migrazio-plan bat behar du. Dokumentatu gabeko salbuespen batek isilka protokolo zaharra berrezartzen badu, ez da bateragarritasun-estrategia bat eta ez du hurrengo auditoria gaindituko.

Onartu aldaketa konexio berriekin

Probatu saio berriekin politika aldatu ondoren, aldaketaren aurretik ezarritako konexio batek ez baitu ezer frogatzen orain indarrean dagoen konfigurazioaz. Egiaztatu baimendutako protokoloak arrakasta duela eta debekatuak porrot egiten duela baimendutako balidazio-prozesuan, eta gero utzi ziurtagiriaren identitatea eta konfiantza-egiaztapenak zeuden bezalaxe.

Gogoratu esku-emateak zer estaltzen ez duen. SSTP-k PPP autentifikazioa eramaten du TLS geruzaren ondoren, beraz protokolo bertsio moderno batek ez du ezer esaten zein erabiltzaile baimendu zen edo saioak zein baliabideetara irits daitekeen. Kontrol bereiziak dira, froga bereiziekin.

Idatzi emaitza zerbitzu, backend, baimendutako politika eta behatutako bertsio gisa. Horrelako erregistro batek segurtasun-galderari zehaztasunez erantzuten dio, eta hori ez du inoiz lortzen etiketaren argudioak ez eta eragozpenaren argudioak ere.