In one of our spring boot apps used in Springcloud dataflow streams, we are currently using HapiContext to construct a new HL7 client and establish a connection out of it to send HL7 messages to a TCP host and port.
#Autowired
HapiContext context;
Connection connection = context.newClient(host, Integer.parseInt(port), false);
// The initiator which will be used to transmit our message
Initiator initiator = connection.getInitiator();
Message response = initiator.sendAndReceive(adtMessage);
Currently we are not using SSL/TLS for this connection and call. but we now have a requirement such that the call should be changed to an SSL based one.
I have tried doing a lot of searches on the Internet, but I am not able to find any documentation on how to achieve this.
Is there anyway to get this done?
How are you creating the HapiContext?
The DefaultHapiContext seems to provide for creating a client with a tls parameter.
lookup for the ca.uhn.hl7v2.hoh.sockets.CustomCertificateTlsSocketFactory, this should have createClientSocket which will add the SSL context necessary
Related
I have a chat implementation working with CometD.
On front end I have a Client that has a clientId=123 and is talking to VirtualMachine-1
The longpolling connection between the VirtualMachine-1 and the Client is done through the clientId. When the connection is established during the handshake, VirtualMachine-1 registers the 123 clientId as it's own and accepts its data.
For some reason, if VM-1 is restarted or FAILS. The longpolling connection between Client and VM-1 is disconnected (since the VirtualMachine-1 is dead, the heartbeats would fail, thus it would become disconnected).
In which case, CometD loadBalancer will re-route the Client communication to a new VirtualMachine-2. However, since VirtualMachine-2 has different clientId it is not able to understand the "123" coming from the Client.
My question is - what is the cometD behavior in this case? How does it re-route the traffic from VM-1 to a new VM-2 to successfully go through handshaking process?
When a CometD client is redirected to the second server by the load balancer, the second server does not know about this client.
The client will send a /meta/connect message with clientId=123, and the second server will reply with a 402::unknown_session and advice: {reconnect: "handshake"}.
When receiving the advice to re-handshake, the client will send a /meta/handshake message and will get a new clientId=456 from the second server.
Upon handshake, a well written CometD application will subscribe (even for dynamic subscriptions) to all needed channels, and eventually be restored to function as before, almost transparently.
Messages published to the client during the switch from one server to the other are completely lost: CometD does not implement any persistent feature.
However, persisting messages until the client acknowledged them is possible: CometD offers a number of listeners that are invoked by the CometD implementation, and through these listeners an application can persist messages (or other information) into their own choice of persistent (and possibly distributed) store: Redis, RDBMS, etc.
CometD handles reconnection transparently for you - it just takes a few messages between client and the new server.
You also want to read about CometD's in-memory clustering features.
As per my last question and with the help I was successfully able to look up an ejb deployed in websphere using the thin client.
Unable to lookup if SSL is enabled in Websphere 8.5
I had also made the SSL-Required for both the inbound and outbound communication.
To conclude my testing I thought of capturing the traffic using the Wireshark to ensure that all the communication is happening over SSL instead of TCP/IP but to my surprise when I seen the packets in wireshark it is still using the TCP/IP and all the data was transferring in text format.
My understanding is once the "SSL-Required" is enabled at the transport layer all the communication and handshake should be happening over SSL rather than TCP/IP. Is my understanding correct ?
Server Configuration :
Sample Client:
public static void main(String args[]) throws NamingException {
Properties ejbProps = new Properties();
ejbProps.put("org.omg.CORBA.ORBClass", "com.ibm.CORBA.iiop.ORB");
ejbProps.put(Context.INITIAL_CONTEXT_FACTORY,
"com.ibm.websphere.naming.WsnInitialContextFactory");
ejbProps.put(Context.PROVIDER_URL, "corbaloc:iiop:160.XX.XX.XX:2809");
InitialContext ffmContext = new InitialContext(ejbProps);
Object remoteObject = ffmContext
.lookup("ejb/MyAppEar-CLUSTER/MyAppEJB.jar/BatchIdTrackingBean#indi.nh.business.framework.bos.di.BatchIdTrackingBeanRemote");
BatchIdTrackingBeanRemote serviceTester = (BatchIdTrackingBeanRemote) PortableRemoteObject
.narrow(remoteObject, BatchIdTrackingBeanRemote.class);
System.out.println(serviceTester);
}
Wireshark capture :
Here , X.X.X.126 is my client location from where I am executing thin client and X.X.X.241 is my websphere app server where i am doing the lookup.
Update :
On analyzing more , i found that when I had enabled the "SSL-Required" , all the data is transferring over TCP/IP but it is encrypted , my understanding is it should be displayed as SSL instead of TCP in wireshark , isn't it ? . And when I made the transport type as only "TCP/IP" , then data transfers over GIOP and I can see the all the data in Text format.
Can anybody please confirm on this behavior ?
I am planning to implement SSL connection with RPC structure in RabbitMQ, where I have RPC server and one RPC client. My understanding is not very clear about the SSL certificate exchange in RabbitMQ. I refered https://www.rabbitmq.com/ssl.html before. My questions are:
Do I have to make connection in my RPCServer as well as in RPCClient code?
Will RPCServer and RPCClient both act as my RabbitMQ clients? If yes, then will I have to create different certificates for both?
Please help me on this as soon as possible.
I am trying to demonstrate to others that my queue is using SSL, however from the RabbitMQ web management tools there seems to be no distinction over which queues are using SSL and which are not.
Using RabbitMQ management on localhost, I am able to see all my queues. I have set up SSL on port 5671 successfully using the troubleshooting from RabbitMQ website.
Using MassTransit I have configured my incoming bus to use localhost:5671/my_queue_name with a client certificate and all is working successfully - I just can't confirm to others that the queue is secure. If I get a message from the queue using the web management tools, I can read the (JSON) message in plain text. Any ideas how I can prove my messages are secure?
I've attempted using BusDriver to peek the queues but get nothing back (independent of whether is SSL or not).
SSL is used to secure connections, not to encrypt queue contents.
What SSL gives you is that communication from clients to RabbitMQ will be encrypted, so you could theoretically be sure that nobody tampered with your messages.
Also if you need to validate that the sender of the message is a particular user, you could use this RabbitMQ extension: http://www.rabbitmq.com/validated-user-id.html
By default, the activemq uses tcp protocol. But now, I change it to use ssl.
If I deploy the publisher and server on one machine, it makes no difference with regard to the speed. But after I deploy them on different machine, it's much slower to use ssl than to use tcp. Is this normal? If not, what's probably wrong with my code?
Thanks.
Depends on how much slower your application is working.
If you process huge amount of data volumes, SSL will take a decent amount of CPU cycles to encrypt (and also decrypt) the data. Is it the ActiveMQ server that is slower or is it the client. Profile the system setup to get an overview where to find the bottenecks.
Another possibillity is frequent hand shakes. Say your client code (can you post it?) to send messages by opening a connection for each message, it might be the case that the latency for sending a message will suffer from the increased SSL handshake time compared to plain tcp.
UPDATE:
A speed up would be to reuse your connection. A SSL handshake has to be done for every message sent in your case which involves cpu expensive asymmetric crypto and a few more tcp roundtrips than plain TCP. It is easy to do, with the pooling connection factory provided by activemq. This example does not alter your code much:
public class MySender{
private static ConnectionFactory factory = new org.apache.activemq.pool.PooledConnectionFactory("ssl://192.168.0.111:61616");
public void send(){
Connection connection = factory.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
Topic topic = session.createTopic(newDataEvent.getDataType().getType());
MessageProducer producer = session.createProducer(topic);
TextMessage message = session.createTextMessage();
message.setText(xstream.toXML(newDataEvent));
producer.send(message);
session.close();
connection.close();
}
}