Namestitev orodja za ustvarjanje varne TLS povezave “Continent TLS Client. Namestitev orodja za ustvarjanje varne povezave TLS »Odjemalec celine TLS Odjemalec celine tls ne vidi prostora za shranjevanje

Kontinent TLS VPN- certificirana rešitev za zaščito dostopa oddaljenih uporabnikov do zaščitenih virov.

TLS VPN Continent ima arhitekturo odjemalec-strežnik in je sestavljen iz strežnika Continent TLS VPN, ki je nameščen na robu omrežnega oboda, in Continent TLS VPN Client, odjemalca VPN CIPF, nameščenega na oddaljenih računalnikih. uporabniki. »Continent TLS VPN Server« zagotavlja zaupnost, celovitost in zaščito pred imitacijo prenesenih informacij in opravlja naslednje funkcije:

avtentikacija uporabnika s certifikati javnih ključev x.509v3 (GOST R 31.11–94, 34.10–2001);
preverjanje uporabniškega potrdila glede na seznam preklicanih CRL;
vzpostavljanje varnih šifriranih povezav preko HTTPS protokola;
prevajanje zahtev na spletne strežnike korporativnega omrežja in drugo.

Strežnik Continent TLS VPN IPC-3000F (S021), 2014

CIPF »Continent TLS VPN Client« je lokalna transparentna proxy storitev, ki omogoča medsebojno avtentikacijo s strežnikom, vzpostavitev varne povezave, izmenjavo šifriranih podatkov s strežnikom. Združljiv je tudi z večino trenutnih internetnih brskalnikov. Poleg tega je dovoljeno, da uporabniki delajo prek "Continent TLS VPN Server" brez namestitve odjemalske programske opreme CIPF "Continent TLS VPN Client". V tem primeru mora uporabnikov računalnik uporabljati brskalnik MS Internet Explorer z nameščenim ponudnikom kriptostoritev CryptoPro CSP (verzija 3.6 ali 3.9), ki zagotavlja podporo za kriptoalgoritme GOST.

Izdelek je namenjen:

varno povezovanje uporabnikov s portali javnih storitev, elektronskimi trgovalnimi platformami, sistemi internetnega bančništva ali korporativnimi aplikacijami preko spletnega brskalnika.
kriptografska zaščita http-prometa med prenosom podatkov po odprtih kanalih javnih omrežij.

Ključne funkcije

Kriptografska zaščita
- Uporaba protokola TLS s šifriranjem v skladu z GOST 28147–89 zagotavlja zanesljivo zaščito prometa HTTP na transportni ravni
Spremljanje in beleženje informacijsko varnostnih dogodkov
- Pridobivanje operativnih informacij o statistiki dela in trenutnih povezavah strežnika "Continent TLS VPN"
Identifikacija uporabnika in avtentikacija
- Identifikacija in avtentikacija uporabnikov z uporabo x.509 standardnih javnih ključev. Posredovanje podatkov za preverjanje pristnosti uporabnika spletnemu strežniku.
Sodelovanje z zunanjimi certifikacijskimi organi (CA)
- Za ustvarjanje potrdil x.509 "Continent TLS VPN" uporablja zunanji CA "CryptoPro"
Transparentno posredovanje HTTP prometa
- Za varno prijavo v spletno storitev mora uporabnik v naslovni vrstici brskalnika le vnesti ip-naslov ali ime domene.
Razširljivost in toleranca napak
- Podpora za način delovanja v shemi visoko zmogljive gruče z izravnavo obremenitve (zunanji izravnalnik obremenitve). Povečanje tolerance napak se doseže z dodajanjem redundantnega vozlišča v gručo.

Posebnosti

Visoka zmogljivost - do 20.000 hkratnih povezav na vozlišče (IPC-3000F).
Združljiv s katerim koli spletnim brskalnikom.
Enostavnost upravljanja - vse nastavitve izvaja skrbnik prek spletnega brskalnika.
Neomejena razširljivost zmogljivosti – možnost združevanja v visoko zmogljivo gručo za doseganje zmogljivosti nad 100 tisoč hkratnimi povezavami.
Enostavnost implementacije in delovanja - že pripravljena rešitev odpravlja potrebo po vgradnji kriptografskih modulov v spletni strežnik in skozi postopek spremljanja vgradnje kriptografske zaščite informacij.
Enostavna integracija z zunanjimi sistemi SIEM.

Certifikati

Potrdilo FSTEC Rusije o izpolnjevanju zahtev za odsotnost NDV za 4. stopnjo nadzora. Uporablja se za zaščito zvočnikov do vključno razreda 1G, ISPD do vključno UZ 1 in GIS do vključno razreda 1.

Certifikati Zvezne varnostne službe Rusije "Continent TLS VPN Server" za CIPF razreda KS2 in "Continent TLS VPN Client" za CIPF razreda KS2 in KS1.

2018: Izdaja "Kontinent strežnika TLS" različice 2.1

Stranke "Continent TLS-Server" 2.1 so dobile možnost centralne posodobitve odjemalskega dela kompleksa na računalnikih oddaljenih uporabnikov. Poleg tega je bil sistem licenciranja izdelkov v tej različici poenostavljen: za gručo več naprav je potrebna samo ena licenca za največje število hkratnih povezav. Odločeno je bilo tudi združiti licence za povezavo s proxy strežnikom in licence za povezavo preko TLS tunela. Vse to poenostavi delovanje in izbiro ustrezne arhitekture rešitve.

Za julij 2018 je "Continent TLS-strežnik" 2.1 prenesen za certificiranje v FSB Rusije. Po opravljenih testih bo izdelek certificiran za razreda KS1 in KS2.

Ta različica izdelka Continent TLS-Server je zasnovana tako, da olajša delo skrbnikov v obdobju spreminjanja standardov šifriranja, da zagotovi priročno spremljanje. Spremembe v politiki licenciranja in možnost dodelitve ločenih nadzornih vrat za izdelek bi morale razširiti njegov obseg. Podpora za široko paleto odjemalcev TLS vam bo omogočila hitro izgradnjo sistema varnega dostopa do spletne aplikacije, kjer so že uporabljeni ponudniki kriptovalut tretjih oseb. Zdaj naš izdelek podpira "CryptoPro", "Validata" in zaupanja vreden brskalnik "Sputnik".

