SSTP en SSL 3.0: die etiket teenoor die bedinge weergawe

Twee mense kan na dieselfde SSTP-ontplooiing kyk en teenoorgestelde gevolgtrekkings maak. Die een lees die produkdokumentasie, sien die letters SSL en neem aan die tonnel hardloop ’n protokol wat jare gelede onttrek is. Die ander wys na ’n moderne handdruk en kom tot die gevolgtrekking dat die vraag gesluit is. Beide redeneer vanuit etikette en nie vanuit die bedinge weergawe nie, en net een van dié is bewys. Die vergelyking wat die moeite werd is, is tussen wat die naam belowe en wat die diens werklik kies.

Twee antwoorde op dieselfde vraag

Die etiketargument is maklik om te stel: SSTP word beskryf as ’n veilige socket-tonnelprotokol, die historiese naam sê SSL, dus moet die verbinding SSL 3.0 wees. Dit oorleef omdat die naam werklik uit daardie lyn kom en omdat die meeste mense wat dit herhaal nog nooit na ’n handdruk gekyk het nie. Dit oorleef ook omdat die gevolgtrekking versigtig klink, asof die ergste aanvaar die veilige keuse is. Die ergste aanvaar en die werklike weergawe meet is twee verskillende aktiwiteite, en net een van hulle verander iets.

Die bewysargument vra ’n smaller vraag. Oor watter protokolweergawe het hierdie kliënt en hierdie bediener ooreengekom, by hierdie eindpunt, op hierdie oomblik? Die antwoord kom van die diens wat TLS beëindig, nie van ’n bemarkingsblad of ’n blaaier wat ’n webwerf met ’n soortgelyke naam bereik het nie.

Die twee argumente verskil in wat hulle kan bewys. Die etiket kan nie ’n ou ontplooiing van ’n gepakte een onderskei nie, en die handdruk kan nie vir jou sê wat ’n onverwante diens op dieselfde gasheer doen nie. Gebruik die tweede en hou op om die eerste te gebruik.

Lees die weergawe wat die diens werklik kies

Begin deur die komponente te benoem: die kliëntimplementering, die bedienerimplementering, die TLS-eindpunt en alles tussenin wat TLS beëindig en weer opstel. ’n Lasbalanseerder wat TLS beëindig en gewone HTTP met die agterkant praat, verander watter toestel se beleid jy moet lees.

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

Skryf die eindpunt en die tyd langs die resultaat neer, want ’n latere beleidsverandering maak ’n ongedateerde waarneming nutteloos. Herhaal die toets vanaf ’n kliënt op dieselfde netwerkpad as die gebruikers wat vir jou saak maak, want ’n onderskeppingsapparaat kan TLS met sy eie instellings beëindig. As die twee standpunte nie ooreenstem nie, het jy die komponent gevind wat saak maak. As hulle ooreenstem, het jy bewys eerder as ’n slagspreuk.

Skei die rekordveld van die onderhandeling

’n Ouderwetse weergawenommer in een veld is nie dieselfde feit as ’n SSL 3.0-sessie nie. RFC 7568 behandel die rekordlaag se weergawe en die bedinge protokol as afsonderlike kwessies, en dit is juis uit daardie onderskeiding dat selfversekerde verkeerde antwoorde kom. Lees die bedinge protokol, dan die syfer, en eers dan maak ’n gevolgtrekking oor die sessie.

Dieselfde dokument is ondubbelsinnig oor die protokol self: SSL 3.0 mag nie gebruik word nie, en onderhandeling of terugval daarheen is verbode. Die rede is die gebreekte CBC-konstruksie wat die POODLE-aanval uitgebuit het, en dit is ’n eienskap van die protokol, nie die konfigurasie van een toepassing nie.

Daarom is „hierdie werklading is waarskynlik moeilik om te misbruik” nie ’n argument om SSL 3.0 aangeskakel te laat nie. Die vereiste is om die protokol te verwyder, nie om ’n debat oor een demonstrasie te wen nie.

Onttrek SSL 3.0 met ’n beleid wat jy kan verdedig

In Windows is Schannel se protokolinstellings onder die Protocols-sleutel en word dit afsonderlik vir kliënt- en bedienerrol gelees, daarom kan ’n verandering wat een rigting regmaak die ander onaangeraak laat. Die huidige instellings en hul herbeginvereistes word deur Microsoft gedokumenteer, en ’n derdeparty-TLS-biblioteek op dieselfde gasheer ignoreer dit heeltemal.

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

Verander die beleid deur die ondersteunde administrasiepad, bevestig dat die eienaardiens sy konfigurasie weer verkry en hou ’n goedgekeurde terugpad. Om ’n breë registergreep uit ’n ander omgewing te plak, is die manier waarop ’n regstelling van een diens ’n onderbreking vir elke TLS-kliënt op die masjien word. Die omvang van die herbegin maak hier saak: ’n instelling wat toegepas lyk, kan steeds in die geheue gehou word deur ’n diens wat dit nie herlaai het nie.

’n Eweknie wat steeds ’n verouderde weergawe vereis, het ’n opdatering of ’n migrasieplan nodig. ’n Ongedokumenteerde uitsondering wat die ou protokol stilweg herstel, is nie ’n versoenbaarheidstrategie nie en sal nie die volgende oudit oorleef nie.

Aanvaar die verandering met nuwe verbindings

Toets met nuwe sessies ná die beleidsverandering, want ’n verbinding wat voor die verandering opgestel is, bewys niks oor die konfigurasie wat nou geld nie. Bevestig dat die toegelate protokol slaag en dat die verbode een in die gemagtigde valideringsproses misluk, en laat dan sertifikaatidentiteit en vertrouetoetse presies soos dit was.

Onthou wat die handdruk nie dek nie. SSTP dra PPP-verifikasie ná die TLS-laag, so ’n moderne protokolweergawe sê niks oor watter gebruiker gemagtig is of watter hulpbronne die sessie kan bereik nie. Dit is afsonderlike beheermaatreëls met afsonderlike bewyse.

Skryf die resultaat neer as diens, agterkant, toegelate beleid en waargeneemde weergawe. So ’n rekord beantwoord die sekuriteitsvraag presies, iets wat nóg die etiketargument nóg ’n argument oor ongerief ooit doen.