Il programma Continent TLS aiuta gli utenti a ottenere un accesso sicuro a determinate risorse web. Le informazioni chiave sono archiviate in un contenitore sicuro.
Utilizzo
Gli utenti della rete aziendale possono ora ottenere un accesso remoto e sicuro a risorse specifiche su Internet. Durante la creazione della connessione viene fornita l'autenticazione reciproca con il server. Per accedere, è necessario inserire l'indirizzo del sito nel browser. Di conseguenza, il client elabora e invia la richiesta al server per creare una connessione sicura. L'autenticazione viene fornita in base ai certificati chiave.
Capacità del cliente
Il protocollo di connessione tra il server e il Client è TLSv1. La risorsa per la quale viene stabilito un contatto sicuro deve contenere il valore TLS nel nome del server. Se tutto è eseguito correttamente, sul display verrà visualizzato un certificato che potrà essere aggiornato premendo l'apposito pulsante. È possibile ricordare automaticamente login e password quando si accede al sistema. Vale la pena notare che se inserisci informazioni false per 5 volte di seguito durante il processo di autorizzazione, il sistema verrà automaticamente bloccato. Potrai reinserire i dati solo dopo 10 minuti.
Caratteristiche principali
- il programma è pienamente compatibile con tutte le versioni di Windows;
- durante l'uso viene fornita una protezione affidabile tra gli utenti aziendali;
- tale Cliente è la soluzione ottimale quando vengono scambiati dati e la fuga di informazioni è inaccettabile;
- Per accedere sarà necessario inserire i propri dati (login e password) ed eseguire una chiave certificata;
- il lavoro viene eseguito solo con server che supportano i protocolli TLSv1 e TLSv1.2.
TLS e SSL sono stati menzionati sempre più recentemente, l'uso dei certificati digitali è diventato più rilevante e sono apparse anche aziende pronte a fornire certificati digitali gratuiti a tutti per garantire che il traffico tra i siti visitati e il browser del cliente sia crittografato. Ciò è naturalmente necessario per la sicurezza, affinché nessuno nella rete possa ricevere i dati trasmessi dal client al server e viceversa. Come funziona tutto questo e come usarlo? Per capirlo, forse dobbiamo iniziare con la teoria e poi mostrarlo nella pratica. Quindi, SSL e TLS.
Cos'è SSL e cos'è TLS?
SSL - Secure Socket Layer, uno strato di socket sicuri. TLS - Transport Layer Security, sicurezza del livello di trasporto. SSL è un sistema precedente, TLS è arrivato dopo e si basa sulla specifica SSL 3.0 sviluppata da Netscape Communications. Tuttavia, questi protocolli hanno un compito: garantire il trasferimento sicuro dei dati tra due computer su Internet. Questo trasferimento viene utilizzato per vari siti Web, per la posta elettronica, per la messaggistica e molto altro. In linea di principio è possibile trasmettere qualsiasi informazione in questo modo; ne parleremo più avanti.
La trasmissione sicura è garantita dall'autenticazione e dalla crittografia delle informazioni trasmesse. Essenzialmente, questi protocolli, TLS e SSL, funzionano allo stesso modo; non ci sono differenze fondamentali. Si può dire che TLS sia il successore di SSL, sebbene possano essere utilizzati contemporaneamente, anche sullo stesso server. Tale supporto è necessario per garantire il funzionamento sia con i nuovi client (dispositivi e browser) che con quelli legacy che non supportano TLS. La sequenza di occorrenza di questi protocolli è simile alla seguente:
SSL 1.0 - mai pubblicato
SSL 2.0 - febbraio 1995
SSL3.0-1996
TLS 1.0 - gennaio 1999
TLS 1.1 - aprile 2006
TLS 1.2 - agosto 2008
Come funzionano SSL e TLS
Il principio di funzionamento di SSL e TLS, come ho detto, è lo stesso. Sopra il protocollo TCP/IP viene stabilito un canale crittografato all'interno del quale i dati vengono trasferiti tramite il protocollo dell'applicazione: HTTP, FTP e così via. Ecco come può essere rappresentato graficamente:
Il protocollo dell'applicazione è “racchiuso” in TLS/SSL, che a sua volta è racchiuso in TCP/IP. In sostanza, i dati del protocollo dell'applicazione vengono trasmessi su TCP/IP, ma sono crittografati. E solo la macchina che ha stabilito la connessione può decrittografare i dati trasmessi. Per tutti gli altri che ricevono i pacchetti trasmessi, queste informazioni saranno prive di significato se non riescono a decrittografarle.
La connessione viene stabilita in più fasi:
1) Il client stabilisce una connessione al server e richiede una connessione sicura. Ciò può essere ottenuto stabilendo una connessione a una porta inizialmente prevista per funzionare con SSL/TLS, ad esempio 443, oppure richiedendo inoltre al client di stabilire una connessione sicura dopo averne stabilita una normale.
2) Quando si stabilisce una connessione, il client fornisce un elenco di algoritmi di crittografia che "conosce". Il server controlla la lista ricevuta con l'elenco degli algoritmi che il server stesso “conosce” e seleziona l'algoritmo più affidabile, dopodiché comunica al client quale algoritmo utilizzare
3) Il server invia al client il suo certificato digitale, firmato dall'autorità di certificazione, e la chiave pubblica del server.
4) Il client può contattare il server dell'autorità di certificazione attendibile che ha firmato il certificato del server e verificare se il certificato del server è valido. Ma forse no. Di solito nel sistema operativo sono già installati i certificati root delle autorità di certificazione, sui quali vengono verificate le firme dei certificati del server, ad esempio, dai browser.
5) Viene generata una chiave di sessione per una connessione sicura. Questo viene fatto come segue:
— Il client genera una sequenza digitale casuale
— Il client lo crittografa con la chiave pubblica del server e invia il risultato al server
— Il server decodifica la sequenza ricevuta utilizzando la chiave privata
Dato che l'algoritmo di crittografia è asimmetrico, solo il server può decrittografare la sequenza. Quando si utilizza la crittografia asimmetrica, vengono utilizzate due chiavi: privata e pubblica. Un messaggio inviato pubblicamente viene crittografato, mentre un messaggio inviato privatamente viene decrittografato. È impossibile decrittografare un messaggio se si dispone di una chiave pubblica.
6) Questo stabilisce una connessione crittografata. I dati trasmessi su di esso vengono crittografati e decrittografati fino al termine della connessione.
Certificato di radice
Appena sopra ho menzionato il certificato radice. Si tratta di un certificato del centro di autorizzazione, la cui firma conferma che il certificato firmato è quello appartenente al servizio corrispondente. Il certificato stesso di solito contiene una serie di campi informativi che contengono informazioni sul nome del server a cui è stato emesso il certificato e sul periodo di validità di questo certificato. Se il certificato è scaduto, viene invalidato.
Richiesta di firma (CSR, richiesta di firma del certificato)
Per ottenere un certificato del server firmato è necessario generare una richiesta di firma (CSR, Certificate Sign Request) ed inviare tale richiesta al centro autorizzazioni, il quale restituirà un certificato firmato installato direttamente sul server, di seguito vedremo come fare in pratica. Innanzitutto viene generata una chiave di crittografia, quindi, sulla base di questa chiave, viene generata una richiesta di firma, un file CSR.
Certificato cliente
È possibile generare un certificato client sia per l'utilizzo del dispositivo che per quello dell'utente. In genere, tali certificati vengono utilizzati nella verifica bidirezionale, in cui il client verifica che il server è chi dice di essere e il server fa lo stesso in cambio. Questa interazione è chiamata autenticazione bidirezionale o autenticazione reciproca. L'autenticazione bidirezionale migliora il livello di sicurezza rispetto all'autenticazione unidirezionale e può anche sostituire l'autenticazione tramite login e password.
Catena di azioni per la generazione di certificati
Diamo uno sguardo pratico a come si verificano le azioni associate alla generazione dei certificati fin dall'inizio e nella pratica.
La prima cosa da fare è generare un certificato root. Il certificato radice è autofirmato. E poi altri certificati verranno firmati con questo certificato.
$ openssl genrsa -out root.key 2048 Generazione della chiave privata RSA in corso, modulo lungo 2048 bit .......+++ ....... ............... .........+++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Ti verrà chiesto di inserire le informazioni che verranno incorporate nella richiesta di certificato . Quello che stai per inserire è quello che viene chiamato Nome distinto o DN. Ci sono alcuni campi ma puoi lasciarne alcuni vuoti. Per alcuni campi ci sarà un valore predefinito. Se inserisci ".", il campo verrà lasciato vuoto. ----- Nome del paese (codice a 2 lettere): RU Nome dello stato o della provincia (nome completo) :N/A Nome della località (ad es. città) :San Pietroburgo Nome dell'organizzazione (ad es. azienda) :Nome dell'unità organizzativa della mia azienda (ad esempio, sezione): Nome comune del servizio IT (ad esempio, FQDN del server o il TUO nome): Indirizzo e-mail del certificato radice della mia azienda: [e-mail protetta] Inserisci i seguenti attributi "extra" da inviare con la richiesta di certificato Una password di verifica: Un nome aziendale opzionale: My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Firma ok oggetto=/C=RU/ST=N/A/L=San Pietroburgo/O=La mia azienda/OU=Servizio IT/CN=Certificato radice della mia azienda/ [e-mail protetta] Ottenere la chiave privata
Pertanto, abbiamo prima generato una chiave privata, poi una richiesta di firma, quindi abbiamo firmato la nostra richiesta con la nostra chiave e abbiamo ricevuto il nostro certificato digitale, rilasciato per 10 anni. Non è necessario inserire una password di verifica durante la generazione di un certificato.
La chiave privata DEVE essere conservata in un luogo sicuro; avendola potrai firmare qualsiasi certificato per tuo conto. E dal certificato root risultante può essere utilizzato per identificare che il certificato, ad esempio, del server è stato firmato da noi e non da qualcun altro. Queste sono le azioni che i centri di autorizzazione eseguono quando generano i propri certificati. Dopo aver creato il certificato radice, puoi iniziare a generare il certificato del server.
Visualizza le informazioni sul certificato
Il contenuto del certificato può essere visualizzato come segue:
$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=San Pietroburgo/O=La mia azienda/OU=Servizio IT/CN=Certificato root della mia azienda/ [e-mail protetta] notAfter=22 gennaio 11:49:41 2025 GMT
Vediamo chi ha emesso questo certificato e quando scade la sua data di scadenza.
Certificato del server
Per firmare un certificato per il server dobbiamo fare quanto segue:
1) Generare una chiave
2) Generare una richiesta di firma
3) Invia il file CSR al centro autorizzazioni o firmalo tu stesso
Un certificato server può includere la catena di certificati che firmano il certificato server, ma può anche essere archiviato in un file separato. In linea di principio, tutto sembra più o meno uguale a quando si genera un certificato radice
$ openssl genrsa -out server.key 2048 Generazione della chiave privata RSA, modulo lungo 2048 bit............................ ....... ............................................ . +++................................+++ e è 65537 (0x10001) $ openssl req -new -key server.key - out server .csr Ti verrà chiesto di inserire le informazioni che verranno incorporate nella richiesta di certificato. Quello che stai per inserire è quello che viene chiamato Nome distinto o DN. Ci sono alcuni campi ma puoi lasciarne alcuni vuoti. Per alcuni campi ci sarà un valore predefinito. Se inserisci ".", il campo verrà lasciato vuoto. ----- Nome del paese (codice a 2 lettere): RU Nome dello stato o della provincia (nome completo) :N/A Nome della località (ad es. città) :San Pietroburgo Nome dell'organizzazione (ad es. azienda) :Nome dell'unità organizzativa della mia azienda (ad esempio, sezione): Nome comune del servizio IT (ad esempio, FQDN del server o il TUO nome): www.miaazienda.com Indirizzo e-mail: [e-mail protetta] Inserisci i seguenti attributi "extra" da inviare con la richiesta di certificato Una password di verifica: Un nome aziendale opzionale: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem -days 365 Firma ok soggetto=/C=RU/ST=N/A/L=San Pietroburgo/O=My Company/OU=IT Service/CN=www.mycompany.com/ [e-mail protetta] Ottenere la chiave privata CA $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=San Pietroburgo/O=La mia azienda/OU=Servizio IT/CN =Certificato radice della mia azienda/ [e-mail protetta] oggetto= /C=RU/ST=N/A/L=San Pietroburgo/O=La mia azienda/OU=Servizio IT/CN=www.mycompany.com/emailAd [e-mail protetta] notAfter=25 gennaio 12:22:32 2016 GMT
In questo modo il certificato del server sarà firmato e sapremo quale organizzazione ha emesso questo certificato. Dopo la firma, il certificato finito può essere utilizzato per lo scopo previsto, ad esempio installato su un server web.
Installazione di un certificato SSL/TLS su un server con nginx
Per installare un certificato SSL/TLS sul server web nginx, è necessario seguire alcuni semplici passaggi:
1) Copiare i file .key e .pem sul server. Su sistemi operativi diversi, i certificati e le chiavi possono essere archiviati in directory diverse. In Debian, ad esempio, questa è la directory /etc/ssl/certs per i certificati e /etc/ssl/private per le chiavi. Su CentOS questo è /etc/pki/tls/certs e /etc/pki/tls/private
2) Scrivere le impostazioni necessarie nel file di configurazione per l'host. Questo è quello che dovrebbe apparire più o meno (solo un esempio):
Server ( ascolta 443; nome_server www.miaazienda.com; root html; indice indice.html indice.htm; ssl attivo; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 non è raccomandato!!! # È qui ad esempio solo 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) Riavvia nginx
4) Vai alla porta del server 443 con un browser - https://www.mycompany.com e verificane la funzionalità.
Installazione di un certificato SSL/TLS su un server che esegue Apache
L'installazione di un certificato SSL/TLS su Apache è simile.
1) Copiare i file della chiave e del certificato sul server nelle directory appropriate
2) Abilitare il modulo ssl per Apache con il comando “a2enmod ssl” se non è già abilitato
3) Crea un host virtuale che ascolterà la porta 443. La configurazione sarà simile a questa:
Allo stesso tempo, c’è qualcos’altro che deve essere fatto. Trovare nel file httpd.conf, o apache2.conf, o ports.conf, a seconda del sistema, la seguente sezione della configurazione:
Se non esiste tale condizione, deve essere aggiunta al file config. E ancora una cosa: devi aggiungere la linea
NomeVirtualHost *:443
Questa riga potrebbe trovarsi nel file httpd.conf, apache2.conf o ports.conf
4) Riavviare il server web Apache
Creazione di un certificato client
Un certificato client viene creato più o meno allo stesso modo di un certificato server.
$ openssl genrsa -out client.key 2048 Generazione della chiave privata RSA, modulo lungo 2048 bit..............................+++ ..... ...............................................+++ e è 65537 (0x10001) $ openssl req -new -key client.key -out client.csr Ti verrà chiesto di inserire le informazioni che verranno incorporate nella richiesta di certificato. Quello che stai per inserire è quello che viene chiamato Nome distinto o DN. Ci sono alcuni campi ma puoi lasciarne alcuni vuoti. Per alcuni campi ci sarà un valore predefinito. Se inserisci ".", il campo verrà lasciato vuoto. ----- Nome del paese (codice a 2 lettere) :RU Nome dello stato o della provincia (nome completo) :San Pietroburgo Nome della località (ad es. città) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Ti verrà chiesto di inserire le informazioni che verranno incorporate nella richiesta di certificato. Quello che stai per inserire è quello che viene chiamato Nome distinto o DN. Ci sono alcuni campi ma puoi lasciarne alcuni vuoti. Per alcuni campi ci sarà un valore predefinito. Se inserisci ".", il campo verrà lasciato vuoto. ----- Nome del paese (codice a 2 lettere) :RU Nome dello stato o della provincia (nome completo) :N/A Nome della località (ad es. città) :Saint-Petrersburg Nome dell'organizzazione (ad es. azienda) :Nome dell'unità organizzativa della mia azienda (ad esempio, sezione): Nome comune Engineering (ad esempio, FQDN del server o il TUO nome): Ivan Ivanov Indirizzo e-mail: [e-mail protetta] Inserisci i seguenti attributi "extra" da inviare con la richiesta di certificato Una password di verifica: Un nome aziendale opzionale: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -days 365 Firma ok soggetto=/C=RU/ST=N/A/L=San Pietroburgo/O=La mia azienda/OU=Ingegneria/CN=Ivan Ivanov/ [e-mail protetta] Ottenere la chiave privata CA $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=San Pietroburgo/O=La mia azienda/OU=Servizio IT/CN =Certificato radice della mia azienda/ [e-mail protetta] oggetto= /C=RU/ST=N/A/L=San Pietroburgo/O=La mia azienda/OU=Ingegneria/CN=Ivan Ivanov/email [e-mail protetta] notAfter=25 gennaio 13:17:15 2016 GMT
Se hai bisogno di un certificato client in formato PKCS12, crealo:
$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Inserisci la password di esportazione: Verifica - Inserisci la password di esportazione:
Ora puoi utilizzare il certificato client per lavorare con il nostro server.
Configurazione di nginx per utilizzare i certificati client
Molto spesso, come ho già detto, viene utilizzata l'autenticazione unidirezionale, di solito viene controllato solo il certificato del server. Vediamo come forzare il server web nginx a verificare il certificato del client. È necessario aggiungere opzioni alla sezione server per lavorare con i certificati client:
# Certificato(i) root con cui il client è firmato ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Opzioni possibili: attivo | spento | facoltativo | optional_no_ca ssl_verify_client opzionale; # Profondità di verifica della catena di certificati con cui è firmato il client ssl_verify_length 2;
Successivamente, è necessario riavviare le impostazioni o l'intero server e puoi verificare il funzionamento.
Configurazione di Apache per utilizzare i certificati client
Apache può anche essere configurato aggiungendo ulteriori opzioni alla sezione host virtuale:
# Directory contenente i certificati root per la verifica del client SSLCARevocationPath /etc/apache2/ssl.crl/ # o file contenente i certificati SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Opzione di verifica del client. Opzioni possibili: # none, optional, require e optional_no_ca SSLVerifyClient require # Visualizza la profondità della catena della firma. Predefinito 1 SSLVerifyDepth 2
Come puoi vedere, le opzioni sono più o meno le stesse di nginx, poiché il processo di verifica è organizzato in modo uniforme.
Ascolto delle informazioni sul certificato utilizzando openssl
Per testare il modo in cui il server interagisce con i certificati client, puoi verificare se la connessione è stabilita utilizzando TLS/SSL.
Lato server, iniziamo ad ascoltare sulla porta utilizzando openssl:
Openssl s_server -accept 443 -cert server.pem -key server.key -state
Lato client accediamo al server, ad esempio, con culr:
Ricciolo -k https://127.0.0.1:443
Nella console lato server è possibile osservare il processo di scambio di informazioni tra il server e il client.
Puoi anche utilizzare le opzioni -verify [profondità di verifica] e -Verify [profondità di verifica]. L'opzione minuscola richiede al cliente un certificato, ma non è tenuto a fornirne uno. In maiuscolo: se non viene fornito un certificato, si verificherà un errore. Iniziamo ad ascoltare dal lato server in questo modo:
Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3
Dal lato server l'errore appare così:
140203927217808:errore:140890C7:routine SSL:SSL3_GET_CLIENT_CERTIFICATE:il peer non ha restituito un certificato:s3_srvr.c:3287:
Dal lato client in questo modo:
Curl: (35) errore:14094410:routine SSL:SSL3_READ_BYTES:sslv3 avviso errore di handshake
Aggiungiamo un certificato e un nome di dominio sul lato client (puoi inserire il nome host per l'indirizzo 127.0.0.1 nel file /etc/hosts per verificare):
Ricciolo https://www.miaazienda.com:443 --cacert root.pem --cert client.pem --key client.key
Ora la connessione avrà successo e potrai installare il certificato del server sul server web, fornire il certificato del client al client e lavorare con loro.
Sicurezza
Quando si utilizza SSL/TLS, uno dei metodi principali è il metodo MITM (Man In The Middle). Questo metodo si basa sull'uso di un certificato del server e di una chiave su un nodo che ascolterà il traffico e decodificherà le informazioni scambiate tra il server e il client. Per organizzare l'ascolto è possibile utilizzare, ad esempio, il programma sslsniff. Pertanto, di solito è consigliabile archiviare il certificato radice e la chiave su una macchina non connessa alla rete; per firmare, portare le richieste di firma su una chiavetta USB, firmare e portare via anche quella. E, naturalmente, fai dei backup.
In termini generali, questo è il modo in cui vengono utilizzati i certificati digitali e i protocolli TLS e SSL. Se avete domande/aggiunte, scrivete nei commenti.
La voce è stata pubblicata dall'autore nella categoria contrassegnata con , .Posta navigazione
: 29 commenti
cl-service.com
È il cliente stesso a generare la CSR al momento dell'ordine di un certificato, dove il cliente decide anche di memorizzare la chiave privata; per emettere un certificato non abbiamo bisogno della chiave privata e il cliente non ce la fornisce in alcun modo. Naturalmente, se ciò accade su un normale server virtuale, anche gli amministratori con accesso root al server hanno accesso alle chiavi ivi archiviate.
- Benefattore.
L'argomento tette non viene trattato perché la tecnologia PKI descritta non ha nulla a che vedere con il titolo dell'argomento. Almeno per una buona ragione ho fornito collegamenti a RFC.
PS C'era una battuta su un cane e una pulce. - Benefattore.
Non volevo offenderti in nessun modo. Stavo cercando informazioni sulla differenza pratica tra SSl e TLS e il tuo collegamento è stato il primo su Google. Mi ha incuriosito il titolo dell'argomento. Va tutto bene, continua così!
- DrAibolit
Grazie per le tue spiegazioni approfondite sulla certificazione digitale. Sono nuovo a questo =)
Spero che tu possa chiarire la seguente domanda.
Poiché il tema delle frodi è molto sviluppato nel settore Internet, vorrei imparare a determinare da solo i "pidocchi" dei siti che visito (soprattutto dove ci sono contanti e pagamenti, investimenti, ecc.) e in base a questo determina il grado della mia fiducia (devo registrarmi spesso, lasciare dati personali, fare acquisti, transazioni, investimenti). Se ho capito bene, avere questa certificazione ti permette di fare una valutazione del genere. Beh, d’altronde ottenerlo non è un problema ed è addirittura gratis.
Come o con quale programma è possibile determinare se un sito web dispone di un certificato digitale? e preferibilmente la sua categoria, che viene assegnata quando un'autorità speciale emette SSL DV (il certificato viene emesso con verifica del solo dominio), SSL OV (con verifica dell'organizzazione), EV (con verifica estesa della persona giuridica). Molto probabilmente i siti fraudolenti non utilizzeranno l'ultima opzione di certificazione.
Sarei felice se mi dicessi altri modi per determinare l'affidabilità dei siti))- mnorin Autore del messaggio
Non ho ancora trovato alcun programma specifico per questi scopi, ma posso dare un paio di consigli al riguardo.
Puoi utilizzare, ad esempio, Chromium o Google Chrome. Prendiamo ad esempio il sito https://www.thawte.com/, un'azienda che si occupa proprio di certificati digitali.
La barra degli indirizzi conterrà il nome dell'azienda e un lucchetto verde. Ciò significa che l'organizzazione è verificata, questo è almeno SSL OV.
Se si fa clic sul lucchetto e nella finestra a discesa "Dettagli", quindi "Visualizza certificato", è possibile visualizzare le informazioni sul certificato. Per Thawte, il certificato è firmato dal seguente certificato: “thawte Extended Validation SHA256 SSL CA”, e anche il certificato per click.alfabank.ru è firmato da Thawte, ma con un certificato diverso. Si tratta di "thawte EV SSL CA - G3", ovvero hanno anche superato la convalida estesa.
Qualcosa come questo.
- mnorin Autore del messaggio
- Ruslan
Sezione "Come funzionano SSL e TLS", "Il client genera una sequenza digitale casuale".
Ero sicuro che il client generasse una sessione privata e, di conseguenza, chiavi pubbliche (che ovviamente hai chiamato “sequenza digitale”). La chiave pubblica viene passata al server e il server crittografa i pacchetti al client con la chiave pubblica della sessione del client.
Si prega di precisare.
- Novizio
L'articolo è molto utile! Ci sono anche esempi pratici =) Ma non ho capito una cosa: qual è la differenza tra un certificato root e un certificato server? oppure è la stessa cosa?
- Vitaly
Ciao.
L'hoster ha offerto un servizio: SSL per server virtuali. Ne abbiamo approfittato. Si è scoperto che per il terzo livello, ad es. Il certificato http://www.site.ru non è valido, solo per site.ru. Inoltre, i visitatori passano costantemente al protocollo https, indipendentemente dal fatto che visitino site.ru o http://www.site.ru. Naturalmente, nel secondo caso, il browser inizia a imprecare in modo straziante e il visitatore non arriva mai al sito.
Ma per coloro che sono riusciti ad accedere al sito, il sito ha iniziato a sembrare storto, parte del menu è scomparsa e alcune immagini nei risultati di ricerca hanno smesso di essere visualizzate da alcuni componenti.
Software VPN TLS continentale– un sistema per fornire un accesso remoto sicuro alle applicazioni web utilizzando algoritmi di crittografia GOST. Continent TLS VPN fornisce protezione crittografica del traffico HTTP a livello di sessione. Le informazioni vengono crittografate utilizzando l'algoritmo GOST 28147–89.
Identificazione e autenticazione degli utenti remoti
L'identificazione e l'autenticazione degli utenti vengono eseguite utilizzando certificati a chiave pubblica dello standard x.509v3 (GOST R 31.11–94, 34.10–2001). Continent TLS VPN controlla i certificati chiave rispetto agli elenchi di revoche di certificati (CRL). I certificati vengono emessi da un'autorità di certificazione esterna.
Se le procedure di autenticazione vengono completate con successo, la richiesta dell'utente viene reindirizzata tramite HTTP su una rete protetta al server web appropriato. In questo caso, identificatori speciali (identificatore client e identificatore IP) vengono aggiunti alla sessione HTTP di ciascun utente.
Protezione crittografica delle informazioni trasmesse
Continent TLS VPN fornisce protezione crittografica del traffico HTTP a livello di sessione. Le informazioni vengono crittografate utilizzando l'algoritmo GOST 28147–89. La funzione hash viene calcolata utilizzando l'algoritmo GOST R 34.11–94, GOST R 34.11–2012. La generazione e la verifica della firma elettronica vengono eseguite secondo l'algoritmo GOST R 34.10–2001, GOST R 34.10–2012.
Nascondere server protetti e traduzione di indirizzi
Continent TLS VPN filtra le richieste e trasmette gli indirizzi delle richieste ai server Web sulla rete aziendale. La traduzione degli indirizzi viene eseguita in conformità con le regole stabilite dall'amministratore di “Continent TLS VPN”.
Tolleranza ai guasti e scalabilità
Continent TLS VPN supporta il funzionamento in un design cluster ad alte prestazioni con bilanciamento del carico (bilanciatore del carico esterno). Una maggiore tolleranza agli errori si ottiene aggiungendo un nodo ridondante al cluster. Allo stesso tempo, l'espansione degli elementi del cluster di bilanciamento può essere effettuata illimitatamente. Il guasto di un elemento del cluster non porta a connessioni interrotte, poiché il carico è distribuito uniformemente tra gli elementi rimanenti.
Monitoraggio e registrazione degli eventi
In Continent TLS VPN, l'amministratore può sempre ottenere informazioni operative sullo stato attuale delle connessioni stabilite e statistiche sul suo funzionamento. Gli eventi di sicurezza delle informazioni vengono registrati sul server. Tutti gli eventi possono essere inviati a un server specificato in formato syslog per ulteriori analisi, il che rende l'integrazione con i sistemi SIEM il più semplice possibile.
Comodi strumenti di gestione
La combinazione di strumenti locali e remoti con un'interfaccia web e una comoda console di gestione grafica fornisce una configurazione flessibile di Continent TLS VPN in conformità con i requisiti delle politiche di sicurezza.
Protocolli supportati
Continent TLS VPN supporta i protocolli TLS v.1, TLS v.2.
Esperienza utente tramite qualsiasi browser web
Utilizzando l'applicazione Continent TLS VPN Client, gli utenti possono accedere alle risorse protette da qualsiasi browser web. Il client VPN Continent TLS è un proxy locale, intercetta il traffico del browser verso server Web protetti e lo inserisce in un tunnel http. Grazie a ciò, l'utente può lavorare con qualsiasi browser web installato sul suo dispositivo.
Utilizzando un client software intuitivo
Utilizzando un client software di facile utilizzo, è possibile utilizzare Continent TLS VPN Client o CryptoPro CSP versione 3.6.1 come client sul dispositivo dell'utente.
Per installare il software Continent TLS Client è necessario:
Figura 33. Finestra di avvio della procedura guidata di installazione del software “Continent TLS Client”.
Figura 34. Finestra del contratto di licenza per il software Continent TLS Client.
3. Seleziona la casella "Accetto i termini del contratto di licenza" e fai clic sul pulsante "Avanti". Sullo schermo verrà visualizzata una finestra in cui inserire la chiave di licenza fornita con il software Continent TLS Client su supporto cartaceo o elettronico.
Figura 35. Finestra per l'inserimento della chiave di licenza del software Continent TLS Client.
4. Immettere la chiave di licenza e fare clic su Avanti. Sullo schermo verrà visualizzata una finestra di dialogo per la selezione del percorso di installazione del software Continent TLS Client.
Figura 36. Finestra per la selezione del percorso di installazione del software Continent TLS Client.
5. Lasciare il percorso di installazione predefinito. Fare clic su "Avanti". Sullo schermo verrà visualizzata la finestra di dialogo "Avvia Configuratore".
Figura 37. Finestra di avvio per il configuratore del software Continent TLS Client.
6. Seleziona la casella di controllo "Esegui il configuratore al termine dell'installazione".
Figura 38. Finestra di preparazione per l'installazione del software Continent TLS Client.
8. Fare clic sul pulsante "Installa". Verrà avviata l'installazione del componente.
Figura 39. Processo di installazione del software Continent TLS Client.
9. Sullo schermo verrà visualizzata la finestra di dialogo delle impostazioni del software “Continent TLS Client”.
Figura 40. Configurazione del software Continent TLS Client.
Per configurare il software è necessario:
a) Nella sezione "Impostazioni client TLS continente", lasciare il valore "Porta" sul valore predefinito di 8080.
b) Nella sezione "Impostazioni server protetto", nel campo "Indirizzo", imposta il nome del server TLS: lk.budget.gov.ru.
c) Nella sezione “Impostazioni server protetto”, nel campo “Certificato”, specificare il file del certificato del server TLS copiato nella directory locale nella clausola 3.1 della presente Guida.
Figura 41. Configurazione del software Continent TLS Client. Selezione di un certificato.
d) Se la postazione di lavoro dell'utente non utilizza un server proxy esterno, fare clic sul pulsante "OK".
e) In caso contrario, indicare l'indirizzo e la porta del server proxy esterno dell'organizzazione utilizzato.
Figura 42. Configurazione del servizio software Continent TLS Client. Configurazione di un server proxy esterno.
f) Fare clic sul pulsante "OK".
10. Sullo schermo verrà visualizzata una finestra di dialogo per completare l'installazione del software Continent TLS Client.
Figura 43. Finestra di dialogo per completare l'installazione del software Continent TLS Client.
11. Fare clic sul pulsante "Fine".
12. Sullo schermo apparirà una finestra di dialogo sulla necessità di riavviare la workstation dell'utente.
Figura 44. Dialogo sulla necessità di riavviare la workstation dell'Utente.
13. Fare clic sul pulsante "No".
VPN TLS continentale- una soluzione certificata per proteggere l'accesso degli utenti remoti alle risorse protette.
Continent TLS VPN ha un'architettura client-server ed è composta dal CIPF “Continent TLS VPN Server”, installato ai margini del perimetro di rete, e dal client VPN del CIPF “Continent TLS VPN Client”, installato sui computer degli utenti remoti. “Continent TLS VPN Server” garantisce riservatezza, integrità e protezione imitativa delle informazioni trasmesse e svolge le seguenti funzioni:
- autenticazione dell'utente mediante certificati a chiave pubblica dello standard x.509v3 (GOST R 31.11–94, 34.10–2001);
- verifica del certificato utente rispetto all'elenco di revoche CRL;
- stabilire connessioni crittografate sicure utilizzando il protocollo HTTPS;
- richieste di trasmissione ai server Web della rete aziendale e altri.
Server VPN TLS continente IPC-3000F (S021), 2014
CIPF "Continent TLS VPN Client" è un servizio proxy locale trasparente che fornisce l'autenticazione reciproca con il server, l'instaurazione di una connessione sicura e lo scambio di dati crittografati con il server. È inoltre compatibile con la maggior parte dei browser Internet esistenti. Inoltre, gli utenti possono lavorare tramite il “Continent TLS VPN Server” senza installare il software client CIPF “Continent TLS VPN Client”. In questo caso, il computer dell’utente deve utilizzare il browser MS Internet Explorer con il provider di servizi di crittografia installato “CryptoPro CSP” (versione 3.6 o 3.9), che fornisce il supporto per gli algoritmi di crittografia GOST.
Il prodotto è destinato a:
- connettere in modo sicuro gli utenti a portali di servizi governativi, piattaforme di commercio elettronico, sistemi bancari su Internet o applicazioni aziendali tramite un browser web.
- protezione crittografica del traffico http durante la trasmissione di dati su canali aperti di reti pubbliche.
Caratteristiche principali
- Protezione crittografica
- L'utilizzo del protocollo TLS con crittografia secondo GOST 28147–89 garantisce una protezione affidabile del traffico HTTP a livello di trasporto
- Monitoraggio e registrazione degli eventi di sicurezza delle informazioni
- Ottenere informazioni operative sulle statistiche operative e sulle connessioni attuali del server “Continent TLS VPN”.
- Identificazione e autenticazione dell'utente
- Identificazione e autenticazione degli utenti mediante certificati a chiave pubblica dello standard x.509. Trasmissione dei dati di autenticazione dell'utente al server web.
- Collaborare con autorità di certificazione esterne (CA)
- Per creare certificati x.509, “Continent TLS VPN” utilizza la CA esterna “CryptoPro”
- Proxy trasparente del traffico HTTP
- Per accedere in modo sicuro al servizio web, l'utente deve semplicemente inserire l'indirizzo IP o il nome del dominio nella barra degli indirizzi del browser.
- Scalabilità e tolleranza agli errori
- Supporto per la modalità operativa in un cluster ad alte prestazioni con bilanciamento del carico (bilanciatore del carico esterno). Una maggiore tolleranza agli errori si ottiene aggiungendo un nodo ridondante al cluster.
Peculiarità
- Prestazioni elevate: fino a 20.000 connessioni simultanee per nodo (IPC-3000F).
- Compatibile con qualsiasi browser web.
- Facilità di gestione: tutte le impostazioni vengono eseguite dall'amministratore tramite un browser web.
- Scalabilità illimitata delle prestazioni: la capacità di combinarsi in un cluster ad alte prestazioni per ottenere prestazioni di oltre 100mila connessioni simultanee.
- Facilità di implementazione e funzionamento: una soluzione già pronta elimina la necessità di incorporare moduli crittografici nel server web e seguire la procedura per monitorare l'integrazione della protezione delle informazioni crittografiche.
- Facile integrazione con sistemi SIEM esterni.
Certificati
- Certificato FSTEC della Russia per il rispetto dei requisiti per l'assenza di non conformità al 4° livello di controllo. Viene utilizzato per proteggere AC fino alla classe 1G inclusa, ISPDn fino a UZ 1 inclusa e GIS fino alla classe 1 inclusa.
- Certificati del FSB russo “Continent TLS VPN Server” per la classe CIPF KS2 e “Continent TLS VPN Client” per la classe CIPF KS2 e KS1.
2018: Rilascio di "Continent TLS Server" versione 2.1
I clienti di Continent TLS Server 2.1 hanno potuto aggiornare centralmente la parte client del complesso sui computer degli utenti remoti. Inoltre, nella versione presentata, il sistema di licenza del prodotto è stato semplificato: per un cluster di più dispositivi è necessaria una sola licenza per il numero massimo di connessioni simultanee. Si è inoltre deciso di combinare le licenze per la connessione a un server proxy e le licenze per la connessione tramite tunnel TLS. Tutto ciò semplifica il funzionamento e la scelta dell'architettura della soluzione appropriata.
A partire da luglio 2018 “Continent TLS Server” 2.1 è stato presentato per la certificazione all’FSB russo. Dopo aver superato i test, il prodotto verrà certificato secondo le classi KS1 e KS2.
| Questa versione del prodotto Continent TLS Server è progettata per facilitare il lavoro degli amministratori durante il periodo di modifica degli standard di crittografia e fornire la possibilità di un comodo monitoraggio. Le modifiche alla politica di licenza e la possibilità di allocare una porta di gestione del prodotto separata dovrebbero ampliare l'ambito della sua applicazione. Il supporto per un'ampia gamma di client TLS ti consentirà di creare rapidamente un sistema di accesso sicuro a un'applicazione web in cui sono già utilizzati provider di crittografia di terze parti. Ora il nostro prodotto supporta "CryptoPro", "Validata" e il browser affidabile "Sputnik". |
2016
Un’elevata dinamica è stata dimostrata anche dai prodotti relativamente nuovi (rilasciati nel 2015) della linea “Continent” – “Continent TLS VPN” e lo switch crittografico “Continent”. Il loro volume di vendita ammontava a 71 milioni di rubli. e 62 milioni di rubli. rispettivamente. La richiesta di “Continent TLS VPN” è dovuta al crescente interesse dei clienti nell’uso degli algoritmi di crittografia russi per proteggere l’accesso ai portali governativi, nonché nell’organizzazione dell’accesso remoto sicuro utilizzando algoritmi GOST. Un fattore nella crescita delle vendite degli switch crittografici Continent è stata la necessità di proteggere i canali di comunicazione nei data center geograficamente distribuiti.
È stata rilasciata la versione tecnica “Continent TLS VPN” 1.0.9 con un portale applicativo
La società Security Code ha annunciato nell'aprile 2016 il rilascio di una versione tecnica della versione del prodotto “Continent TLS VPN”, progettata per fornire un accesso remoto sicuro ai sistemi informativi che trattano dati personali (ISPD) e ai sistemi informativi governativi (GIS). Il prodotto ha una serie di nuove funzionalità.
Uno dei cambiamenti più significativi in "VPN TLS continentale" 1.0.9è la creazione di un portale applicativo con la possibilità di autenticarsi e autorizzare utilizzando le credenziali di Active Directory. Questo miglioramento semplifica notevolmente il processo di gestione degli accessi ai servizi web aziendali per diverse categorie di utenti. Ad esempio, utilizzando un portale è possibile fornire un unico punto di accesso per i dipendenti dell'azienda e per i suoi collaboratori. In questo caso, l'insieme delle applicazioni disponibili dipenderà dalla categoria e dai diritti dell'utente.
Un'altra differenza è l'aggiunta della possibilità di creare una pagina iniziale del server, accessibile tramite il protocollo HTTP aperto. Ti consente di ridurre significativamente i costi di mantenimento di un'applicazione web sicura.
La versione 1.0.9 aggiunge anche la possibilità di far funzionare il prodotto in modalità tunnel TLS, che consente all'utente remoto di rimuovere le restrizioni sull'interazione attraverso un canale crittografato utilizzando il protocollo TLS. Tale connessione consente di fornire l'accesso non solo alle risorse web, ma anche ad altri tipi di applicazioni, ad esempio terminal server (tramite il protocollo RDP) o "thick client" per applicazioni aziendali (ERP, CRM, ecc.). Questo approccio aumenta significativamente il numero di scenari di accesso remoto in cui è possibile utilizzare la VPN Continent TLS.
Il "Codice di sicurezza" ha valutato i tempi del passaggio delle agenzie governative agli strumenti di crittografia russi
Il 16 luglio 2016, sul sito web del Cremlino è stato pubblicato l'ordine del presidente al capo del governo sulla necessità di preparare la transizione degli organi governativi all'uso degli algoritmi crittografici e degli strumenti di crittografia russi entro il 1 dicembre 2017. In particolare, il governo deve garantire lo sviluppo e l'attuazione di una serie di misure necessarie per una transizione graduale all'uso degli algoritmi crittografici e degli strumenti di crittografia russi, nonché fornire ai cittadini della Federazione Russa il libero accesso all'uso della crittografia russa utensili.
Il documento pubblicato comporterà alcuni passaggi per adeguare le infrastrutture informatiche degli enti pubblici ai requisiti stabiliti. In particolare, negli enti statali sono previste installazioni di massa di strumenti nazionali di protezione crittografica delle informazioni (CIPF) in aggiunta alle soluzioni esistenti.
Più dettagli:
- Legge Yarovaya (Sulle modifiche al codice penale e al codice di procedura penale della Federazione Russa riguardanti l'istituzione di misure aggiuntive contro il terrorismo)
Gli esperti del Codice di sicurezza notano che l'innovazione riguarderà soprattutto i portali dei servizi governativi dei dipartimenti federali e regionali. Allo stesso tempo, l'implementazione di questo compito riguarda due aspetti: l'implementazione di CIPF lato server web e lato utente. Se presupponiamo che gli utenti incorporino una libreria crittografica certificata nel browser, il problema può essere risolto lato server web in due modi.
Uno di questi è l’integrazione di CIPF nei server web, il secondo è l’implementazione di un complesso software e hardware (SHC) con l’implementazione di TLS VPN (uno di questi prodotti è il “Continent TLS VPN Server”, sviluppato dalla “ Codice di sicurezza"), che intercetta il traffico HTTP /HTTPS e lo crittografa secondo l'algoritmo di crittografia secondo GOST (28147-89). Ciascuna delle opzioni ha le sue caratteristiche, sia dal punto di vista dell'implementazione tecnica che dal punto di vista dei tempi del progetto.
Secondo gli analisti di Security Code, nel primo caso (embedding), le fasi di lavoro saranno le seguenti:
- Sviluppo della documentazione organizzativa e amministrativa (ORD) - 2 mesi;
- Attuazione - 0,5 mesi;
- Monitoraggio dell'integrazione del CIPF nell'FSB della Russia - 7 mesi;
Di conseguenza, tale progetto può essere completato entro 1 anno.
Scegliendo l'opzione di installazione PAC, il progetto sarà suddiviso nelle seguenti fasi:
- Sviluppo della documentazione operativa - 2 mesi;
- Condurre un concorso pubblico sotto 44-FZ - 2,5 mesi;
- Fornitura di attrezzature e software - 1,5 mesi;
- Attuazione: 0,5 mesi.
La durata totale del progetto in questo caso sarà di circa 7 mesi.
Gli esperti del Codice di sicurezza notano che, secondo la pratica generalmente accettata, tra l'emanazione delle istruzioni al governo e l'inizio dei lavori da parte delle aziende sui progetti passano almeno tre mesi (tenendo conto della necessità di elaborare e adottare statuti). Di conseguenza, esiste il rischio che le organizzazioni che scelgono l'opzione di incorporare il CIPF nei server web abbiano difficoltà a rispettare le scadenze fissate dal presidente. E se l’adozione dello statuto viene ritardata per più di tre mesi, i termini di attuazione potrebbero non essere rispettati.
“Oltre alle difficoltà legate alla tempistica, il primo percorso - l'inclusione - è associato ad altre difficoltà. Si tratta di costi di manodopera aggiuntivi, prima per preparare e approvare un pacchetto di documenti per il laboratorio di prova, quindi per apportare modifiche al codice ed eseguire il debug dell'applicazione in base ai risultati dell'analisi del laboratorio di prova. Ma il vantaggio principale della seconda opzione è che, scegliendo un PAK, il cliente riceve una soluzione industriale potente e ad alte prestazioni progettata per le grandi organizzazioni. È scalabile, facile da gestire, compatibile con qualsiasi browser Internet e si integra facilmente con i sistemi SIEM esterni", ha affermato Pavel Korostelev, responsabile marketing del prodotto presso Code Security.
Tenendo conto di quanto sopra, il “Codice di sicurezza” raccomanda ai clienti governativi di scegliere l’algoritmo ottimale per conformarsi ai requisiti legali e di seguire il percorso di implementazione di un sistema software e hardware (SHC) con l’implementazione della VPN TLS. Per l'accesso sicuro degli utenti remoti alle risorse web, viene utilizzato il complesso software e hardware "Continent TLS VPN" certificato dall'FSB russo. È facile da implementare, dispone di un client TLS gratuito per gli utenti finali e può supportare oltre 100.000 connessioni simultanee.
Russia del 30 luglio 2015 SF/124–2676 sul CIPF “Continent TLS VPN Server” e SF/525-2677, SF/525-2678 sul CIPF “Continent TLS VPN Client” (versione 1 e 2) confermano la conformità con i requisiti del FSB Russia per i mezzi di crittografia (crittografici) di classe KS2 e KS1. I certificati dell’FSB russo autorizzano l’uso del CIPF “Continent TLS VPN” per la protezione crittografica delle informazioni che non contengono informazioni che costituiscono un segreto di stato.
Il certificato FSTEC della Russia n. 3286, rilasciato il 2 dicembre 2014 per il CIPF “Continent TLS VPN Server”, conferma la conformità del prodotto ai requisiti delle linee guida per il 4° livello di controllo per l'assenza di non conformità con non- conformità e ne consente l'utilizzo nella realizzazione di sistemi fino alla classe di sicurezza 1G inclusa e per la protezione delle informazioni in ISPDn e GIS fino al 1° grado compreso.