2016

Relativno novi (izdani leta 2015) izdelki linije Continent - Continent TLS VPN in kripto stikalo Continent so pokazali visoko dinamiko. Obseg njihove prodaje je znašal 71 milijonov rubljev. in 62 milijonov rubljev. oz. Povpraševanje po "Continent TLS VPN" je bilo posledica naraščajočega zanimanja strank za uporabo ruskih algoritmov šifriranja za zaščito dostopa do vladnih portalov, pa tudi za organizacijo varnega oddaljenega dostopa z uporabo algoritmov GOST. Faktor rasti prodaje kripto-stikal "Kontinent" je bila potreba po zaščiti komunikacijskih kanalov v geografsko porazdeljenih centrih za obdelavo podatkov.

Izdana je tehnična izdaja "Continent TLS VPN" 1.0.9 s portalom aplikacij

Podjetje Security Code je aprila 2016 objavilo izid tehnične izdaje različice produkta TLS VPN Continent, namenjenega zagotavljanju varnega oddaljenega dostopa do informacijskih sistemov, ki izvajajo obdelavo osebnih podatkov (ISPD) in državnih informacijskih sistemov ( GIS). Izdelek ima številne nove funkcije.

Ena najpomembnejših sprememb v "Continent TLS VPN" 1.0.9 je izdelava aplikacijskega portala z možnostjo avtentikacije in avtorizacije z uporabo poverilnic iz imenika Active Directory. Ta izboljšava močno poenostavlja proces upravljanja dostopa do spletnih storitev podjetja za različne kategorije uporabnikov. Na primer, z uporabo portala lahko zagotovite enotno točko dostopa za zaposlene v podjetju in njegove izvajalce. V tem primeru bo nabor razpoložljivih aplikacij odvisen od kategorije in uporabniških pravic.

Druga razlika je dodana možnost ustvarjanja začetne strani strežnika, dostopne prek odprtega protokola HTTP. Omogoča znatno znižanje stroškov vzdrževanja varne spletne aplikacije.

Različica 1.0.9 dodaja tudi zmožnost delovanja izdelka v tunelskem načinu TLS, ki vam omogoča, da odstranite omejitve interakcije oddaljenega uporabnika prek kanala, šifriranega s protokolom TLS. Takšna povezava vam omogoča dostop ne le do spletnih virov, temveč tudi do drugih vrst aplikacij, na primer terminalskih strežnikov (prek protokola RDP) ali "debelih odjemalcev" za korporativne aplikacije (ERP, CRM itd.). Ta pristop znatno poveča število scenarijev oddaljenega dostopa, v katerih je mogoče uporabiti TLS VPN Continent.

"Varnostni kodeks" je ocenil čas prehoda vladnih agencij na ruska orodja za šifriranje

16. julija 2016 je spletno mesto Kremlja objavilo navodilo predsednika predsedniku vlade o potrebi po pripravi prehoda državnih organov na uporabo ruskih kriptografskih algoritmov in orodij za šifriranje do 1. decembra 2017. Vlada bi morala zlasti zagotoviti razvoj in izvajanje nabora ukrepov, potrebnih za postopen prehod na uporabo ruskih kriptografskih algoritmov in orodij za šifriranje, ter državljanom Ruske federacije zagotoviti brezplačen dostop do uporabe ruskega šifriranja. orodja.

Objavljeni dokument bo vseboval določene korake za uskladitev IT infrastruktur državnih organov z navedenimi zahtevami. Predvsem se pričakuje množična namestitev v državnih agencijah poleg obstoječih rešitev domačih sredstev za kriptografsko zaščito informacij (CIPF).

več:

Zakon Yarovaya (o spremembah kazenskega zakonika in zakonika o kazenskem postopku Ruske federacije v delu uvedbe dodatnih ukrepov za boj proti terorizmu)

Strokovnjaki za varnostno kodo ugotavljajo, da bo novost vplivala predvsem na portale javnih storitev zveznih in regionalnih oddelkov. Hkrati pa izvajanje te naloge vpliva na dva vidika: implementacijo CIPF na strani spletnega strežnika in na strani uporabnikov. Če predpostavimo, da bo certificirana kripto knjižnica vgrajena v brskalnik na uporabniški strani, potem obstajata dva načina za rešitev težave na strani spletnega strežnika.

Eden od njih je vgradnja kriptografske zaščite informacij v spletne strežnike, drugi je uvedba kompleksa programske in strojne opreme (HSS) z implementacijo TLS VPN (eden od teh izdelkov je "Continent TLS VPN Server", ki ga je razvil "Varnostna koda"), ki bo prestregla HTTP /HTTPS - promet in ga šifrirala v skladu z algoritmom šifriranja po GOST (28147-89). Vsaka od možnosti ima svoje značilnosti - tako glede tehnične izvedbe kot glede časovnega okvira projekta.

Po mnenju analitikov "Varnostnega kodeksa" bodo v prvem primeru (vdelava) faze dela naslednje:

Izdelava organizacijske in administrativne dokumentacije (ORD) - 2 meseca;
Izvedba - 0,5 meseca;
Nadzor integracije kriptografske zaščite informacij v FSB Rusije - 7 mesecev;

Posledično je takšen projekt mogoče izvesti v 1 letu.

Pri izbiri možnosti namestitve PAK bo projekt razdeljen na naslednje faze:

Razvoj ORD - 2 meseca;
Izvedba odprtega razpisa po 44-FZ - 2,5 meseca;
Dobava opreme in programske opreme - 1,5 meseca;
Izvedba - 0,5 meseca.

Skupno trajanje projekta bo v tem primeru približno 7 mesecev.

Strokovnjaki za varnostni kodeks ugotavljajo, da glede na splošno sprejeto prakso med izdajo navodil vladi in začetkom dela na projektih podjetij (ob upoštevanju potrebe po pripravi in sprejetju podzakonskih aktov) minejo vsaj trije meseci. Skladno s tem obstaja tveganje, da se organizacije, ki so se odločile za integracijo kriptografske zaščite informacij v spletne strežnike, težko držijo rokov, ki jih je določil predsednik. In v primeru zamude pri sprejemanju podzakonskih aktov za več kot tri mesece so možne motnje v izvedbenih rokih.

