Opas TLS Standardien noudattaminen

Kuljetuskerroksen turvallisuus (TLS) -protokolla on ensisijainen tapa suojata verkkoviestintä Internetissä. Tämä artikkeli on lyhyt opas, jonka avulla voit määrittää suojatun palvelimen vastaamaan nykyistä TLS standardit.

esittely

- Kuljetuskerroksen turvallisuus (TLS) protokolla on ensisijainen tapa suojata verkkoviestintä Internetissä. Se (ja edeltäjänsä, Secure Sockets Layer tai SSL) on käytetty vuosikymmenien ajan monissa sovelluksissa, mutta erityisesti selaimissa, kun he vierailevat HTTPS sivustot. TLS toimii yleensä hiljaisesti taustalla, mutta toisin kuin voidaan ajatella, TLS ei ole musta laatikko, joka vain toimii. Pikemminkin turvallisuus TLS tarjoaa johtuu erilaisten salausalgoritmien yhteistyöstä. Lisäksi, TLS, kuten SSL ennen sitä, kehittyy jatkuvasti turvallisuusalan kanssa - uuden tekniikan ja liiketoiminnan vaatimukset on täytettävä, ja viimeisimpiä turvallisuusuhkia on lievennettävä. Algoritmit voivat vanhentua ajan myötä tai käytännöt voidaan hylätä, ja jokainen muutos vaikuttaa a: n yleiseen turvallisuuteen TLS esimerkki (kuten se, joka suojaa yhteyttäsi tällä hetkellä).

Tämä volatiliteetti on motivoinut useita standardointijärjestöjä julkaisemaan ohjeasiakirjoja siten, että vähimmäisperustaso vuodelle TLS tietoturva voitaisiin luoda tietyille markkinoille, toimialoille tai palveluille. Valitettavasti tällaisia ​​standardeja on useita, ja eri sektorit vaativat erilaisten sovellettavien asiakirjojen noudattamista, kun taas itse standardit Myös kehittyvät ajan myötä, ottaen huomioon muutokset alalla, jonka tarkoituksena on suojata.

Ymmärrettävästi selaaminen tällä standardienmerellä modernin perustamiseksi TLS esimerkki voi olla todellinen päänsärky järjestelmänvalvojille. Tämä artikkeli on lyhyt opas, jonka avulla voit määrittää suojatun palvelimen vastaamaan odotuksia TLS standardeja vuonna 2021. (Lisäapua varten olemme myös antaneet esimerkkikokoonpanoja suosituimmista verkkopalvelinratkaisuista liite.)

Standardit

On olemassa useita yksiköitä, jotka pitävät yllä suuntaviivoja TLS verkkoturvallisuuden osalta, kuten Yhdysvaltojen terveys- ja henkilöstöministeriö (HHS) tai National Institute of Standards and Technology (NIST). Lyhyyden vuoksi tässä artikkelissa tutkitaan vain kolmea eniten hyväksyttyä asiakirjaa:

1. - Sairausvakuutuksen siirrettävyys ja vastuuvelvollisuus (HIPAA)
2. NIST: n SP 800-52r2 -ohjeet
3. - Maksukorttiteollisuuden tietoturvastandardi (PCI-DSS)

HIPAA

HIPAA on Yhdysvaltojen hallituksen vuonna 1996 antama asetus, joka koskee ihmisten turvallista käsittelyä Suojattuja terveystietoja (PHI). PHI tarkoittaa mitä tahansa digitaalista potilastietoa, kuten testituloksia tai diagnooseja. HIPAA ohjeasiakirja julkaistiin vuonna 2013, todetaan seuraavaa:

Voimassa olevat liikkuvan datan salausprosessit ovat sellaisia, jotka soveltuvin osin noudattavat NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Toteutukset; 800-77, IPsec VPN -oppaat; tai 800-113, Opas SSL VPN -verkoihin tai muihin, jotka ovat Federal Information Processing Standards (FIPS) 140-2 -validoituja.

NIST-standardit

Vuonna 2005 NIST julkaisi erityisjulkaisun (SP) 800-52, jossa kuvaillaan oikeat toimintamenetelmät a TLS esimerkiksi valtion palvelimille. SP 800-52 on sittemmin korvattu versioilla SP 800-52r1 (2014) ja SP 80052r2 (2019). Tämä artikkeli noudattaa SP 800-52r2: n ohjeita, joka on tällä hetkellä vakaa.

PCI DSS

PCI-DSS on maksukorttiteollisuuden (PCI) Standards Security Council (SSC) ylläpitämä vaatimustenmukaisuusstandardi, joka määrittelee, miten maksu- ja korttitietoja käsitellään sähköisen kaupan verkkosivustoilla. Oikeiden konfiguraatioiden suhteen TLS tapauksissa, PCI-DSS toteaa:

