Juhend TLS Standardite vastavus

Transpordikihi turvalisus (TLS) protokoll on peamine vahend Interneti kaudu võrguside kaitsmiseks. See artikkel on lühike juhend, mis aitab teil turvalist serverit praegusele vastavaks konfigureerida TLS standardid.

Sissejuhatus

. Transpordikihi turvalisus (TLS) Internetis võrguühenduse kaitsmise peamine vahend on protokoll. See (ja tema eelkäija, Turvaline pistikupesakiht või SSL) on aastakümneid kasutatud paljudes rakendustes, kuid eriti brauserites, kui nad külastavad HTTPS veebisaitidel. TLS töötab tavaliselt taustal vaikselt, kuid vastupidiselt sellele, mida võiks arvata, TLS ei ole must kast, mis lihtsalt töötab. Pigem turvalisus TLS pakub tuleneb erinevate krüptograafiliste algoritmide koostööst. Enamgi veel, TLS, nagu SSL enne seda, areneb pidevalt koos turvatööstusega - uue tehnoloogia ja ärinõuded peavad olema täidetud, samas tuleb leevendada uusimaid turvaohte. Algoritmid võivad aja jooksul vananeda või tavadest loobuda, kusjuures iga muudatus mõjutab a üldist turvalisust TLS näiteks (nagu see, mis praegu teie ühendust kaitseb).

See volatiilsus on motiveerinud erinevaid standardiorganisatsioone avaldama suuniseid, nii et minimaalne lähtepunkt aastaks XNUMX oleks TLS turvalisuse võiks kehtestada konkreetsel turul, sektoris või teenuses. Kahjuks on selliseid standardeid arvukalt, kusjuures erinevad sektorid nõuavad vastavust erinevatele kohaldatavatele dokumentidele, samas kui standardeid endid Ka muutuvad aja jooksul, võttes arvesse muutusi sektoris, mille kaitseks nad olid loodud.

Mõistetavalt on navigeerimine selles standardite meres, et luua moodne TLS eksemplar võib olla administraatoritele tõeline peavalu. See artikkel on lühike juhend, mis aitab teil konfigureerida turvalise serveri oodatud vastavusse TLS standardid aastal 2021. (Täiendava abi saamiseks oleme andnud ka näite kõige populaarsemate veebiserveri lahenduste konfiguratsioonidest lisa.)

Standardid

On mitu üksust, kes peavad juhiseid TLS võrgu turvalisuse osas, näiteks Ameerika Ühendriikide tervishoiu- ja inimteenistuste ministeerium (HHS) või Riiklik standardite ja tehnoloogia instituut (NIST). Lühiduse huvides uuritakse selles artiklis ainult kolme enim vastuvõetud dokumenti:

1. . Tervisekindlustuse ülekantavuse ja vastutuse seadus (HIPAA)
2. NIST-id SP 800-52r2 juhised
3. . Maksekaarditööstuse andmeturbe standard (PCI-DSS)

HIPAA

HIPAA on USA valitsuse poolt 1996. Aastal vastu võetud määrus, mis käsitleb inimkaubanduse turvalist käitlemist Kaitstud tervisealane teave (PHI). PHI viitab patsiendi digitaalsele teabele, näiteks testitulemustele või diagnoosidele. HIPAA juhenddokument 2013. aastal avaldatud on järgmine:

Liikuvate andmete kehtivad krüptimisprotsessid on need, mis vastavad vajaduse korral NIST-i eriväljaannete 800–52 juhistele transpordikihi turvalisuse valimiseks ja kasutamiseks (TLS) Rakendused; 800–77, IPseci VPN-ide juhend; või 800-113, SSL VPN-ide juhend või muud, mis on föderaalsed infotöötlusstandardid (FIPS) 140-2 kinnitatud.

NIST standardid

2005. aastal avaldas NIST spetsiaalse väljaande (SP) 800-52, milles kirjeldatakse õigeid tööprotseduure turvaliseks konfigureerimiseks a TLS näiteks valitsuse serverite jaoks. SP 800-52 on sellest ajast alates asendatud versioonidega SP 800-52r1 (2014) ja SP 80052r2 (2019). See artikkel järgib SP 800-52r2 juhiseid, mis on praegu stabiilsed.

PCI-DSS

