esittely
Kun käyttäjä vierailee HTTPS-verkkosivustollasi, hänen on vastattava työskentelemällä julkinen avain, ja voimassa oleva SSL-varmenne, joka yhdistää avaimen henkilöllisyyteesi joko henkilönä, yrityksenä tai organisaationa. Varmenteille annetaan aina ennalta määrätty voimassaolopäivä, joka sisältyy itse allekirjoitettuun varmenteeseen, ja selaimet tarkistavat aina viimeisen voimassaolopäivän ja hylkäävät kaikki vanhentuneet varmenteet.
Tietyissä tapauksissa varmenne on kuitenkin merkittävä virheelliseksi (ja luottamus kyseisiin varmenteisiin on oltava peruutettu) ennen se vanhenee. Yleisiä esimerkkejä ovat palvelimen omistaja, jolla on todisteita (tai epäillään yksinkertaisesti), että heidän yksityisen avaimensa on vaarannettu (ts. Se on kadonnut, varastettu tai tuhottu), koska tätä yksityistä avainta hallussaan pitävä kolmas osapuoli voi käytännössä ohittaa kaikki selainverkon tietoturvallisuudet.
Seurauksena on selaimen myyjät julkisesti luotettu todistusviranomaiset (CA) ottamaan käyttöön ainakin yksi menetelmä sekä ongelmallisten varmenteiden peruuttamiseksi että ilmoittamaan selaimille näiden peruutettujen varmenteiden hylkäämiseksi.
Lyhyt historia peruutuksen tarkistuksesta (ongelmista)
SSL: n alkuaikoina CA-menetelmänä oli julkaista sertifikaattiensa peruuttamistila julkisesti saatavilla olevissa asiakirjoissa, joita kutsuttiin varmenteiden peruuttamisluettelot (CRL). CRL on yksinkertaisesti luettelo kaikista varmenteista, jotka CA on koskaan peruuttanut ennen voimassaolon päättymistä. CA: t julkaisivat säännöllisesti CRL-luokkiensa uusimman version, jonka selainten oli vaadittava neuvottelemaan ennen jokainen HTTPS-yhteys.
Luonnollisesti HTTPS (ja SSL /TLS) hyväksyminen lisääntyi vuosien varrella, samoin kuin julkaistujen vertailulaboratorioiden koko. Vaatimus, jonka mukaan suuri CRL on ladattava ja jäsennettävä ennen jokaista yhteyttä, aiheutti jatkuvasti kasvavan verkon yleiskustannuksen. Nopeasti kävi ilmi, että CRL-menetelmä ei skaalautunut hyvin.
Näiden skaalausongelmien lieventämiseksi selaimet ja varmentajat ovat suunnitelleet ja toteuttaneet Online-varmenteen tilaprotokolla (OCSP). Julkisesti luotettavat varmentajat, kuten SSL.com, ylläpitä nyt yksinkertaisia HTTP-palvelimia nimeltä OCSP-vastaajat. Selaimet voisivat nyt ottaa yhteyttä vastaajaan pyytääkseen varmentajan myöntämän yksittäisen varmenteen peruuttamistilaa sen sijaan, että tarvitsisi hankkia ja käsitellä koko CRL.
OCSP-vastaajat allekirjoittavat vastauksensa varmentajan yksityisellä allekirjoitusavaimella, ja selaimet voivat varmistaa, että todellinen varmentaja on todella luonut saamansa peruutustilan.
Valitettavasti, vaikka OCSP näytti aluksi tehokkaalta ratkaisulta, uudella protokollalla on osoittautunut käytännöllisiä suorituskykyyn, turvallisuuteen ja yksityisyyteen liittyviä kysymyksiä.
Suorituskykyä koskevat kysymykset
Yhteyden ottaminen vastaajaan jokaisesta sertifikaatista, jonka selain kohtaa, tarkoittaa, että selainten on suoritettava ylimääräinen HTTP-pyyntö jokaiselle uudelle HTTPS-yhteydelle. Tämä verkon yläpinta oli käyttäjän havaittavissa, etenkin sivuilla, jotka sisältävät kolmansien osapuolien sisältöä etäsisällönjakelupalvelimille (joilla jokaisella voi olla yksi tai useampi varmenne paikallaan).
Reagointikykyä on hyvän käyttöliittymäsuunnittelun olennainen periaate. Pitkät viiveet voivat olla tärkeä syy käyttäjien turhautumiseen, ja voivat johtaa käyttäjiin uskomaan, että verkkosivustosi ei toimi tai että heidän syöttöeleensä on jätetty huomiotta.
Lisäksi monet opinnot aiemmin ovat yhdistäneet nopean sivun latausnopeuden ja reagointikyvyn parannettuun SEO ja lisääntyneisiin muuntokursseihin. Itse asiassa Amazon on laskenut, että vain sekunnin viive voi maksaa heille $1.6 miljardi vuosittain.
(Lisätietoja siitä, kuinka sivun latausnopeus vaikuttaa verkkosivustoosi, ja ehdotettuja optimointeja saat tutustumalla sivustoomme artikkeli kuvaavat kuinka sekalaisen sisällön poistaminen verkkosivustoltasi parantaa sen suorituskykyä.)
Turvallisuusasiat
OCSP: llä on myös tärkeitä turvallisuusongelmia. Se, että suurin osa käytännöllisistä OCSP-toteutuksista ei ollut riittävän luotettavia (joko verkon viiveestä, tai kokoonpano- tai sovellusvirheistä johtuen), motivoi selaimia ja muita asiakasohjelmistoja toteuttamaan OCSP-kirjautumisen soft-hylätty tilassa.
Tämä tarkoittaa, että jos OCSP-palvelinta ei tavoiteta tai aikakatkaisu antaessaan vastausta, selaimet tekevät pitää todistusta pätevänä ja jatka HTTPS-yhteyttä kuitenkin.
Syynä tähän on se, että koska OCSP-palvelin voi palvella miljoonia verkkosivustoja ja OCSP-palvelin voi epäonnistua milloin tahansa, yhteyden katkaiseminen jokaisessa OCSP-virheessä häiritsisi miljoonien käyttäjien selauskokemusta. Vaikka OCSP-palvelin toimii, mutta vastaaminen vie kauan, tämä lisää havaittua viivettä ja käyttäjän turhautumista.
Mies keskellä (MITM) Hyökkääjien on tiedetty hyödyntävän tätä käyttäytymistä estämällä kaikki yhteydet OCSP-vastaajiin, mikä tarkoittaa käytännössä sitä, että he voivat käyttää varastettua sertifikaattia ja avainparia haittaohjelmassa riippumatta varmenteen peruutustilasta.
Tietosuojakysymykset
Lopuksi, koska varmenne on linkitetty avaimeen ja verkkotunnukseen, ja selaimet pyytävät peruutustilaa ennen jokaista uutta HTTPS-yhteyttä, tämä tarkoittaa, että selaimet vuotavat merkittävän osan käyttäjien verkkohistoriasta OCSP-vastaajalle.
Tietenkin julkisesti luotetut varmentajat eivät ole haitallisia organisaatioita, jotka haluavat vaarantaa käyttäjän yksityisyyden. (Maineikkaat CA: t yrittävät aina aktiivisesti suojella käyttäjien turvallisuutta ja yksityisyyttä.) Jos kuitenkin varmentajan OCSP-vastaaja vaarantuu, kyseisen ei-luotettavan palvelimen kanssa vaihdettu data voi johtaa arkaluonteisten ja yksityisten tietojen paljastamiseen.
OCSP Nidonta pelaamiseen
Näiden ongelmien lieventämiseksi selaimet ja varmentajat esittivät uuden menetelmän varmenteen tilan määrittämiseksi, nimeltään OCSP-nidonta. OCSP-nidonta antaa verkkopalvelimille (selainten sijaan) hankkia allekirjoitettuja OCSP-vastauksia varmenteilleen, jotka voidaan välimuistiin jopa 7 päivän ajan.
Palvelimiin kuuluu (tai nitoa) välimuistissa oleva OCSP-vastaus heidän HTTPS-vastauksissaan itse SSL-varmenteen kanssa. Tällä tavalla selaimet voivat varmistaa CA-allekirjoitukset OCSP-vastauksessa ja olla varmoja siitä, että varmennetta ei ole peruutettu ennen suojatun yhteyden luomista ja joutumatta suorittamaan kallista lisäpyyntöä itse OCSP-palvelimelle.
OCSP-nidonta on yksinkertainen, mutta erittäin tehokas ratkaisu edellä mainittuihin ongelmiin. Palvelimet voivat hakea välimuistiin tallennetut OCSP-vastaukset omalla ajallaan, mikä poistaa CRL: n ja OCSP: n asettamat suorituskyvyn yleiskustannukset sekä siihen liittyvät yksityisyyden suojaan liittyvät huolenaiheet.
OCSP-nidonta itsessään ei kuitenkaan ratkaise OCSP: n pehmeän epäonnistumisen turvallisuusongelmaa kokonaan. Koska nidonta on toteutettu palvelimessa, selaimet eivät voi tietää, tukeeko palvelin todella nidontaa vai ei.
Tämän seurauksena MITM-hyökkääjät, joilla on varastettu (mutta kumottu) sertifikaatti, voivat suorittaa alennushyökkäyksen palvelemalla sertifikaattia ilman OCSP-nidontaa. Uhrin selain ei voi vahvistaa, tukeeko palvelin todella nidontaa, ja jatkaa kyselyä OCSP-vastaajaa normaalisti.
MITM-hyökkääjät voivat sitten vain estää tämän OCSP-kyselyn ja pakottaa selaimet tehokkaasti hyväksymään varmenteen kelvollisena.
OCSP pakollinen
Tämä hyökkäys motivoi CA: it ja selaimen myyjiä ottamaan käyttöön laajennuksen SSL-varmenteille, jotka määritellään RFC 7633, jota yleisesti kutsutaan OCSP Pakollinen (Vaikka RFC itse ei mainitse tätä nimeä, mikä voi aiheuttaa sekaannusta.) Tämä yksinkertaisesti määrää OCSP: n nidonnan sertifikaatille. Jos selain havaitsee tällä laajennuksella olevan varmenteen, jota käytetään ilman OCSP-nidontaa, se hylätään. OCSP Must Staple lievittää edellä mainittua alennushyökkäystä ja vähentää myös tarpeetonta liikennettä varmentajan OCSP-vastaajalle, mikä voi myös auttaa parantamaan OCSP: n yleistä suorituskykyä.
Jos olet kiinnostunut ottamaan OCSP Must Staple -laajennuksen käyttöön varmenteissasi, ota yhteyttä johonkin tukiedustajamme osoitteessa support@ssl.com lisätietoja.
Ota OCSP-nidonta käyttöön palvelimellasi
Seuraavien osioiden ohjeiden mukaan OCSP-nidonta otetaan käyttöön Apache ja nginx ympäristöissä:
Apache
Ota OCSP-nitominen käyttöön Apache lisää seuraavat rivit palvelimesi määritystiedostoon.
# OCSP nidonta, vain httpd 2.3.3 ja uudemmissa SSLUseStapping on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb: / var / run / ocsp (128000)
nginx
Ota OCSP-nitominen käyttöön nginx lisää seuraava teksti palvelimesi määritystiedostoon.
# OCSP nidonta --- # nouta OCSP-tietueet URL-osoitteesta ssl_certificate ja tallenna ne välimuistiin ssl_stapling; ssl_stapling_verify on;
Yhteenveto
Verkko on monimutkainen verkosto toisistaan riippuvaisia komponentteja, jotka kaikki (yleensä) toimivat harmoniassa tarjotakseen saumattoman selauskokemuksen. Tämän järjestelmän jatkuvasti kasvava monimutkaisuus luo kuitenkin jatkuvasti laajenevan hyökkäyspinnan ja mahdollistaa uusien verkkohyökkäysten suunnittelun ja toteuttamisen.
Komponenttien suuri määrä lisää luonnollisesti viivettä ja aiheuttaa viivästyksiä, mikä tarkoittaa, että yritysten on löydettävä tapoja parantaa tietoturvaa vaikuttamatta käyttökokemukseen. OCSP-nidonnan ottaminen käyttöön antaa sinulle harvan mahdollisuuden parantaa tietoturvaa ja suorituskyky verkkosivustollesi samanaikaisesti.
Kuten aina, vastaamme mielellämme OCSP-nidonta- tai muihin kysymyksiisi koskeviin kysymyksiisi - pudota meille sähköpostia osoitteeseen support@ssl.com.
