SSL /TLS Parimad tavad 2023. aastaks

2023. aastal oma veebisaidi turvamine SSL-iga /TLS sertifikaat pole enam valikuline, isegi nende ettevõtete jaoks, kes ei tegele veebis otseselt tundliku klienditeabega. Otsingumootorid, nagu Google, kasutavad saidi turvalisust SEO järjestussignaalina ja populaarsed veebibrauserid, nagu Chrome, hoiatavad kasutajaid veebisaitide eest, mis ei kasuta HTTPS-i:

Võimalus seadistada oma veebiserverid ja rakendused SSL-i /TLS õigesti võib tunduda hirmuäratav, kuna teha on palju salapäraseid konfiguratsiooni ja kujunduse valikuid. See juhend annab kiire ülevaate peamistest punktidest, mida SSL /TLS oma veebisaidi jaoks, keskendudes samal ajal nii turvalisusele kui ka jõudlusele. Ainult põhitõdedega on veel palju katta, nii et oleme selle jaotanud mitmeks sammuks.

Valige usaldusväärne sertifitseerimisasutus (CA)

Teie sertifikaadid on ainult sama usaldusväärsed kui neid väljastav CA. Kõigile avalikult usaldusväärsetele CA-dele tehakse ranged kolmandate osapoolte auditid, et säilitada oma positsioon suuremates operatsioonisüsteemi ja brauseri juursertifikaatide programmides, kuid mõned suudavad seda staatust paremini hoida kui teised. Otsige CA-d, mis (nagu SSL.com):

• Kas suurem osa oma ärist on avalikult usaldusväärne PKI. Neil ettevõtetel on kõige rohkem kaotada, kui ilmnevad halvad turbepraktikad, ja kõik, mis saadakse, kui ollakse kursis arenevate tööstusharu standarditega.
• Reageerib tõhusalt ja tõhusalt kasutaja turvalisust ja privaatsust mõjutavatele haavatavuse avastustele, näiteks kogu tööstuses seerianumbri entroopia 2019. aasta alguse väljaanne. Otsitakse näiteks tööstusharu foorumitest mozilla.dev.security.policy võib anda teile hea idee selle kohta, kuidas konkreetne CA reageerib ebaõnnele.
• Pakub kasulikke tooteid ja teenuseid, näiteks laiendatud valideerimise (EV) sertifikaadid, hulgi- / automatiseeritud sertifikaatide väljastamine intuitiivse kaudu API või ACME protokoll, lihtsad sertifikaatide olelusringi haldamise ja jälgimise teenused ning toetama integreerimiseks kolmanda osapoole lahenduste ulatusliku loendiga.
• Tal on hea klienditeeninduse ja tehnilise toe maine. Ettevõtte veebisaidi 100% -lise turvalisuse tagamine on oluline ja kui peaksite valesti minema, peate suutma telefonile tõelise eksperdi hankida.

Sertifikaadiasutuse autoriseerimine (CAA)

Sertifikaadiasutuse autoriseerimine (CAA) on standard veebisaitide kaitsmiseks, määrates konkreetsed CA-d, kellel on lubatud domeeninime jaoks sertifikaate välja anda. Kui olete valinud CA, peaksite seda kaaluma CAA kirjete konfigureerimine selle volitamiseks.

Genereerige ja turvaline oma isiklikud võtmed

. SSL /TLS protokoll kasutab a paar võtit Interneti kaudu saadetud identiteetide autentimiseks ja krüptimiseks. Üks neist ( avalik võti) on ette nähtud laialdaseks levitamiseks ja teine ​​( isiklik võti) tuleks hoida võimalikult kindlalt. Need võtmed luuakse koos, kui genereerite sertifikaadi allkirjastamistaotlus (CSR). Siin on mõned näpunäited, mida tuleks oma privaatvõtmete osas meeles pidada:

• Kasutage tugevaid privaatvõtmeid: Suuremaid klahve on raskem lõhendada, kuid need vajavad suuremat arvutustehnikat. Praegu on soovitatav kasutada vähemalt 2048-bitist RSA-võtit või 256-bitist ECDSA-võtit ning enamikul veebisaitidel on võimalik saavutada hea turvalisus, optimeerides samal ajal nende väärtustega jõudlust ja kasutajakogemust.
  
  Märge: Nendest kahest algoritmist ülevaate saamiseks vaadake palun SSL.com artiklit, ECDSA ja RSA võrdlus.