PCI-DSS on maksekaarditööstuse (PCI) standardite turvanõukogu (SSC) poolt järgitav vastavusstandard, mis kehtestab, kuidas e-poe veebisaitidel makse- ja kaarditeavet käideldakse. Seadme õige konfiguratsiooni osas TLS PCI-DSS:

"Tugeva krüptograafia ja turvaliste protokollide kohta leiate teavet tööstuse standarditest ja parimatest tavadest (nt NIST SP 800-52 ja SP 800-57, OWASP jne)"

TLS standardid: nende kõigi kokku panemine

Nüüdseks tuleb märkida, et iga standard mõjutab erinevaid süsteeme, lähtudes nende funktsioonist ja nende käsutatavatest andmetest. Näiteks võib haigla e-posti server kuuluda HIPAA suuniste alla, kuna vahetatud sõnumid võivad sisaldada patsienditeavet, samas kui haigla CRM-süsteem võib kuuluda PCI-DSS-i alla, kuna see võib sisaldada krediitkaardi ja muid klientide andmeid. Kõigi kolme standardi järgimine eeldaks ühise kasutamist TLS kõigis dokumentides esinevad parameetrid.

Õnneks on ilmne, et kõik standardid järgivad NIST-i valimisel juhiseid TLS parameetrid. See tähendab, et selle kirjutamise hetkel peaks SP 800-52r2-ga ühilduvus muutma serveri vastavaks ka HIPAA ja PCI-DSS-iga. (Okei, see pole nii täpselt tõsi, aga järgmises osas saavad asjad selgemaks.)

seadistatav TLS parameetrid

Selle turvalisuse tase TLS pakub enim mõjutatud protokolli versioon (st 1.0, 1.1 jne) ja lubatud šifri sviidid. Šifreerijad on algoritmid, mis teostavad krüptimist ja dekrüptimist. Siiski a šifri komplekt on algoritmide kogum, mis sisaldab šifrit, võtmevahetuse algoritmi ja räsimisalgoritmi, mida kasutatakse koos turvalise loomiseks TLS ühendus. Enamik TLS kliendid ja serverid toetavad mitut alternatiivi, nii et ühise valimiseks peavad nad turvalise ühenduse loomisel pidama läbirääkimisi TLS versioon ja šifrikomplekt.

TLS protokolli versioon

Kohta TLS versiooni tugi, NIST SP 800-52r2 sedastab järgmist:

Serverid, mis toetavad ainult riiklikele rakendustele peab olema konfigureeritud kasutamiseks TLS 1.2 ja peaks olema konfigureeritud kasutamiseks TLS Ka 1.3. Need serverid ei peaks olema konfigureeritud kasutamiseks TLS 1.1 ja ei tohi kasutama TLS 1.0, SSL 3.0 või SSL 2.0.

...

Serverid, mis toetavad kodanikele või ettevõtetele suunatud rakendusi (st klient ei pruugi olla osa valitsuse IT-süsteemist) peab olema konfigureeritud läbirääkimisi pidama TLS 1.2 ja peaks olema konfigureeritud läbirääkimisi pidama TLS 1.3. Kasutamine TLS Versioone 1.1 ja 1.0 üldiselt ei soovitata, kuid neid versioone võidakse vajaduse korral konfigureerida, et võimaldada suhtlemist kodanike ja ettevõtetega ... Need serverid ei tohi lubage kasutada SSL 2.0 või SSL 3.0.

Ametid peab toetama TLS 1.3 1. jaanuariks 2024. Pärast seda kuupäeva serverid peab toetama TLS 1.3 ainult valitsusele mõeldud ja kodanikele või ettevõtetele suunatud rakenduste jaoks. Üldiselt serverid, mis toetavad TLS 1.3 peaks olema konfigureeritud kasutamiseks TLS 1.2 samuti. Kuid, TLS 1.2 võib olla keelatud serverites, mis toetavad TLS 1.3, kui on kindlaks tehtud, et TLS 1.2 ei ole koostalitlusvõime jaoks vajalik.