"Katso alan standardeista ja parhaista käytännöistä tietoja vahvasta salauksesta ja suojatuista protokollista (esim. NIST SP 800-52 ja SP 800-57, OWASP jne.)"

TLS standardit: koota nämä kaikki yhteen

Tähän mennessä on huomattava, että jokainen standardi vaikuttaa eri järjestelmiin niiden toiminnan ja käsittelemien tietojen perusteella. Esimerkiksi sairaalan sähköpostipalvelin voi kuulua HIPAA-ohjeiden piiriin, koska vaihdetut viestit saattavat sisältää potilastietoja, kun taas sairaalan CRM-järjestelmä saattaa kuulua PCI-DSS-järjestelmään, koska se voi sisältää luottokortti- ja muita asiakastietoja. Kaikkien kolmen standardin noudattaminen edellyttäisi yhteisen käyttöä TLS kaikissa asiakirjoissa olevat parametrit.

Onneksi on ilmeistä, että kaikki standardit noudattavat NIST: n valintaa koskevia ohjeita TLS parametreja. Tämä tarkoittaa, että tämän kirjoittamisen hetkellä SP 800-52r2 -yhteensopivuuden tulisi tehdä palvelimesta myös HIPAA: n ja PCI-DSS: n mukainen. (Okei, tämä ei ole täsmälleen totta, mutta asiat selviävät seuraavassa osiossa.)

Määritettävät TLS parametrit

Turvallisuuden taso, joka TLS tarjoaa vaikuttaa eniten protokollaversio (eli 1.0, 1.1 jne.) ja sallitut salaussviitit. Salakirjoittajat ovat algoritmeja, jotka suorittavat salausta ja salauksen purkamista. Kuitenkin a salausohjelma on joukko algoritmeja, mukaan lukien salaus, avaintenvaihtoalgoritmi ja hajautusalgoritmi, joita käytetään yhdessä luomaan turvallinen TLS yhteys. Useimmat TLS asiakkaat ja palvelimet tukevat useita vaihtoehtoja, joten heidän on neuvoteltava turvallisen yhteyden luomisessa yhteisen valitsemiseksi TLS versio ja salausohjelma.

TLS protokollaversio

Mitä TLS version tuki, NIST SP 800-52r2 julkaisee seuraavan:

Palvelimet, jotka tukevat vain valtionhallinnon sovelluksia on määritettävä käytettäväksi TLS 1.2 ja shouldnt määritettävä käytettäväksi TLS Myös 1.3. Nämä palvelimet ei pitäisi määritettävä käytettäväksi TLS 1.1 ja ei saa käyttää TLS 1.0, SSL 3.0 tai SSL 2.0.

...

Palvelimet, jotka tukevat kansalaisia ​​tai yrityksiä koskevia sovelluksia (ts. Asiakas ei välttämättä ole osa valtion IT-järjestelmää) on olla konfiguroitu neuvottelemaan TLS 1.2 ja shouldnt olla konfiguroitu neuvottelemaan TLS 1.3. Käyttö TLS versioita 1.1 ja 1.0 ei yleensä suositella, mutta nämä versiot voidaan määrittää tarvittaessa kansalaisten ja yritysten kanssa tapahtuvan vuorovaikutuksen mahdollistamiseksi. ei saa sallia SSL 2.0: n tai SSL 3.0: n käyttö.

Yritykset on tuki TLS 1.3 1. tammikuuta 2024. Tämän päivämäärän jälkeen palvelimet on tuki TLS 1.3 sekä hallituksille että kansalaisille tai yrityksille suunnattuihin sovelluksiin. Yleensä palvelimet, jotka tukevat TLS 1.3 shouldnt määritettävä käytettäväksi TLS Myös 1.2. Kuitenkin, TLS 1.2 voidaan poistaa käytöstä palvelimilla, jotka tukevat TLS 1.3 jos se on todettu TLS 1.2 ei tarvita yhteentoimivuutta.

Vaikka TLS 1.0 on kielletty ja TLS 1.1 on vanhentunut julkishallinnon sivustoille. NIST-ohjeissa todetaan, että yhteensopivuuden suhteen kolmansien osapuolien palveluiden kanssa on valtion hallitsemia palvelimia saattaa toteuttaa TLS 1.0 ja 1.1 tarvittaessa. Kohdassa PCI-DSS 3.2.1 (nykyinen versio) yhteensopivat palvelimet täytyy pudottaa tuki varten TLS 1.0 ja “siirtyä vähintään TLS 1.1, mieluiten TLS 1.2. ” HIPAA sallii teknisesti kaikkien versioiden käytön TLS. Täten yleisesti tuettu vähimmäismäärä TLS versio on 1.1; PCI-DSS ja NIST suosittelevat kuitenkin vahvemmin turvallisemman käytön TLS 1.2 (ja kuten edellä nähdään, NIST suosittelee TLS Ja aikoo vaatia tukea vuoteen 1.3 mennessä).

