Wesentra Oy
Alkuun

Certificates, sertifikaatit eli varmenteet

Historiaa, kuinka varmenne toimii ja mihin sitä käytetään

SSL/TLS Certificates eli varmenteet suojaavat verkkoliikennettä. Entrust certificates, Entrust certifikater, Telia certifikater

Varmenteen toiminta, mihin sitä käytetään

Varmenteita on turvaominaisuuksiltaan periaatteessa kolmea tasoa: OV, EV ja DV (neljää, jos varmenneautomaatti Let's Encrypt lasketaan mukaan). Näistä eri tyypeistä löydät tarkempaa tietoa täältä: Weseblog.com ja täältä.

Lyhyesti sanottuna sertifikaattia (varmennetta) käytetään tiedonkulun salaamiseen, mutta myös organisaation tunnistamiseen. OV/EV-varmenteet ovat kuin passi, näet suoraan varmenteesta kenen kanssa asioit ja sen lisäksi keskustelunne on turvassa urkkivilta korvilta.

Asymmetric / Symmetric keys, public and private key. PKI ja varmenteen eli certificate toiminta.

Kun viesti halutaan toimittaa salattuna vastaanottajalle, pitää lähettäjällä ja vastaanottajalla olla hallussaan sama salausmenetelmä. Tyypillisesti tämä tehdään salausavaimella, joka on etukäteen turvallisesti toimitettu viestin lähtö- ja vastaanottopäähän. Tätä kutsutaan symmetriseksi salaukseksi.

Symmetrisen salauksen aikaansaamiseen käytetään PKI-menetelmää (Public Key Infrastructure). PKI:n lähtökohtana on kaksi salausavainta, jotka ovat erittäin pitkiä alkulukuja. Toinen on salainen avain (Private Key) ja toinen julkinen avain (Public Key). Jos salaisella avaimella salataan viesti, sen voi avata vain julkisella avaimella. Ja päinvastoin: jos julkisella avaimella salataan viesti, sen voi avata vain salaisella avaimella.

Kun esimerkiksi web-palvelimella tehdään varmennehakemus (CSR, Certificate Signing Request), muodostuu palvelimella salainen ja julkinen avain. Julkinen lähtee varmennepyynnön mukana varmentajalle (esim. Entrust tai Telia), joka tarkastaa pyynnön oikeutuksen. Varmentaja lähettää takaisin SSL/TLS-varmenteen, joka sisältää mm. julkisen avaimen. SSL/TLS-varmenne asennetaan web-palvelimelle ja se lukittuu salaiseen avaimeen.

Kun selain ottaa yhteyttä suojattuun web-palvelimeen, se saa varmenteen ja sen mukana web-palvelimen julkisen avaimen. Selain muodostaa istunnon ajaksi symmetrisen avaimen, jonka se lähettää palvelimelle. Selain salaa tämän yhden viestin web-palvelimen julkisella avaimella. Tämä viesti voidaan purkaa vain web-palvelimella olevalla salaisella avaimella.

Nyt sekä selaimella että web-palvelimella on käytössä symmetrinen salausavain, jota kenelläkään muulla ei voi olla. Tätä käytetään kyseisen selainistunnon ajan liikenteen salaamiseen. Ja kun istunto päättyy, symmetriset avaimet poistetaan.

Varmenteiden historiaa

Varmenteiden, PKI:n ja verkkoturvallisuuden historian pieni otanta.

1994

Entrust valmisti ja möi ensimmäisen PKI ratkaisun, joka mahdollisti avainten ja varmenteiden hallinnan sekä salaamisen. Voidaan siis sanoa, että Entrust on SE varmenneteknologian kehittäjä. Varmenteilla on pitkä historia joka alkaa jo vuodesta 1994, jolloin Netscape kehitti ensimmäisen varteenotettavan version SSL:stä, SSL v2:n. Jo vuotta myöhemmin, tämä versio "ammuttiin alas" pahojen tietoturvaongelmien vuoksi ja SSL v3 sai alkunsa.

1999

Rauhaisaa eloa riitti aina vuoteen 1999 asti, jolloin mm. Microsoftin mukaan tulo aiheutti uuden nimeämiskäytännön ja TLS v1.0 sai alkunsa. Telia loi ensimmäisen PKI-palvelunsa. Ruotsissa alettiin myöntää kaupallisessa mielessä varmenteita yritysasiakaille. Samaan aikaan Soneran, suomalaisten pankkien, TietoEnatorin ja Suomen Postin yhteisyritys Certall Finland Oy aloitti toimintansa teknisten varmennepalvelujen tarjoamiseksi Suomessa.

2001

Vuonna 2001 VeriSign sai siipeensä jonkun pystyttyä hankkimaan siltä väärennetyn code signing varmenteen Microsoftin nimellä. Sonera aloitti kaupallisen varmennetoiminnan siten että osakkuusyhtiö Certall Oy hoiti CA-tuotannon ja laitteet olivat Tiedon konesalissa. Soneran varmenteita alettiin toimittaa esimerkiksi suomalaisille pankeille. Juurivarmenteet ”Sonera Class 1 CA” ja ”Sonera Class 2 CA” luodaan. Näistä jälkimmäinen on edelleen käytettävissä ja takaa erittäin laajan luottamuksen selaimissa ja käyttöjärjestelmissä. CA-ohjelmistoksi valitaan SmartTrust CA jonka alkuperäinen kehittäjä oli ID2 Technologies.

2004

Certall Oy lopettaa toimintansa. Sonera lunastaa oman varmennejärjestelmänsä itselleen ja jatkaa PKI-toimintaa oman CA-henkilöstön voimin samalla laitteistolla, ohjelmistolla ja laitesaliratkaisulla. Samalla Soneran PKI-prosessit ja juurivarmenteet auditoidaan ulkopuolisen tahon toimesta. Sonera CA saa ensi kertaa Webtrust-sinetin joka takaa erittäin korkean turvallisuuden ja pääsyn luotetuksi varmentajaksi lähes kaikkiin selaimiin ja käyttöjärjestelmiin. Tämän pohjalta Telia nopeasti pääsi luotetuksi varmentajaksi kaikkiin yleisiin selaimiin ja käyttöjärjestelmiin. Sen jälkeen Webtrust-auditointi Telian CA-palveluille on toistettu vuosittain.

2005

Telian ja Soneran fuusioitua vuonna 2002 konsernissa on neljä erillistä CA-järjestelmää useiden yrityskauppojen seurauksena. Näitä päätettiin lähteä yhdistämään yhteen uuteen järjestelmään siten että uusi pääpaikka sijoittuu Suomeen. Uuden yhteisen CA-järjestelmän laitteisto sijoitetaan Suomessa kahteen Telian omaan laitesaliin ja lisäksi eräitä osia Tukholman seudulle Ruotsiin. Telian uudeksi CA-ohjelmistoksi valitaan evaluointien jälkeen RSA Securityn CA-ohjelmisto.

2006

TLS v1.1 syntyy, joka muun muassa otti kantaa BEAST haavoittuvuuteen, joskin suuremman yleisön tietoisuuteen tämä haavoittuvuus nousi vasta viisi vuotta myöhemmin. Telian uusi CA-järjestelmä tulee käyttöön ja kaikkien Telia-konsernin aiempien CA-järjestelmien varmenteet migroidaan siihen. Tästä alkaa voimakas varmennemäärän kasvu siten että nykyisessä Telian järjestelmässä on miljoonia aktiivisia varmenteita

2007

Varmenteiden merkitys ja kehitys on kautta niiden olemassaoloajan kiihtynyt ja korkeimman turvatason, Extended Validation (EV), varmenteet syntyvät. Telia luo uusien vaatimusten mukaisen CA-hierarkian siten että juurivarmenteeksi tulee nykyisinkin käytössä oleva ”TeliaSonera Root CA v1”. Tämä juurivarmenne ristiinvarmennettiin vanhemmalla myöntäjällä ”Sonera Class2 CA”. Tästä eteenpäin Telian asiakkaat ovat voineet hakea samoille Telia-varmenteille luottamuksen kahta erilaista juurivarmennepolkua hyväksikäyttäen.

2008

Vuosi 2008 näki mielenkiintoisia haavoittuvuuksia sekä väärinkäytöksiä varmenteiden myöntämisessä (Live.com palveluun hankittiin väärennetty varmenne, StartCom:lla sekä CertStar:lla oli puuttellinen verifiointi joka salli väärennettyjen varmenteiden hankinnan). Hyviäkin uutisia oli, TLS v1.2 sai alkunsa.

2009

SSL Labs joka julkaisee työkaluja paremman verkkoturvallisuuden kehittämiseksi saa alkunsa. Samalle vuodelle osuu myös ainakin kolme haavoittuvuutta/hyödyntämismenetelmää: Insecure renegotiation, sslstrip ja NUL byte attacks

2010

Google aktivoituu parantamaan verkkoliikenteen turvallisuutta ja ottaa käyttöön HSTS, SPDY ja False Start teknologioita, jotka parantavat SSL/TLS verkkoliikenteen tehokkuutta. Samalle vuodelle osuu myös ikävä susi lampaan vaatteissa, Firesheep joka mahdollisti ei suojatun liikenteen helpon urkkimisen.

2011

Pyrittiin virallisesti pääsemään eroon SSL v2:sta, mutta onnistuiko se kokonaan? Ehkäpä ei. Samaiselle vuodelle napsahti jälleen muutama epäonnistuminen varmennetoimittajilla. Diginotar hakkeroitiin pahemman kerran ja myös Comodon varmenteita onnistuttiin kaappaamaan. Onneksi nämä huomattiin ajoissa ja Comodo revokoi varmenteet. Google otti käyttöön Public Key Pinning toiminnon omistamilleen saiteille ja vuosien varrella tämä onkin auttanut löytämään useita väärennösyrityksiä. Tämä oli myös PEDON vuosi, BEAST hyökkäys nousi tapetille ja tuli kertarysäyksellä julkisuuteen. Google ottaa käyttöön Forward Secrecy ominaisuuden.

2012

Chrome lakkaa tarkistamasta varmenteiden revokointilistoja. Toimittajat tosin kehittivät omia menetelmiänsä, voidakseen varmistaa varmenteiden revokoitumisen. HTTP/2 saa orastavan kasteen ja keskustelu sen ympärillä kiihtyy. SSL Labs julkaisee SSL Pulse palvelun, jolla voidaan seurata saittien kehittymistä. Tämä palvelu tuo tilastollisen näkymän internetin saiteista ja niiden turvatasosta. Liekit leimuavat myös FLAME haittaohjelman löydyttyä Iranista. Valtiolliset toimijat ovat todennäköisesti tämän takana. CABrowser Forum julkaisee ns. Baseline Requirements ohjeet, joita kaikkien CA:na toimivien tulee noudattaa. Microsoft alkaa blokkaamaan 1024 RSA:ta heikompia avaimia. HSTS, CSP nousevat merkittävästi esille. Synkempinä uutisina löytyy CRIME, sekä TurkTrust joka oli vahingossa myöntänyt CA varmenteita loppukäyttäjille.

2013

LUCKY 13 hyökkäysmenetelmä pintautuu ja RC4 saa kuoliniskun uusien tutkimusten valossa. Tosin kestää vielä muutaman vuoden, ennen kuin tämä käytännössä toteutuu. Edward Snowden tulee "kaapista" ja tekee historiallisen paljastuksen NSA:n urkintakoneistosta. Google julkaisee Certificate Transparency logituksen, joka mahdollistaa myönnettyjen varmenteiden viennin julkisiin rekistereihin. TIME ja BREACH hyökkäysmenetelmät pintautuvat. vTLS 1.3 kehittäminen alkaa. NSA ja GCHQ ovat kehittäneen Bulrun ja Edgehill menetelmiä kryptauksen heikentämiseksi. Safari ja IE11 alkavat tukea TLS v1.2 versiota. Google alkaa käyttää ChaCha20-Poly1305 TLS:ää, myöhemmin tämä standardisoidaan laajempaan käyttöön. ANSSI CA rajoitetaan myöntämään varmenteita vain Ranskan alueelle, tämä johtuu siitä että Google Public Key Pinning havaitsee väärennettyjä varmenteita myönnettyinä heidän toimestaan. v2011-2013 Voimakasta kasvua Telian Client-varmenteissa. Myönnetään useita miljoonia client-varmenteita Suomen ja Ruotsin keskeisille toimijoille erityisesti julkiselle sektorille. Telian SSL-varmenteiden rakennetta uudistetaan siten, että http-pohjainen CRL tulee LDAP:n rinnalle ja vähitellen korvaajaksi. SSL-varmenteiden laajennukset uusitaan muutenkin yleisien käytäntöjen mukaiseksi. Mobiilivarmenteissa suomalaiset operaattorit keskittävät voimansa ja tehdään mobiilivarmenne-roaming, joka tarkoittaa sitä, että kenen tahansa operaattorin mobiilivarmenne kelpaa kaikissa mobiilivarmenteita tukevissa palveluissa.

2014

Vuosi alkaa hyvin. RSA 2048 tulee standardiksi ja RSA 1024 jää eläkkeelle. Vanhat root ja intermediate varmenteet saavat edelleen jatkaa 1024:lla. Firefox liittyy Safarin ja IE11 seuraan ja tukee TLS v1.2:ta. Triple Handshake tutkimus pintautuu ja TLS renegotiation pitää miettiä jälleen uudelleen. HEARTBLEED OpenSSL projectissa tuo haavoittuvuudet koko kansan tietoisuuteen ja saa ennätysmäärän julkisuutta ja pöhinää aikaan varmenteiden parissa työskentelevissä. Hyvänä puolena HEARTBLEED tuo projektille lisärahoitusta suurten organisaatioiden toimesta ja sen kehittäminen ja korjaaminen saa uutta pontta. HEARTBLEED on piileskellyt projektissa reilun 20 vuotta, tämä verenvuodatus ehkä kannatti.Google kehittää oman versionsa OpenSSL:stä, BoringSSL:n ja alkaa portata Chromiumia sille. NIC India kärähtää väärennettyjen varmenteiden myöntämisestä ja Chrome rajoittaa tämän root varmenteiden käytön ainoastaan Intialaisille domaineille. LibreSSL saa HEARTBLEED:in innoittamana alkunsa Ivan Ristic julkaisee Bulletproof SSL and TLS kirjansa, johon tämäkin tarina osittain perustuu (kts. Lähteet sivun lopussa). 2014 oli jokseenkin huimaa SSL rintamalla, tälle vuodelle mahtui BESerk, POODLE, POODLE TLS ja tuntemattomampi (tutkielma) Bleichenbacher side channel hyökkäys. Telia siirtyy kaikissa varmenteissa turvalisempaan SHA256-tiivistealgoritmiin. RSA-algoritmin rinnalle tuodaan mahdollisuus käyttää halutessaan EC-algorimeja. Telian mobiilvarmenteen alkavat käyttää EC-algoritmia. Samalla OCSP otetaan päätavaksi tarkistaa varmenteen status. http-CRL säilyy vaihtoehtoisena tarkistustapana.

2015

LOGJAM aloittaa vuoden 2015 ja heti perään pintautuu SUPERFISH, Lenovon kannettavissa esiintynyt haavoittuvuus. Ongelmana oli kovakoodattu root varmenne, jonka privaattiavaimella kuka tahansa vastaavan koneen omistaja pystyi rakentamaan toimivan hyökkäyksen vastaaviin laitteisiin. Tätä seurasi välittömästi Komodia ja PrivDog, vastaavanlaiset haavoittuvuudet. IETF julkaisee RFC 7465 julkaisun kieltääkseen virallisesti heikoksi havaitun RC4 Cipher suiten. CNNIC myöntää testikäyttöön lyhytaikaisen Subordinate CA:n, jota päästiin hyväksikäyttämään. Tämän johdosta sekä Google, että Mozilla poistavat CNNIC-rootit käytöstä. LIVE.FI saa kolauksen Microsoftin unohdettua lukita sen admin sähköpostin ja suomalainen it-manageri saa haettua väärin perustein sille varmenteen. Tämä oli kuitenkin hyväntahtoinen teko, eikä varmennetta käytetty vääriin tarkoituksiin. Firefox julkaisee OneCRL:n varmenteiden sulkemista varten. Tätä ennen Firefoxin ainoa keino poistaa varmenteita käytöstä oli ohjelmistopäivitykset. Microsoft esittelee Certificate Reputation ominaisuuden, Windows 10 ottaa näytteitä käyttäjien kohtaamista varmenteista ja toimittaa ne edelleen Bing webmaster ohjelman kautta sivustojen omistajille. Punaiselle putoaa SMACK ja FREAK haavoittuvuudet. Firefox pudottaa pois turvattomat TLS Fallbackit. HTTP Public Key Pinning, vuosien debaatin jälkeen, julkaisee RFC 7469:n joka mahdollistaa suojautumisen väärennetyiltä varmenteilta. Suojausprotokolla TLS Fallback SCSV julkaistaan (RFC 7507) suojaamaan downgrade hyökkäyksiltä, sekä Firefox että Chrome tukee sitä, mutta Microsoft jää kelkasta pois. Google alkaa vaatimaan EV varmenteiden julkaisemista certificate transparency logeihin. HTTP/2 julkaistaan (RFC 7540), tätä onkin jo odotettu. Kaikki selainvalmistajat ovat päättäneet julkaista HTTP/2:sen suojatulla protokollalla, vaikka itse HTTP/2 ei sitä vaadi. SSL v3 pistetään jäihin POODLEn saattelemana. Let's Encrypt julkaistaan, tämä mahdollistaa varmenteiden haun automatisoinnin, ilmaiseksi. Telia päättää aloittaa SSL-varmenteiden markkinoinnin jotta tietoisuus leviää siitä että Suomessa tuotetaan selaimissa julkisesti luotettuja varmenteita. Aloitetaan prosessi EV-varmenteiden saamiseksi Telian SSL-lajeihin. Se edellyttää lisäauditointeja ja uusia sopimuksia selainvalmistajien kanssa.

2016

Pääosa selaimista poistaa tuen haavoittuvalle RC4 suitelle. SHA1 varmenteita ei enää myönnetä. Crypto Forum Research Group (CFRG) julkaisee (RFC 7748) julkaisun myötä kaksi uutta ECC menetelmää standardoitavaksi. SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes, CVE-2015-7575) tutkimuksella osoitetaan kuinka monet sovellukset edelleen käyttävät (client ja server) turvattomia RSA-MD5 allekirjoituksia. TLS 1.3 debaatti jatkuu, onko valmista vai ei. Firefox 45 parantaa varmenteiden sulkulistan käsittelyä. Tärkeimpänä uutena ominaisuutena on kuitenkin Must-Staple ominaisuus, varmenteille, jotka on niitattu tuoreella OCSP vastineella. DROWN hukutti taas toivon kirkkaammista vesistä netissä surffaamiselle. Tutkijat julkaisevat DROWN hyödyntämismenetelmän SSL v2.0 vastaan. Masentavaksi havainnon tekee se, että arvion mukaan n. 33% palvelimista oli tälle alttiina julkaisuhetkellä. Chrome lopettaa kaikki TLS fallback toiminnot. Tämä muutos on tärkeä siksi, että se heikentää man-in-the-middle väijyjien mahdollisuutta pudottaa suojattu yhteys heikommalle turvatasolle. Google myös lopettaa RC4 ja SSLv3 käytön ja ottaa HSTS:n käyttöön. Kaikki näyttää tässä vaiheessa heinäkuuta kauniilta, kunnes SWEET32 osoittaa kuinka yleisesti käytetyt BLOWFISH ja 3DES cipher:it ovat haavoittuvia. Telia modernisoi CA-toiminnoissa käytetyt serverit uuden tekniikan mukaisiksi. Telia CA saa oman pilviympäristön jonka sisällä on yli 100 CA-järjestelmille dedikoitua palvelinta. Dedikoidut CA-palvelimet kattavat kaikki modernin IT-järjestelmän osa-alueet kuten palomuurit, kuormantasaajat, lokiserverit, hallintaserverit, offline-ympäristöt, LDAP-palvelimet, Web-palvelimet, HSM-laitteet, tietokantapalvelimet, haavoittuvuusskannaukset, CA-palvelimet yms.