»Poleg težav s časovnim razporedom je prvi način - vdelava - poln drugih težav. Gre za dodatne stroške dela, najprej za oblikovanje in potrditev paketa dokumentov za preskusni laboratorij, nato pa za spremembe kode in razhroščevanje aplikacije na podlagi rezultatov analize preskusnega laboratorija. Toda glavni plus druge možnosti je, da pri izbiri PAK stranka prejme zmogljivo visoko zmogljivo industrijsko rešitev, zasnovano za velike organizacije. Je razširljiv, enostaven za upravljanje, združljiv z vsemi internetnimi brskalniki, enostavno integriran z zunanjimi sistemi SIEM,« je povedal Pavel Korostelev, vodja trženja izdelkov za varnostno kodo.

Glede na navedeno »Varnostni kodeks« državnim strankam priporoča, da izberejo optimalen algoritem za izpolnjevanje zakonskih zahtev in sledijo poti implementacije programsko-strojnega kompleksa (HSS) z implementacijo TLS VPN. Za varen dostop oddaljenih uporabnikov do spletnih virov se uporablja sistem strojne in programske opreme Continent TLS VPN, ki ga je potrdila Zvezna varnostna služba Rusije. Je enostaven za uvajanje, ima brezplačen odjemalec TLS za končne uporabnike in lahko podpira več kot 100.000 sočasnih povezav.

Rusije z dne 30. julija 2015 SF/124-2676 o CIPF "Continent TLS VPN Server" in SF/525-2677, SF/525-2678 o CIPF "Continent TLS VPN Client" (različica 1 in 2) potrjujeta skladnost z zahtevami FSB Rusije za šifrirna (kriptografska) sredstva razreda KS2 in KS1. Potrdila FSB Rusije dovoljujejo uporabo CIPF "Continent TLS VPN" za kriptografsko zaščito informacij, ki ne vsebujejo informacij, ki predstavljajo državno skrivnost.

Certifikat FSTEC Rusije št. 3286, izdan 2. decembra 2014 za CIPF "Continent TLS VPN Server", potrjuje skladnost izdelka z zahtevami smernic za 4. stopnjo nadzora za odsotnost NDV in dovoljuje njegovo uporabo pri ustvarjanju AU do vključno varnostnega razreda 1G in za zaščito informacij v ISPD in GIS do vključno 1. razreda.

Če želite namestiti programsko opremo Continent TLS Client, morate:

Slika 33. Začetno okno čarovnika za namestitev za programsko opremo Continent TLS Client.

Slika 34. Okno licenčne pogodbe za programsko opremo Continent TLS Client.

3. Potrdite polje »Sprejmem pogoje licenčne pogodbe« in kliknite gumb »Naprej«. Na zaslonu se prikaže okno za vnos licenčnega ključa, ki je priložen programski opremi Continent TLS Client na papirju ali elektronskem mediju.

Slika 35. Okno za vnos licenčnega ključa za programsko opremo Continent TLS Client.

4. Vnesite licenčni ključ in kliknite Naprej. Na zaslonu se prikaže pogovorno okno za izbiro namestitvene poti za programsko opremo Continent TLS Client.

Slika 36. Okno za izbiro namestitvene poti za programsko opremo Continent TLS Client.

5. Pustite privzeto namestitveno pot. Kliknite "Naprej". Na zaslonu se prikaže pogovorno okno "Zaženi konfigurator".

Slika 37. Okno za zagon konfiguratorja programske opreme Continent TLS Client.

6. Označite polje »Zaženi konfigurator po končani namestitvi«.

Slika 38. Okno pripravljenosti za namestitev programske opreme Continent TLS Client.

8. Kliknite gumb "Namesti". Začela se bo namestitev komponente.

Slika 39. Postopek namestitve programske opreme Continent TLS Client.

9. Na zaslonu se bo prikazalo konfiguracijsko pogovorno okno programske opreme Continent TLS Client.

Slika 40. Konfiguriranje programske opreme Continent TLS Client.

Za konfiguracijo programske opreme potrebujete:

a) V razdelku »Client TLS Continent Settings« pustite privzeto vrednost »Port«, ki je enaka 8080.

b) V razdelku »Nastavitve zaščitenega strežnika« v polje »Naslov« vnesite ime strežnika TLS: lk.budget.gov.ru.

c) V razdelku »Nastavitve zaščitenega strežnika« v polju »Potrdilo« določite datoteko potrdila strežnika TLS, kopirano v lokalni imenik v členu 3.1 tega vodnika.

Slika 41. Konfiguriranje programske opreme Continent TLS Client. Izbira certifikata.

d) Če delovna postaja uporabnika ne uporablja zunanjega strežnika proxy, kliknite gumb "V redu".

e) V nasprotnem primeru navedite naslov in vrata zunanjega proxy strežnika organizacije, ki bo uporabljen.

Slika 42. Nastavitev programske storitve Continent TLS Client. Nastavitev zunanjega proxy strežnika.

f) Pritisnite gumb OK.

10. Na zaslonu se bo prikazalo pogovorno okno za dokončanje namestitve programske opreme Continent TLS Client.

Slika 43. Pogovorno okno za dokončanje namestitve programske opreme Continent TLS Client.

11. Pritisnite gumb "Dokončaj".

12. Na zaslonu se prikaže pogovorno okno, ki vas prosi, da znova zaženete uporabnikovo delovno postajo.

Slika 44. Pogovorno okno o potrebi po ponovnem zagonu uporabnikove delovne postaje.

13. Pritisnite gumb "Ne".

