SSTP ja SSL 3.0: tarra vastaan neuvoteltu versio

Kaksi ihmistä voi katsoa samaa SSTP-käyttöönottoa ja päätyä vastakkaisiin johtopäätöksiin. Toinen lukee tuotteen dokumentaatiota, näkee SSL-kirjaimet ja olettaa, että tunneli ajaa vuosia sitten poistettua protokollaa. Toinen osoittaa nykyaikaista kättelyä ja toteaa kysymyksen suljetuksi. Molemmat väittelevät tarroista eivätkä neuvotellusta versiosta, ja vain toinen näistä on todiste. Vertailu, joka kannattaa tehdä, on nimen lupauksen ja palvelun todella valitseman asian välillä.

Kaksi vastausta samaan kysymykseen

Tarra-argumentti on helppo esittää: SSTP kuvataan turvalliseksi socket-tunnelointiprotokollaksi, historiallinen nimi sanoo SSL, joten yhteyden on oltava SSL 3.0. Se pysyy hengissä, koska nimi todella tulee siltä linjalta ja koska useimmat sitä toistavat eivät ole koskaan katsoneet kättelyä. Se pysyy hengissä myös siksi, että johtopäätös kuulostaa varovaiselta, ikään kuin pahimman olettaminen olisi turvallinen valinta. Pahimman olettaminen ja todellisen version mittaaminen ovat eri toimia, ja vain toinen niistä muuttaa jotain.

Todisteargumentti kysyy kapeampaa kysymystä. Mihin protokollaversioon tämä asiakas ja tämä palvelin päätyivät tässä päätepisteessä, tällä hetkellä? Vastaus tulee palvelulta, joka päättää TLS:n, ei markkinointisivulta eikä selaimelta, joka päätyi samannimiselle sivustolle.

Kaksi argumenttia eroavat siinä, mitä ne voivat todistaa. Tarra ei erota vanhaa käyttöönottoa paikatusta, eikä kättely voi kertoa, mitä riippumaton palvelu samalla isännällä tekee. Käytä jälkimmäistä ja lopeta ensimmäisen käyttö.

Lue versio, jonka palvelu todella valitsee

Aloita nimeämällä osat: asiakastoteutus, palvelintoteutus, TLS-päätepiste ja kaikki siltä väliltä, mikä päättää ja perustaa TLS:n uudelleen. Kuormantasaaja, joka päättää TLS:n ja puhuu taustajärjestelmälle tavallista HTTP:tä, muuttaa sitä, minkä laitteen käytäntö sinun on luettava.

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

Kirjaa päätepiste ja aika tuloksen viereen, sillä myöhempi käytännön muutos tekee päiväämättömästä havainnosta hyödyttömän. Toista koe asiakkaalta, joka on samalla verkkopolulla kuin sinulle tärkeät käyttäjät, koska sieppauslaite voi päättää TLS:n omilla asetuksillaan. Jos kaksi kantaa eroavat, löysit osan, jolla on merkitystä. Jos ne täsmäävät, sinulla on todiste eikä iskulause.

Erota tietuekenttä neuvottelusta

Vanhalta näyttävä versionumero yhdessä kentässä ei ole sama tosiasia kuin SSL 3.0 -istunto. RFC 7568 kohtelee tietuekerroksen versiota ja neuvoteltua protokollaa erillisinä asioina, ja juuri tästä erosta syntyvät itsevarmat väärät vastaukset. Lue neuvoteltu protokolla, sitten salaus, ja vasta sitten tee johtopäätös istunnosta.

Sama asiakirja on yksiselitteinen itse protokollasta: SSL 3.0:aa ei saa käyttää, ja sen neuvotteleminen tai siihen palaaminen on kielletty. Syy on rikkinäinen CBC-rakenne, jota POODLE-hyökkäys hyödynsi, ja se on protokollan ominaisuus, ei yhden sovelluksen kokoonpano.

Siksi „tätä työkuormaa on luultavasti vaikea hyödyntää” ei ole peruste pitää SSL 3.0 käytössä. Vaatimus on poistaa protokolla, ei voittaa väittelyä yhdestä esityksestä.

Poista SSL 3.0 käytöstä sellaisella käytännöllä, jonka voit perustella

Windowsissa Schannelin protokolla-asetukset ovat Protocols-avaimen alla ja ne luetaan erikseen asiakas- ja palvelinroolille, minkä vuoksi toisen suunnan korjaava muutos voi jättää toisen koskematta. Nykyiset asetukset ja niiden uudelleenkäynnistysvaatimukset on dokumentoinut Microsoft, ja samalla isännällä oleva kolmannen osapuolen TLS-kirjasto jättää ne kokonaan huomiotta.

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

Muuta käytäntöä tuetun hallintapolun kautta, varmista että omistajapalvelu hankkii kokoonpanonsa uudelleen ja pidä hyväksytty paluupolku. Laajan rekisteriskriptin liittäminen toisesta ympäristöstä on se tapa, jolla yhden palvelun korjauksesta tulee katko kaikille koneen TLS-asiakkaille. Uudelleenkäynnistyksen laajuus on tässä tärkeä: asetus, joka näyttää sovelletulta, voi olla yhä sen palvelun muistissa, joka ei ole ladannut sitä uudelleen.

Kumppani, joka vaatii yhä vanhentunutta versiota, tarvitsee päivityksen tai siirtosuunnitelman. Dokumentoimaton poikkeus, joka hiljaa palauttaa vanhan protokollan, ei ole yhteensopivuusstrategia, eikä se selviä seuraavasta auditoinnista.

Hyväksy muutos uusilla yhteyksillä

Testaa uusilla istunnoilla käytännön muutoksen jälkeen, sillä ennen muutosta muodostettu yhteys ei todista mitään nyt voimassa olevasta kokoonpanosta. Varmista, että sallittu protokolla onnistuu ja että kielletty epäonnistuu valtuutetussa validointiprosessissa, ja jätä sitten varmenneidentiteetti ja luottamustarkistukset täsmälleen sellaisiksi kuin ne olivat.

Muista, mitä kättely ei kata. SSTP kuljettaa PPP-todennuksen TLS-kerroksen jälkeen, joten nykyaikainen protokollaversio ei kerro, kuka käyttäjä valtuutettiin tai mihin resursseihin istunto voi päästä. Ne ovat erillisiä kontrolleja erillisine todisteineen.

Kirjoita tulos muotoon palvelu, taustajärjestelmä, sallittu käytäntö ja havaittu versio. Sellainen kirjaus vastaa turvallisuuskysymykseen tarkasti, mitä tarra-argumentti tai vaivallisuusargumentti ei koskaan tee.