2017

Back to the future... Ehkä merkittävin asia on se, että SHA-1 varmenteiden hautajaisia pidettiin helmikuussa 2017. Aikataulua nopeutettiin jo kerran kun huomattiin, että laskentateho laitteissa on kasvanut niin huimasti, että jopa rikollisille alkaa avautua mahdollisuus hankkia teholtaan tarvittavat laitteet. SHA-2 on tehnyt tuloaan jo pitkään ja aiheuttanut myös kohtuullisen suuria kustannuksia laitteistojen uusimisten myötä. Ehkä saamme hetken hengähtää, ennen kuin seuraava uhka nousee tuhkasta. Vai onko se jo ovella? Kvanttitietokoneiden ylivertainen suorituskyky laskennassa saattaa tehdä tähänkin kohtaan loven. Suuria mullistuksia on tapahtunut myös CA rintamalla. Markkinajohtaja Symantec sai pahasti siipeensä annettuaan kumppaneilleen oikeuden verifioida ja myöntää varmenteita itsenäisesti. Tämä johti useisiin väärinkäytöksiin ja lopulta siihen, että Google "suuttui" ja laittoi Symantecin mustalle listalle. Käytännössä tämä johti siihen, että Symantecin eri brändien varmenteisiin lakattiin luottamasta. Lisänsä tähän soppaan toi Digicert, joka päätyi ostamaan Symantecin varmenneliiketoiminnan. Symantecin varmenteet tulee näin ollen ennustusten mukaan tiensä päähän 2018 vuoden alussa. Telia uusii CA-palvelinten ohjelmiston koska aiemman RSA CA-ohjelmiston kehittäminen lopetettiin. Uusi CA-ohjelmisto tuo uusia toiminnallisuuksia joista Telia kertoo myöhemmin. Telia sopi useiden suomalaisten jälleenmyyjien kanssa aloittavansa SSL-varmenteiden toimittamisen heidän kauttaan. Wesentra on toistaiseksi ainoa Telian SSL-jälleenmyyjä Suomessa joka myöntää Telian SSL-varmenteita kelle tahansa suomalaiselle yritykselle. Muut Telian jälleenmyyjät toimittavat Telian varmenteita omien konesaliensa asiakkaille.