• Kaitske oma privaatvõtmeid:
  • Looge oma privaatvõtmed turvalises ja usaldusväärses keskkonnas (eelistatavalt serveris, kus need juurutatakse, või FIPS või Common Criteria ühilduvale seadmele). Mitte kunagi lubage CA-l (või kellelgi teisel) teie nimel privaatvõtmeid genereerida. Hea mainega avalik CA, näiteks SSL.com, ei paku kunagi teie privaatvõtmete genereerimist ega käsitsemist, välja arvatud juhul, kui need on loodud turvalises riistvara märgis või HSM-is ja neid ei saa eksportida.
  • Andke juurdepääs privaatvõtmetele ainult vastavalt vajadusele. Looge uued võtmed ja tühistada kõik vanade võtmete sertifikaadid, kui privaatvõtmega juurdepääsuga töötajad lahkuvad ettevõttest.
  • Uuendage sertifikaate nii tihti kui võimalik (hea oleks vähemalt kord aastas), eelistatavalt kasutades iga kord värskelt loodud privaatvõtit. Automaatika tööriistad nagu ACME protokoll on abiks sagedase sertifikaatide uuendamise ajastamisel.
  • Kui privaatvõtit on rikutud (või võidi ohustada), tühistada kõik selle võtme sertifikaadid, genereerige uus võtmepaar ja väljastage uue võtmepaari jaoks uus sertifikaat.

Seadistage oma server

Pinnale, SSL-i installimine /TLS sertifikaat võib tunduda sirgjoonelise toiminguna; siiski on veel palju seadistamisotsuseid, mis tuleb vastu võtta, et tagada veebiserveri kiire ja turvaline toimimine ning lõppkasutajate sujuv kogemus, milles pole brauseri vigu ja hoiatusi. Siin on mõned konfiguratsiooninäpunäited, mis aitavad teil SSL /TLS teie serverites:

• Veenduge, et kõik hostinimed oleksid kaetud: Kas teie sertifikaat hõlmab teie saidi domeeninime nii koos kui ka ilma www eesliide? on seal Õppeaine alternatiivne nimi (SAN) iga domeeninime jaoks on sertifikaat kaitsta mõeldud?
• Installige täielikud sertifikaatide ketid: Lõpp-üksuse SSL /TLS sertifikaadid allkirjastatakse tavaliselt vahesertifikaatide, mitte CA juurvõtme abil. Veenduge, et kõik vahesertifikaadid on teie veebiserverisse installitud, et brauserid saaksid täieliku sertifitseerimise tee ning vältige lõppkasutajate usaldushoiatusi ja vigu. Teie CA suudab pakkuda teile vajalikke vaheaineid; SSL.com kliendid saavad meie kasutada Vahesertifikaadi allalaadimine paljude serveriplatvormide vahepakettide hankimiseks.
• Kasuta praegust SSL-i /TLS Protokollid (TLS 1.2 või 1.3): 2018. aasta lõpus teatasid kõik suuremad brauserimüüjad kahanemisest TLS 1.0 ja 1.1 2020. aasta esimeseks pooleks. Google vananenud TLS v1.0 ja v1.1 Chrome 72-s (välja antud 30. jaanuaril 2919). Chrome'i versioonid 84 (välja antud 14. juulil 2020) ja uuemad sisaldavad nende protokollide jaoks vahehoiatust ja tugi oli plaanitud täielikult eemaldatud mais 2021. Varasema SSL /TLS versioonid, näiteks SSL v3, on ammu kadunud. Kuigi TLS 1.2 on praegu kõige sagedamini kasutatav SSL /TLS protokoll, TLS 1.3 (uusim versioon) on juba toetatud enamiku suuremate veebibrauserite praegustes versioonides.
• Kasutage turvaliste Cipher Suite'i lühiloendit: Valige ainult need šifrikomplektid, mis pakuvad vähemalt 128-bitist krüptimist või võimalusel tugevamat. Ka riiklik standardite ja tehnoloogia instituut (NIST) soovitab seda kõike TLS juurutused eemalduvad DES-šifrit (või selle variante) sisaldavatest šifripakettidest AES-i kasutavatele. Lõpuks vähendab potentsiaalselt aktsepteeritavate šifrikomplektide ainult väike alamhulk minimeerimata veel avastamata haavatavuste rünnakupinda. SSL.com-de lisa Juhend TLS Standardite vastavus pakub näiteid kõige populaarsemate veebiserveriplatvormide konfiguratsioonidest, kasutades TLS 1.2.
  
  Märge: Ebaturvaliste, aegunud šifrite (näiteks RC4) kasutamine võib põhjustada brauseri turvavigu, näiteks ERR_SSL_VERSION_OR_CIPHER_MISMATCH Google Chrome'is.
