1

There are two servers. I am going to transfer very secret messages from the first one to the second.

The second server (the one that receives data) doesn't have access to any other resources except the first server.

Messages are simple JSON strings whose lengths don't exceed 1024 symbols and usually are much smaller.

Which protocol should I use for very secure data transfers? Does it really matter or can I take the easy way and just use HTTPS?

PS. Data processing and storage is absolutely another story. I care only about data transfer.

6
  • 3
    what do you want to protect against? what's the threat model? if using TLS, do you have a method to confirm the validity of certificates?
    – schroeder
    Commented Feb 28, 2017 at 14:46
  • @schroeder, I am not sure I understood your question well. The main threat I want to protect again is traffic interception.
    – roman4ak
    Commented Feb 28, 2017 at 14:50
  • 2
    @user12907 TLS performs two major functions - encrypts data and verifies communication is occurring with who you think it's occurring with (mitigates MITM attacks). If your messages are super secret you should be confirming that the certificates are valid to ensure there is no MITM attack possible.
    – DKNUCKLES
    Commented Feb 28, 2017 at 15:20
  • 3
    @aoroman4ak certificates work because a 3rd party says that the server is the server you think you are talking to. Without access to this validation, the certificate (and the server) could be anyone. But it all depends on your threat model. Even with self-signed certificates, the data will be encrypted, but it is open to MITM attacks. If MITM is not in your threat model, then you are fine. If you are worried about MITM, then you need another approach.
    – schroeder
    Commented Feb 28, 2017 at 15:31
  • 1
    TLS is a great approach. For how to verify validity of certificates, I'd suggest certificate pinning.
    – mikeazo
    Commented Feb 28, 2017 at 16:25

3 Answers 3

4

TLS - for sure.
You can use client certificate and choose strong ciphers. If servers are not limited in trafic - add some entropy data flow inside the socket.
If you wish to transfer two directions - https is not a solution. SIP. Or XMPP. Or WebSocket or any other TCP Socket implementation with TLS support.

In addition to comments:

  1. TLS is well implemented, open source, fast and reliable transport layer protection. So, when we speak about channel encryption, it provides enough security, if to set up both sides properly: strong ciphers, avoid SHA1 and SSLv2/3 usage (Jan 2021 - TLSv1 is dead too).
  2. It is very important not to give to potential attacker a chance to determine any significant part of message for compraison. Modern ciphers can stand against this decryption method. However, I think that it is good style if you mix some random data that can be considered pseudo entropy to the data channel.
  3. As long as you need to communicate between two servers, let's say that data transfer model must be equal on both sides, so each part can act both as client and server, having equal data transfer abilities.
  4. Of course, it will be TCP - needed to guarantee packet receipt. This task data takes one IP packet, so if UDP (DTLS) looses packet, even transfer fact will be lost.
  5. XMPP or SIP: one of servers will be local for SIP or XMPP (I prefer the last) server and remote for another. So, it is additional authentication for data transfering backends. (2021 update) Websocket - nice solution too if you wish to code. Number of frameworks to implement client and server.
  6. As for self signed certificates. If you create correct chain with Root - Intermediate and Server certificates properly signed - both servers can check their validity by adding Root and/or Intermediate certificate to trusted CA list.
  7. Why not https? Trafic can pass operator's proxy and you will never know it. Some proxies use to bump ssl. Moreover, it is public port that for sure has risk of botnets attack. It will be single side communication, where one always is a server and another is a client, where client to server side instructions need to pass additional authentication and web oriented backend. And the last - it is not so fast, cause http is not designed for service data transfer. I would say, that https is good only for low security level data such as session validity confirmation.

I would create an XMPP bot that is reliable, has reach and flexible stanzas set for anything: presence, data transfer and even files transfer. If the system must be extremely paranoid - OTR encryption can be added.

Conclusion: For 1024 symbols messages (1 or few IP packets) TCP as transport protocol to ensure delivery (socket), TLS as transport layer security to simplify implementation, CA signed certificate to avoid MItM. Application layer - SIP / XMPP / WS

5
  • 1
    given the scenario, TLS would have to be using self-signed certificates - that detail makes TLS not a default solution and the weaknesses of the scheme need to be assessed
    – schroeder
    Commented Feb 28, 2017 at 15:32
  • No weekness if both servers have root certificate in trust.
    – ETech
    Commented Feb 28, 2017 at 15:52
  • @ETech, that sounds interesting. Could you please tell more about this?
    – roman4ak
    Commented Mar 1, 2017 at 16:38
  • 1
    @aoroman4ak Self-signed certificates are normally a problem because there is no chain of trust, so the client cannot verify it is talking to who it thinks it's talking to. In this case you control both sides of the connection, so you can create your own certificate authority and use that to create the certificates. If you install your CA as a trusted root on both sides then the chain of trust is restored. Ideally your CA private keys would be stored on an offline server to reduce the risk of compromise.
    – spencercw
    Commented Mar 3, 2017 at 12:37
  • One of hosts - authority. Another just adds the CA to trust. No need to store private key on both sides.
    – ETech
    Commented Mar 3, 2017 at 12:41
2

HTTPS is certainly an excellent choice, but you will have to setup an HTTP server on recipient size, and configure it with self signed certificates unless you already have valid certificates for that usage.

An alternative way would be to use ssh:

  • send a json message with sftp
  • start the processing script directly with ssh

Simple to setup and to encapsulate in trivial scripts. As you have one single sender, you could simply use for your messages file names as msgxxxxx.json where xxxxx is a rolling unique number from 00000 to 99999

2

Model: bulk transfer of data from one server to another, you'd want to prevent information leakage by a MITM attacker

Solution: TLS or any protocol over TLS such as HTTPS is a good choice. You'd want to make sure you have proper authentication. Server need to authenticate client, and client need to authenticate server. Two common ways to do this: 1) TLS mutual authentication, 2) TLS server certificate authentication + API Key within message headers. Other possible solution is alternative stream encryption like SSH (scp or sftp) or IPSec VPN.

Model: low latency messaging or multimedia streams, threat model as above

Solution: DTLS with Web Socket or other protocol designed for low latency like XMPP. Authentication concerns as above.h

Model: the sender server don't necessarily trust the recipient server, you'd want to be able to mutually prove that a message comes from the sender server and hasn't been tampered by the recipient

Solution: the sender need to cryptographically sign the messages, e.g. using GPG. Alternatively, you might want to use a merkle chain/block chain to prove message sequencing. You might want to use trusted time stamping as well.

Model: you want to have zero trust on any third parties, such as public/commercial CA

Solution: run your own CA, use self signed certificate. Now you're responsible for all the verification process that a CA would normally do.

SSH may be more suitable for this purpose, but you'll need to do your server fingerprint validation properly, otherwise you expose yourself to first use attack due to TOFU.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .