Windows application client di un WebService in Mutua Autenticazione

jackfolla79

il 09 gen 2021, 19:01

9 risposte

jackfolla79

Pochi posts

Iscritto da: set, 2020

Messaggi:: 7

Windows application client di un WebService in Mutua Autenticazione

09 gen 2021, 19:29

Ciao a tutti,
buon inizio anno
Ho un'applicazione .NET presente in un server Windows (Duckburg) che invoca un web service di terze parti (Mouseton), lo scambio dei dati avviene in Mutua Autenticazione tramite certificati SSL (abbiamo il certificato pubblico .cer di Mouseton e la catena delle CA)
Ho verificato il file config della mia applicazione .NET:

<behavior name="ClientCredentialsBehavior_Mouseton">
<clientCredentials>
<!-- Defines an X.509 certificate used to authenticate a client to a service.
Specifies the certificate used to authenticate the client to the service.
thumbprint file Mouseton.cer
-->
<clientCertificate findValue="1234"
storeLocation="LocalMachine" storeName="My"
x509FindType="FindByThumbprint"/>
<serviceCertificate>
<!-- Specifies the certificate used to authenticate the service to the client and provides a
structure for setting certificate options.
This certificate must be supplied out-of-band from the service to the client.
thumbprint file Mouseton.cer
-->
<defaultCertificate findValue="1234"
storeLocation="LocalMachine" storeName="TrustedPeople"
x509FindType="FindByThumbprint"/>
<authentication certificateValidationMode="PeerTrust"
trustedStoreLocation="LocalMachine"/>
</serviceCertificate>
<windows allowNtlm="false" allowedImpersonationLevel="Anonymous"/>
<httpDigest impersonationLevel="Anonymous"/>
</clientCredentials>
</behavior>

Innanzitutto chiedo conferma della modalità che stiamo usando, si tratta di CERTIFICATE PINNING giusto?
In pratica "clientCertificate" e "serviceCertificate" hanno lo stesso puntamento al certificato pubblico di Mouseton ,
e comunque leggendo un pò sul web forse sarebbe meglio usare "FindByIssuerName" e non il "Thumbprint " che lo devi poi aggiornare nel file config ogni anno quando scade il certificato di Mouseton . Giusto?
Ho verificato nel nostro server Windows il file .cer di Mouseton è stato installato nei certificati personali e nei certificati attendibili (ed i cerfificati delle CA nelle CA attendibili)
Adesso ho scoperto che un collega vuole farsi dare il file PFX da Mouseton , secondo me questo è sbagliato. Ora sta funzionando secondo la Mutua autenticazione corretta, infatti il file pfx ha la chiave privata di Mouseton che secondo me deve essere segreta e non devono inviarla mai.
Grazie in anticipo per le risposte
Bye

9 Risposte

sspintux
Utente Attivo
Iscritto da
dic, 2012
Messaggi:
500
Re: Windows application client di un WebService in Mutua Autenticazione
09 gen 2021, 20:30
jackfolla79 ha scritto:
Ciao a tutti,
buon inizio anno
Ho un'applicazione .NET presente in un server Windows (Duckburg) che invoca un web service di terze parti (Mouseton), lo scambio dei dati avviene in Mutua Autenticazione tramite certificati SSL (abbiamo il certificato pubblico .cer di Mouseton e la catena delle CA)
....
Adesso ho scoperto che un collega vuole farsi dare il file PFX da Mouseton , secondo me questo è sbagliato. Ora sta funzionando secondo la Mutua autenticazione corretta, infatti il file pfx ha la chiave privata di Mouseton che secondo me deve essere segreta e non devono inviarla mai.
Grazie in anticipo per le risposte
Bye
non credo proprio che vi daranno la loro chiave privata
che come dici deve restare segreta. Eviterei di chiederla pena una rispostaccia

Per la mutua autenticazione voi dovete avere la loro chiave pubblica e loro la vostra
( oltre alla catena delle rispettive CA che si suppone venga controllata)

HTH
J
jackfolla79
Pochi posts
Iscritto da
set, 2020
Messaggi:
7
Re: Windows application client di un WebService in Mutua Autenticazione
09 gen 2021, 20:47
non credo proprio che vi daranno la loro chiave privata
che come dici deve restare segreta. Eviterei di chiederla pena una rispostaccia

