SSL issue connecting to 2 diff https server at different port; javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake - weblogic

Problem Description
Getting "javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake" error while sending SOAP request over Https URL
Environnent:
1) Weblogic 10.3.6.0.1
2) java version "1.6.0_31" Java(TM) SE Runtime Environnent (build 1.6.0_31-b04)
3) Https Server where posting the request is Jetty Server
Overview:
1) In previous release of application it was sending SOAP message to Server 1 over https URL
2) In current release we implemented new requirement where we are using Third party client jar which internally call third party https server
3) Third party client jar is setting up SSL certificate and posting the request. For SSL they are using 443 port and we have opened Proxy for their host server.
4) Now we have 2 third party servers where we are connecting over Https. Server 1 https port is 30042 and Server2 https port is 443.
Usecase Scenario for error:
1) Submit a request to server 1 over https, getting back response properly.
2) Submit a request to Server2 using Third party client jar through proxy server, getting back response properly.
3) Submit a request to server 1 over https, it failing with error “javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake”.
4) Submit a request to Server2 using Third party client jar , getting back response properly.
5) On server 1 it will always fail and we are not able to send SOAP message over Https
6) For Server 1 app is using SOAPConnection and URL API to post SOAPmessage over Https URL
7) For Server 2 app is using third party provided jar which internally opening the socket and writing on it
Error Codes
---------------------------------------------------
javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
Recent Changes to this Environment
Currently we migrated our application from Solaris to Suse Lunix servers.
Processor specs
Linux onsrnasdfgpsdev1 2.6.32.54-0.3-default #1 SMP 2012-01-27 17:38:56 +0100 x86_64 x86_64 x86_64 GNU/Linux
Weblogic 10.3.6.01
java version "1.6.0_31" Java(TM) SE Runtime Environment (build 1.6.0_31-b04) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
Workaround
• For Server 1 connection if we create a raw Socket and set Host and Port(30042).
• The request is going fine.
• But if we use SOAPConnection or HttpsURLConnection the request are not going and throwing Handshake error
• If we use Http Url for Server1 everything works fine

If the Proxy is set using System Property in that case all the subsequent Https call will use that proxy even though your are not setting in your program, java do that internally.
In our case we want to access Server 1 without proxy and for server 2 we want proxy.
So when we were trying first time to access Server2 we were setting Proxy with system property, after that when we were trying to connect to server 1 it was failing coz the https request was going throught proxy and at our proxy server there was no policy set for server 1
Solutions:
1) Donot set proxy at system level, add at connection level
2) Add rule in proxy server for server 1, so both server 1 & 2 go through proxy
3) At runtime remove proxy from system property before calling server1 and after that set it again. So that Server 2 go through proxy.
Solutions will depend on conditions; choose which is suitable for you.
Thanks Bhanu Thapa

Related

Proxy passing setup for stomp over websocket on apache 2.4

I want to map a domain with my spring websocket deployed on server(tomcat) over port 8090.
I need to access my application through proxy passing over apache 2.4 installed on centOS.
The application(.war file) is being accessed from a client build on
react and this client is on another server.
I followed each step of below article but it is not working in my case.
Getting below error :
WebSocket connection to 'ws://xyz/abc/greeting/251/lcnlhdwc/websocket' failed: Error during WebSocket handshake: Unexpected response code: 400
Please help me.
WebSockets and Apache proxy : how to configure mod_proxy_wstunnel?

apache mina FTPS on remote requets not works

For the Apache MINA FTP Server SSL FILTER configuration : I tried everything and I read more than 50 posts on stackoverflow to find the error. But still no solution.
Problem Is that,
When the SSL Filter Enabled for the Apache MINA FTP, it is working on server side and at the Server Locally FileZilla Client Can Access to server over implicitSSL it works without problem.
I allowed the 21 port and passive ports over firewall for all ips.
But when the remote client wants to access to the server, SERVER getting request but session.write not works then MINA can not switch to USER exec, SO REMOTE client can not connect FTP server.
But when I disable implicitSSL mode on SERVER side, CLIENT can connect . SO, without SSL, Client Connect Remote SERVER. It is tricky But WHY, what is the problem.
If the problem is firewall , why the client connects when I disable implicitSSL.
If the CODE is or configuration is the problem, WHEN I enable implicitSSL =true, WHY local SERVER filezilla application can connect to server over implicitSSL.
**
Please help.
**

Kurento Hello World, not returning loopback

I am trying to setup the basic hello world example.
I am using a t2.micro instance with Ubuntu 14.04 LTS and I have the github code for the example on my local machine.
The url I am using is:
https://localhost:8443/index.html?ws_uri=wss://ec2INSTANCE:8888&ice_servers=[{"urls":"stun:stun.l.google.com"}]#
I do not have the stun or turn configured on the server, but it should be ok since I am passing the stun server to use in the url.
Any advice on this?
I just checked my console and I see this, even though port 8888 is open in AWS Security group that this instance is in
VM8812:35 WebSocket connection to 'wss://ec2Instance:8888/' failed: Error in connection establishment: net::ERR_CONNECTION_CLOSED
I was able to get past the issues that I was seeing
Follow basic instructions on a fresh EC2 (Ubuntu 14.04 LTS), using http://doc-kurento.readthedocs.io/en/stable/installation_guide.html
Add a STUN server in conf
Using stun:173.194.66.127:19302
Tested with http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
Secure WS to use WSS, which is required due to HTTPS requirement since Chrome 47, using http://doc-kurento.readthedocs.io/en/stable/mastering/securing-kurento-applications.html#configure-javascript-applications-to-use-https
Uncomment secure section of /etc/kurento/kurento.conf.js
Create the self signed certificate, and placed in /etc/kurento
Go to https://ec2InstanceUrl:8433/kurento and accept insecure connection
Go to example https://ec2InstanceUrl:8443
You must verify that your STUN server is working by seeing something similar to the below image, with the srflx under Component Type.