• Kasuta edasisaladust (FS): Tuntud ka kui täiuslik ettetellimisaladus (PFS), FS kinnitab, et ohustatud privaatvõti ei kahjusta ka minevikuistmeid. FS-i lubamine:
  • Seadistamine TLS 1.2 kasutama elliptilise kõvera Diffie-Hellmani (EDCHE) võtmevahetuse algoritmi (kui DHE on varu) ja vältige võimaluse korral RSA võtmete täielikku vahetamist.
  • Kasutama TLS 1.3. TLS 1.3 tagab kõigile saladuse hoidmise TLS seansid Efemaatiline Diffie-Hellman (EDH või DHE) võtmevahetuse protokoll.
• Võimaldama TLS Sessiooni jätkamine: Sarnaselt säilitustüüpide kasutamisele püsivate TCP-ühenduste säilitamiseks, TLS seansi jätkamine võimaldab teie veebiserveril jälgida hiljuti kokku lepitud SSL /TLS seansse ja jätkake neid, minnes mööda seansi võtme läbirääkimiste arvutuslikust üldkulust.
• Mõelge OCSP klammerdamisest: OCSP klammerdamine võimaldab veebiserveritel edastada vahemällu salvestatud tühistamisteavet otse kliendile, see tähendab, et brauser ei pea OCSP-serveriga ühendust võtma, et kontrollida, kas veebisaidi sertifikaat on tühistatud. Selle taotluse kõrvaldades pakub OCSP klammerdamine tõelist jõudlust. Lisateabe saamiseks lugege meie artiklit, Lehe koormuse optimeerimine: OCSP klammerdamine.

Kasutage veebirakenduste kujundamise parimaid tavasid

Veebirakenduste kujundamine turvalisust silmas pidades on sama oluline kui serveri õige seadistamine. Need on kõige olulisemad punktid tagamaks, et teie kasutajad ei puutuks kokku mees keset rünnakud ja teie rakendus saab SEO-eeliseid, mis kaasnevad heade turvatavadega:

• Kõrvaldage segatud sisu: JavaScripti failid, pildid ja CSS-failid peaksid kõik pääseda juurde SSL-iga /TLS. Nagu on välja toodud SSL.com artiklis, HTTPS Kõikjal, serveerimine segatud sisu pole enam aktsepteeritav viis veebisaidi toimivuse suurendamiseks ning võib põhjustada brauseri turvahoiatusi ja SEO probleeme.
• Kasutage turvalisi küpsiseid: Seadistamine Secure küpsistes sisalduv märge tagab edastamise turvaliste kanalite kaudu (nt HTTPS). Samuti saate hoida kliendipõhise JavaScripti küpsistele juurdepääsu kaudu HttpOnly ja piirata küpsiste saitidevahelist kasutamist SameSite lipp
• Hinnake kolmanda osapoole koodi: Veenduge, et mõistaksite kolmandate osapoolte teekide oma veebisaidil kasutamise võimalikke riske, näiteks võimalust tahtmatult sisse viia haavatavusi või pahatahtlikku koodi. Looge oma võimaluste piires alati kolmanda osapoole usaldusväärsus ja linkige HTTPS-i abil kõigi kolmandate osapoolte koodidega. Lõpuks veenduge, et teie kasu veebisaidi mis tahes kolmanda osapoole elementidest on riski väärt.

Kontrollige oma tööd diagnostiliste tööriistadega

Pärast SSL-i seadistamist /TLS serveris ja veebisaidil või konfiguratsioonis muudatusi tehes on oluline veenduda, et kõik on õigesti seadistatud ja teie süsteem on turvaline. Teie saidi SSL-i kontrollimiseks on saadaval arvukad diagnostikavahendidTLS. Näiteks SSL Shopperi oma SSL-i kontrollija annab teile teada, kas teie sertifikaat on õigesti installitud, millal see aegub, ja kuvab sertifikaadi usalduse ahel.

Saadaval on ka muid võrgutööriistu ja -rakendusi, mis indekseerivad teie saiti turvaprobleemide (nt segatud sisu) kontrollimiseks. Samuti saate veebisirvija abil kontrollida segasisu olemasolu, kasutades selle sisseehitatud arendaja tööriistu:

Ükskõik, milliseid tööriistu valite, on oluline ka SSL /TLS paigaldamine ja seadistamine. Teie CA võib teid selles osas ka aidata; Näiteks pakub meie klientidele mugavuse huvides SSL.com automatiseeritud teateid eelseisva sertifikaadi aegumise kohta.

Rakendage HTTP range transpordi turvalisus (HSTS)

HTTP range transpordi turvalisus (HSTS) on turvapoliitika mehhanism, mis aitab kaitsta veebisaite protokolli alandamise rünnakute ja küpsiste kaaperdamise eest. See võimaldab veebiserveritel deklareerida, et veebibrauserid (või muud nõuetele vastavad kasutajaagendid) peaksid sellega suhtlema ainult turvalisi HTTPS-ühendusi kasutades ja mitte kunagi ebaturvalise HTTP-protokolli kaudu. Server edastab selle reegli kasutajaagendile HTTP-vastuse päisevälja kaudu nimega "Strict-Transport-Security".

