Certificate Transparency -lokit: mitä ne paljastavat verkkotunnuksistanne
Certificate Transparency (CT) on joukko lokeja, joihin merkintöjä voi vain lisätä ja joihin TLS-varmenteet kirjataan sitä mukaa kuin varmentajat niitä myöntävät. Kuka tahansa voi lukea näitä lokeja. Yrityksellenne se tarkoittaa 2 asiaa: lokit näyttävät kaikille, mille palvelinnimille teillä on varmenteita, ja niiden avulla huomaatte verkkotunnuksellenne myönnetyn varmenteen, jota kukaan teidän puoleltanne ei pyytänyt.
Protokolla kuvattiin ensin dokumentissa RFC 6962 (kesäkuu 2013), ja se päivitettiin versioksi 2.0 dokumentissa RFC 9162 (joulukuu 2021). Molemmat ovat kokeellisia (Experimental) RFC-dokumentteja, mutta selaimet nojaavat CT:hen käytännössä: Chrome edellyttää, että sen hyväksymät TLS-varmenteet noudattavat CT-vaatimuksia, ja Applella on oma CT-käytäntönsä alustoilleen.
Jos selain siis hyväksyy varmenteen osoitteelle yourcompany.com, sille on lähes varmasti lokimerkintä.
Mitä lokit paljastavat yrityksestänne
CT-merkintä sisältää nimet, jotka varmenne kattaa, myöntäjän ja voimassaolopäivät. Yhdessä verkkotunnuksenne merkinnät paljastavat:
- Aliverkkotunnuksenne.
vpn.yourcompany.com,jira.yourcompany.com,staging-api.yourcompany.com: jokaisen nimen, jolle on joskus myönnetty varmenne. - Toimittajanne. Myöntäjät ja nimeämistavat vihjaavat usein, mitä hosting-, sähköposti- tai SaaS-alustoja käytätte.
- Historianne. Vanhat merkinnät jäävät lokiin, joten vuosia sitten lopetettujen projektien nimet näkyvät yhä.
- Uudet varmenteet sitä mukaa kuin ne ilmestyvät. Uusi merkintä nimelle, jota ette tunnista, tai myöntäjältä, jota ette käytä, kannattaa kyseenalaistaa.
Mikään tästä ei ole CT:n vika. Järjestelmän tarkoitus on, ettei virheellisesti myönnettyjä varmenteita voi piilottaa. Palvelinnimienne luettelo ei siksi ole yksityinen, joten se kannattaa lukea ennen muita.
Miten haette lokeista itse
Helpoin tapa on crt.sh, CT-lokien hakukäyttöliittymä. Hakekaa verkkotunnuksellanne tai käyttäkää %-merkkiä jokerimerkkinä, jolloin mukaan tulevat kaikki aliverkkotunnukset:
https://crt.sh/?q=%25.yourcompany.com
Jos haluatte luettelon jatkokäsittelyä varten, lisätkää &output=json:
curl -s 'https://crt.sh/?q=%25.yourcompany.com&output=json' \
| jq -r '.[].name_value' | sort -u
Tuloksia lukiessanne etsikää:
- Nimiä, joita kukaan ei tunnista. Jokaisen pitäisi vastata järjestelmää, jolla on tunnettu omistaja.
- Testi- ja staging-nimiä, kuten
dev,test,old,beta. Ne osoittavat usein unohdettuihin testipalvelimiin. - Nimiä, joille DNS ei enää palauta osoitetta tai jotka osoittavat alustalle, jolta olette lähteneet. Tarkistakaa ne orvoiksi jääneiden DNS-tietueiden ja aliverkkotunnuksen kaappauksen varalta.
- Odottamattomia myöntäjiä. Varmenne myöntäjältä, jota ette ole koskaan käyttäneet, kannattaa käydä läpi DNS:ää ja hostingia hoitavan tiimin kanssa.
- Tuoreita päivämääriä, joita ette osaa selittää. Uusi varmenne pääkirjautumispalvelimellenne, jota kukaan ei pyytänyt, on kiireellisin tapaus.
Muistakaa, että jokerimerkkivarmenteet (*.yourcompany.com) eivät luettele yksittäisiä aliverkkotunnuksia, joten lokit näyttävät paljon mutta eivät kaikkea.
Rajatkaa varmentajat: CAA-tietue
CAA-tietueella, joka on määritelty standardissa RFC 8659, voitte kertoa varmentajille, mikä niistä saa myöntää varmenteita verkkotunnuksellenne. Myöntäjät tarkistavat sen ennen myöntämistä. Tyypillinen määritys:
yourcompany.com. CAA 0 issue "letsencrypt.org"
yourcompany.com. CAA 0 issuewild ";"
yourcompany.com. CAA 0 iodef "mailto:security@yourcompany.com"
Tämä sallii yhden myöntäjän, kieltää jokerimerkkivarmenteet ja antaa osoitteen ilmoituksille. CAA ei korvaa CT:tä: se rajoittaa sitä, mitä voidaan myöntää, kun taas CT näyttää, mitä todella myönnettiin.
Voimassaoloajat lyhenevät, joten lokimerkintöjä tulee enemmän
CA/Browser Forumin äänestyksen SC-081 mukaan, joka on nyt osa Baseline Requirements -vaatimuksia, selainten hyväksymien TLS-varmenteiden enimmäisvoimassaolo on 200 päivää 15.3.2026 alkaen myönnetyille varmenteille, 100 päivää 15.3.2027 alkaen ja 15.3.2029 alkaen vain 47 päivää. Varmenteita uusitaan useammin ja enimmäkseen automaattisesti, joten verkkotunnuksenne tuottavat enemmän CT-merkintöjä. Käsin lukeminen käy siksi hankalammaksi, ja selkeä perustaso ”odotetuista” varmenteista tulee hyödyllisemmäksi. Uusimisen näkökulmasta muutosta käsittelemme artikkelissa miksi varmenteen vanheneminen kaataa yhä verkkosivustoja.
Mitä tehdä, kun löydätte jotain odottamatonta
- Selvittäkää omistaja. Kysykää IT-osastolta, markkinoinnilta ja kumppanitoimistoiltanne, pyysivätkö he varmenteen.
- Jos kukaan ei pyytänyt, ottakaa yhteyttä myöntäjään. Jokainen myöntäjä kertoo, miten virheellisesti myönnetyistä varmenteista ilmoitetaan ja miten niiden peruuttamista pyydetään.
- Tarkistakaa DNS ja verkkotunnusvälittäjä. Odottamaton varmenne voi seurata DNS-muutosta, joten käykää läpi artikkelimme nimipalvelimen ja verkkotunnusvälittäjän muutoksista kuvatut vaiheet.
- Lisätkää tai tiukentakaa CAA:ta, jotta sama varmentaja ei voi myöntää uutta varmennetta ilman suostumustanne.
Lyhyt tarkistuslista
- Hakekaa crt.sh:sta
%.yourcompany.comja tallentakaa nimiluettelo. - Yhdistäkää jokainen nimi järjestelmään ja omistajaan.
- Poistakaa tai korjatkaa nimet, jotka eivät osoita mihinkään.
- Julkaiskaa CAA-tietue, jossa nimetään käyttämänne myöntäjät.
- Käykää uudet merkinnät läpi säännöllisesti, ei kerran vuodessa.
Datahorsesin rooli
Datahorses valvoo yritystänne ulkopuolelta joka päivä, ja Certificate Transparency on yksi asioista, joita luemme puolestanne: verkkotunnuksillenne myönnetyt uudet varmenteet, uudet aliverkkotunnukset sekä CAA-tietueet, joiden pitäisi rajoittaa niitä. Emme mene järjestelmiinne emmekä tarvitse pääsyoikeuksia. Kun jokin näyttää väärältä, saatte havainnon selkeine ohjeineen, kuten kohdassa mitä tapahtuu, kun löydämme jotain kerrotaan. Koko luettelo siitä, mitä valvomme, on etusivulla.
Lisää artikkeleita
Brändiänne jäljittelevät väärennetyt kirjautumissivut: miten ne syntyvät ja miten ne saa poistettua
Kopio kirjautumissivustanne samankaltaisessa verkkotunnuksessa voi kerätä asiakkaidenne salasanoja. Näin tällaiset sivut syntyvät, näin huomaatte ne ajoissa ja näin saatte ne poistettua.
Hyökkäyspinnan valvonta vai EDR ja XDR: toisiaan täydentävät, eivät kilpailevat
EDR ja XDR katsovat sisäänpäin laitteisiin, kirjautumisiin ja prosesseihin. Ulkoinen hyökkäyspinnan valvonta katsoo yritystänne internetistä. Siksi tarvitsette molemmat näkymät.
Miten DMARC-koosteraporttia (rua) luetaan ja mitä sillä tehdään
DMARC-koosteraportit luettelevat jokaisen palvelimen, joka lähetti postia verkkotunnuksenne nimissä, ja sen, läpäisikö se tarkistukset. Näin luette XML:n ja teette siitä korjauslistan.