Defaults.Exposed › Korjaukset › Nykyaikainen salaus (TLS-versio ja salausalgoritmit)

Kuinka korjata Nykyaikainen salaus (TLS-versio ja salausalgoritmit)

TLS on lukko, joka salaa kävijöidesi ja verkkosivustosi välillä kulkevan datan. Kaksi asiaa tekee tuosta lukosta luotettavan: nykyaikaisen TLS-version käyttö (ei vanhoja, rikkinäisiä versioita) ja vahvojen salausalgoritmien käyttö (varsinainen salausresepti). Tämä sivu kattaa molemmat – sekä muutaman siihen liittyvän asetuksen, jotka eivät vaikuta arvioosi mutta on hyvä tietää.

Lyhyesti liiketoiminnallesi: Jos sivustosi toimii vanhentuneella salauksella tai heikoilla salausalgoritmilla, asiakkaidesi kirjoittamat yksityiset tiedot – kirjautumiset, korttinumerot, yhteystiedot – voidaan hiljaa siepata ja lukea jaetuissa verkoissa, ja voit epäonnistua tietoturvatarkistuksissa, joita pankit, maksunkäsittelijät ja suuremmat asiakkaat nyt vaativat ennen liiketoimintaa sinun kanssasi.

Mitä tämä voi maksaa sinulle

• Asiakas maksaa tai kirjautuu sisään hotellin tai kahvilan WiFin kautta, vanhentunut yhteys tai heikko salausalgoritmi antaa vieraan kyseisessä verkossa lukea heidän korttinsa ja salasanansa reaaliajassa, ja petos – ja vihainen puhelu – jäljitetään suoraan sivustoosi.
• Haet korttimaksujen hyväksymistä (tai maksuntarjoajasi auditoi sinut uudelleen) ja sinut hylätään, koska vanhentunut TLS tai kielletty salausalgoritmi rikkoo maksutietoturvamääräyksiä – verkkomaksujesi käsittely on jäässä kunnes se on korjattu.
• Suuremman asiakkaan IT-tiimi suorittaa rutiinitietoturvaskannauksen ennen allekirjoittamista, näkee sivustosi sallivan edelleen rikkinäistä salausta ja merkitsee sinut riskiksi – sopimus pysähtyy ongelmaan, joka ei maksa mitään korjata.
• Tietosuojavalitus tai tietomurto päätyy pöydällesi ja ensimmäinen kysymys, jonka sääntelyviranomainen esittää, on oliko asiakastietoja suojeltu 'asianmukaisesti' – julkisesti tiedettynä rikkinäisenä vuosia olleen salauksen käyttäminen on hyvin vaikea vastaus antaa.
• Sivustosi näyttää lukon, joten kaikki olettavat sen olevan täysin turvallinen, ja tämä aukko jää huomaamatta vuosiksi – kunnes yksi siepattu kirjautuminen tai korttinumero muuttuu tapaukseksi, joka on huomattavasti kalliimpi kuin ilmainen korjaus olisi ollut.

Miksi tällä on merkitystä. Turvallinen salaus on näkymätön; vanhentunut tai heikko salaus on vastuu, joka istuu hiljaa siihen päivään asti, jona se maksaa sinulle asiakkaan, sopimuksen tai vaatimustenmukaisuuden läpäisyn. TLS-versio ja salausalgoritmin tarkistukset ovat kaksi osaa, jotka todella liikuttavat arviotasi, ja molemmat ovat tyypillisesti yksittäinen ilmainen asetus – ei ole mitään etua jättää vanhoja, rikkinäisiä vaihtoehtoja päälle.

Selkokielellä

Kun joku vierailee verkkosivustollasi, kaikki, mitä he kirjoittavat – kirjautumiset, korttinumerot, nimet, puhelinnumerot, viestit – salataan matkalla, jotta vieraat eivät pysty lukemaan sitä. Salaamisen tekevä teknologia on nimeltään TLS (saatat myös kuulla sen kutsuttavan SSL:ksi, vanhemmaksi nimekseen). Jotta kyseinen salaaminen olisi todella turvallinen, kaksi asiaa on oltava oikein:

