Protecting encryption server

[Peter Pentchev]

On Tue, Jul 28, 2020 at 10:33:42PM +0200, Denis BEURIVE via Gnupg-users wrote:
> > Oh, quite the contrary.  It just forces the attacker to get clever.
> 
> If your server only sends data through an "outgoing data diode", then it
> does not expose any entry point (you just disable all services : no SSH, no
> ping, no HTTP... nothing). There is no way you can establish a connection
> to the server. How can you hack a server if you have absolutely no way to
> access it from the outside ? It seems just impossible.

Quick question: how do you send data out? It cannot be via TCP
connections, since those require a handshake and acknowledgements
flowing both ways. It cannot be via any kind of TLS-based protocol for
the exact same reason. In theory you might be able to devise some
one-way protocol based on e.g. UDP or your own datalink layer and add
some kind of signing into it, but that would require a security audit in
its own right, and then there is the issue of dropped packets. So, as
described in Rob's paper, the sending server has to continuously send
the data over and over again, with no idea whether the receiving server
has received any of it, parts of it, or the whole of it.

Also, hm, here's a possibly stupid question: how do you keep the system
time synchronized between the sender and the receiver? You cannot use
any kind of time synchronization similar to NTP or even SNTP, since that
would require incoming data and programs that process that incoming data
and possible avenues of attack via (possibly still undiscovered)
problems in those programs. So at some point, time drift will start to
cause problems in the verification of the cryptographic signatures of
the data the server sends.

I am not saying that any of those problems is unsolvable, but it seems
to me that devising robust solutions to all of them (and to all of
the others that will come up along the way) will make the system much,
much, *much* more complicated than "just a single one-way comm device".
At some point the question would arise whether all these complications
and all these newly-devised communication protocols are indeed worth it.
Once again, not saying that the answer is always "no", but, well...

G'luck,
Peter

-- 
Peter Pentchev  roam at ringlet.net roam at debian.org pp at storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200729/f7469e93/attachment-0001.sig>