Rakendada HTTP range transpordi turvalisus (HSTS), peate oma veebiserveri konfiguratsioonile lisama spetsiaalse vastuse päise.

Siin on üksikasjalik juhend:

1. Veenduge, et teie sait toetaks HTTPS-i: enne HSTS-i lubamist peab teie saidil olema kehtiv SSL-sertifikaat ja suutma edastada sisu HTTPS-i kaudu. Kui teie sait pole veel HTTPS-i jaoks konfigureeritud, peate seda tegema hankige SSL-sertifikaat ja konfigureerige oma server seda kasutama.

Päis on alati määratud Strict-Transport-Security "max-age=31536000; includeSubDomains"

_{See rida annab brauserile käsu kasutada järgmisel aastal (31,536,000 XNUMX XNUMX sekundit) teie saidil alati HTTPS-i, sealhulgas kõiki alamdomeene.}

2. Testige oma konfiguratsiooni: pärast HSTS-i päise lisamist peaksite oma saiti testima, et veenduda, et see töötab õigesti. Seda saate teha, külastades oma saiti ja kasutades oma brauseri arendaja tööriistu, et kontrollida vastuste päiseid. Peaksite nägema päist Strict-Transport-Security teie määratud väärtusega.
3. Kaaluge oma saidi lisamist HSTS-i eellaadimisloendisse: HSTS-i eellaadimise loend on saitide loend, mis on brauseritesse kodeeritud HSTS-i toega. See tagab täiendava kaitsetaseme, kuna see tagab, et esimene ühendus teie saidiga on turvaline isegi enne HSTS-i päise vastuvõtmist. Saate esitada oma saidi HSTS-i eellaadimisloendisse aadressil hstspreload.org.

Kasuta Case'it: uudisteveebisait soovib tagada, et selle kasutajad loovad sellega alati turvalise ühenduse, isegi kui nad kogemata sisestavad URL-i "https" asemel "http". Veebisait kasutab HSTS-i, lisades oma serveri konfiguratsioonile päise Strict-Transport-Security, määrates pika maksimaalse vanuse ja kaasates kõik alamdomeenid. See käsib kasutajaagentidel alati sellega ühenduse luua HTTPS-i abil, kaitstes kasutajaid rünnakute eest, mis üritavad ühendust HTTP-le alandada ja nende küpsiseid varastada. Veebisait esitab end täiendava kaitse tagamiseks ka HSTS-i eellaadimisloendile.

Kasutama TLS Varu-SCSV protokolli alandamise rünnakute vältimiseks

TLS Varu-SCSV (Signaling Cipher Suite Value) on mehhanism, mis võeti kasutusele protokolli alandamise rünnakute vältimiseks. Need rünnakud toimuvad siis, kui ründaja sekkub ühenduse seadistamise protsessi ja meelitab klienti ja serverit kasutama vähem turvalist protokolli versiooni, kui nad mõlemad tegelikult toetavad.

Siin on, kuidas saate seda rakendada TLS Varu-SCSV:

1. Värskendage oma serveri SSL-i/TLS Raamatukogu: esimene samm on tagada, et teie serveri SSL/TLS raamatukogu toetab TLS Varu-SCSV. Seda funktsiooni tutvustati versioonides OpenSSL 1.0.1j, 1.0.0o ja 0.9.8zc. Kui kasutate teist SSL-i/TLS raamatukogu, kontrollige selle dokumentatsiooni või võtke ühendust selle arendajatega.
2. Seadistage oma server: kui teie serveri SSL/TLS raamatukogu toetab TLS Varu-SCSV, peate võib-olla oma serveri selle kasutamiseks konfigureerima. Täpsed sammud sõltuvad teie serveritarkvarast. Näiteks Apache'is peate võib-olla lisama või muutma oma konfiguratsioonifaili rea järgmiselt:

SSLprotokoll Kõik -SSLv2 -SSLv3

See rida käsib serveril kasutada kõiki protokolliversioone, välja arvatud SSLv2 ja SSLv3. Kui klient ja server mõlemad toetavad TLS 1.2, kuid klient proovib seda kasutada TLS 1.1 (võib-olla ründaja sekkumise tõttu) tuvastab server selle varukatsena ja lükkab ühenduse tagasi.

3. Testige oma serverit: pärast serveri konfigureerimist peaksite seda testima, et veenduda selle korrektses rakendamises TLS Varu-SCSV. On mitmeid veebitööriistu, mis võivad teid selles aidata, näiteks SSL Labs Server Test.