ROBOT Attack nousee julkisuuteen loppuvuodesta 2017. Tämä juontaa juurensa niinkin kauas menneisyyteen kuin vuoteen 1998 jolloin Daniel Bleichenbacher (Bleichenbacher side channel) havaitsi, että virheilmoitukset joita SSL server antavat PKCS #1 1.5 täyttämisessä mahdollistivat hyökkäyksen joka rikkoo TLS luotettavuuden kokonaan käytettäessä RSA kryptausta. Tämä on paha paikka palveluille, jotka käyttävät ainoastaan RSA avainten vaihtoa (RSA encryption key exchange), sillä MITM voi tallentaa liikenteen ja myöhemmin purkaa sen. Tätä kirjoitettaessa (joulukuu 2017) haavoittuvuudelle alttiina on ollut ainakin 7 laitevalmistajaa, mm. F5, Citrix ja Cisco.
Tässä listausta, jonka avulla voi seurata joidenkin laitevalmistajien edistymistä tämän suhteen:

F5 BIG-IP SSL vulnerability CVE-2017-6168
Citrix TLS Padding Oracle Vulnerability in Citrix NetScaler Application Delivery Controller (ADC) and NetScaler Gateway CVE-2017-17382
Radware Security Advisory: Adaptive chosen-ciphertext attack vulnerability CVE-2017-17427
Cisco ACE Bleichenbacher Attack on TLS Affecting Cisco Products, End-of-Sale and End-of-Life CVE-2017-17428
Bouncy Castle Fix in 1.59 beta 9, Patch / Commit CVE-2017-13098
Erlang OTP 18.3.4.7, OTP 19.3.6.4, OTP 20.1.7 CVE-2017-1000385
WolfSSL Github PR / patch CVE-2017-13099
MatrixSSL Changes in 3.8.3 CVE-2016-6883
Java / JSSE Oracle Critical Patch Update Advisory - October 2012 CVE-2012-5081