1. TLS-versio – minkä sukupolven teknologiaa käytät. Varhaiset versiot (TLS 1.0 ja 1.1) ovat olleet julkisesti rikki vuosia; turvalliset ovat TLS 1.2 ja TLS 1.3.
2. Salausalgoritmi – tietty resepti, jota TLS käyttää salaamiseen. Jotkut algoritmit (kuten RC4, DES ja 3DES) on murrettu ja ne ovat nyt kiellettyjä; nykyaikaiset algoritmit ovat edelleen vahvoja.

Tämä sivu kattaa molemmat, koska sivusto voi saada toisen oikein ja toisen väärin. Sinulla voi olla nykyaikainen lukko vanhan, murrettavissa olevan reseptin kanssa edelleen päällä – tai vahva resepti suojeltuna vanhentuneella lukolla. Kumpikin aukko on auki oleva ovi. Molemmat suljetaan yleensä samalla yksittäisellä ilmaisella muutoksella palvelinasetuksiisi tai hostingiin.

Mitä tämä voi maksaa yrityksellesi

• Asiakas ryöstetään julkisessa WiFissä. Joku kirjautuu tilillensä tai maksaa hotellin, kahvilan tai lentokentän kautta. Koska sivustosi sallii edelleen vanhan TLS-version tai heikon algoritmin, joku samassa verkossa pakottaa yhteyden alaspäin murrettavaan vaihtoehtoon ja lukee salasanansa ja korttinumeronsa reaaliajassa. Petos koituu asiakkaalle, mutta syytökset – ja tukipuhelu – koituvat sinulle.
• Korttimaksusi katkaistaan. Maksutietoturvamääräykset (PCI DSS) vaativat TLS 1.2:ta minimuminaan ja kieltävät eksplisiittisesti heikot algoritmit kuten RC4:n. Kun käsittelijäsi auditoi sinut tai kun haet korttien hyväksymistä, vanhentunut konfiguraatio epäonnistuu tarkistuksessa ja kassapisteesi on jäässä kunnes se on korjattu – täsmälleen väärällä hetkellä kassavirralle.
• Kauppa pysähtyy tietoturvatarkistuksessa. Ennen kuin suurempi asiakas allekirjoittaa, heidän IT-tiiminsä suorittaa rutiinitarkistuksen. Se merkitsee heti, että sivustosi hyväksyy edelleen rikkinäistä salausta – sellainen löydös, joka näyttää huolimattomalta ja saa ostajan miettimään, mitä muuta on löysällä. Sopimus istuu limbossa ongelman takia, joka ei maksa mitään korjata.
• Sääntelyviranomainen esittää kiusallisen kysymyksen. Minkä tahansa valituksen tai tietomurron jälkeen ensimmäinen asia, jonka tietosuojaviranomainen haluaa tietää, on suojelitko henkilötietoja “asianmukaisesti”. Julkisesti vuosia rikkinäisenä tunnetun salauksen käyttäminen on hyvin vaikea puolustaa, ja “emme tajunneet vanhan version olevan edelleen päällä” ei ole mukava vastata.
• Se piiloutuu lukon takana vuosia. Koska sivustosi näyttää silti normaalin lukon, kukaan ei huomaa aukkoa – kunnes yksi siepattu kirjautuminen tai korttinumero muuttuu julkiseksi tapaukseksi, joka on huomattavasti kalliimpi kuin viiden minuutin korjaus olisi ollut.

Mitä se oikeasti on

TLS-versio

