9 Manuale - Connessioni

9.1 Il comando s_client

Nome

s_client - programma client SSL/TLS.

Sintassi

Openssl s_client[-connect host:port][-verify depht][-cert filename][-key filename][-Capath directory][-Cafile filename][-reconnect][-pause][-showcerts][-debug][-nbio_test][-state][-nbio][-crlf][-ign_eof][-quiet][-ssl2][ssl3][-tls1][-no_ssl2][-no_ssl3][-no_tls1][-bugs][-cipher cipherlist][-engine id][-rand file(s)]

Descrizione

Il comando s_client implementa un generico client SSL/TLS che si connette a un remoto host usando SSL/TLS. E’ uno strumento diagnostico molto utile per i servers SSL.

Opzioni del comando

  • -connect host:port: questa opzione specifica l’host e la porta opzionale per connettersi. Se non è specificata allora viene fatto un tentativo per connettere l’host locale sulla porta 4433.

  • -cert certame: ll certificato da usare, se ne è richiesto uno dal server. Per default non si usa il certficato.

  • -key keyfile: la chiave privata da usare. Se non è specificato allora sarà usato il file del certificato.

  • -verify depht: il livello di verifica da usare. Essa specifica la massima lunghezza della catena dei certificati del server e restituisce la verifica del certificato del server. Correntemente l’operazione di verifica continua dopo gli errori così tutti i problemi con una catena di certificati possono essere visti. Come effetto collaterale la connessione non fallirà mai a causa di fallimenti nella verifica del certificato del server.

  • -CApath directory: la directory da usare per la verifica del certificato del server. Questa directory deve essere in formato hash, vedi verifica per maggiori informazioni. Questa viene anche usata per la costruzione di una catena di certificati del client.

  • -CAfile file: un file contenente certificati fidati da usare durante l’autenticazione del server e da usare quando si tenta di costruire la catena di certificati del client.

  • -reconnect: riconnette allo stesso server 5 volte usando lo stesso ID di sessione, questo potrebbe essere usato per testare se una sessione sta lavorando.

  • -pause: si arresta un secondo tra ogni chiamata di lettura e scrittura.

  • -showcerts: visualizza l’intera catena di certificati del server: normalmente solo il certificato del server stesso è visualizzato.

  • -prexit: visualizza le informazioni sulla sessione quando il programma esce. Questa opzione tenterà sempre di stampare le informazioni anche se la connessione fallisce. Normalmente le informazioni saranno visualizzate una sola volta se la connessione ha successo. Quest’opzione è utile poiché il cifrario in uso può essere rinegoziato o la connessione può fallire poiché il certificato di un client è richiesto o è richiesto solo dopo che è fatto un tentativo di accedere a un certo URL. Note: l’output prodotto da quest’opzione non è sempre esatto poiché una connessione potrebbe non essere stata stabilita.

  • -state: visualizza lo stato della sessione SSL.

  • -debug: stampa le informazioni estese di debugging includendo in formato esadecimale il dump di tutto il traffico.

  • -nbio_test: testa il non-blocking I/O.

  • -nbio: abilita il non-blocking I/O.

  • -crlf: quest’opzione traduce un line feed dal terminale in un CR+LF come richiesto da qualche server.

  • -ign_eof: inibisce la chiusura della connessione quando la fine del file è raggiunta dall’input.

  • -quiet: inibisce la visualizzazione delle informazioni sulla sessione e sul certificato. Questo implicitamente abilita anche –ign_eof

  • -ssl2,-ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1: queste opzioni disabilitano l’uso di un certo protocollo SSL o TLS. Per default l’Handshake iniziale usa un metodo che dovrebbe essere compatibile con tutti i server e permette loro di usare SSL v3, SSL v2 o TLS come appropriato. Sfortunatamente ci sono molti server antichi e rotti in uso che non possono trattare questa tecnica e falliranno nella connessione. Alcuni server lavorano solo se TLS è abilitato con l’opzione –no_tls altri supporteranno solo SSL v2 e possono aver bisogno dell’opzione –ssl2.

  • -bugs: ci sono molti bug noti nelle implementazioni SSL e TLS. Aggiungendo quest’opzione si abilitano diversi banchi di lavoro.

  • -cipher cipherlist: questa permette di cambiare la lista dei cifrari spedita dal client. Sebbene il server determina quale cipher suite è usato esso dovrebbe prendere il primo cifrario supportato nella lista spedita dal client. Vedere il comando ciphers per maggiorni informazioni.

  • -engine id: specificando un’engine (dalla sua unica stringa di id) l’s_client tenterà di ottenere un referimento funzionale all’engine specificato, inizializzandolo se necessario. L’engine allora sarà settata come di default per tutti gli algoritmi disponibili.

  • -rand file(s): un file o più files contenenti dati casuali usati per inizializzare il generatore di numeri casuali, o un socket EGD (vedi RAND_egd(3)). Files multipli possono essere specificati separati da un carattere dipendente dal SO. Il separatore è ‘ ; ‘ per Windows, la ‘ , ‘ per Open VMS e ‘ : ‘ per utti gli altri.

    • Comandi di connessione

    Se viene stabilita una connessione con un server SSL tutti i dati ricevuti dal server vengono visualizzati e ogni tasto premuto sarà inviato al server. Quando viene usato interattivamente (che significa né –quiet e né –ign_eof sono stati settati), la sessione sara rinegoziata se la linea comincia con una R e se la linea comincia con una Q o viene ragginuta la fine del file, la connessione sarà chiusa.

    Note

    s_client può essere usato come debug per il server SSL. Per connettersi a un server SSL HTTP tipicamente sarà usato il comando(https usa la porta 443):

    Se la connessione ha successo allora il comando http può essere preso come un ‘GET/’ per ritrovare una pagina web.
    Se l’handshake fallisce allora ci sono molte possibili cause; se la causa non è ovvia (come nel caso di mancanza del certificato del client), allora possono essere tentati i comandi –bugs, -ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -no_tls1, nel caso in cui si tratta di un errore del server. In particolare si potrebbe giocare con queste opzioni prima di sottoporre un referto di bug a una mailing list OpenSSL.
    Un problema frequente quando si tenta di ottenere un certificato del client è che un web client non ha un certificato o fornisce una lista vuota da cui scegliere. Questo è ciò che avviene normalmente perché il server non sta spedendo l’Autorità di Certificatzione dei client nella sua lista delle CA accettabili quando esso richiede un certificato. Usando s_client la lista CA può essere vista e controllata. Comunque alcuni server richiedono solo l’autenticazione del client dopo che uno specifico URL è richiesto. Per ottenere la lista in questo caso è necessario usare il comando –prexit e spedire una richiesta http per una pagina appropriata.
    Se un certificato è specificato sulla linea di comando usando l’opzione –cert, esso non sarà usato a meno che il server non richiede esplicitamente il certificato del client. Pertanto includendo semplicemente un certificato del client sulla linea di comando non è garantito che il certificato lavori.
    Se ci sono problemi verificando il certificato di un server allora l’opzione –showcerts può essere utilizzata per mostrare tutta la catena.

    Bugs

    Poichè questo programma ha molte opzioni ed anche perchè alcune delle tecniche usate sono piuttosto vecchie, il sorgente C di s_client è piuttosto difficile da leggere e non è un modello di come le cose dovrebbero essere fatte. Un tipico programma SSL client potrebbe essere molto semplice.
    L’opzione –verify dovrebbe realmente uscire se le verifiche del server fallissero.
    L’opzione –prexit è un bit di un hack. Si dovrebbero riportare informazioni ogni qual volta una sessione viene rinegoziata.

    Vedi anche

    sess_id(1), s_server(1), ciphers(1)

    9.2 Il comando s_server

    Nome

    s_server - programma server SSL/TLS.

    Sintassi

    openssl s_server [-accept port] [-context id] [-verify depth] [-Verify depth] [-cert filename] [-key keyfile] [-dcert filename] [-dkey keyfile] [-dhparam filename] [-nbio] [-nbio_test] [-crlf] [-debug] [-state] [-CApath directory] [-CAfile filename] [-nocert] [-cipher cipherlist] [-quiet] [-no_tmp_rsa] [-ssl2] [-ssl3] [-tls1] [-no_ssl2] [-no_ssl3] [-no_tls1] [-no_dhe] [-bugs] [-hack] [-www] [-WWW] [-HTTP] [-engine id] [-rand file(s)]

    Descrizione

    Il comando s_server implementa un server generico SSL/TLS che ascolta una connessione su una data porta usando SSL/TLS.

    Opzioni del comando

  • -accept port: la porta TCP da ascoltare per le connessioni. Se non specificata è usata la porta 4433.

  • -context id: setta il context id di SSL. Esso può essere indicato tramite una qualsiasi stringa del valore. Se questa opzione non è presente sarà usato un valore di default.

  • -cert certame: il certificato da usare, molte cipher suites di server richiedono l’uso di un certificato e alcune richiedono un certificato con una chiave pubblica di un certo tipo: per esempio le cipher suites DSS richiedono un certificato contenete una chiave DSS (DSA). Se non specificato viene usato il file “server.pem”

  • -key keyfile: chiave privata da usare. Se non specificato allora sarà usato il file del certificato.

  • -decert filename , -dkey keyname: specificano un certificato e una chiave privata aggiuntive, questi si comporteranno nello stesso modo dell’opzione –cert e -key eccetto per il fatto che non vengono usati valori di default se esse non sono specificate (non sono usati certificati e chiavi aggiuntive). Come notato in precedenza, molte cipher suites richiedono un certificato contenente una chiave di un certo tipo. Alcune cipher suites hanno bisogno di un cifrario che porti una chiave RSA e altri una chiave DSS. Usando certificati e chiavi RSA e DSS, un server può supportare client che supportano solo cipher suites RSA e DSS usando un appropriato certificato.

  • -nocert: se questa opzione è settata allora non è usato nessun certificato. Ciò costringe ad utilizzare solo le cipher suites anonime (attualmente solo la DH anonima).

  • -dhparam filename: il file dei parametri DH da usare. La cipher suite DH effimera genera le chiavi usando un insieme di parametri DH. Se non specificato allora viene fatto un tentativo di caricare i parametri dal file del certificato del server. Se questo fallisce, allora sarà usato un insieme statico di parametri codificati in modo robusto nel programma s_server.

  • -no_dhe: se questa opzione è settata allora nessun parametro DH sarà effettivamente caricato disabilitato la cipher suite DH.

  • -no_tmp_rsa: alcune export cipher suites usano talvolta una chiavei temporanea RSA; questa opzione disabilita la generazione di chiavi temporaneeRSA.

  • -verify depth, -Verify depth: il livello di verifica da usare. Questo specifica la lunghezza massima della catena dei cerificati del client e invia una richiesta di certificato da parte del server al client. Con l’opzione –verify un certificato viene richiesto, ma il client non ne ha alcuno da spedire, con l’opzione –Verify il client deve fornire un certificato altrimenti si avrà un errore.

  • -CApath directory: directory da usare per la verifica del certificato del client. Questa directory deve essere in formato hash. Vedere verify per ulteriori informazioni. Queste sono usate anche quando si costruisce la catena dei certificati del server.

  • -CAfile file: un file contenente certificati fidati usati durante l’autenticazione del client e da usare quando si cerca di costruire la catena dei certificati del server. La lista è usata anche nella lista dei clienti accettabili dal CA passata al client quando è richiesto un certificato.

  • -state: visualizza lo stato della sessione SSL.

  • -debug: stampa informazioni dettagliate sul debugging includendo un dump esadecimale di tutto il traffico.

  • -nbio_test: testa l’I/O non blocking.

  • -nbio: abilita l’I/O non blocking.

  • -crlf: questa opzione traduce un line feed del terminale in CR+LF.

  • -quiet: inibisce la stampa delle informazioni sulla sessione e sul certificato.

  • -ssl2, -ssl3, -tls1, -no_ssl2, -no_ssl3, -notls1: queste opzioni disabilitano l’uso di alcuni protocolli SSL o TLS. Per default l’handshake iniziale usa un metodo che dovrebbe essere compatibile con tutti i server e permettere a loro di usare SSL v3, SSL v2 o TLS.

  • -bugs: ci sono molti errori conosciuti nelle implementazioni SSL o TLS. Aggiungendo questa opzione si abilitano vari workarounds.

  • -hack: questa opzione abilita un ulteriore workaround per alcune versioni vecchie di codice Netscape SSL.

  • -cipher cipherlist: questa opzione consente di modificare la lista dei cifrari usata dal server. Quando il client spedisce una lista di cifrari supportati, viene usato il primo cifrario del client incluso anche nella lista del server. Poiché il client specifica l’ordine di preferenza, l’ordine della lista dei cifrari del server è irrilevante. Vedere il comando ciphers per ulteriori informazioni.

  • -www: spedisce un messaggio di stato di ritorno al client quando si connette. Questo include molte informazioni riguardanti i cifrari usati e i parametri delle varie sessioni. L’output è in formato HTML così questa opzione sarà normalmente usata con un browser web.

  • -WWW: emula un semplice sever WEB. Le pagine saranno risolte relativamente alla directory corrente, per esempio se viene richiesto l’URL https://myhost/page.html verrà caricato il file ./page.html.

  • -HTTP: emula un semplice server web. Le pagine saranno risolte relativamente alla directory corrente, per esempio se è richiesto L’URL https://myhost/page.html sarà caricato il file ./page.html. Si assume che i file caricati contengono una risposta http corretta e completa (le linee che sono parte della linea di risposta http e le intestazioni devono terminare con CRLF).

  • -engine id: specificando un engine (attraverso la sua unica string di id) l’s_server cercherà di ottenere un riferimento funzionale all’engine specificato, inizializzandolo se è necessario. L’engine sarà settato come quello di default per tutti gli algoritmi disponibili.

  • -rand file(s): un file o più file contenenti dati casuali usati per inizializzare il generatore dei numeri casuali, oppure un socket EGD (vedere RAND _egd(3)). File multipli possono essere specificati separandoli con un carattere dipendente dal SO. Il separatore è ‘;’ per MS-Windows, ‘, ‘per Open VMS, e ‘:‘ per tutti gli altri.

    • Comandi di connessione

    Se una connessione richiesta è stabilita con un client SSL e non è usata ne l’opzione –www ne –WWW allora normalmente ogni dato ricevuto dal client viene visualizzato e ogni tasto digitato sarà inviato al client.
    Vengono anche riconosciuti alcuni comandi formati da una singola lettera che eseguono operazioni speciali: questi sono elencati di seguito:

  • q termina la connessione corrente di SSL ma accetta ancora

  • Q Termina la connessione corrente di SSL ed esce.

  • r rinegozia la sessione SSL.

  • R rinegozia la sessione SSL e richiede un certificato client.

  • P invia alcuni testi in chiaro alla sottostante connessione TCP: questo potrebbe causare al client la disconnessione dovuta a una violazione del protocollo.

  • S stampa alcune informazioni sullo stato della cache delle sessioni.

    • Note

    S_server può essere usato per il debug del client SSL. Per accettare la connessione da un browser web può essere usato per esempio il comando:

    Molti web browser (in particolare Netscape e MSIE) supportano solo RSA cipher suites, così che non possono connettersi ai server che non usano un certificato avente una chiave RSA oppure una versione di OpenSSL con RSA disabilitato.
    Sebbene lo specificare una lista vuota di CA quando è richiesto un certificato del client è, strettamente parlando, una violazione di protocollo, alcuni client SSL interpretano ciò come se indicasse che qualsiasi CA è accettabile.Ciò è utile per scopi di debugging.
    I parametri di sessione possono essere stampati usando il programma sess_id.

    Bugs

    Poiché questo programma ha molte opzioni e anche perchè alcune delle tecniche usate sono piuttosto vecchie, il sorgente C del s_server è piuttosto difficile da leggere e non è un modello di come le cose dovrebbero essere fatte. Un tipico programma SSL server dovrebbe essere più semplice.
    L’output di un comune cifrario è inesatto: esso fornisce soltanto la lista dei cifrari che OpenSSL riconosce e che il client supporta.
    Ci dovrebbe essere un modo per il programma s_server di stampare i dettagli di ogni cipher suites sconosciuto che un client dice di supportare.

    Vedi anche

    sess_id (1), s_client(1), ciphers(1).

    9.3 Il comando sess_id

    Nome

    sess_id - utility per trattare la sessione SSL/TLS.

    Sintassi

    openssl sess_id [-inform PEM|DER][-outform PEM|DER][-in filename][-out filename] [-text][-noout][-context ID]

    Descrizione

    Il comando sess_id elabora la versione codificata della struttura della sessione SSL e opzionalmente stampa i dettagli della sessione SSL ( per esempio la sessione SSL master key) in formato leggibile.
    Poiché questo è un tool diagnostico che necessita alcune conoscenze del protocollo SSL per essere usato in modo appropriato, molti utenti non hanno bisogno di utilizzarlo.

    Opzioni del comando

  • -inform DER|PEM: questa specifica il formato di input. L’opzione DER usa un formato codificato ASN1 DER contienente i dettagli della sessione. Il formato preciso può variare da una versione all’altra. Il PEM è il formato di default: esso consiste del formato DER codificato base64 con intestazioni e linee di chiusura addizionali.

  • -outform DER|PEM: specifica il formato di output, le opzioni hanno lo stesso significato dell’opzione -inform.

  • -in filename: specifica il filename di input da cui leggere le informazioni della sessione o lo standard input per default.

  • -out filename: specifica il filename di output dove scrivere le informazioni della sessione o se questa opzione non è specificata lo standard output.

  • -text: stampa le varie componenti della chiave publica e privata nel testo in chiaro in aggiunta alla versione codificata.

  • -cert: se un certificato è presente nella sessione può essere messo in output usando questa opzione, se è presente anche l’opzione –text esso sarà stampato in formato testo.

  • -noout: questa opzione impedisce l’output della versione codificata della sessione.

  • -context ID: questa opzione può settare l’ID della sessione in modo tale che l’output delle informazioni sulla sessione usi l’ID fornito.L’ID può essere una qualsiasi stringa di caratteri. Questa opzione normalmente è usata per consuetudine.

    • OUTPUT

  • Output tipico:

    • SSL-Session:

    Queste sono descritte di seguito più dettagliatamente.

  • Protocol: Questo è il protocollo in uso TLSv1, SSLv3 o SSLv2.

  • Cipher: Questo è il cifrario usato nell’attuale codice cifrario di SSL o TLS, vedi le specifiche SSL o TLS per maggiori informazioni.

  • Session-ID: La sessione ID del SSL nel formato esadecimale.

  • Session-ID-ctx: La sessione ID context nel formato esadecimale.

  • Master_key: Questa è la master key della sessione SSL.

  • Key-arg: L’argomento key, questo è usato solo nel SSLv2.

  • Start Time: Questa è lo start time della sessione rappresentato come un intero nel formato Unix standard.

  • Timeout: Il timeout in secondi.

  • Verify return code: Questo è il codice restituito quando il certificato di un client SSL è verificato.

    • Note

    IL formato della sessione codificata PEM usa le linee di intestazione e di chiusura:

    Poiché l’output della sessione SSL contiene la master key è possibile leggere il contenuto di una sessione codificata usando questa informazione. Di conseguenza le appropriate precauzioni sulla sicurezza dovrebbero essere prese se l’informazione è stata data in output da un’applicazione reale.
    Questo è ,comunque , fortemente scoraggiato e potrebbe essere usato per scopi di debugging.

    Bugs

    Il cifrario e il tempo di inizio dovrebbe essere in un formato leggibile.

    Vedi anche

    ciphers(1), s_server(1)

    9.4 Il comando smime

    Nome

    smime - S/MIME utility

    Sintassi

    openssl smime [-encrypt] [-decrypt] [-sign] [-verify] [-pk7out] [-des] [-des3] [-rc2-40] [-rc2-64] [-rc2-128] [-in file] [-certfile file] [-signer file] [-recip file] [-in file] [-inform SMIME|PEM|DER] [-passin arg] [-inkey file] [-out file] [-outform SMIME|PEM|DER] [-content file] [-to addr] [-from ad] [-subject s] [-text] [-rand file(s)] [cert.pem]...

    Descrizione

    Il comando smime si occupa della S/MINE mail. Esso può cifrare, decifrare, firmare e verificare i messaggi S/MIME.

    Opzioni di comando

    Ci sono cinque opzioni operative che settano il tipo di operazione che si vuole realizzare.Lo scopo delle altre opzioni varia in accordo con il tipo di operazione.

  • -encrypt: cifra la posta per i certificati dei destinatari. Il file di input è il messaggio da cifrare. Il file di output è la posta cifrata nel formato MIME.

  • -decrypt: decifra la posta usando il certificato e la chiave privata forniti. Richiede un messaggio di posta cifrato nel formato MIME come file di input. La posta decifrata viene scritta nel file di output.

  • -sign: firma la posta utilizzando il certificato e la chiave privata forniti. Il file di input è il messaggio che deve essere firmato. Il messaggio firmato , in formato MIME, viene scritto in un file di output.

  • -verify: verifica la posta firmata. Richiede un messaggio di posta firmato come file di input e restituisce in output i dati firmati. Sono supportati sia clear text e opaque signing.

  • -pk7out: prende come input un messaggio e restituisce una struttura PKCS#7 codificata in formato PEM.

  • -in filename: il messaggio di input che si vuole criptare, firmare, o il messaggio MIME che si vuole decriptare o verificare.

  • -inform SMIME|PEM|DER: questa opzione specifica il formato dell’input per la struttura PKCS#7.Il default è SMIME che legge un messaggio nel formato S/MIME. I formati PEM e DER ,invece, cambiano il messaggio nei formati PEM e DER per la struttura PKCS#7. Ciò ha effetto solo se il file di input è nel formato della struttura PKCS#7, se nessuna struttura PKCS#7 è data come input (per esempio con –encrypt o –sign) questa opzione non ha effetto.

  • -out filename: il messaggio di testo che è stato decifrato o verificato o il messaggio di output nel formato MIME che è stato firmato o verificato.

  • -outform SMIME|PEM|DER: questa opzione specifica il formato dell’output per la struttura PKCS#7. Per default è SMIME che scrive un messaggio nel formato S/MIME. I formati PEM e DER lo cambiano,invece, per scrivere la struttura PKCS#7 nei formati PEM e DER. Ciò ha effetto solo se il formato del output è una struttura PKCS#7, se non esiste un struttura PKCS#7 come output ( per esempio con –verify o – decrypt) questa opzione non ha alcuno effetto.

  • -content filename: questa specifica un file il cui contenuto è separato e viene utilizzata solo con il comando –verify.È utilizzabile solo se la struttura PKCS#7 utilizza la firma nella forma separata dove il contenuto non è incluso.Questa opzione potrebbe ignorare qualsiasi contenuto se il formato dell’input è S/MIME e se il contenuto è del tipo multipart/signed MIME.

  • -text: questa opzione aggiunge un testo in chiaro MIME alle headers del messaggio dato se cifrato o firmato. Se viene decriptato o verificato gli headers del testo vengono tolti: se il messaggio da decifrare o da verificare non è del tipo MIME text/plain allora si avrà un errore.

  • -CAfile file: un file contenente i certificati CA fidati, viene usato solo con –verify.

  • -CApath dir: una directory contenente i certificati CA fidati, da usare solo con –verify. Questa directory deve essere una directory standard certificata: così che un hash di ciascun nome di un soggetto ( usando x509 –hash) possa essere linkato a ciascun certificato.

  • -des -des3 -rc2-40 -rc2-64 -rc2-128: l’algoritmo di cifratura da utilizzare. Rispettivamente DES (56 bits), triple DES (168 bits) o 40, 64 o 128 bit RC2 se non è specificato viene utilizzato RC2 con 40 bit. Da usare solo con – encrypt.

  • -nointern: quando si verifica un messaggio normalmente i certificati inlcusi nel messaggio sono cercati per firmare il certificato. Con questa opzione solo i certificati specificati con la opzione –certfile vengono utilizzati. I cartificati forniti possono tuttavia essere utilizzati in qualche modo come CA non fidate.

  • -noverify: non verifica i certificati dei firmatari di un messaggio firmato.

  • -nochain: non concatena la conferma delle firme dei certificati: questo per non utilizzare i certificati come CA non fidate nel messaggio firmato.

  • -nosigs: non prova a verificare la firma sul messaggio.

  • -nocerts: quando un messaggio viene firmato il certificato del firmatario è normalmente incluso, mentre con questa opzione viene escluso. Ciò riduce la grandezza del messaggio firmato ma il verificatore deve avere una copia dei certificati dei firmatari disponibili localmente (superato usando l’opzione –certfile).

  • -noattr: normalmente quando un messaggio è firmato un insieme di attributi sono inclusi come il signing time e gli algoritmi simmetrici supportati. Con questa opzione essi non sono inclusi.

  • -binary: normalmente il messaggio di input è convertito nel formato “ canonico” che usa CR e LF come end line: come richiesto dalle specifiche del S/MIME. Quando questa opzione è presente non occorrono ritrasmissioni. Questa è utile quando si trattano dati in binario che non possono esserci nel formato MIME.

  • -nodetach: quando si firma un messaggio si usa una opaque signing: questa forma è più resistente alle ritrasmissioni delle ritrasmissioni di mail ma essa non può essere letta dai mail agents che non supportano S/MIME. Senza questa opzione viene utilizzato cleartext signing con il tipo di MIME multipart/signed.

  • -certfile file: i certificati addizzionali permessi devono essere specificati. Quando li si firma bisogna includerli nel messaggio. Quando li si verifica bisogna ricercarli tra i certificati firmati. I certificati dovrebbero essere nel formato PEM.

  • -signer file: il certificato dei firmatari quando si firma un messaggio. Se un messaggio viene verificato allora i certificati dei firmatari vengono scritti in questo file se la verifica ha avuto successo.

  • -recip file: i contenitori dei certificati quando un messaggio viene decifrato. Questa certificato deve combaciare con uno dei recipienti dei messaggi o si avrà un errore.

  • -inkey file: la chiave privata da utilizzare quando si firma o si decifra. Questa deve combaciare il corrispondente certificato. Se questa opzione non è specificata allora la chiave privata deve essere inclusa nel file del certificato specificato con –recip o –signer file.

  • -passin arg: la sorgente delle password delle chiavi private. Per più informazioni circa il formato degli argomenti vedi PASS PHRASE ARGUMENTS section in openssl(1).

  • -rand file(s): uno o più files contenenti dati random utilizzati per inizializzare il generatore dei numeri casuali, o un EGD socket.( vedi RAND_egd(3)). Possono essere specificati più file separandoli da un carattere OS-dependent. Il separatore è “ ; ” per MS-Windows “ , ” per OpenVMS, e “ : “ per tutti gli altri.

  • cert.pem...: uno o più certificati per il contenitore dei messaggi: usato quando si cifra un messggio.

  • -to, -from, -subject: i relativi headers mail. Questi devono essere inclusi all’esterno della parte firmata di un messaggio quindi devono essere inclusi manualmente. Quando si firma, molti client di mail S/MIME controllano che l’indirizzo e-mail del certificato del firmatario combacia con quello specificato in From:address

    • Note

    Il messaggio MIME deve essere mandato senza alcuna linea vuota tra l’header e l’output. Alcuni programmi di posta aggiungono automaticamente una linea vuota. Spedire la mail direttamente a sendmail è un modo per archiviare il formato corretto.
    I messaggi forniti che devono essere firmati o cifrati devono includere le necessarie headers MIME o molti clients S/MIME non potranno visualizzarli correttamente. Si può usare l’opzione –text per aggiungere automaticamente un testo in chiaro come headers.
    Un messaggio firmato e cifrato è uno di quelli che sono firmati e poi cifrati. Questo può essere fatto cifrando un messaggio già firmato: vedi gli esempi della sessione.
    Questa versione del programma permette solo una firma per messaggio ma può verificare firme multiple sui messaggi ricevuti. Alcuni client S/MIME si possono bloccare se un messaggio contiene firme multiple. E’ possibile firmare messaggi in parallelo firmando messaggi già firmati.
    Le opzioni –encrypt e –decrypt trovano un uso comune nel clients S/MIME. Parlando rigorosamente questi processi PKCS#7 includevano dati: i dati PKCS#7 cifrati sono usati per altri scopi.

    Codici di uscita

  • 0: l’operazione ha avuto successo

  • 1:vi è stato un errore di parsine delle opzioni del comando

  • 2:uno dei file di input potrebbe non essere stato letto

  • 3:si è verificato un errore creando il file PKCS#7 o quando è stato letto il messaggio MIME.

  • 4:si è verificato un errore decifrando o verificando il messaggio.

  • 5:il messaggio è stato verificato correttamente ma si è verificato un errore scrivendo i certificati firmati.

    • Esempi

    1) Crea un messaggio firmato cleartext

    2) Crea un messaggio con unaopaque signing

    3) Crea un messaggio firmato, include alcuni certificati addizionali e legge la chiave privata da un altro file

    4) Manda un messaggio firmato sotto unix direttamente al sendmail, includendo gli headers

    5) Verifica un messaggio e estrae la firma del certificato se ha successo

    6) Manda una mail cifrata con il des triplo

    7) Firma una mail cifrata

    nota: il comando di cifratura non include l’opzione –text perchè il messaggio che sta per essere cifrato ha già gli headers MIME

    8) Decifra la mail

    L’output del form di firma per netscape è una struttura PKCS#7 con il modello di firma separato.
    Si può utilizzare questo programma per verificare la firma in linea prendendo la codifica base64 della struttura e racchiudendola con:

    e utilizzando il comando

    Alternativamene si può decodificare in base64 la firma e usare:

    Bugs

    Il parser del MIME non è molto furbo:sembra che esso gestisca la maggior parte dei messaggi che gli sono stati indirizzati ma è possibile che fallisca su altri
    Attualmente il codice verrà scritto in un file solo fuori dal certificato del firmatario: se il firmatario ha una cifratura separata di un certificato questo deve essere estratto manualmente. Ci dovrebbero essere alcune euristiche per determinare il corretto certificato cifrato.
    Idealmente un database dovrebbe mantenere un certificato per ciascun indirizzo e-mail.
    Il codice generalmente non prende nota degli algoritmi di cifratura simmetrica permessi così fornisce nel SMIMECapabilities l’attributo firmato. Ciò significa che l’utente deve includere manualmente l’algoritmo di cifratura. Potrebbe immagazzinare la lista dei cifrari permessi in un database e usare solo questi.
    Nessun controllo di revoca è fatto sul certificato del firmatario.
    Il corrente codice può solo gestire messaggi S/MIME v2, la struttura S/MIME v3, più complessa, potrebbe causare errori di parsing.