2018

Hypätään historiasta suoraan tulevaisuuteen (19/10/2017 hetkestä). Maaliskuun 1, 2018 OV varmenteiden elinikä putoaa 27 kuukauteen, eli tulee samalle tasolle kuin EV varmenteissa jo ollaan menossa. Näitä muutoksia sanelee CABrowser forum, joka pitää varmentajat tiukasti ruodussa. Jotkut varmennetoimittaja varautuvat jo tähän muutokseen joulukuussa 2017. Tästä linkistä saat lisätietoa.

Varmenneteollisuus elää murrosaikaa, suuri varmennejättiläinen Symantec ajautui jo 2017 vaikeuksiin alihankkijoittensa myönnettyä virheellisiä varmenteita. Erityisesti Google, joka on ilmaisen Let's Encrypt varmenteen taustavoima, otti Symantecin hampaisiinsa ja lopputuloksena Symantecin varmenneliiketoiminta myytiin huomattavasti pienemmälle toimijalle, Digicertille. Tämä aiheutti melkoisen kaaoksen markkinaan kun asiakkaat joutuivat uusimaan varmenteita ja tekemään varasuunnitelmia verkkoliikenteensä turvallisuuden ja toimivuuden takaamiseksi jatkossakin. Tästä myllerryksestä löytyy hyvä artikkeli tästä: (klik!)