Sivusto ei vain tue yhtä TLS-versiota – se voi tarjota useita kerralla ja antaa jokaisen kävijän selaimen valita. Nykyaikainen kävijä käyttää uusinta saatavilla olevaa versiota ja näkee normaalin lukon. Vaara on siinä, että vanhat, rikkinäiset versiot voivat istua siellä hyvien rinnalla auki olevana takaovenana: hyökkääjä voi pakottaa kävijän yhteyden “alentumaan” TLS 1.0:ksi tai 1.1:ksi ja sitten hyödyntää tunnettuja heikkouksia niissä versioissa (BEAST- ja POODLE-hyökkäykset ovat kuuluisia esimerkkejä) liikenteen purkamiseksi.

Joten tarkistuksemme muodostaa yhteyden sivustoosi ja testaa jokaisen version erikseen – TLS 1.0, 1.1, 1.2 ja 1.3 – nähdäkseen mitkä palvelimesi vielä hyväksyy. Tässä on, miltä “hyvä” näyttää ja kuinka se pisteytyy:

• TLS 1.3 (yhdessä tai ilman 1.2:ta) eikä vanhentuneita: paras tulos – nykyaikainen, siisti konfiguraatio. Täydet pisteet.
• Vain TLS 1.2, ei 1.3:ta: turvallinen ja läpäisee, mutta jätät uusimman, nopeimman version hyödyntämättä. Suurin osa pisteistä; 1.3:n käyttöönotto on tehtävä joskus.
• TLS 1.0 tai 1.1 yhä hyväksyttynä: automaattinen epäonnistuminen, pisteytetään nollaksi ja merkitään kriittiseksi – ei merkitystä, että 1.2/1.3 myös toimivat, koska rikkinäiset versiot ovat auki oleva ovi. Tämä on se, joka on korjattava.

Salausalgoritmi

Kun versio on valittu, TLS valitsee algoritmin – varsinaisen algoritmin, joka salaa datan. Useimmat nykyaikaiset algoritmit ovat vahvoja. Kourallinen on rikkinäisiä eikä niitä saa koskaan käyttää: RC4 (sen salaus on vinoutunut ja vuotaa selkotekstiä), DES (sen avain on niin lyhyt, että se voidaan väkivoimaisesti murtaa), 3DES (haavoittuvainen “Sweet32”-hyökkäykselle), sekä NULL (ei salausta lainkaan), EXPORT-luokan algoritmit (tarkoituksellisesti heikennetyt – FREAK- ja Logjam-hyökkäykset) ja anonyymit algoritmit (ei henkilöllisyystarkistusta, joten jäljittelijä voi istua välissä).

Algoritmitarkistuksemme tekee kaksi asiaa. Ensinnäkin se katsoo algoritmin, jonka palvelimesi neuvotteli meille. Sitten – ja tämä on tärkeä osa – se aktiivisesti yrittää kätellä useilla tunnettuja rikkinäisiä algoritmeja käyttäen (RC4, 3DES, EXPORT, NULL ja anonyymit muunnelmat). Palvelin voi valita vahvan algoritmin puhuessaan nykyaikaiselle asiakkaalle, mutta silti hyväksyä heikon, jos hyökkääjä vaatii – ja se on todellinen alentumisriski. Jos palvelimesi hyväksyy minkä tahansa kielletyn algoritmin, tarkistus merkitsee sen; kriittisen (kuten RC4 tai NULL) hyväksyminen on epäonnistuminen. (TLS 1.3:ssa ei ole mitään huolehdittavaa täällä – kyseinen versio poisti kaikki heikot algoritmit suunnittelulla, joten sondit ohitetaan.)

Kolme tiedoksi annettavaa lisäasiaa

Kolme siihen liittyvää kohtaa raportoidaan, mutta eivät vaikuta arvioosi – ne merkitään tiedoksi, koska niitä ei voi luotettavasti varmentaa ulkopuolelta, ja millä tahansa nykyaikaisella palvelimella tai CDN:llä ne ovat jo käsitelty oikein:

• TLS-pakkaus (CRIME-hyökkäys): vanha ominaisuus, joka jos se jätetään päälle, voisi antaa hyökkääjän tihutella istuntoevästeitä. Se on ollut oletuksena poistettuna jokaisesta nykyaikaisesta verkkopalvelimesta yli vuosikymmenen ajan, joten tämä on käytännössä nykyään ongelmatonta.
• OCSP-nidonta: suorituskyky- ja yksityisyyshienosäätö, jossa palvelimesi esihakee todisteen siitä, ettei sertifikaattiasi ole peruutettu, joten jokaisen kävijän ei tarvitse kysyä sertifikaattiviranomaiselta itse (mikä on hitaampaa ja vuotaa selailutietoja). CDN:t kuten Cloudflare tekevät tämän automaattisesti.
• Turvallinen uudelleenneuvottelu: korjaus vanhaan haavoittuvuuteen (CVE-2009-3555), joka antoi hyökkääjien lisätä dataa istuntoon. TLS 1.3 poisti uudelleenneuvottelun kokonaan, joten se on siellä ongelmatonta, ja nykyaikaiset TLS 1.2 -palvelimet toteuttavat korjauksen oletuksena.

Nostamme nämä esiin, jotta IT-henkilöllesi on täydellinen kuva, mutta suurimmalle osalle omistajista ei ole mitään tehtävää – pisteytystäsi ohjaa yllä olevat versio- ja algoritmitarkistukset.

Korjausohje (ilmainen, n. 30 minuuttia)

Anna tämä IT-henkilöllesi – korjaus on ilmainen. Tämä osio on sitä varten, joka hallinnoi verkkotunnustasi, verkkosivustoasi tai hostingiasi. Korjaus on konfigurointimuutos, ei osto; veloitamme vain salauksesi oikeana pysymisen seurannasta ajan myötä. Alla oleva yksittäinen nykyaikainen konfiguraatio korjaa sekä versio- että algoritmilöydökset kerralla.

Yksinkertaisin luotettava lähestymistapa on luoda tunnettu hyvä konfiguraatio sen sijaan, että kirjoitat sellaisen käsin: liitä palvelintyyppisi Mozillan SSL-konfiguraatiosgeneraattoriin osoitteessa https://ssl-config.mozilla.org/ ja valitse “Intermediate”-profiili (laaja yhteensopivuus) tai “Modern” (vain TLS 1.3, jos sinun ei tarvitse tukea mitään vanhaa). Se tuottaa oikeat ssl_protocols- ja ssl_ciphers-rivit sinulle.

Alustalla:

1. Cloudflare tai hallittu hosting – yleensä yksi tai kaksi klikkausta. Cloudflare: SSL/TLS → Reunasertifikaatit → Minimaalinen TLS-versio → TLS 1.2, ja siellä olevat algoritmit hallitaan puolestasi (alusta ei tarjoa kiellettyjä algoritmeja). Useimmat hallitut hostingit ja sivustonrakentajat (Squarespace, Wix, Shopify, nykyaikaiset WordPress-hostingit) pakottavat jo TLS 1.2+:n vahvoilla algoritmeilla – vahvista vain, ettei “legacy TLS”- tai “vanha-selain-yhteensopivuus”-vaihtoehtoa ole edelleen päällä.
2. Nginx. Aseta vain nykyaikaiset versiot ja eksplisiittinen vahva algoritmilista, sitten lataa uudelleen:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

   (TLS 1.3 vaatii OpenSSL 1.1.1+ palvelimella.)