Zadnje čase se vse pogosteje omenjata TLS in SSL, vse bolj aktualna je uporaba digitalnih potrdil, pojavila so se celo podjetja, ki so vsem pripravljena brezplačno ponuditi digitalna potrdila, ki zagotavljajo šifriranje prometa med obiskanimi stranmi in brskalnikom odjemalca. To je seveda potrebno zaradi varnosti, da nihče v omrežju ne more prejeti podatkov, ki se prenašajo od odjemalca do strežnika in obratno. Kako vse skupaj deluje in kako ga uporabljati? Da bi to razumeli, je morda treba začeti s teorijo in nato pokazati v praksi. Torej, SSL in TLS.

Kaj je SSL in kaj TLS?

SSL pomeni Secure Socket Layer, raven varnih vtičnic. TLS - Transport Layer Security, varnost transportnega sloja. SSL je starejši sistem, TLS je novejši in temelji na specifikaciji SSL 3.0, ki jo je razvil Netscape Communications. Kljub temu je naloga teh protokolov enaka – zagotoviti varen prenos podatkov med dvema računalnikoma v internetu. Ta prenos se uporablja za različna spletna mesta, za e-pošto, za sporočanje in še veliko več. Načeloma lahko na ta način prenesete vse informacije, več o tem spodaj.

Varen prenos je zagotovljen s pomočjo avtentikacije in šifriranja prenesenih informacij. Pravzaprav ta protokola, TLS in SSL, delujeta na enak način, ni bistvenih razlik. Za TLS lahko rečemo, da je naslednik SSL, čeprav se lahko uporabljata hkrati, tudi na istem strežniku. Takšna podpora je potrebna, da se zagotovi delo tako z novimi odjemalci (naprave in brskalniki) kot s starejšimi, ki ne podpirajo TLS. Zaporedje pojavljanja teh protokolov izgleda takole:

SSL 1.0 – nikoli objavljen
SSL 2.0 - februar 1995
SSL 3.0 - 1996
TLS 1.0 - januar 1999
TLS 1.1 - april 2006
TLS 1.2 - avgust 2008

Kako delujeta SSL in TLS

Načelo delovanja SSL in TLS je, kot sem rekel, enako. Preko protokola TCP/IP se vzpostavi šifriran kanal, znotraj katerega se podatki prenašajo preko aplikacijskega protokola - HTTP, FTP itd. Takole ga je mogoče grafično predstaviti:

Protokol aplikacije je "zavit" v TLS/SSL, ta pa v TCP/IP. Pravzaprav se podatki protokola aplikacije prenašajo prek TCP / IP, vendar so šifrirani. In le stroj, ki je vzpostavil povezavo, lahko dešifrira poslane podatke. Za vse ostale, ki prejmejo poslane pakete, bodo te informacije brez pomena, če jih ne bodo mogli dešifrirati.

Povezava se vzpostavi v več korakih:

1) Odjemalec vzpostavi povezavo s strežnikom in zahteva varno povezavo. To lahko dosežete bodisi z vzpostavitvijo povezave na vratih, ki so prvotno zasnovana za delo s SSL/TLS, na primer 443, bodisi z dodatno zahtevo odjemalcu, da po vzpostavitvi normalne vzpostavi varno povezavo.

2) Pri vzpostavljanju povezave odjemalec posreduje seznam šifrirnih algoritmov, ki jih »pozna«. Strežnik prejeti seznam primerja s seznamom algoritmov, ki jih strežnik sam "pozna" in izbere najbolj zanesljiv algoritem, nakar odjemalcu sporoči kateri algoritem naj uporabi.

3) Strežnik odjemalcu pošlje svoje digitalno potrdilo, podpisano s strani overitelja in strežnikov javni ključ.

4) Odjemalec se lahko obrne na strežnik zaupanja vredne službe za potrdila, ki je podpisala potrdilo strežnika, in preveri, ali je potrdilo strežnika veljavno. Vendar se morda ne bo povezal. Operacijski sistem ima običajno že nameščena korenska potrdila overiteljev, s katerimi se preverjajo podpisi strežniških potrdil, na primer brskalnikov.

5) Za varno povezavo se ustvari sejni ključ. To se naredi na naslednji način:
- Odjemalec ustvari naključno digitalno zaporedje
- Odjemalec ga šifrira z javnim ključem strežnika in pošlje rezultat strežniku
- Strežnik dešifrira prejeto zaporedje z uporabo zasebnega ključa
Glede na to, da je algoritem šifriranja asimetričen, lahko samo strežnik dešifrira zaporedje. Pri uporabi asimetričnega šifriranja se uporabljata dva ključa - zasebni in javni. Javno poslano sporočilo je šifrirano, zasebno sporočilo pa dešifrirano. Sporočila ne morete dešifrirati z javnim ključem.

6) Tako je vzpostavljena šifrirana povezava. Podatki, ki se prenašajo prek njega, so šifrirani in dešifrirani, dokler se povezava ne prekine.

Korensko potrdilo

Tik zgoraj sem omenil korensko potrdilo. To je potrdilo avtorizacijskega centra, katerega podpis potrjuje, da je podpisano potrdilo tisto, ki pripada ustrezni službi. Certifikat sam po navadi vsebuje več informacijskih polj, ki vsebujejo podatke o imenu strežnika, kateremu je bil certifikat izdan, in obdobju veljavnosti tega certifikata. Če je potrdilo poteklo, je razveljavljeno.

Zahteva za podpis (CSR, zahteva za podpis potrdila)

Če želite pridobiti podpisano potrdilo strežnika, morate ustvariti zahtevo za podpis (CSR, Certificate Sign Request) in to zahtevo poslati avtorizacijskemu centru, ki bo vrnil podpisano potrdilo, ki je nameščeno neposredno na strežniku, spodaj bomo videli, kako naredi to v praksi. Najprej se generira šifrirni ključ, nato pa se na podlagi tega ključa generira zahteva za podpisovanje, datoteka CSR.

Potrdilo stranke

Potrdilo odjemalca je mogoče ustvariti za uporabo naprave in uporabnika. Običajno se takšna potrdila uporabljajo pri dvosmernem preverjanju, ko odjemalec preveri, ali je strežnik res tisti, za katerega se predstavlja, strežnik pa v odgovor stori isto. Ta interakcija se imenuje dvosmerna avtentikacija ali medsebojna avtentikacija. Dvosmerna avtentikacija vam omogoča povečanje stopnje varnosti v primerjavi z enosmerno avtentikacijo, lahko pa tudi nadomesti avtentikacijo z uporabo prijave in gesla.