CA Browser forum teki 5.2.2018 päätöksen muuttaa verifiontitapoja ja sitä myötä poistaa ns. manuaalisen verifiontitavan, jota yleisesti ottaen on pidetty asiakasystävällisenä tapana. Käytännössä tämä työ, jonka on aiemmin suorittanut verifiontiin koulutettu ja erikoistunut asiantuntija, tapahtuu jatkossa koneellisesti. Domainin omistajan on pystyttävä todistamaan domainin hallinta jollain automaattisella tavalla. Automatiikkaa on ollut käytössä aiemminkin ja valitettavasti siihen on kohdistunut onnistuneita hyväksikäyttöjä menneisyydessä (myös hyvässä tarkoituksessa, lue tämä artikkeli). Teknologiat on noista ajoista kehittynyt ja tietoisuus domainien suojaamisesta väärinkäytöksiltä kasvanut.

Tässä tarkempi selostus BALLOT 218 vaikutuksesta:

Tausta – CA/Browser Forumin päätös

Kaikkia varmentajia säätelevä CA/Browser Forum on päättänyt, että 1.8.2018 alkaen kaikkien Certificate Authority (CA) -toimijoiden tulee verifioida domainit muuten, kuin WHOIS-tietoihin kirjatun omistajatiedon perusteella. Tämä muutos koskee kaikkia varmentajia.