Per la mutua autenticazione voi dovete avere la loro chiave pubblica e loro la vostra
( oltre alla catena delle rispettive CA che si suppone venga controllata)
Infatti anche io sono contrario alla loro chiave privata ( e pensare che ci hanno pure inviato il loro file pfx.. )

Quanto presente nel nostro file config è detto CERTIFICATE PINNING?

Dal mio pc infatti la chiamata al ws funziona correttamente con la loro chiave pubblica ovvere il loro file .cer

Devo dimostrare ai miei colleghi che lo standard è la configurazione del mio pc: la Mutua autenticazione deve avvenire con la chiavi pubbliche e non con i files pfx del provider (Mouseton)

Grazie
sspintux
Utente Attivo
Iscritto da
dic, 2012
Messaggi:
500
Re: Windows application client di un WebService in Mutua Autenticazione
09 gen 2021, 22:35
jackfolla79 ha scritto:
....
Quanto presente nel nostro file config è detto CERTIFICATE PINNING?
...
sinceramente non lo so ;
ma, secondo me, se vuoi accettare solo quel certificato puoi implementare
ServicePointManager.ServerCertificateValidationCallback
e verificare quale chiave pubblica ti arriva

EDIT
però a rileggere mi sta venendo il dubbio
perchè sia client che server potrebbero usare lo stesso certificato
ed in quel caso anche il client dovrebbe avere la chiave privata
se il certificato è uno solo e te lo fornisce questo Mouseton

HTH
J
jackfolla79
Pochi posts
Iscritto da
set, 2020
Messaggi:
7
Re: Windows application client di un WebService in Mutua Autenticazione
10 gen 2021, 10:59
Ciao ,
ti assicuro che funziona con il certificato pubblico del Provider.
nel codice C# ho quanto segue

ServicePointManager.ServerCertificateValidationCallback = delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
.....
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
MousetonWSClient client = new MousetonWSClient();
...

io sono assolutamente contrario a farmi dare il loro PFX, ovviamente anche mettendo il PFX nei certificati personali funziona la chiamata.

Ho commentato il mio file config sulla base della documentazione Microsoft

<behavior name="ClientCredentialsBehavior_Mouseton">


<clientCredentials>


<clientCertificate findValue="1234" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint"/>



<serviceCertificate>



<defaultCertificate findValue="1234" x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="TrustedPeople" />




<authentication certificateValidationMode="PeerTrust" trustedStoreLocation="LocalMachine"/>

</serviceCertificate>


<windows allowNtlm="false" allowedImpersonationLevel="Anonymous"/>



<httpDigest impersonationLevel="Anonymous"/>

</clientCredentials>
</behavior>
sspintux
Utente Attivo
Iscritto da
dic, 2012
Messaggi:
500
Re: Windows application client di un WebService in Mutua Autenticazione
10 gen 2021, 12:12
jackfolla79 ha scritto:
Ciao ,
ti assicuro che funziona con il certificato pubblico del Provider.
...
Non ho dubbi su questo;
le chiavi private stanno solo sui server e non vengono mai scambiate ;
solo quelle pubbliche vengono scambiate nel processo di handshake.

Non so spiegarmi il perchè ve l'abbiamo inviata
J
jackfolla79
Pochi posts
Iscritto da
set, 2020
Messaggi:
7
Re: Windows application client di un WebService in Mutua Autenticazione
10 gen 2021, 13:56
Ho trovato questo in rete

Certificate pinning aumentare il livello di sicurezza delle connessioni

Quando si lavora in settori, come quello finanziario, la sicurezza è un elemento fondamentale. Occorre quindi progettare e implementare con attenzione ogni ambito coinvolto nella funzionalità su cui si sta lavorando. Il compito di chi supervisiona e progetta servizi è aumentare il più possibile il grado di sicurezza nella connessione di un’applicazione web al server.

È il caso dello sviluppo dei pinning dei certificati. Ogni volta che un client si collega a un server, tipicamente tramite applicazioni web o mobile tramite HTTPS, quello che avviene normalmente è uno scambio di informazioni tra i due, necessario a instaurare un collegamento sicuro.

