we have realized our communications between nodes are using TLSv1. However checking ArtemisTcpTransport.kt class it looks like only v1.2 is supported:
val TLS_VERSIONS = listOf("TLSv1.2")
I would like to use v1.2 in our communications. Is that possible ?
Corda nodes do communicate using TLS 1.2. See https://docs.corda.net/permissioning.html#keypair-and-certificate-formats.
Related
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
Has been changed the RAFT implementation on Corda Version 3 or it is similar to Version 2 and is not possible to disabled TLS v1?
We know Corda use TLS v1.2 but v1 is still active and we need to completely disabled. Is there a way to perform that ?
Thanks!!
There haven't been any changes for that in Corda 3.0, and it's slightly outside our control since it's managed by an external libary we use, Copycat.
I'm just curious why you need to completely disable it – the Raft notary is configured to use TLS v1.2, and you could firewall the Raft ports to only be accessible to cluster members.
I am using Kafka Version 0.10.2.0. Is there a way to secure communication between Zookeper Client i.e ZkClient and zookeper server with SSL. I found some way to do through SASL but i want it through SSL.
Zookeeper 3.5 includes SSL support but it is still in alpha so Kafka doesn't yet support it. The highest supported version is 3.4 which only includes sasl.
Ref: https://issues.apache.org/jira/browse/ZOOKEEPER-1000
This task can still be achieved by a simple workaround mentioned in the steps below;
Install zookeeper-3.5.1-alpha (to use the .jar files. version 3.5+ can be used)
Replace default zookeeper*.jar with /zookeeper-3.5.1-alpha/zookeeper-3.5.1-alpha.jar in <kafka-installation-folder>\libs
Copy /zookeeper-3.5.1-alpha/lib/netty-3.7.0.Final.jar into <kafka-installation-folder>\libs
Relevant changes to enable SSL on Zookeeper (https://cwiki-test.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide)
I'm building a spring-websocket application that currently uses RabbitMQ as a message broker via the STOMP protocol. The rest of our organization mostly uses IBM Websphere MQ as a message broker, so we'd like to convert it away from RabbitMQ. However Websphere MQ doesn't support the STOMP protocol, which is spring-websocket's default. MQTT seems like the easiest supported protocol to use instead. Ideally our front-end web clients will continue to use STOMP, but I'm also OK with migrating them to MQTT if needed.
What classes do I need to overwrite to make spring-websocket interface with the broker via MQTT instead of STOMP? This article provides some general guidance that I should extend AbstractMessageBrokerConfiguration, but I'm unclear where to begin.
Currently I'm using the standard configuration methods: registry.enableStompBrokerRelay and registerStompEndpoints in AbstractWebSocketMessageBrokerConfigurer
Ryan has some good pointers.
The main work is going to be creating a replacement for StompBrokerRelayMessageHandler with an MqttBrokerMessageHandler that not only talks to an MQTT broker but also adapts client STOMP frames to MQTT and vice versa. The protocols are similar enough that it may be possible to find common ground but you won't know until you try.
Note that we did have plans for for MQTT support https://jira.spring.io/browse/SPR-12581 but the key issue was that SockJS which is required over the Web for fallback support does not support binary messages.
Here's my stab at this after reviewing the spring-websocket source code:
Change WebSocketConfig:
Remove #EnableWebSocketMessageBroker
Add new annotation: #EnableMqttWebSocketMessageBroker
Create MqttBrokerMessageHandler that extends AbstractBrokerMessageHandler -- suggest we copy and edit StompBrokerRelayMessageHandler
Create a new class that EnableMqttWebSocketMessageBroker imports: DelegatingMqttWebSocketMessageBrokerConfiguration
DelegatingMqttWebSocketMessageBrokerConfiguration extends AbstractMessageBrokerConfiguration directly and routes to MqttBrokerMessageHandler
Add this to server.xml on WebSphere Liberty:
<feature>websocket-1.1</feature>
I have to write a simple c code for CONNECT API function in MQTT to an Active MQ broker without using the existing libraries. I am new to this protocol and any help would be great.
In that case, you'll just want to get the MQTT specification. The current version, 3.1, can be found here: http://www.ibm.com/developerworks/webservices/library/ws-mqtt/index.html
The protocol is currently undergoing standardisation at Oasis. You can find the draft version of the updated spec through the documents link at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt , but you should bear in mind that Active MQ almost certainly only supports version 3.1.
Here is a link that explains how to write a simple MQTT client https://www.ibm.com/developerworks/community/blogs/messaging/entry/write_your_own_mqtt_client_without_using_any_api_in_minutes1?lang=en . You will need to code the required part of the MQTT client.