Kasuta Case'it: Ülemaailmne korporatsioon kasutab TLS Varu-SCSV oma sisekommunikatsiooni kaitsmiseks. See tagab, et kui ründaja üritab sundida protokolli alandada, tunneb server selle ära ja lükkab ühenduse tagasi, kaitstes ettevõtte tundlikke andmeid. Ettevõtte IT-meeskond uuendab regulaarselt oma serverite SSL/TLS teegid ja konfiguratsioonid tagamaks, et nad kasutavad uusimaid turvafunktsioone, ning kasutavad veebitööriistu oma serverite testimiseks ja nende õige rakendamise kinnitamiseks. TLS Varu-SCSV.

Vältige erineva sisuga probleeme

Segasisu on turvarisk, mis tekib siis, kui turvalise HTTPS-ühenduse kaudu laaditud veebileht sisaldab ressursse, nagu pildid, videod, laaditabelid või skriptid, mis laaditakse üle ebaturvalise HTTP-ühenduse. Brauserid võivad selle segasisu blokeerida või kuvada kasutajale hoiatuse, mis võib kahjustada kasutaja ettekujutust saidi turvalisusest.

Sega sisuga probleeme saate vältida järgmiselt.

1. Kasutage kõigi ressursside jaoks HTTPS-i: Kõige lihtsam viis segasisu vältimiseks on tagada, et kõik saidi ressursid laaditakse HTTPS-i kaudu. See hõlmab pilte, skripte, laaditabeleid, iframe'e, AJAX-i päringuid ja muid ressursse, mida teie sait kasutab.
2. Värskendage oma saidi koodi: kui teie saidi kood sisaldab ressursside jaoks kõvakodeeritud HTTP-URL-e, peate need HTTPS-i kasutamiseks värskendama. Kui ressurssi majutatakse serveris, mis ei toeta HTTPS-i, peate võib-olla majutama ressurssi oma serveris või leidma alternatiivse ressursi, mida saab laadida HTTPS-i kaudu.
3. Seadistage oma server sisu-turvapoliitika päist saatma: Content-Security-Policy (CSP) HTTP-päis võimaldab teil juhtida, milliseid ressursse teie saidil on lubatud laadida. Kui määrate CSP päise, mis lubab ainult HTTPS-i ressursse, saate tagada, et teie sait ei sisalda kogemata segasisu.

Kasuta Case'it: Interneti-ajakiri tagab, et kogu sisu, sealhulgas pildid ja skriptid, laaditakse HTTPS-i kaudu. See takistab ründajatel neid ressursse rikkumast ja potentsiaalselt pahatahtlikku sisu süstimast. Ajakirja veebiarendajad vaatavad saidi koodi regulaarselt üle, et kõik ressursid oleksid laaditud HTTPS-i kaudu, ja konfigureerivad oma serveri nii, et see saadaks range sisu-turvapoliitika päise. Nad kasutavad ka veebitööriistu, et otsida oma saiti segasisuga probleemide suhtes ja parandada leitud probleeme.

Kasutage mitme saidi hostimiseks serveri nime indikatsiooni (SNI).

Serveri nime tähis (SNI) on laiendus TLS protokoll, mis võimaldab serveril esitada mitu sertifikaati samal IP-aadressil ja pordinumbril. See on eriti kasulik veebimajutusteenuste pakkujatele, kes peavad samas serveris majutama mitut turvalist veebisaiti, millest igaühel on oma SSL-sertifikaat.

SNI-d saate kasutada järgmiselt.

1. Veenduge, et teie serveritarkvara toetab SNI-d: Esimene samm on tagada, et teie serveritarkvara toetab SNI-d. Enamik kaasaegseid veebiservereid, sealhulgas Apache, Nginx ja IIS, toetavad SNI-d.
2. Seadistage oma server: Järgmine samm on serveri konfigureerimine SNI-d kasutama. Tavaliselt hõlmab see eraldi konfiguratsiooniploki lisamist iga saidi jaoks, mida soovite serveris hostida, ja selle täpsustamist SSL-sertifikaat kasutada iga saidi jaoks. Täpsed sammud sõltuvad teie serveritarkvarast.
3. Testige oma konfiguratsiooni: Pärast serveri konfigureerimist peaksite seda testima, et veenduda, et see kasutab SNI-d õigesti. Seda saate teha, külastades iga saiti, mida serveris majutate, ja kontrollides, kas kasutatakse õiget SSL-sertifikaati.

Kasuta Case'it: hostingu pakkuja kasutab SNI-d mitme veebisaidi teenindamiseks samalt IP-aadressilt. See võimaldab neil tõhusalt kasutada oma IP-aadressi ruumi ja lihtsustada võrgukonfiguratsiooni. Nad konfigureerivad oma serveri kasutama iga saidi jaoks erinevat SSL-sertifikaati ja testivad regulaarselt oma konfiguratsiooni, et tagada iga saidi jaoks õige sertifikaadi kasutamine. See tagab, et igal saidil on turvaline ja usaldusväärne ühendus, kuigi neid kõiki teenindatakse samalt IP-aadressilt.