Per aumentare il livello di sicurezza della connessione può essere eseguito il pinning del certificato. Questa tecnica consiste nel verificare che il server contattato dal client sia quello voluto e che, invece, non si diventi vittima di un attacco man-in-the-middle. A volte infatti può succedere che un soggetto si interponga tra il client e il server al fine di intercettare il traffico di dati e rubare contenuti importanti.

I certificati sono dei documenti che servono a stabilire con esattezza l’identità delle parti. Contengono informazioni sull’identità del proprietario e informazioni sulla chiave pubblica, ovvero la chiave crittografica utilizzata in un sistema di crittografia asimmetrica (ogni chiave pubblica è associata a una chiave privata [fonte Wikipedia]).

Per essere considerato affidabile il certificato deve essere firmato da un’autorità di certificazione (CA) che, usando la propria chiave privata, pone la firma digitale alle informazioni del server. Queste CA possono essere anche intermedie, ossia autorità che a loro volta hanno un proprio certificato firmato da un’altra CA. Grazie a queste informazioni è possibile risalire per gradi alla Root CA, ossia all’ultima autorità di certificazione che firma anche il suo stesso certificato. Questa catena che si crea, prende il nome di catena del trust (chain of trust), dove all’ultimo livello, definito leaf, c’è il client dal quale parte la richiesta di connessione.

Le modalità per eseguire il pinning del certificato differiscono in base al livello all’interno della catena del trust a cui vogliamo rivolgerci per verificare l’affidabilità della connessione, ossia qual è la chiave pubblica che vogliamo verificare.
Il pinning del certificato consiste nel controllare la corrispondenza tra la chiave pubblica del certificato e la chiave che il client conosce e che ha memorizzato in maniera codificata (pin). Se il confronto ha successo allora la connessione è considerata affidabile, altrimenti la si considera non affidabile e si interrompe. Se il pinning viene eseguito sull’ultimo livello della catena dei certificati si parla di pinning leaf. Oltre al pin della chiave contenuta nel certificato corrente, per evitare di non riuscire a instaurare una connessione affidabile, è necessario avere almeno un altro pin di backup, che verrà utilizzato se il confronto con il pin corrente fallisce.

Il server crea una o più coppie Chiave privata/Chiave pubblica, tenendole memorizzate off-line, possibilmente in due locazioni differenti e sicure e ne definisce i corrispondenti pin, che verranno memorizzati dal client come pin di backup.
Quando necessario (scadenza del certificato, compromissione, …) il server chiede alla CA di firmare un nuovo certificato, utilizzando la chiave pubblica di backup. Il client usando il pin di backup sarà ancora in grado di eseguire il pinning del certificato e instaurare così una connessione affidabile, senza rischi di down, ossia di non poter accedere ai servizi del server.
Una volta utilizzate le chiavi di backup si procede a definire una nuova coppia di chiavi e il corrispondente pin di backup che dovrà poi essere salvato nel client (es. aggiornando l’app).

Il pinning della chiave della CA intermedio ha un livello di sicurezza più basso ma ha diversi vantaggi, a partire dal fatto che non occorre gestire alcun pin di backup, a meno che non lo si voglia comunque usare per avere un livello di sicurezza maggiore.
Se la chiave è compromessa, oppure è necessario rinnovare il certificato, è sufficiente che la stessa CA firmi un nuovo certificato affinché sia accettato in fase di pinning senza alcuna modifica lato client e rischi di down.

Nell’intermediate pinning si può procedere in diversi modi:

si aggiunge il pin di un’altra CA intermediate, a cui richiedere l’emissione di un nuovo certificato quando necessario;
si aggiunge il pin di una coppia di chiavi che potrà essere usata per la richiesta di un nuovo certificato ad una qualsiasi CA.
Per maggiore sicurezza possono essere adottate entrambe le soluzioni.

Il pinning a una Root CA significa che può essere accettato un qualsiasi certificato che quella determinata CA emette, quindi firma.
Come per il pinning della CA intermedia, come pin di backup può essere usato quello di un’altra root CA, oppure il pin di una chiave propria.
Questa configurazione dà una grande flessibilità, ma presenta diverse criticità: il client potrebbe determinare una catena dei certificati diversa da quella che ci si aspetta e quindi non individuare alcun pin valido.