Veriga dejanj za generiranje potrdil

Poglejmo si v praksi, kako potekajo dejanja v zvezi z generiranjem certifikatov od samega začetka, hkrati pa tudi v praksi.

Prva stvar je ustvariti korensko potrdilo. Korensko potrdilo je podpisano samo. In potem bodo s tem potrdilom podpisani drugi certifikati.

$ openssl genrsa -out root.key 2048 Generiranje zasebnega ključa RSA, 2048 bit dolg modul ..........+++ ................... ........................+++ e je 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Ste boste morali vnesti podatke, ki bodo vključeni v vašo zahtevo za potrdilo. Tisto, kar boste vnesli, je tako imenovano razločno ime ali DN. Obstaja kar nekaj polj, vendar lahko nekatera pustite prazna. Za nekatera polja bo privzeta vrednost. Če vnesete ».«, bo polje ostalo prazno. ----- Ime države (2 črkovna koda) :RU Ime države ali province (polno ime) :N/A Ime kraja (npr. mesto) :Sankt Peterburg Ime organizacije (npr. podjetje) :Ime organizacijske enote mojega podjetja (npr. razdelek) :Splošno ime storitve IT (npr. FQDN strežnika ali VAŠE ime) :E-poštni naslov korenskega potrdila mojega podjetja: [e-pošta zaščitena] Vnesite naslednje "dodatne" atribute, ki bodo poslani z vašo zahtevo za potrdilo Geslo za izziv : Izbirno ime podjetja : My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Podpis ok subjekt=/C=RU/ST=N/A/L=Saint-Petersburg/O=Moje podjetje/OU=IT Storitev/CN=Korenski certifikat mojega podjetja/ [e-pošta zaščitena] Pridobivanje zasebnega ključa

Tako smo najprej izdelali zasebni ključ, nato zahtevo za podpis, nato pa z našim ključem podpisali svojo zahtevo in prejeli lastno digitalno potrdilo izdano za 10 let. Geslo (izzivno geslo) lahko pri generiranju potrdila izpustite.

Zasebni ključ MORA biti shranjen na varnem mestu, z njim lahko podpišete katerokoli potrdilo v svojem imenu. In prejeto korensko potrdilo lahko uporabimo za identifikacijo, da smo potrdilo, na primer strežnika, podpisali mi in ne nekdo drug. To so dejanja, ki jih izvajajo avtorizacijski centri, ko generirajo lastna potrdila. Ko ustvarite korensko potrdilo, lahko začnete z ustvarjanjem strežniškega potrdila.

Ogled informacij o potrdilu

Vsebino potrdila si lahko ogledate na naslednji način:

$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=Moje podjetje/OU=IT Service/CN=Korenski certifikat mojega podjetja/ [e-pošta zaščitena] notAfter=22. januar 11:49:41 2025 GMT

Vidimo, kdo je izdal to potrdilo in kdaj poteče.

Certifikat strežnika

Za podpis potrdila za strežnik moramo narediti naslednje:

1) Ustvarite ključ
2) Ustvarite zahtevo za podpis
3) Datoteko CSR pošljite v avtorizacijski center ali jo podpišite sami

Strežniško potrdilo lahko vključuje verigo potrdil, ki so podpisala strežniško potrdilo, lahko pa je tudi shranjeno v ločeni datoteki. Načeloma je vse videti približno tako kot pri generiranju korenskega potrdila

$ openssl genrsa -out server.key 2048 Generiranje zasebnega ključa RSA, 2048 bit dolg modul ................................ ................................................. . +++ ..................+++ e je 65537 (0x10001) $ openssl req -new -key server.key - out server.csr Ti boš morate vnesti podatke, ki bodo vključeni v vašo zahtevo za potrdilo. Kar boste vnesli, je tisto, kar se imenuje razločno ime ali DN. Obstaja kar nekaj polj, vendar lahko nekatera pustite prazna. Za nekatera polja bo privzeta vrednost. Če vnesete ».«, bo polje ostalo prazno. ----- Ime države (2 črkovna koda) :RU Ime države ali province (polno ime) :N/A Ime kraja (npr. mesto) :Sankt Peterburg Ime organizacije (npr. podjetje) :Ime organizacijske enote mojega podjetja (npr. razdelek) :Splošno ime storitve IT (npr. FQDN strežnika ali VAŠE ime) :www.mycompany.com E-poštni naslov : [e-pošta zaščitena] Vnesite naslednje "dodatne" atribute, ki bodo poslani z vašo zahtevo za potrdilo. Izzivno geslo: Izbirno ime podjetja: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem -days 365 Podpis ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/ [e-pošta zaščitena] Pridobivanje zasebnega ključa CA $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Korenski certifikat mojega podjetja/ [e-pošta zaščitena] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=Moje podjetje/OU=IT Service/CN=www.mycompany.com/emailAd [e-pošta zaščitena] notAfter=25. januar 12:22:32 2016 GMT

Tako je potrdilo strežnika podpisano in vedeli bomo, katera organizacija je potrdilo izdala. Po podpisu lahko končano potrdilo uporabite za predvideni namen, na primer namestite ga na spletni strežnik.

Namestitev potrdila SSL/TLS na strežnik z nginx

Za namestitev potrdila SSL/TLS na spletni strežnik nginx morate slediti nekaj preprostim korakom:

1) Kopirajte datoteki .key in .pem na strežnik. V različnih operacijskih sistemih so lahko potrdila in ključi shranjeni v različnih imenikih. V Debianu je to na primer /etc/ssl/certs za potrdila in /etc/ssl/private za ključe. V CentOS sta to /etc/pki/tls/certs in /etc/pki/tls/private

2) Zapišite potrebne nastavitve v konfiguracijsko datoteko za gostitelja. Takole bi moralo izgledati (to je samo primer):

Strežnik (poslušaj 443; ime_strežnika www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 ni priporočljiv!!! # Tukaj je samo na primer ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / (try_files $uri $uri/ =404; ) )

3) Znova zaženite nginx

