¿Qué protocolo debo usar para las transferencias seguras de mensajes entre dos servidores?

TLS - seguro.
Puede utilizar el certificado de cliente y elegir cifrados fuertes. Si los servidores no están limitados en el tráfico, agregue algo de flujo de datos de entropía dentro del socket.
Si desea transferir dos direcciones, https no es una solución. Sorbo. O xmpp?
Además de los comentarios:

1. TLS está bien implementado, es una protección de capa de transporte de código abierto, rápida y confiable. Por lo tanto, cuando hablamos de cifrado de canales, proporciona suficiente seguridad si se configura ambos lados correctamente: cifrados sólidos, evite el uso de SHA1 y SSLv2 / 3.
2. Es muy importante no darle al atacante potencial la oportunidad de determinar cualquier parte significativa del mensaje para su compra. Los cifrados modernos pueden oponerse a este método de descifrado. Sin embargo, creo que es un buen estilo si se mezclan algunos datos aleatorios que pueden considerarse pseudo entropía al canal de datos.
3. Mientras tenga que comunicarse entre dos servidores, digamos que el modelo de transferencia de datos debe ser igual en ambos lados, de modo que cada parte pueda actuar como cliente y como servidor, con las mismas capacidades de transferencia de datos.
4. Por supuesto, será TCP, necesario para garantizar la recepción del paquete.
5. XMPP o SIP: uno de los servidores será local para SIP o XMPP (prefiero el último) y remoto para otro. Por lo tanto, es una autenticación adicional para la transferencia de datos backends.
6. En cuanto a los certificados autofirmados. Si crea la cadena correcta con los certificados Root - Intermedio y Servidor correctamente firmados, ambos servidores pueden verificar su validez agregando el Certificado Raíz o Intermedio a la lista de CA confiables.
7. ¿Por qué no https? Trafic puede pasar el proxy del operador y nunca lo sabrás. Algunos proxies usan para golpear ssl. Por otra parte, es un puerto público que sin duda tiene riesgo de ataques de botnets. Será una comunicación de un solo lado, donde uno siempre es un servidor y otro es un cliente, donde las instrucciones del cliente al servidor deben pasar la autenticación adicional y el backend orientado a la web. Y lo último: no es tan rápido, ya que http no está diseñado para la transferencia de datos de servicio. Diría que https solo sirve para datos de bajo nivel de seguridad, como la confirmación de la validez de la sesión.
   

Yo crearía un bot XMPP que sea confiable, tenga un alcance y se establezcan estrofas flexibles para cualquier cosa: presencia, transferencia de datos e incluso transferencia de archivos. Si el sistema debe ser extremadamente paranoico, se puede agregar el cifrado OTR.

HTTPS es sin duda una excelente opción, pero tendrá que configurar un servidor HTTP según el tamaño del destinatario y configurarlo con certificados autofirmados a menos que ya tenga certificados válidos para ese uso.

Una forma alternativa sería usar ssh:

• enviar un mensaje json con sftp
• iniciar el script de procesamiento directamente con ssh

Fácil de configurar y encapsular en scripts triviales. Como tiene un solo remitente, simplemente puede usar para sus nombres de archivos de mensajes como msgxxxxx.json , donde xxxxx es un número único variable de 00000 a 99999

Modelo: transferencia masiva de datos de un servidor a otro, desearía evitar la fuga de información por parte de un atacante MITM

Solución: TLS o cualquier protocolo sobre TLS, como HTTPS, es una buena opción. Usted querrá asegurarse de que tiene la autenticación adecuada. El servidor debe autenticar al cliente y el cliente debe autenticar el servidor. Dos formas comunes de hacer esto: 1) Autenticación mutua TLS, 2) Autenticación de certificado de servidor TLS + Clave API dentro de los encabezados de los mensajes. Otra solución posible es el cifrado de flujo alternativo como SSH (scp o sftp) o IPSec VPN.

Modelo: mensajes de baja latencia o transmisiones multimedia, modelo de amenaza como se indica arriba

Solución: DTLS con Web Socket u otro protocolo diseñado para baja latencia como XMPP. La autenticación se refiere a lo anterior.h

Modelo: el servidor del remitente no necesariamente confía en el servidor del destinatario, querría poder probar mutuamente que un mensaje proviene del servidor del remitente y no ha sido manipulado por el destinatario

Solución: el remitente debe firmar criptográficamente los mensajes, por ejemplo, utilizando GPG. De forma alternativa, es posible que desee utilizar una cadena de merkle / cadena de bloque para probar la secuencia de mensajes. Es posible que desee utilizar el sello de tiempo de confianza también.

Modelo: desea tener cero confianza en terceros, como CA pública / comercial

Solución: ejecute su propia CA, use un certificado autofirmado. Ahora eres responsable de todo el proceso de verificación que normalmente haría una CA.

SSH puede ser más adecuado para este propósito, pero deberá realizar la validación de la huella digital de su servidor correctamente, de lo contrario, se expondrá a un primer ataque debido a TOFU .