Mitä tämä tarkoittaa?
Jatkossa ei riitä se, että domain on rekisteröity hakijan nimellä, vaan domainien hallinta tulee varmistaa toisella tavoin (Mail, Web Server tai DNS -menetelmällä – tästä alempana lisää). Kaikki nykyiset varmenteet ovat normaalisti voimassa loppupäiväänsä asti. Hakijan nimen perustella verifioidut domainit pitää uudelleenverifioida 1.8.2018 mennessä uuden ohjeen mukaisesti, jotta voidaan tehdä uusia varmenteita tai nykyisiin varmenteisiin voidaan tarvittaessa tehdä muutoksia (ReIssue, Renew). Tämän muutoksen nähdään lisäävän varmenteiden turvallisuutta ja tietoturvaa. Tämän muutoksen myötä varmistetaan varmenteen hakijan kontrolli kyseiseen domainiin.

Jatkossa käytettävissä olevat verifiointitavat ovat seuraavat:

Email

  • Domainin hyväksymiseksi lähetetään automaattinen sähköposti domainin WHOIS-tiedoista löytyvään sähköpostiosoitteeseen sekä lisättävän domainin administrator@, admin@, postmaster@, hostmaster@, ja webmaster@ -sähköpostiosoitteisiin. Jonkun em. vastaanottajista on avattava sähköpostissa oleva hyväksymislinkki ja hyväksyttävä domain. Tämän jälkeen domain on käytettävissä.