4) Pojdite na strežnik 443 vrat brskalnika - https://www.mycompany.com in preverite njegovo delovanje.

Namestitev potrdila SSL/TLS na strežnik Apache

Namestitev potrdila SSL/TLS na Apache je videti približno enako.

1) Kopirajte datoteke ključev in potrdil na strežnik v ustrezne imenike

2) Omogočite modul ssl za Apache z ukazom "a2enmod ssl", če še ni omogočen

3) Ustvarite navideznega gostitelja, ki bo poslušal na vratih 443. Konfiguracija bo videti nekako takole:

ServerAdmin [e-pošta zaščitena] DocumentRoot /var/www Možnosti FollowSymLinks AllowOverride Brez Možnosti Indeksi FollowSymLinks MultiViews AllowOverride None Razvrsti dovoli, zavrni dovoli od vseh ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel warn CustomLog $(APACHE_LOG_DIR)/ssl_access.log kombinirani SSLEngine na SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key # Ta direktiva doda datoteka , ki vsebuje seznam # vseh potrdil, ki so podpisala potrdilo strežnika #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions+StdEnvVars SSLOptions+StdEnvVars BrowserMatch "MSIE" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE " ssl-unclean-shutdown

Hkrati je treba storiti še eno stvar. V datoteki httpd.conf ali apache2.conf ali ports.conf, odvisno od sistema, poiščite naslednji razdelek konfiguracije:

Poslušaj 443

Če takega pogoja ni, ga morate dodati v konfiguracijo. In še nekaj: dodati morate vrstico

ImeVirtualHost *:443

Ta vrstica je lahko v httpd.conf, apache2.conf ali ports.conf

4) Znova zaženite spletni strežnik Apache

Ustvarite potrdilo odjemalca

Potrdilo odjemalca se ustvari na približno enak način kot potrdilo strežnika.

$ openssl genrsa -out client.key 2048 Generiranje zasebnega ključa RSA, 2048 bit dolg modul ........................+++ ..... .............................................+++ e je 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Tisto, kar boste vnesli, je tako imenovano razločno ime ali DN. Obstaja kar nekaj polj, vendar lahko nekatera pustite prazna. Za nekatera polja bo privzeta vrednost. Če vnesete ».«, bo polje ostalo prazno. ----- Ime države (2 črkovna koda) :RU Ime države ali province (polno ime) :Saint-Petersburg Ime kraja (npr. mesto) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Tisto, kar boste vnesli, je tako imenovano razločno ime ali DN. Obstaja kar nekaj polj, vendar lahko nekatera pustite prazna. Za nekatera polja bo privzeta vrednost. Če vnesete ».«, bo polje ostalo prazno. ----- Ime države (2 črkovna koda) :RU Ime države ali province (polno ime) :N/A Ime kraja (npr. mesto) :Saint-Petrersburg Ime organizacije (npr. podjetje) :Ime organizacijske enote mojega podjetja (npr. razdelek) :Engineering Common Name (npr. FQDN strežnika ali VAŠE ime) :E-poštni naslov Ivana Ivanova : [e-pošta zaščitena] Vnesite naslednje "dodatne" atribute, ki bodo poslani z vašo zahtevo za potrdilo. Izzivno geslo: Izbirno ime podjetja: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -days 365 Podpis ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=Moje podjetje/OU=Inženiring/CN=Ivan Ivanov/ [e-pošta zaščitena] Pridobivanje zasebnega ključa CA $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN =Korenski certifikat mojega podjetja/ [e-pošta zaščitena] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=Moje podjetje/OU=Inženiring/CN=Ivan Ivanov/e-pošta [e-pošta zaščitena] notAfter=25. januar 13:17:15 2016 GMT

Če potrebujete potrdilo odjemalca v formatu PKCS12, ga ustvarite:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Vnesite geslo za izvoz: Preverjanje - Vnesite geslo za izvoz:

Zdaj lahko uporabimo potrdilo odjemalca za delo z našim strežnikom.

Konfiguriranje nginx za uporabo odjemalskih potrdil

Najpogosteje se, kot sem rekel, uporablja enosmerna avtentikacija, običajno se preveri samo potrdilo strežnika. Poglejmo, kako doseči, da spletni strežnik nginx potrdi potrdilo odjemalca. V razdelku strežnika je potrebno dodati možnosti za delo s potrdili odjemalcev:

# Korenska potrdila, podpisana s strani odjemalca ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Možni možnosti: na | izklopljen | neobvezno | optional_no_ca ssl_verify_client neobvezno; # Globina preverjanja verige potrdil, podpisanih s strani odjemalca ssl_verify_depth 2;

Po tem morate znova zagnati nastavitve ali celoten strežnik in lahko preverite delo.

Konfiguriranje Apache za uporabo potrdil odjemalca

Apache je konfiguriran tudi z dodajanjem dodatnih možnosti v razdelek navideznega gostitelja:

# Imenik, ki vsebuje korenska potrdila za preverjanje odjemalcev SSLCARevocationPath /etc/apache2/ssl.crl/ # ali datoteka, ki vsebuje potrdila SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Možnost preverjanja odjemalca. Možnosti so: # brez, neobvezno, zahteva in optional_no_ca SSLVerifyClient zahteva # Globina iskanja verige podpisa. Privzeto 1 SSLVerifyDepth 2

Kot lahko vidite, so možnosti približno enake kot pri nginxu, saj je postopek preverjanja organiziran na enoten način.

Poslušanje informacij potrdila z openssl

Če želite preveriti, ali strežnik komunicira s potrdili odjemalca, lahko preverite, ali je povezava vzpostavljena s TLS/SSL.

Na strani strežnika začnemo poslušati vrata z uporabo openssl:

Openssl s_server -accept 443 -cert server.pem -key server.key -state

Na strani odjemalca dostopamo do strežnika, na primer, s culr:

Curl -k https://127.0.0.1:443

V konzoli s strani strežnika lahko opazujete proces izmenjave informacij med strežnikom in odjemalcem.

