Quale protocollo dovrei usare per trasferimenti sicuri di messaggi tra due server?

TLS - di sicuro.
È possibile utilizzare il certificato client e scegliere cifrari forti. Se i server non sono limitati nel traffico - aggiungi un flusso di dati entropici all'interno del socket.
Se desideri trasferire due direzioni, https non è una soluzione. Sorso. O xmpp?
Oltre ai commenti:

1. TLS è una protezione del livello di trasporto ben implementata, open source, veloce e affidabile. Quindi, quando parliamo di cifratura dei canali, fornisce abbastanza sicurezza, se impostare correttamente entrambi i lati: cifratura strong, evitare l'utilizzo di SHA1 e SSLv2 / 3.
2. È molto importante non dare a potenziali aggressori la possibilità di determinare una parte significativa del messaggio per l'acquisto. I codici moderni possono resistere a questo metodo di decrittazione. Tuttavia, penso che sia un buon stile se si mescolano dati casuali che possono essere considerati pseudo entropia nel canale dati.
3. Finché è necessario comunicare tra due server, diciamo che il modello di trasferimento dati deve essere uguale su entrambi i lati, in modo che ciascuna parte possa agire sia come client sia come server, avendo le stesse capacità di trasferimento dei dati.
4. Naturalmente, sarà TCP - necessario per garantire la ricezione del pacchetto.
5. XMPP o SIP: uno dei server sarà locale per SIP o XMPP (preferisco l'ultimo) server e remoto per un altro. Quindi, è un'autenticazione aggiuntiva per il trasferimento dei dati sui backend.
6. Come per i certificati autofirmati. Se si crea una catena corretta con i certificati Root - Intermediate e Server correttamente firmati - entrambi i server possono verificare la loro validità aggiungendo il certificato Root o Intermedia alla lista delle CA attendibili.
7. Perché non https? Trafic può passare il proxy dell'operatore e non lo saprai mai. Alcuni proxy usano per sballare ssl. Inoltre, è un porto pubblico che sicuramente ha il rischio di attaccare botnet. Sarà una comunicazione single side, dove uno è sempre un server e un altro è un client, dove le istruzioni lato client a server devono passare autenticazione aggiuntiva e backend web oriented. E l'ultimo - non è così veloce, perché http non è progettato per il trasferimento dei dati di servizio. Direi che https è valido solo per i dati a basso livello di sicurezza, come la conferma della validità della sessione.
   

Creerei un bot XMPP affidabile, con set di stance flessibili e disponibili per qualsiasi cosa: presenza, trasferimento dati e persino trasferimento di file. Se il sistema deve essere estremamente paranoico, è possibile aggiungere la crittografia OTR.

HTTPS è sicuramente una scelta eccellente, ma dovrai configurare un server HTTP sulla dimensione del destinatario e configurarlo con certificati autofirmati a meno che tu non abbia già certificati validi per tale utilizzo.

Un modo alternativo sarebbe usare ssh:

• invia un messaggio json con sftp
• avvia lo script di elaborazione direttamente con ssh

Semplice da configurare e incapsulare in script banali. Poiché hai un singolo mittente, puoi semplicemente utilizzare i nomi dei file dei tuoi messaggi come msgxxxxx.json dove xxxxx è un numero univoco rotante da 00000 a 99999

Modello: trasferimento in blocco di dati da un server a un altro, si desidera impedire la perdita di informazioni da parte di un utente malintenzionato MITM

Soluzione: TLS o qualsiasi protocollo su TLS come HTTPS è una buona scelta. Dovresti assicurarti di avere un'autenticazione corretta. Il server deve autenticare il client e il client deve autenticare il server. Due modi comuni per farlo: 1) autenticazione reciproca TLS, 2) autenticazione certificato server TLS + chiave API all'interno delle intestazioni dei messaggi. Altre possibili soluzioni sono la crittografia alternativa del flusso come SSH (scp o sftp) o VPN IPSec.

Modello: messaggistica a bassa latenza o flussi multimediali, modello di minaccia come sopra

Soluzione: DTLS con Web Socket o altro protocollo progettato per bassa latenza come XMPP. Problemi di autenticazione come sopra.h

Modello: il server mittente non si fida necessariamente del server destinatario, vorresti essere in grado di dimostrare reciprocamente che un messaggio proviene dal server mittente e non è stato manomesso dal destinatario

Soluzione: il mittente deve firmare crittograficamente i messaggi, ad es. usando GPG. In alternativa, potresti voler utilizzare una catena di merker / catena di blocchi per dimostrare la sequenza dei messaggi. Si consiglia di utilizzare anche l'indicazione dell'ora attendibile.

Modello: vuoi avere fiducia zero su terze parti, come la CA pubblica / commerciale

Soluzione: eseguire la propria CA, utilizzare un certificato autofirmato. Ora sei responsabile di tutto il processo di verifica che normalmente farebbe una CA.

SSH potrebbe essere più adatto a questo scopo, ma dovrai eseguire correttamente la convalida dell'impronta digitale del server, altrimenti ti esponi per primo a utilizzare l'attacco a causa di TOFU .