Web Server

  • Domainin hyväksymiseksi varmentajalta toimitetaan pieni tiedosto ja ohjeet sen sijoittamiseksi web serverille kyseisen domainin osoitteen alle. Tiedoston olemassaoloa ja sisältöä tarkastetaan automaattisesti n. 20 minuutin välein ja kun se havaitaan ja sisältö on oikea, domain hyväksytään ja se on käytettävissä. Kokemukseen perustuen hyväksymiseen voi mennä n. 1-2 tuntia nimipalvelulisäyksen jälkeen.

DNS

  • Domainin hyväksymiseksi saat varmentajalta teksti-/numerosarjan, joka on lisättävä domainin DNS:n TXT-tietueeseen. DNS-tietuetta pollataan n. 60 minuutin (varmentajasta riippuen) välein ja kun oikea teksti-/numerosarja löytyy, domain hyväksytään ja on käytettävissä. HUOM! random-arvo laitetaan osoitteelle _pki-validation.<verifioitava domain>

Entrustin Knowledge Basessa on englanninkielisiä ohjeita liittyen yllämainittuihin domainien verifiointitapoihin: http://www.entrust.net/knowledge-base/technote.cfm?tn=71169)
Tämä muutos perustuu Certificate Authority/Browser Forum baseline requirements -vaatimuksiin. Voit lukea tarkemmin päätöksesta (Ballot 218): https://cabforum.org/2018/02/05/ballot-218-remove-validation-methods-1-5/

Lähteitä:
Wesentra Oy, SSL/TLS-Palvelut
www.feistyduck.com
Weseblog
CA Browser Forum
Entrust Datacard
Telia
Qualys SSL Labs SSL/TLS Wiki