Optimeerige jõudlust seansi jätkamisega

Seansi jätkamine on funktsiooni funktsioon TLS Protokoll, mis võimaldab kliendil ja serveril kasutada samu krüpteerimisvõtmeid mitme seansi jooksul, vähendades iga kord uue turvalise ühenduse loomise kulusid. See võib oluliselt parandada jõudlust, eriti rakenduste puhul, kus klient sageli katkestab ja taasühendab.

 Seansi jätkamist saate kasutada järgmiselt.

1. Veenduge, et teie serveritarkvara toetaks seansi jätkamist: Esimene samm on tagada, et teie serveritarkvara toetab seansi jätkamist. Enamik kaasaegseid veebiservereid, sealhulgas Apache, Nginx ja IIS, toetavad seda funktsiooni.
2. Seadistage oma server: Järgmine samm on konfigureerida oma server kasutama seansi jätkamist. Tavaliselt hõlmab see seansi vahemälu lubamist ja vahemälu ajalõpu väärtuse määramist. Täpsed sammud sõltuvad teie serveritarkvarast.
3. Testige oma konfiguratsiooni: Pärast serveri konfigureerimist peaksite seda testima, et veenduda, et see kasutab seansi jätkamist õigesti. Seda saate teha, luues a TLS serveriga ühenduse loomine, ühenduse katkestamine ja seejärel uuesti ühendamine. Kui seansi jätkamine töötab õigesti, peaks teise ühenduse loomine olema kiirem kui esimene.

Kasuta Case'it: mobiilirakendus kasutab kiirete ja turvaliste ühenduste säilitamiseks seansi jätkamist. See on eriti kasulik, kui rakendust kasutatakse täpilise võrgu levialaga piirkondades, kuna see võimaldab rakendusel pärast katkemist kiiresti turvalise ühenduse taastada. Rakenduse arendajad konfigureerivad oma serveri kasutama seansi jätkamist ja testivad regulaarselt funktsiooni, et tagada selle korrektne töö. See tagab, et rakendus pakub kasutajatele kiiret ja sujuvat kasutuskogemust isegi keerulistes võrgutingimustes.

Tagage sertifikaadi kehtivus OCSP klammerdamisega

OCSP (Online Certificate Status Protocol) klammerdamine on meetod SSL-i jõudluse parandamiseks.TLS säilitades samal ajal ühenduse turvalisuse. See võimaldab serveril hankida oma sertifikaatide praegune olek sertifitseerimisasutuselt (CA) ja seejärel edastada see olek klientidele TLS käepigistus.

OCSP klammerdamise rakendamiseks tehke järgmist.

1. Veenduge, et teie serveritarkvara toetab OCSP klammerdamist: Esimene samm on tagada, et teie serveritarkvara toetab OCSP klammerdamist. Enamik kaasaegseid veebiservereid, sealhulgas Apache, Nginx ja IIS, toetavad seda funktsiooni.
2. Seadistage oma server: Järgmine samm on serveri konfigureerimine OCSP klammerdamist kasutama. Tavaliselt hõlmab see funktsiooni lubamist teie serveri SSL/TLS konfiguratsiooni ja serveri asukoha määramine OCSP vastuste salvestamiseks. Täpsed sammud sõltuvad teie serveritarkvarast.
3. Testige oma konfiguratsiooni: Pärast serveri konfigureerimist peaksite seda testima, et veenduda, et see kasutab õigesti OCSP klammerdamist. Seda saate teha, luues a TLS ühendust oma serveriga ja kontrollides, kas server sisaldab OCSP-vastust TLS käepigistus.

Kasuta Case'it: Interneti-jaemüüja kasutab oma SSL-sertifikaadi oleku kiireks kontrollimiseks OCSP klammerdamist. See tagab, et klientidel on alati turvaline ühendus ja nad saavad usaldada nende andmete turvalisust. Jaemüüja IT-meeskond konfigureerib oma serveri kasutama OCSP klammerdamist ja testib funktsiooni regulaarselt, et tagada selle õige töö. See aitab säilitada nende klientide usaldust ja kaitsta nende tundlikke andmeid.

Keela TLS Kompressioon kuritegevuse rünnaku leevendamiseks

TLS tihendamine on funktsioon, mis võib parandada SSL/TLS vähendades võrgu kaudu edastatavate andmete hulka. See võib aga muuta ühenduse haavatavaks ka CRIME (Compression Ratio Info-leak Made Easy) rünnaku suhtes, mis võimaldab ründajal järeldada krüptitud liikluse sisu.

Siit saate keelata TLS kokkusurumine: 