Kui TLS 1.0 on keelatud ja TLS 1.1 on valitsuse saitide jaoks aegunud, NIST-i juhised väidavad, et ühilduvuse tagamiseks kolmandate osapoolte teenustega on valitsuse kontrollitavad serverid võib rakendada TLS Vajaduse korral 1.0 ja 1.1. PCI-DSS 3.2.1 (praegune versioon) all ühilduvad serverid peab toetuse maha jätma eest TLS 1.0 ja „migreeruvad miinimumini TLS 1.1, eelistatavalt TLS 1.2. ” HIPAA võimaldab tehniliselt kasutada kõiki versioone TLS. Seega minimaalselt toetatud miinimum TLS versioon on 1.1; PCI-DSS ja NIST soovitavad siiski tungivalt kasutada turvalisemat TLS 1.2 (ja nagu eespool näha, soovitab NIST vastu võtta TLS 1.3 ja plaanib 2024. aastaks toetust nõuda).

Cipher Suites

TLS 1.2 ja varem

SP 800-52r2 määratleb mitmed aktsepteeritavad šifripaketid TLS 1.2 ja varasemad. Standard ei nõua ühegi konkreetse šifrikomplekti tuge, kuid pakub juhiseid tugevamate valimiseks:

1. Eelistage staatiliste võtmete asemel lühikesi võtmeid (st eelistage DHE DH-le ja ECDHE-le ECDH-le). Ajutised klahvid tagavad täiusliku saladuse.
2. Eelistage GCM- või CCM-režiime CBC-režiimi asemel. Autentitud krüptimisrežiimi kasutamine hoiab ära mitu rünnakut (lisateavet leiate jaotisest 3.3.2 [SP 800-52r2-st]). Pange tähele, et need pole versioonile enne versiooni saadaval TLS 1.2.
3. Eelistage CCM-i asemel CCM-i. Viimane sisaldab lühemat autentimismärgendit, mis tagab väiksema autentimistugevuse.

Lisaks, kuigi need on lubatud šifri sviiti, kui teie TLS server ei tegele paljude erinevate platvormide ja klientidega, seetõttu on soovitatav kasutada nende algoritmide ainult väikest alamhulka. Rohkemate šifrikomplektide lubamine võib teie serveri rünnaku pinda laiendada ainult siis, kui (või kui) avastatakse uus protokollihaavatavus.

TLS 1.3

TLS 1.3-l on palju lühem salakoodide loend:

• 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)

Järeldus

Loodame, et see lühike juhend aitab teil rohkem mõista TLSja abistab teid konfigureerimisel TLS oma serveris. Seoses meie arutatud standardite ja soovitustega sisaldab järgmine jaotis näite konfiguratsioonist, mida peaksite saama rakendada kõige populaarsematele veebiserveri lahendustele. Kui teil on küsimusi selle kohta, kuidas veebipõhist vastavust säilitada, võtke meiega meili teel ühendust Support@SSL.com või klõpsates selle ekraani allosas nuppu reaalajas vestlus.

Lisa: Näide TLS konfiguratsioonid

Kolmes tehnilises dokumendis toodud reegleid kokku kogudes peaks juurutama kaasaegse turvalise serveri TLS 1.2 ja / või TLS 1.3, koos lühikese, kuid mitmekesise valitud šifrite komplektide loendiga. Kiire viide on allpool toodud turu populaarseimate veebiserverite näidiskonfiguratsioonid. Need on Mozilla omadega loodud “vahepealsed” (üldotstarbelised) konfiguratsioonid SSL-i konfiguratsioonigeneraator:

... SSLProtokol kõik -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 SSLSessionPiletid väljas

...

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: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 = ("Protokoll" => "KÕIK, -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-GS SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 "ssl.honor-šifr

...

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 no-tlsv10 no-tlsv11 no-tls-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 no-tlsv10 no-tlsv11 no-tls-tickets

... Reeglid: - PolicyName: Mozilla-intermed-v5-0 PolicyType: SSLNegotiationPolicyType Atribuudid: - Nimi: Protocol-TLSv1.2 Väärtus: true - Nimi: Server-Defined-Cipher-Order Väärtus: false - Nimi: ECDHE-ECDSA-AES128-GCM-SHA256 Value: true - Nimi: ECDHE-RSA-AES128-GCM-SHA256 Väärtus: true - Nimi: ECDHE-ECDSA-AES256-GCM-SHA384 Väärtus: true - Nimi: ECDHE-RSA-AES256-GCM-SHA384 Väärtus: true - Nimi: DHE-RSA-AES128-GCM-SHA256 Väärtus: true - Nimi: DHE-RSA -AES256-GCM-SHA384 Väärtus: tõene