Uporabite lahko tudi možnosti -verify [globina preverjanja] in -Verify [globina preverjanja]. Možnost z malimi črkami od odjemalca zahteva potrdilo, vendar ga ni treba zagotoviti. Napisane z veliko začetnico - če potrdilo ni na voljo, bo prišlo do napake. Začnimo poslušati s strani strežnika takole:

Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

S strani strežnika je napaka videti takole:

140203927217808:napaka:140890C7:SSL rutine:SSL3_GET_CLIENT_CERTIFICATE:vrstnik ni vrnil potrdila:s3_srvr.c:3287:

S strani stranke takole:

Curl: (35) error:14094410:SSL rutine:SSL3_READ_BYTES:sslv3 alert rokovanje napaka

Dodamo certifikat in ime domene s strani odjemalca (za preverjanje lahko vnesete ime gostitelja za naslov 127.0.0.1 v datoteko /etc/hosts):

Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Zdaj bo povezava uspešna in lahko namestite strežniško potrdilo na spletni strežnik, daste odjemalsko potrdilo odjemalcu in delate z njim.

Varnost

Pri uporabi SSL/TLS je ena glavnih metod metoda MITM (Man In The Middle). Ta metoda temelji na uporabi strežniškega potrdila in ključa na nekem vozlišču, ki bo poslušal promet in dešifriral informacije, izmenjane med strežnikom in odjemalcem. Za organizacijo poslušanja lahko uporabite na primer program sslsniff. Zato je običajno zaželeno, da korensko potrdilo in ključ shranite na stroj, ki ni povezan z omrežjem, zahteve za podpisovanje prinesete na bliskovni pogon v podpis, podpišete in odnesete na enak način. In seveda naredite varnostne kopije.

Na splošno se tako uporabljajo digitalna potrdila ter protokola TLS in SSL. Če imate kakršna koli vprašanja / dodatke, jih napišite v komentarje.

Ta vnos je avtor objavil v oznaki .

Navigacija po objavi

: 29 komentarjev

cl-service.com
Naročnik sam generira CSR ob naročilu certifikata, kjer se naročnik tudi odloči za shranjevanje zasebnega ključa, zasebnega ključa za izdajo potrdila ne potrebujemo in nam ga naročnik na noben način ne posreduje. Seveda, če se to zgodi na navadnem virtualnem strežniku, imajo skrbniki s korenskim dostopom do strežnika dostop do ključev, ki so tam shranjeni.
Dobronamernik.
Tema o joškah ni razkrita, ker opisana tehnologija PKI nima nobene zveze z naslovom teme. Če le z razlogom, bi dal povezave do rfc.
P.S. Bila je šala o psu in bolhi.
Dobronamernik.
Nikoli te nisem hotel užaliti. Iskal sem informacije o razliki med SSl in TLS v praksi in tvoja povezava v Googlu je bila prva. Navdušil me je naslov teme. Vse je super, samo tako naprej!
DrAibolit
Hvala za smiselna pojasnila o digitalnem certificiranju. Sem nov v tem =)
Upam, da mi bo uspelo razjasniti naslednje vprašanje.
Ker je tema goljufij v internetni industriji zelo razvita, bi se rad naučil sam določiti "uši" strani, ki jih obiskujem (predvsem tam, kjer so gotovina in plačila, naložbe itd.) in ugotoviti, na podlagi tega stopnja mojega zaupanja (pogosto se moram registrirati, pustiti osebne podatke, opraviti nakupe, transakcije, naložbe). Če prav razumem, vam prisotnost tega certifikata omogoča takšno oceno. No, po drugi strani pa ga dobiti ni problem in celo brezplačno.
Kako oziroma s pomočjo katerega programa lahko ugotovite prisotnost digitalnega potrdila za določeno spletno mesto? in po možnosti njegova kategorija, ki se dodeli ob izdaji posebnega organa SSL DV (izdaja certifikata se izvede s preverjanjem samo domene), SSL OV (s preverjanjem organizacije), EV (z razširjenim preverjanjem pravne osebe). Goljufiva spletna mesta najverjetneje ne bodo uporabila zadnje možnosti certificiranja.
Vesel bi bil, če bi mi povedali več načinov za ugotavljanje zanesljivosti spletnih mest))
1. mnorin Avtor objave
  Za te namene še nisem naletel na noben poseben program, lahko pa dam nekaj nasvetov o tej zadevi.
  Uporabite lahko na primer Chromium ali Google Chrome. Vzemimo za primer spletno stran https://www.thawte.com/ – podjetje, ki se dejansko ukvarja z digitalnimi potrdili.
  Naslovna vrstica bo vsebovala ime podjetja in zeleno ključavnico. To pomeni, da je organizacija preverjena, je vsaj SSL OV.
  Če kliknete na ključavnico in v spustnem polju "Podrobnosti" in nato "Ogled potrdila", lahko vidite informacije o potrdilu. Za Thawte je potrdilo podpisano z naslednjim potrdilom: "thawte Extended Validation SHA256 SSL CA", potrdilo za click.alfabank.ru pa je prav tako podpisano s strani Thawte, vendar z drugim potrdilom. To so "thawte EV SSL CA - G3", torej so prestali tudi Extended Validation.
  Nekaj podobnega.
Ruslan
Razdelek "Načelo delovanja SSL in TLS", "Odjemalec ustvari naključno digitalno zaporedje".

Prepričan sem bil, da odjemalec ustvari zasebni sejni in s tem javni ključ (ki ste ga očitno poimenovali "digitalno zaporedje"). Javni ključ se posreduje strežniku in strežnik šifrira pakete proti odjemalcu z javnim ključem seje odjemalca.

Prosim pojasni.
Novinec
Članek je zelo koristen! Obstajajo celo praktični primeri =) Samo ene stvari nisem razumel - kakšna je razlika med korenskim potrdilom in strežniškim? ali je to ista stvar?
Vitalij
Zdravo.
Gostitelj je ponudil storitev - SSL za virtualne strežnike. Izkoristili. Izkazalo se je, da je za tretjo stopnjo, tj. Potrdilo http://www.site.ru ni veljavno, samo za site.ru. Poleg tega so obiskovalci trmasto vrženi na protokol https, ni pomembno, ali gredo na site.ru ali http://www.site.ru. Seveda v drugem primeru brskalnik začne srčno preklinjati in obiskovalec nikoli ne pride na spletno mesto.
In za tiste, ki so prišli do spletnega mesta, je spletno mesto začelo izgledati ukrivljeno, del menija je izginil, nekaterih slik v rezultatih iskanja nekatere komponente niso več prikazale.