1. Veenduge, et teie serveritarkvara toetaks keelamist TLS Kokkusurumine: Esimene samm on tagada, et teie serveritarkvara toetab keelamist TLS kokkusurumine. Enamik kaasaegseid veebiservereid, sealhulgas Apache, Nginx ja IIS, toetavad seda funktsiooni.
2. Seadistage oma server: Järgmine samm on serveri konfigureerimine keelamiseks TLS kokkusurumine. Täpsed sammud sõltuvad teie serveritarkvarast. Näiteks Apache'is saate oma konfiguratsioonifaili lisada sellise rea:

SSLCkompressioon väljas

See rida käsib serveril SSL/ jaoks tihendamist mitte kasutadaTLS ühendusi.

3. Testige oma konfiguratsiooni: Pärast serveri konfigureerimist peaksite seda testima, et veenduda, et see keelab õigesti TLS kokkusurumine. Seda saate teha, luues a TLS ühendust oma serveriga ja kontrollige, et ühendus ei kasutaks tihendamist.

Kasuta Case'it: finantsasutus keelab TLS tihendus oma serverites, et kaitsta KRIMI rünnaku eest. See aitab tagada tundlike finantsandmete, näiteks kontonumbrite ja tehingute üksikasjade konfidentsiaalsuse. Asutuse IT-meeskond konfigureerib oma serverid keelama TLS tihendust ja nad testivad servereid regulaarselt, et tagada selle turvameetme õige rakendamine. See aitab kaitsta asutuse kliente ja säilitada nende usaldust.

Täitma TLS Seansipiletid õigesti

TLS seansi piletid on funktsioon TLS protokoll, mis võib jõudlust parandada, võimaldades kliendil ja serveril jätkata eelmist seanssi ilma täielikku käepigistust tegemata. Võimalike turvaprobleemide vältimiseks tuleb neid siiski õigesti rakendada.

Siit saate teada, kuidas saate seda õigesti rakendada TLS seansi piletid:

1. Veenduge, et teie serveritarkvara toetab TLS Seansi piletid: Esimene samm on tagada, et teie serveritarkvara toetab TLS seansi piletid. Enamik kaasaegseid veebiservereid, sealhulgas Apache, Nginx ja IIS, toetavad seda funktsiooni.
2. Seadistage oma server: Järgmine samm on serveri konfigureerimine kasutamiseks TLS seansi piletid. Tavaliselt hõlmab see funktsiooni lubamist teie serveri SSL/TLS konfiguratsiooni. Täpsed sammud sõltuvad teie serveritarkvarast.
3. Kasutage unikaalseid seansipileti võtmeid: võimalike turvaprobleemide vältimiseks peaks iga server kasutama kordumatut seansipileti võtit. Kui kasutate koormuse tasakaalustajat, peaksite selle konfigureerima jaotama kliente nende seansipileti põhjal, mitte lubama klientidel kasutada ühe serveri väljastatud seansipiletit teise serveriga seansi loomiseks.
4. Pöörake seansipiletite võtmeid regulaarselt: turvalisuse suurendamiseks peaksite oma seansipileti võtmeid regulaarselt vahetama. Seda saab sageli automatiseerida teie serveritarkvara või eraldi võtmehaldussüsteemi abil.

Kasuta Case'it: suur mitme serveriga tehnoloogiaettevõte tagab, et iga server kasutab ainulaadset seansipileti võtit. See takistab ründajal kasutada ühest serverist pärinevat seansipiletit, et kehastuda kasutajana teises serveris. Ettevõtte IT-meeskond seadistab oma serverid kasutamiseks TLS seansipiletid ja nad loovad süsteemi seansipileti võtmete korrapäraseks pööramiseks. Samuti konfigureerivad nad oma koormuse tasakaalustaja, et jaotada kliente nende seansipileti alusel, suurendades veelgi oma süsteemi turvalisust.

Luba turvaline uuesti läbirääkimine

Turvaline uuesti läbirääkimine on SSL/TLS protokollid, mis võimaldavad kliendil või serveril taotleda uut TLS käepigistus keset seanssi. See võib olla kasulik mitmel põhjusel, näiteks krüpteerimisvõtmete värskendamiseks või krüpteerimistaseme muutmiseks. Kui aga seda turvaliselt ei käsitleta, võib ründaja seda kasutada lihtteksti sisestamiseks krüpteeritud suhtlusse.

Turvalise uuesti läbirääkimise lubamiseks tehke järgmist.

