I am new to SSL/TLS topics, but I need to test the scenario where application deployed on WebLogic 12c (client machine, so to speak) communicates with the SOAP service deployed on WebLogic 12c (server machine). I need to make sure that specific cipher suites are used for this communication. In this regard, I have 2 questions:
Is there a way to set the specific cipher suite in the system properties on the server machine (by setting EXTRA_JAVA_PROPERTIES in one of the startup scripts) to make it choose this cipher suite to communicate to a client machine? If this is not how it can be done, can it be done at all and how?
I can see a lot of cipher suites in the ClientHello message sent by the client machine during the handshake, however when I execute nmap against this machine (nmap -sV --script ssl-enum-ciphers -p port_number machine_name), only a subset of the cipher suites from the ClientHello message is reported. Why? What is the source of truth here? ClientHello message or the result of the above mentioned nmap command?
Ok, I found the answer myself. In order to force the server (WebLogic12c in the above scenario) to choose very specific cipher suite to use in the handshake with the client, you will need to modify $DOMAIN_HOME/config/config.xml file. Search for ssl element and modify it for a server where your service is deployed to (either Admin or managed server). Re-boot WLS after that.
<server>
<name>AdminServer</name>
<ssl>
<name>AdminServer</name>
<enabled>true</enabled>
<ciphersuite>SSL_RSA_WITH_RC4_128_SHA</ciphersuite>
<listen-port>7002</listen-port>
...
</ssl>
Related
Hello I recently set up SSL on my server, and the clients that connect to it need to know what cipher suit to use. I use Let's Encrypt certbot on an Ubuntu 20 server and NGINX webserver.
I was following this tutorial from start to finish: MQTT Broker Setup but it doesn't really get into that level of detail. However, my client devices lists:
Is there a default cipher suit that I can expect or a way to look through the lets encrypt files on the server to see what it is using? In general who determines the cipher suit to be used?
I'm trying a set up a secure websocket in activemq using CA certs, but I keep getting this message in the browser:
SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key)
I believe this is related to the cipher suite, but I'm A) not finding using the right cipher suite or B) configuring it in the wrong area of Apache Activemq. Currently, I've been adjusting the configuration of ssl in transport connector in activemq.xml( http://activemq.apache.org/ssl-transport-reference.html). However, I know that activemq uses a jetty server and i'm wondering if I should be configuring the suite in jetty.xml a la How to config local Jetty ssl to avoid weak phermeral DH key error?.
So, my questions are, is this the right approach? If so, what's the correct cipher suite for activemq?
The Java JDK version 1.7.0_79
Alright, I was able to create a work around by reading the activemq-apollo guide and then matching it to closed JIRA's in activemq:
http://activemq.apache.org/apollo/documentation/user-manual.html#Working_Around_Java_7_SSL_Bugs
https://issues.apache.org/jira/browse/AMQ-4520
I am trying to install IHS certs in Websphere Application Server 8.5
and after I install the IHS WebServer certs I am getting
javax.net.ssl.SSLHandshakeException: no cipher suites in common.
I did not even touch the application server or go into the Cell Level
but both the IHS and the app server are on the same box.
Please help me resolve this and point out where and why is the root
cause for all this.
I don't know Websphere but you can get this kind of error if the server side has no certificates configured and thus falls back to the ADH ciphers (anonymous authentication). These ciphers are usually not supported by the clients, at least not by default and thus you get "no shared ciphers". Just a guess because of lack of more information in the question.
A client installed on jBOSS is trying to access a secured website configured on DataPower xi50v6.0.0.2 appliance. The connection is getting failed at SSL handshake.
I have taken a packet capture at DataPower and observed that SSL Handshake is failing with the Description:Handshake failure(40).
However, at the Client Hello step, I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV.
The TLS protocol used ( as per packet capture) is TLS1.1. Can this Cipher Suite be a problem?
In the DataPower system logs I can see below error:
Request processing failed: Connection terminated before request headers read because of the connection error occurs
Update:
The client application is running on jBOSS7.I have asked our jBOSS administrator to check the configuration at jBOSS end. I somehow got the access to server where jBOSS instance is installed and checked domain.xml where the ssl is configured. Where exactly in domain.xml, ths configuration related to cipher suites can be found?
I have observed that, only one Cipher Suite is specified which is : TLS_EMPTY_RENEGOTIATION_INFO_SCSV
This is no real cipher. If no other ciphers are specified then the client does not offer any ciphers at all which means that no shared ciphers can be found and thus the handshake will fail. It looks like the client is buggy. Reason might be a failed attempt to fight POODLE attack by disabling all SSL3.0 ciphers, which in effect disables all ciphers for TLS1 1.0 and TLS 1.1.
I am trying to use an SSL connection with x11vnc (VNC server) and noVNC (VNC client). Whenever I try to connect, I get the error "Unsupported Security Types: 19,18" from noVNC and "SSL: ssl_helper[2957]: exit case 2 (ssl_init failed)
SSL: accept_openssl: cookie from ssl_helper[2957] FAILED. 0" from x11vnc. If I turn off SSL for x11vnc, the client is able to connect with no problem.
I do realize that x11vnc does come packaged with a java based applet viewer. However, I'm more interested in the HTML5 based noVNC.
Both x11vnc and noVNC both run on the same machine, using the commands:
x11vnc:
x11vnc -forever -shared -unixpw_cmd [cmd] -ssl [pem]
noVNC: ./utils/websockify --ssl-only --cert=[pem] --web=./ 6080 localhost:5900
Note: Both are pointing to the same pem. I use websockify instead of noVNC's launch.sh to have more options such as --ssl-only.
The encrypt option for noVNC seems to have no effect on connecting to the server (the results are the same whether it's on or off).
I am most concerned about a secure connection. As of now, it does not seem like turning on noVNC's encrypt option does much if x11vnc's SSL must be turned off (the encrypt option makes noVNC use wss:// instead of ws://). If this does create a secure connection, please let me know. Else, how can I get noVNC and x11vnc working with SSL?
First some clarifications:
noVNC and websockify are actually separate projects:
websockify is a generic proxy/bridge that allows WebSocket connections (e.g. from a browser) to connect to raw TCP socket services (e.g. a VNC server).
noVNC is the HTML5 VNC client.
If the VNC server supported WebSocket connections then websockify would not be needed. The only VNC server that currently supports direct WebSocket connections is this fork of libvncserver. websockify is included in noVNC since most VNC servers do not yet support WebSocket clients, but websockify is a separate project.
You are dealing with two different network connections each of which has separate encryption options:
noVNC (browser) to websockify - using WebSocket protocol
websockify to x11vnc (VNC server) - direct TCP socket connection
The WebSocket protocol supports unencrypted connections (ws://) and SSL/TLS encrypted connections (wss://).
The RFB protocol (Remote Frame Buffer) used in VNC has the ability to upgrade during the initialization to use an encrypted connection. There are several encryption methods supported such as TLS (security type 18), VeNCrypt (security type 19).
Now to your question:
When you pass -ssl PEM to x11vnc this enabled RFB/VNC encryption. noVNC does not support RFB/VNC encryption. Javascript is not fast enough to do encryption/decryption fast enough to be usable for noVNC. There is some discussion about adding a crypto API to Javascript which would enable noVNC to support this type of encryption.
When you enabled encryption in noVNC you are enabling WebSocket encryption (wss://). This encrypts the connection between the browser and websockify. As long as the connection between websockify and the VNC server are over a trusted network (e.g. running both on the same server) and use WebSocket encryption in noVNC then no unencrypted data will be exposed. However, if you run websockify on the same system as your browser and the VNC server is remote then the VNC traffic from you client to the server system will not be encrypted (unless noVNC gets RFB/VNC VeNCrypt encryption support in the future).
The output from websockify will indicate whether the WebSocket connection is encrypted or unencrypted.