I want to encrypt the data at rest in ActiveMQ Artemis. Could not find a resource suggesting the expected configuration.
ActiveMQ Artemis does not support data encryption at rest. You should either encrypt your data end-to-end or use file-system based encryption.
Related
I am using TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suite, and I have sucessfully finished the handshake process, so i should have the correct KEYS for the server side and client side, but when i use the server write key and iv to encrypt the data and put under record layer(applicaiton type) send to client, but when i use wireshark ssl debug, i found out that wireshark didn't decrypt the application data correctly, wonder is the application data use a different key to do the encryption and decryption? Thanks
I have finally found the problem, TLS 1.0 used the last block of encrypted data as new IV to encrypt the data. its a little surprised, the encrypted data is visible on the network, so anyone capture that data can find out the IV.
Is it safe to send a mobile client an AES Key and IV from the server to use for encrypting sensitive data? The key and IV would be sent using TLS. This key would be used for encrypting data from end to end.
Update:
My requirements have actually changed, so I don't need to do this, but the solution I came up with was actually to have the client send a public key to the server over tls. Then the server could encrypt the keys with that public key and send them back to the client.
It would be as secure as any data in TLS. It also depends on how much your client trusts this TLS, which may not have two sided authentication.
But basically sending the key this way doesn't add much to using TLS. If TLS is insecure then the AES key is insecure. If it isn't then the AES key is secure...but TLS was already secure. There might be a slight advantage if you'd use a ciphersuite that provides forward security (DHE_ or ECDHE_).
But mostly, if you send anything, you'd send a public key such as a PGP key. The person on the other hand still has to trust the sender of course (i.e. by validating the fingerprint) but if the TLS connection is insecure then leaking the public key would at least not break anything encrypted using it.
I'm trying to use the Qt Cryptographic Architecture to generate public/private key pairs for nodes, and want to have a protocol in which nodes confirm that a message came from a given source (public key) by issuing a challenge to ensure they are the owners of the corresponding private key. I'm a little stuck on the actual syntax for QCA though ...
This should get me a private key, from which I can also get the public key:
QCA::KeyGenerator generator;
QCA::PrivateKey privateKey = generator.createRSA(1024);
Does QCA already have some sort of challenge protocol built in? If so, how can I use it? If not, how can I apply some of the standard cryptographic challenge protocols using these keys? I'm really just trying to demo a simple security concept - I'm not looking for anything complicated or even particularly robust.
Also, this is a side question, but since I don't need encryption, should I be opting for DSA as opposed to RSA?
There are more than one of doing that. But since all clients already have their asymmetric key pairs you may deploy two-way TLS in establishing connection.
In this scheme both client and server allow establishing connection only, if they trust certificates (public keys) of each other. This guarantees client authentication and non-repudiation.
From your side you will need to provision server certificate to all clients and all client certificates to the server. To avoid dealing with certificate authorities, certificates could be self-signed.
QCA has examples for TLS client and server.
I use transport security over nettcpbinding. How can I verify data over the wire is really encrypted? I tried wireshark, but since data is in binary format without encryption, I cannot distinguish non-encrypted-binary-data and encrypted-binary-data.
Thanks a lot!
just a very general question, but can somebody tell me when I use openSSL and
when IPSEC to secure data transfer over the internet? It seems both of them
are doing the same, only at different levels of the network protocol. So
I am not absolutely sure why we need both of them.
Cheers for your help
Yes, different levels of the network protocol. One is implemented in the OS and the other in an application.
So the reason that both are needed:
IPSEC can secure all traffic including that from applications that don't use encryption. But, both sides must use an OS that supports IPSEC and must be configured by the system administrator.
SSL can secure the traffic for one application. It does not need to use a particular OS and it does not need administrator access permissions to configure it.
You are getting it all wrong buddy...IPSEC is required for a secure communication between two machines.
Like you want to send a packet to other machine but you want that no one could possibly even determine what protocol you are using (tcp/udp.. etc) then you use this IPSEC. and it is not all over there is so much to explore about IPSEC.
openssl is you can say just a encrytion/authentication functions library.
A clear difference could be understood wh a little example.
Suppose you want to secure traffic between two machines so you create secure encrypted packet , send it to other machine there it needs to be decrypted based on security associations.All this is part of IPSEC Protocol.
While when encrypting the packet on your sending machine you may have used some C/Linux functions to encrypt the packet.This is where openssl comes in place.
Similarly on the other end when you will capture the packet and extract the required part then you can decrypt it using openssl function used on your machine.
I tried explaining it with my best ... hope it helped !!! If still you have any doubt do clear !!!
IPSec is based on a configuration file that runs in the background and encrypts all the data between two machines. This encryption is based on IP pairs, an initiator and a responder (at least that's the configuration they use at my workplace, which more or less conforms to the standards). ALL the IP traffic between the two machines is then encrypted. Neither the type nor the content of the traffic is shown. It has its own encapsulation that encapsulates the WHOLE packet (including all the headers that the packet previously had). The packet is then decapsulated (if that's a word) at the other end to get a fully formed packet (not just the payload). The encryption might be using the encryption provided by SSL (e.g. OpenSSL).
SSL, on the other hand, encrypts the data and then you can do what ever you want with it. You can put it on a USB and then give it to someone or just keep it encrypted locally to prevent data theft or send it over the internet or a network (in which case the packet itself won't be encrypted, only the payload, which will be encrypted by SSL).