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.

  • 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 Feb 28 '17 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 Feb 28 '17 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 Feb 28 '17 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 Feb 28 '17 at 15:31
  • 1
    TLS is a great approach. For how to verify validity of certificates, I'd suggest certificate pinning. – mikeazo Feb 28 '17 at 16:25
3

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?
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.
  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.
  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.
  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 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.

|improve this answer|||||
  • 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 Feb 28 '17 at 15:32
  • No weekness if both servers have root certificate in trust. – ETech Feb 28 '17 at 15:52
  • @ETech, that sounds interesting. Could you please tell more about this? – roman4ak Mar 1 '17 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 Mar 3 '17 at 12:37
  • One of hosts - authority. Another just adds the CA to trust. No need to store private key on both sides. – ETech Mar 3 '17 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

|improve this answer|||||
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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.