3. Apache. Poista vanhat versiot käytöstä ja kiinnitä vahva algoritmilista, sitten käynnistä uudelleen:

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. Käytä ilmaista IIS Crypto -työkalua (tai vastaavia rekisteriasettuja) poistaaksesi TLS 1.0:n ja 1.1:n käytöstä, poistaksesi RC4/DES/3DES/NULL/EXPORT-algoritmit käytöstä ja jättääksesi TLS 1.2:n ja 1.3:n vahvoilla algoritmeilla käytössä. Työkalun “Best Practices” -malli tekee kaiken tämän yhdellä klikkauksella.
5. Tiedoksi annettavat lisäosat (valinnainen, ilmainen). Jos haluat täydellisen siisteyden: Nginxiin lisää ssl_stapling on; ssl_stapling_verify on; (sekä resolver-rivi) OCSP-nidontaan; Apachessa SSLUseStapling On. TLS-pakkaus ja turvallinen uudelleenneuvottelu ovat jo turvallisia oletuksena nykyaikaisissa palvelimissa – toimenpiteitä ei tarvita. Cloudflare hoitaa kaikki kolme automaattisesti.
6. Vahvista, sitten tarkista täällä uudelleen. Vahvista, että vain turvalliset versiot ja algoritmit ovat jäljellä – esimerkiksi nmap --script ssl-enum-ciphers -p 443 verkkotunnuksesi.fi tai testaa https://ssl-config.mozilla.org/:n linkitetyillä työkaluilla – sitten suorita tämä tarkistus uudelleen. Mahdollisuuksien mukaan ota TLS 1.3 käyttöön 1.2:n rinnalla: se on sekä nopeampi että turvallisempi.

Yleisimmät virheet

• “Meillä on lukko, joten olemme kunnossa.” Lukko vain todistaa turvallisen yhteyden olevan olemassa. Se ei sano mitään siitä, hyväksytäänkö vanha versio tai kielletty algoritmi taustalla – mikä on täsmälleen se aukko, jonka nämä tarkistukset löytävät.
• Version korjaaminen mutta ei algoritmeja (tai päinvastoin). TLS 1.0:n/1.1:n poistaminen käytöstä ei automaattisesti poista RC4:ää tai 3DES:ää, ja vahvojen algoritmien kiinnittäminen ei automaattisesti poista vanhoja versioita käytöstä. Aseta molemmat – yllä oleva generoitu konfiguraatio tekee niin.
• “Perintö”- tai “vanha-selain-yhteensopivuus”-vaihtoehtojen jättäminen päällä. Monilla hosteilla ja CDN:illä on vaihtoehto, joka hiljaa ottaa uudelleen käyttöön rikkinäiset versiot tai heikot algoritmit “yhteensopivuuden vuoksi”. Se ei lähes koskaan auta todellista kävijää ja aiheuttaa suoraan tämän löydöksen.
• Palvelimen lataamisen unohtaminen uudelleen. Konfigurointimuutokset eivät tule voimaan ennen kuin verkkopalvelin ladataan uudelleen – yllättävän yleinen syy “korjatun” sivuston epäonnistumiselle uudelleentarkistuksessa.
• Yhden palvelimen konfigurointi mutta ei kaikkien. Jos sinulla on kuormantasaaja, useita verkkopalvelimia tai erillisiä aliverkkotunnuksia (kauppa, blogi, sovellus), jokaisella TLS-päätepisteellä täytyy olla sama konfiguraatio – heikoin on se, johon hyökkääjä kohdistuu.

Muistettavaa

TLS versio ja algoritmi ovat kaksi salauksesi osaa, jotka todella liikuttavat arviotasi, ja molemmat johtuvat sellaisten vaihtoehtojen poistamisesta käytöstä, jotka ovat olleet julkisesti rikkinäisiä vuosia. Korjaus on ilmainen, se on yleensä yksi nykyaikainen konfigurointirivi palvelinta kohti, ja normaalille kävijälle se ei muuta mitään muuta kuin tekee heidän yhteytensä aidosti turvalliseksi. Siihen liittyvät kohteet – pakkaus, OCSP-nidonta, turvallinen uudelleenneuvottelu – ovat hyödyllisiä tietää, mutta eivät vaikuta pisteeseesi, ja millä tahansa nykyaikaisella kokoonpanolla ne on jo hoidettu sinulle.

UKK