utoni
Encrypt the json
Hi Toni, another suggestion is to encrypt the json sent to the sock/UDP client.
-
architecture: nDPId -> internet -> client (sock/UDP)
-
issue: the json is clear text and could be intercepted by anyone json part contains important data that can not be visible by all
-
solution/proposal: encrypt with openssl (ex: cipher method AES-128-CTR) using a special encryption text encrypted json must be decrypted by the client (sock/UDP) using C, Go, PHP, etc...
-
ndpid.conf: passkey="blablabla..." # take care the value should double quoted because spaces could be allowed #'passkey' or whatever you think it'll be the best way #argument (ex: -P "blablabla...") also in the command line
what do you think ?
bye Fred
That is an idea that I already had in my mind. (See: https://github.com/utoni/nDPId/milestone/3) I wanted to encrypt the nDPIsrvd connections to it's distributor clients. But doing this within nDPId UDP send is also something I'll consider as it should be more easy to implement as kinda "first crypto support".
excellent ! we'll be happy for testing it as soon as it'll be available...
bye Fred
Toni, but think that our proposal is a bit different what you mean with the milestone 1.8 or maybe we're wrong here ;o) the idea is that the nDPId sends encrypted json to another daemon (ex: ncat, socat, personal tool, etc...)
bye Fred
The idea is bit similar so far as it's the same JSON messages which are getting encrypted, but by a different application.
I'll probably start with the nDPId UDP encryption as this might be easier to achieve and may also be reused for other applications such as nDPIsrvd.
Hi Toni, we've tested the OpenSSL part to encrypt the Json: x.zip
we have tested the process and it works fine... so if you could add that to your source code it'll be cool :o)
bye Fred
Hi Fred,
thanks for your proposal. Is there any reason why you've used aes256-cbc and not an AEAD i.e. aes256-gcm ?
Toni, that's the source from Mistral (French IA, https://mistral.ai/) that we have modified a bit. we don't care if CBC or GCM, use the mode you think is the best... the only point we take care is that it must be Go langage compatible, we do use Go as our receiver daemon (nDPId -> Go daemon) anyway, CBC or GCM or etc..., I think we should find the way with Go :o)
bye Fred
Hi Toni,
happy new year 2025 !!
any update regarding this case ?
bye Fred
The PR #54 can be already used for testing. But it does currently only provide a C API as example (examples/c-decrypt).
It's not stable and subject to change. I am also investigating currently an issue with OpenSSL.
Toni, why not using a basis and simple way as explained here (https://github.com/utoni/nDPId/issues/47#issuecomment-2444171554) ?
bye Fred
why not using a basis and simple way as explained here (https://github.com/utoni/nDPId/issues/47#issuecomment-2444171554) ?
It does not protect the payload from being tampered by a third party. That is not the security that I would like to have.
Hey @UnveilTech , thanks for asking. I am still working on this. But at the moment I am almost completely occupied with paid work. :/
@UnveilTech sorry for beeing late, nDPId now supports standardized TLS channels, nDPId's UDP was replaced by TLS
Hi Toni, maybe we missed a step somewhere, we saw options -k, -K and -F are here about our request if we enable CRYPTO, but what about if we set CRYPTO=OFF, will it work as previously with UDP ? we have re-compiled with CRYPTO=OFF but not UDP traffic anymore, what we did wrong ?
regards, Bye Fred
Hi Fred,
I removed UDP support in favor of TCP only. The reason behind it was IP fragmentation together with UDP, which is a message based protocol. It resulted quite often in out-of-order JSON messages, which is not good for the JSON stream protocol used, where messages are expected to be in order.
But in theory, w/ ENABLE_CRYPTO=OFF you should still be able to use an unencrypted TCP connection via -c.