The system cannot infer the transport information from xxxx url

I have been trying to configure a simple pass through proxy using wso2 esb, which points to a REST service in https port.
I had tried doing the same using my development machine (Windows 7) and it is successful.
But when I try repeating the same in production server, in RHEL, I get The system cannot infer the transport information error in system log.
Things Tried
Created passthrough proxy service pointing to https://some.domain.in/something/something.
Tried CURL to https://some.domain.in/something/something and its shows the response properly
Imported certificate from the site to client-truststore.jks. Same was done locally and it worked.
in axis2.xml, edited <parameter name="HostnameVerifier">AllowAll</parameter>under https transporter
Error Message
When clicked in test in configuration console, I got the following message, Invalid address
CURL the proxy service URL, and got Empty response
Checked system logs and saw below logs
Am I missing out something?
I could see in the wso2-error-logs following messages
ERROR {org.apache.synapse.transport.passthru.TargetHandler} - I/O
error: handshake alert: unrecognized_name
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
Then I realised that I was using java 1.6 locally but 1.7 in production.
And in Java 1.7 there are some changes in SSL handling
The JDK 7 release supports
the Server Name Indication (SNI) extension in the JSSE client. SNI,
described in RFC 4366 enables TLS clients to connect to virtual
servers.
In order to bypass this, I added JAVA_OPTS="-Djsse.enableSNIExtension=false" in wso2server.sh and restarted.
This solved my problem.
Not sure if this is the correct way though
This url helped me finally

Running Fiddler as a Reverse Proxy for HTTPS server

I have the following situation: 2 hosts, one is a client and the other an HTTPS server.
Client (:<brwsr-port>) <=============> Web server (:443)
I installed Fiddler on the server so that I now have Fiddler running on my server on port 8888.
The situation i would like to reach is the following:
|Client (:<brwsr-port>)| <===> |Fiddler (:8888) <===> Web server (:443)|
|-Me-------------------| |-Server--------------------------------|
From my computer I want to contact Fiddler which will redirect traffic to the web server. The web server however uses HTTPS.
On The server I set up Fiddler to handle HTTPS sessions and decrypt them. I was asked to install on the server Fiddler's fake CA's certificate and I did it! I also inserted the script suggested by the Fiddler wiki page to redirect HTTPS traffic
// HTTPS redirect -----------------------
FiddlerObject.log("Connect received...");
if (oSession.HTTPMethodIs("CONNECT") && (oSession.PathAndQuery == "<server-addr>:8888")) {
oSession.PathAndQuery = "<server-addr>:443";
}
// --------------------------------------
However when I try https://myserver:8888/index.html I fail!
Failure details
When using Fiddler on the client, I can see that the CONNECT request starts but the session fails because response is HTTP error 502. Looks like no one is listening on port 8888. In fact, If I stop Fiddler on the server I get the same situation: 502 bad gateway.
Please note that when I try https://myserver/index.html and https://myserver:443/index.html everything works!
Question
What am I doing wrong?
Is it possible that...?
I thought that since maybe TLS/SSL works on port 443, I should have Fiddler listen there and move my web server to another port, like 444 (I should probably set on IIS an https binding on port 444 then). Is it correct?
If Fiddler isn't configured as the client's proxy and is instead running as a reverse proxy on the Server, then things get a bit more complicated.
Running Fiddler as a Reverse Proxy for HTTPS
Move your existing HTTPS server to a new port (e.g. 444)
Inside Tools > Fiddler Options > Connections, tick Allow Remote Clients to Connect. Restart Fiddler.
Inside Fiddler's QuickExec box, type !listen 443 ServerName where ServerName is whatever the server's hostname is; for instance, for https://Fuzzle/ you would use fuzzle for the server name.
Inside your OnBeforeRequest method, add:
if ((oSession.HostnameIs("fuzzle")) &&
(oSession.oRequest.pipeClient.LocalPort == 443) )
{
oSession.host = "fuzzle:444";
}
Why do you need to do it this way?
The !listen command instructs Fiddler to create a new endpoint that will perform a HTTPS handshake with the client upon connection; the default proxy endpoint doesn't do that because when a proxy receives a connection for HTTPS traffic it gets a HTTP CONNECT request instead of a handshake.
I just ran into a similar situation where I have VS2013 (IISExpress) running a web application on HTTPS (port 44300) and I wanted to browse the application from a mobile device.
I configured Fiddler to "act as a reverse proxy" and "allow remote clients to connect" but it would only work on port 80 (HTTP).
Following on from EricLaw's suggestion, I changed the listening port from 8888 to 8889 and ran the command "!listen 8889 [host_machine_name]" and bingo I was able to browse my application on HTTPS on port 8889.
Note: I had previously entered the forwarding port number into the registry (as described here) so Fiddler already knew what port to forward the requests on to.