Programska oprema Kontinent TLS VPN– sistem za zagotavljanje varnega oddaljenega dostopa do spletnih aplikacij z uporabo šifrirnih algoritmov GOST. TLS VPN Continent izvaja kriptografsko zaščito prometa HTTP na ravni seje. Šifriranje informacij se izvaja v skladu z algoritmom GOST 28147–89.

Identifikacija in avtentikacija oddaljenih uporabnikov

Identifikacija in avtentikacija uporabnikov se izvajata s potrdili javnih ključev standarda x.509v3 (GOST R 31.11–94, 34.10–2001). TLS VPN Continent preverja ključna potrdila glede na sezname preklicanih potrdil (CRL). Certifikate izda zunanji overitelj.

V primeru uspešnega zaključka postopkov avtentikacije se uporabnikova zahteva preko HTTP preusmeri v varno omrežje na ustrezen spletni strežnik. V tem primeru se vsaki HTTP seji uporabnika dodajo posebni identifikatorji (identifikator odjemalca in identifikator IP).

Kriptografska zaščita prenesenih informacij

TLS VPN Continent izvaja kriptografsko zaščito prometa HTTP na ravni seje. Šifriranje informacij se izvaja v skladu z algoritmom GOST 28147–89. Zgoščevalna funkcija se izračuna v skladu z algoritmom GOST R 34.11–94, GOST R 34.11–2012. Oblikovanje in preverjanje elektronskega podpisa se izvajata v skladu z algoritmom GOST R 34.10–2001, GOST R 34.10–2012.

Skrivanje zaščitenih strežnikov in prevajanje naslovov

TLS VPN Continent filtrira zahteve in prevaja naslove zahtev v spletne strežnike korporativnega omrežja. Prevajanje naslovov poteka v skladu s pravili, ki jih je določil skrbnik »Continent TLS VPN«.

Odpornost na napake in razširljivost

TLS VPN Continent podpira delo v visoko zmogljivi gručni shemi z izravnavo obremenitve (zunanji izravnalnik obremenitve). Povečanje tolerance napak se doseže z dodajanjem redundantnega vozlišča v gručo. Hkrati se lahko elementi izravnalnega grozda povečujejo neomejeno. Odpoved elementa grozda ne povzroči prekinitve povezav, saj je obremenitev enakomerno porazdeljena med preostale elemente.

Spremljanje in beleženje dogodkov

V TLS VPN Continent lahko skrbnik vedno dobi ažurne informacije o trenutnem stanju vzpostavljenih povezav in statistiko o svojem delu. Dogodki informacijske varnosti se beležijo na strežniku. Vse dogodke je mogoče poslati na navedeni strežnik v formatu syslog za nadaljnjo analizo, kar olajša integracijo s sistemi SIEM.

Priročna orodja za upravljanje

Kombinacija lokalnih in oddaljenih orodij s spletnim vmesnikom in priročno grafično upravljalno konzolo zagotavlja prilagodljivo konfiguracijo TLS VPN Continent v skladu z zahtevami varnostnih politik.

Podprti protokoli

TLS VPN Continent podpira protokole TLS v.1, TLS v.2.

Uporabniško delovanje prek katerega koli spletnega brskalnika

Z uporabo aplikacije Continent TLS VPN Client lahko uporabniki dostopajo do zaščitenih virov iz katerega koli spletnega brskalnika. Kontinent TLS VPN Odjemalec je lokalni proxy, ki prestreže promet brskalnika do zaščitenih spletnih strežnikov in ga pakira v tunel http. Zahvaljujoč temu lahko uporabnik dela s katerim koli spletnim brskalnikom, nameščenim v njegovi napravi.

Uporaba uporabniku prijaznega programskega odjemalca

Uporaba uporabniku prijaznega odjemalca programske opreme Kot odjemalca na uporabnikovi napravi je mogoče uporabiti Continent TLS VPN Client ali CryptoPro CSP različice 3.6.1.

Program TLS Continent pomaga uporabnikom pridobiti varen dostop do določenih spletnih virov. Ključni podatki so shranjeni v varnem vsebniku.

Uporaba

Uporabniki korporativnega omrežja lahko sedaj dobijo oddaljen in varen dostop do določenih virov na internetu. Pri vzpostavljanju povezave je zagotovljena medsebojna avtentikacija s strežnikom. Za dostop morate v brskalnik vnesti naslov spletnega mesta. Na koncu odjemalec obdela in strežniku pošlje zahtevo za vzpostavitev varne povezave. Avtentikacija se izvaja na podlagi certifikatov ključev.

Zmogljivosti odjemalca

Protokol povezave med strežnikom in odjemalcem je TLSv1. Vir, na katerem je vzpostavljen varen stik, mora vsebovati vrednost TLS v imenu strežnika. Če je vse opravljeno pravilno, se na zaslonu prikaže potrdilo, ki ga lahko posodobite s pritiskom na ustrezno tipko. Obstaja možnost, da si ob prijavi samodejno zapomnite uporabniško ime in geslo. Omeniti velja, da če med postopkom avtorizacije 5-krat zaporedoma vnesete napačne podatke, bo sistem samodejno blokiral. Ponoven vnos podatkov bo možen šele po 10 minutah.

Ključne funkcije

program je popolnoma združljiv z vsemi različicami sistema Windows;
v procesu uporabe je zagotovljena zanesljiva zaščita med korporativnimi uporabniki;
tak Naročnik je optimalna rešitev, ko se podatki izmenjujejo in je uhajanje informacij nesprejemljivo;
za vstop boste morali vnesti podatke (prijavo in geslo) in zagnati certificiran ključ;
delo se izvaja samo s strežniki, ki podpirajo protokola TLSv1 in TLSv1.2.