La scelta di implementare una tra le tre differenti modalità di pinning è da valutare e da pianificare con attenzione. Infatti, una cattiva gestione potrebbe portare il client a rifiutare la connessione, non ritenendola sicura. Di conseguenza, nel caso in cui il pinning fallisca, non sarà possibile usufruire del servizio richiesto.
sspintux
Utente Attivo
Iscritto da
dic, 2012
Messaggi:
500
Re: Windows application client di un WebService in Mutua Autenticazione
10 gen 2021, 16:37
Se vuoi metter su questo meccanismo del certificate pinning ( google l'ha rimosso da chrome a quanto ho letto)
per aumentare la sicurezza di colloquiare con il server giusto, secondo me e come già ti dicevo,
potresti implementare ServicePointManager.ServerCertificateValidationCallback
dove hai sia il certificato finale che la catena dei certificati.

Buona fortuna!

jackfolla79

Pochi posts

Iscritto da: set, 2020

Messaggi:: 7

Re: Windows application client di un WebService in Mutua Autenticazione

10 gen 2021, 18:01

Ho semplicemente un pulsante che esegue il test di connessione al Ws provider:

  try
            {
                ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
                MousetonWSClient client = new MousetonWSClient();
                string result = client.PROPERTY_CHECK_WS();
                tbxMousetonResult.Text = result;
                client.Close();
            }

.....

Nel form il codice è :

 public partial class frmMouseton_Ws : Form
    {
        SslPolicyErrors error = SslPolicyErrors.None;
        public frmMouseton_Ws()
        { 
		
		ServicePointManager.[b]ServerCertificateValidationCallback [/b]= delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
            {
                
                error = sslPolicyErrors;

                // If the certificate is a valid, signed certificate, return true.
                if (sslPolicyErrors == System.Net.Security.SslPolicyErrors.None) {
                    return true;
                }
                // If there are errors in the certificate chain, look at each error to determine the cause.
                if ((sslPolicyErrors & System.Net.Security.SslPolicyErrors.RemoteCertificateChainErrors) != 0)
                {
                    if (chain != null && chain.ChainStatus != null)
                    {
                        foreach (System.Security.Cryptography.X509Certificates.X509ChainStatus status in chain.ChainStatus)
                        {
                            if ((certificate.Subject == certificate.Issuer) && (status.Status == System.Security.Cryptography.X509Certificates.X509ChainStatusFlags.UntrustedRoot))
                            {
                                // Self-signed certificates with an untrusted root are valid. 
                                continue;
                            }
                            else
                            {
                                if (status.Status != System.Security.Cryptography.X509Certificates.X509ChainStatusFlags.NoError)
                                {
                                    // If there are any other errors in the certificate chain, the certificate is invalid,
                                    // so the method returns false.
                                    return false;
                                }
                            }
                        }
                    }
                    // When processing reaches this line, the only errors in the certificate chain are 
                    // untrusted root errors for self-signed certificates. These certificates are valid
                    // for default Exchange server installations, so return true.
                    return true;
                }
                else
                {
                    // In all other cases, return false.
                    return false;
                }
            };
        }

Poi nel file app.config ho anche questa parte:

     <client>
		<endpoint address="https://mouseton.com/services/ws" 
				behaviorConfiguration="ClientCredentialsBehavior_Mouseton" 
				binding="basicHttpBinding" 
				bindingConfiguration="MousetonWSPortBinding" 
				contract="Mouseton_Client.MousetonWS" name="MousetonWSPort"/>
    </client>

J
jackfolla79
Pochi posts
Iscritto da
set, 2020
Messaggi:
7
Re: Windows application client di un WebService in Mutua Autenticazione
10 gen 2021, 18:17
Qua ho trovato un esempio di CERTIFICATE PINNING : https://howto.one/knowledgebase/how-to-enable-certificate-pinning-in-your-application-with-the-webclient-or-httprequest-object/

Noi lo facciamo tramite il file app.config invece di schiantarlo nel codice C#

Bye

Devi accedere o registrarti per scrivere nel forum

9 risposte