Cipher Suites

TLS 1.2 ja aikaisemmin

SP 800-52r2 määrittelee useita hyväksyttäviä salauspaketteja TLS 1.2 ja vanhemmat. Standardi ei vaadi minkään tietyn salauspaketin tukea, mutta tarjoaa ohjeita vahvempien valitsemiseen:

1. Mieluummin lyhytaikaiset avaimet staattisten avainten sijaan (ts. Mieluummin DHE kuin DH, ja mieluummin ECDHE kuin ECDH). Väliaikaiset avaimet tarjoavat täydellisen salaisuuden eteenpäin.
2. Mieluummin GCM- tai CCM-tilat CBC-tilan sijaan. Todennetun salaustilan käyttö estää useita hyökkäyksiä (katso lisätietoja kohdasta [SP 3.3.2-800r52: n kohta 2). Huomaa, että nämä eivät ole saatavana versioita ennen TLS 1.2.
3. Mieluummin CCM kuin CCM_8. Jälkimmäinen sisältää lyhyemmän todennustunnisteen, mikä antaa pienemmän todennuksen vahvuuden.

Lisäksi vaikka nämä ovat sallittua salaussviitti, jos TLS Palvelin ei käsittele suurta määrää erilaisia ​​alustoja ja asiakkaita, on suositeltavaa käyttää vain pientä osaa näistä algoritmeista. Useampien salausohjelmien salliminen voi laajentaa hyökkäyspinnan palvelimellesi vain, jos (tai kun) uusi protokollaheikkous havaitaan.

TLS 1.3

TLS 1.3: lla on paljon lyhyempi luettelo salauspaketeista:

• TLS_AES_128_GCM_SHA256 (0x13, 0x01)
• TLS_AES_256_GCM_SHA384 (0x13, 0x02)
• TLS_AES_128_CCM_SHA256 (0x13, 0x04)
• TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)

Yhteenveto

Toivomme, että tämä lyhyt opas auttaa sinua ymmärtämään paremmin TLS, ja auttaa sinua konfiguroinnissa TLS omalla palvelimellasi. Seuraavassa osassa on keskustelun kohteena olevien standardien ja suositusten osalta esimerkki kokoonpanosta, jota sinun pitäisi pystyä soveltamaan suosituimpiin verkkopalvelinratkaisuihin. Jos sinulla on kysyttävää online-vaatimusten noudattamisen ylläpitämisestä, ota rohkeasti yhteyttä sähköpostitse Support@SSL.com tai napsauttamalla live-chat-painiketta tämän ruudun alaosassa.

Liite: Esimerkki TLS kokoonpanot

Keräämällä kolmen eritelmän sisältämät säännöt nykyaikaisen suojatun palvelimen tulisi toteuttaa TLS 1.2 ja / tai TLS 1.3, jossa on lyhyt mutta monipuolinen luettelo valituista salauspaketeista. Pikaohjeena alla on esimerkkejä markkinoiden suosituimpien verkkopalvelimien kokoonpanoista. Nämä ovat Mozillan luomia "väli" (yleiskäyttöisiä) kokoonpanoja SSL -määritysgeneraattori:

... 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-GCMSA-SHA384 POLY20: ECDHE-RSA-CHACHA1305-POLY20: DHE-RSA-AES1305-GCM-SHA128: DHE-RSA-AES256-GCM-SHA256 SSLHonorCipherOrder off SSLSessionTickets off

... ssl_protokollat 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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

... ssl.openssl.ssl-conf-cmd = ("Protokolla" => "KAIKKI, -SSLv2, -SSLv3, -TLSv1, -TLSv1.1 ") ssl.cipher-list =" ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AC256- SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 "ssl.honor-salakirjoitin

...

ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options prefer-client-ciphers no-sslv3 ei-tlsv10 eitlsv11 eitls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-server-options no-sslv3 ei-tlsv10 eitlsv11 eitls-liput

... Politiikat: - PolicyName: Mozilla-intermed-v5-0 PolicyType: SSLNegotiationPolicyType-attribuutit: - Nimi: Protokolla-TLSv1.2 Arvo: true - Nimi: Server-Defined-Cipher-Order Arvo: false - Nimi: ECDHE-ECDSA-AES128-GCM-SHA256 Arvo: true - Nimi: ECDHE-RSA-AES128-GCM-SHA256 Arvo: true - Nimi: ECDHE-ECDSA-AES256-GCM-SHA384 Arvo: true - Nimi: ECDHE-RSA-AES256-GCM-SHA384 Arvo: true - Nimi: DHE-RSA-AES128-GCM-SHA256 Arvo: true - Nimi: DHE-RSA -AES256-GCM-SHA384 Arvo: tosi