SSTP en SSL 3.0: het label tegenover de onderhandelde versie

Twee mensen kunnen naar dezelfde SSTP-uitrol kijken en tegenovergestelde conclusies trekken. De een leest de productdocumentatie, ziet de letters SSL en neemt aan dat de tunnel een protocol draait dat jaren geleden is uitgefaseerd. De ander wijst op een moderne handshake en concludeert dat de vraag is afgesloten. Beiden redeneren vanuit labels in plaats van vanuit de onderhandelde versie, en slechts één daarvan is bewijs. De vergelijking die de moeite waard is, gaat tussen wat de naam belooft en wat de dienst werkelijk selecteert.

Twee antwoorden op dezelfde vraag

Het labelargument is snel geformuleerd: SSTP wordt beschreven als een beveiligd socket-tunnelprotocol, de historische naam zegt SSL, dus de verbinding moet SSL 3.0 zijn. Het houdt stand omdat de naam echt uit die lijn komt en omdat de meeste mensen die het napraten nooit een handshake hebben bekeken. Het houdt ook stand omdat de conclusie behoudend klinkt, alsof het ergste aannemen de veilige keuze is. Het ergste aannemen en de werkelijke versie meten zijn verschillende bezigheden, en slechts één ervan verandert iets.

Het bewijsargument stelt een engere vraag. Op welke protocolversie zijn deze client en deze server het eens geworden, op dit endpoint, op dit moment? Het antwoord komt van de dienst die TLS beëindigt, niet van een marketingpagina of een browser die een gelijknamige website heeft bereikt.

De twee argumenten verschillen in wat ze kunnen bewijzen. Het label kan een oude uitrol niet onderscheiden van een gepatchte, en de handshake kan niet vertellen wat een ongerelateerde dienst op dezelfde host doet. Gebruik het tweede en stop met het eerste.

Lees de versie die de dienst werkelijk selecteert

Begin met het benoemen van de componenten: de clientimplementatie, de serverimplementatie, het TLS-endpoint en alles daartussen dat TLS beëindigt en opnieuw opzet. Een load balancer die TLS beëindigt en platte HTTP met de backend spreekt, verandert van welk apparaat u het beleid moet lezen.

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

Noteer het endpoint en de tijd naast het resultaat, want een latere beleidswijziging maakt een ongedateerde waarneming waardeloos. Herhaal de test vanaf een client op hetzelfde netwerkpad als de gebruikers die u belangrijk vindt, omdat een onderscheppingsapparaat TLS met zijn eigen instellingen kan beëindigen. Als de twee standpunten van elkaar afwijken, hebt u de component gevonden die ertoe doet. Als ze overeenkomen, hebt u bewijs in plaats van een slogan.

Scheid het recordveld van de onderhandeling

Een ouderwets uitziend versienummer in één veld is niet hetzelfde feit als een SSL 3.0-sessie. RFC 7568 behandelt de versie van de recordlaag en het onderhandelde protocol als afzonderlijke zaken, en juist uit dat onderscheid komen zelfverzekerde foute antwoorden. Lees het onderhandelde protocol, dan de cipher, en trek pas daarna een conclusie over de sessie.

Hetzelfde document is ondubbelzinnig over het protocol zelf: SSL 3.0 mag niet worden gebruikt, en onderhandeling of terugval ernaar is verboden. De reden is de kapotte CBC-constructie die de POODLE-aanval uitbuitte, en dat is een eigenschap van het protocol, niet de configuratie van één applicatie.

Daarom is „deze workload is waarschijnlijk moeilijk uit te buiten” geen argument om SSL 3.0 ingeschakeld te laten. De eis is het protocol verwijderen, niet een debat over één demonstratie winnen.

Schakel SSL 3.0 uit met een beleid dat u kunt dragen

Op Windows staan de Schannel-protocolinstellingen onder de sleutel Protocols en worden ze per client- en per serverrol gelezen, waardoor een wijziging die één richting repareert de andere ongemoeid kan laten. De huidige instellingen en hun herstartvereisten zijn door Microsoft gedocumenteerd, en een TLS-bibliotheek van derden op dezelfde host negeert ze volledig.

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

Wijzig het beleid via het ondersteunde beheerpad, bevestig dat de eigenaar-dienst zijn configuratie opnieuw inleest en houd een goedgekeurde weg terug. Een breed registerscript uit een andere omgeving plakken is hoe een oplossing voor één dienst een storing wordt voor elke TLS-client op de machine. De herstartomvang is hier van belang: een instelling die toegepast lijkt, kan nog in het geheugen zitten van een dienst die hem niet opnieuw heeft geladen.

Een peer die nog een verouderde versie eist, heeft een update of een migratieplan nodig. Een ongedocumenteerde uitzondering die het oude protocol stilletjes herstelt, is geen compatibiliteitsstrategie en overleeft de volgende audit niet.

Accepteer de wijziging met nieuwe verbindingen

Test met nieuwe sessies na de beleidswijziging, want een verbinding die vóór de wijziging tot stand kwam, bewijst niets over de configuratie die nu geldt. Bevestig dat het toegestane protocol slaagt en dat het verboden protocol faalt via het geautoriseerde validatieproces, en laat certificaatidentiteit en vertrouwenscontroles precies zoals ze waren.

Onthoud wat de handshake niet dekt. SSTP draagt PPP-authenticatie na de TLS-laag, dus een moderne protocolversie zegt niets over welke gebruiker is geautoriseerd of welke bronnen de sessie mag bereiken. Dat zijn aparte controles met apart bewijs.

Schrijf het resultaat op als dienst, backend, toegestaan beleid en waargenomen versie. Dat verslag beantwoordt de beveiligingsvraag nauwkeurig, wat het labelargument noch een argument van ongemak ooit doet.