La terza parte richiede la chiave pubblica del mio server per una connessione sicura?

Question

La terza parte richiede la chiave pubblica del mio server per una connessione sicura?

#1 da (5 voti)
#2 da (0 voti)

3

Sto cercando di integrarmi con un servizio di terze parti e hanno richiesto la chiave pubblica del nostro server. L'ho inviato a loro e hanno detto che l'hanno configurato sulla loro estremità. Per farmi fare richieste, sostengono che devo includere il certificato con la richiesta.

Come funziona esattamente questo schema? Non vedo come una borsa Diffie-Hellman possa funzionare in questo caso. Qualsiasi schema che penso possa essere facilmente rotto nel caso di un MITM. Non abbiamo modo di generare il segreto e inviarlo a loro in modo sicuro come una normale stretta di mano. Ma se generano il segreto, come possono inviarlo indietro e dimostrare che sono stati loro a generarlo?

Sto usando cURL quindi presumo che vogliano che faccia la richiesta con il flag --cert (include la chiave pubblica e privata).

--cert tells curl to use the specified client certificate file when getting a file with HTTPS, FTPS or another SSL-based protocol. The certificate must be in PKCS#12 format if using Secure Transport, or PEM format if using any other engine. If the optional password isn't specified, it will be queried for on the terminal. Note that this option assumes a "certificate" file that is the private key and the client certificate concatenated.

tls key-exchange

posta James E 17.11.2015 - 09:28

fonte

2 risposte

0

Lo schema funziona come segue:

Mostrando che puoi crittografare o decrittografare un messaggio con la tua chiave privata , puoi autentificarti da solo a terzi.

Poiché la tua chiave pubblica è pubblica, la terza parte non è autenticata.

Quando si utilizza https nelle richieste, si ottiene un certificato che autentica anche la terza parte.

Naturalmente, stabilisci anche un canale di comunicazione crittografato (sicuro).

risposta data 17.11.2015 - 09:53

fonte

Leggi altre domande sui tag tls key-exchange

È un buon modo per gestire il processo di login Reinstradamento dei domini e la necessità di più certificati SSL

score 5 · Accepted Answer

Questa è l'autenticazione reciproca TLS.

È una parte comprovata e ben documentata di TLS e si verifica durante l'handshake.

Non accade nulla di insolito e l'handshake viene specificato in errore se non si fornisce il certificato client.

MitM è sicuramente ancora un problema, ma viene attenuato per te come un client dalla CA, dall'affidabilità e dalla firma (o dal blocco dei certificati) dalla tua parte e da un simile CA trust (o blocco dei certificati client) sul lato server. Qualcuno che fornisca un certificato contraffatto da una posizione MitM dovrà firmare CA o un ingegnere sociale da un lato o dall'altro per bloccare i propri certificati dannosi.

IMPORTANTE : DEVI fornire il certificato del cliente (se non firmato dalla CA) in modo sicuro all'operatore del server. Lo scambio di chiavi in banda non è certamente all'altezza di questo compito. Un'opzione è di pubblicare il certificato su un endpoint HTTPS protetto per un dominio che possiedi da cui l'operatore del server può scaricare la certezza con sicurezza che proviene da te e non è stata manomessa durante il transito. Questo ha i suoi difetti (CA incompleti, compromissione del server, ecc.), Ma dovrebbe essere sufficiente per la maggior parte dei casi.

Ecco una buona descrizione del processo qui: link