2. Veenduge, et teie serveritarkvara toetaks turvalist uuesti läbirääkimist: Esimene samm on tagada, et teie serveritarkvara toetab turvalist uuesti läbirääkimist. Enamik kaasaegseid veebiservereid, sealhulgas Apache, Nginx ja IIS, toetavad seda funktsiooni.
3. Seadistage oma server: Järgmine samm on serveri konfigureerimine kasutama turvalist uuesti läbirääkimist. Tavaliselt hõlmab see funktsiooni lubamist teie serveri SSL/TLS konfiguratsiooni. Täpsed sammud sõltuvad teie serveritarkvarast.
4. Testige oma konfiguratsiooni: pärast serveri konfigureerimist peaksite seda testima, et veenduda, et see töötab õigesti, kasutades turvalist uuesti läbirääkimist. Seda saate teha, luues a TLS looge ühendus oma serveriga ja proovige seejärel ühendust uuesti läbi rääkida.

Kasuta Case'it: sotsiaalmeedia platvorm võimaldab kasutajaandmete kaitsmiseks turvaliselt uuesti läbi rääkida. See takistab ründajal kasutaja ja serveri vahelisse krüpteeritud suhtlusse pahatahtlikku sisu süstida. Platvormi IT-meeskond konfigureerib oma serverid kasutama turvalist uuesti läbirääkimist ja testib servereid regulaarselt, et tagada selle turvameetme õige rakendamine. See aitab kaitsta platvormi kasutajaid ja säilitada nende usaldust.

DoS-rünnakute vältimiseks keelake kliendi algatatud uuesti läbirääkimised

Kliendi algatatud uuesti läbirääkimine on SSL/TLS protokollid, mis võimaldavad kliendil taotleda uut TLS käepigistus keset seanssi. Kui aga ründaja suudab sundida serverit pidevalt seansse uuesti läbi rääkima, võib see kulutada liigselt ressursse ja viia teenuse keelamise (DoS) rünnakuni.

Kliendi algatatud uuesti läbirääkimiste keelamiseks tehke järgmist.

1. Veenduge, et teie serveritarkvara toetaks kliendi algatatud uuesti läbirääkimiste keelamist: Esimene samm on tagada, et teie serveritarkvara toetab kliendi algatatud uuesti läbirääkimiste keelamist. Enamik kaasaegseid veebiservereid, sealhulgas Apache, Nginx ja IIS, toetavad seda funktsiooni.
2. Seadistage oma server: Järgmine samm on serveri konfigureerimine kliendi algatatud uuesti läbirääkimiste keelamiseks. See hõlmab tavaliselt direktiivi lisamist teie serveri SSL-ile/TLS konfiguratsiooni. Täpsed sammud sõltuvad teie serveritarkvarast.
3. Testige oma konfiguratsiooni: Pärast serveri konfigureerimist peaksite seda testima, et veenduda, et see keelab õigesti kliendi algatatud uuesti läbirääkimised. Seda saate teha, luues a TLS looge ühendus oma serveriga ja proovige seejärel ühendust uuesti läbi rääkida. Kui server keeldub uuesti läbirääkimistaotlusest õigesti, on see õigesti konfigureeritud.

Kasuta Case'it: Interneti-mänguplatvorm keelab kliendi algatatud uuesti läbirääkimised, et kaitsta end võimalike DoS-rünnakute eest. See aitab tagada, et platvorm jääb kasutajatele kättesaadavaks isegi potentsiaalsete rünnakute korral. Platvormi IT-meeskond konfigureerib oma serverid nii, et see keelaks kliendi algatatud uuesti läbirääkimised, ja nad testivad servereid regulaarselt, et tagada selle turvameetme õige rakendamine. See aitab kaitsta platvormi kasutajaid ja säilitada nende usaldust.

Hoia uus haavatavus

Veebiturve on pidevalt liikuv sihtmärk ja peaksite alati olema järgmise rünnaku otsimisel ning rakendama viivitamatult oma serveril turvapaiku. See tähendab nii infoturbega kui ka silmapiiril olevaga tutvumist ja nendega kursis püsimist, samuti tarkvarauuenduste - eriti kriitiliste - tipus püsimist. SSL.com veebisait (kust sa seda praegu loed) on suurepärane allikas SSL-is kursis püsimiseks /TLS ja infoturve.

Aga kuidas on lood…?

Kui soovite rohkem teada saada mõne selles juhendis käsitletud teema kohta ja õppida uute probleemide ja tehnoloogiate kohta nende tekkimisel, võite kõigepealt sirvida ja otsida SSL.com-sid Teadmistebaas Juhendvideod, mida ajakohastatakse kord nädalas SSL /TLS ja PKI. Võite ka meie tugiteenuste töötajatega igal ajal ühendust võtta e-posti aadressil Support@SSL.com, telefonil 1-877-SSL-Secure või klõpsates selle lehe paremas alanurgas oleval vestluslingil.

Hankige SSL-sertifikaatide kohta asjatundlikku nõu.
Konsultatsiooniks täitke vorm.