From last few Days we are facing some problem because of Firefox 93(latest version) protects against Insecure Downloads and due to this
Mozilla Firefox block insecure HTTP downloads on a secure HTTPS page,
so we can not download our report which was based on HTTP(without SSL) from our Production Site which is based on SSL Certified HTTPS
Here is I have shown how our report is generated from our Production site
whereas the user sending the request to fetch or downloading the report that time one request goes to the report Server via Java Code and then the report server gives a response for report downloading or fetching a reports
sample response URL Report Server: http//report.abc.com/mycertificate.doc
so whenever we request a downloading a report at that time we get security-related warning from the Mozilla browser while downloading the report
We try some tackle points as follows:
we were trying to make the report server SSL enable but did not work for us because our report server is based on windows server 2003 so all supports from this windows server its almost not good enough for making SSL enable.
2)Reverse Proxy: we also used the concept of reverse proxy in our project which was deployed on JBoss (Wildfly version 9) for that we did configure some code in the standalone.xml file which follows:
Here is the some configuration changes which was we made but no luck for this:
<subsystem xmlns="urn:jboss:domain:undertow:2.0">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<location name="/myservices/services" handler="myproxy"/>
</host>
</server>
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
<reverse-proxy name="myproxy">
<host name="http://www.example.com" instance-id="myRoute" outbound-socket-binding="https-remote"/>
</reverse-proxy>
</handlers>
</subsystem>
<outbound-socket-binding name="https-remote">
<remote-destination host="http://www.example.com" port="${jboss.https.port:8443}"/>
</outbound-socket-binding>
above code snippet I have made changes to the JBoss standalone configuration file but did not get help out from this configuration setting so, What I am looking for is a reverse proxy in Wildfly 9 to handle insecure HTTP downloads on a secure HTTPS page
Any help would be appreciated.
Thanks
Related
We've recently migrated a Spring REST application from Wildfly 15.0.1.Final to Wildfly 21.0.0.Final which apparently introduced an issue with GET requests: whenever we have a | (pipe) character in the query parameter string of the GET request, the request returns no response and we get ERR_HTTP2_PROTOCOL_ERROR.
I know that '|' (pipe) character is unsafe according to the RFC1738 specification of HTTP, while RFC3986 allows for the encoding of Unicode characters.
I would like this to keep working though, as we have external clients sending requests with | character in the query parameter, and currently if we would move to the current Wildfly 21 config, those requests would fail.
The same configuration was working fine on Wildfly 15.0.1.Final.
I have these in standalone.xml with no avail:
<system-properties>
<property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
<property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
</system-properties>
<http-listener name="default" socket-binding="http" allow-unescaped-characters-in-url="true" redirect-socket="https" enable-http2="true" url-charset="UTF-8" />
<https-listener name="https" socket-binding="https" max-post-size="1048576000" allow-unescaped-characters-in-url="true" ssl-context="LocalhostSslContext" enable-http2="true" url-charset="UTF-8" />
...and this in standalone.conf.bat:
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.URI_ENCODING=UTF-8"
The very same code on the very same VM, with (migrated) config works fine on Wildfly 15.0.1.Final but throws the ERR_HTTP2_PROTOCOL_ERROR in Wildfly 21.0.0.Final whenever I have a | in the request. In these cases it looks like the request is not even hitting my breakpoints.
I can programmatically do a dirty fix by URL encoding all | in our $.ajaxSetup, but this only fixes requests originating from the server itself, and not requests that are coming externally with | in their GET request query params.
The dirty (and insufficient) fix:
$.ajaxSetup({
beforeSend: function (jqXHR, settings) {
settings.url = settings.url.replace(/\|\|/g, "%7C%7C");
}
});
Has anyone encountered this issue?
Full standalone.xml (with sensitivre info masked) here.
EDIT: In the meantime I noticed that this issue only happens when I hit endpoints defined in Windows hosts file. When I go through our company's load balancer, it works fine.
So e.g. http://localhost.myproduct.com is not working from SERVER1 if 127.0.0.1 localhost.myproduct.com is in hosts file, but https://server1.myproduct.com that hits the very same server works fine, if the endpoint is routed through the load balancer.
I saw a few related postings around this time, all of which seem to have gone unanswered.
I've also encountered a similar issue with Wildfly 23.0.0.Final, which was a problem with http/2 handling - there is a fix for that: UndertowOptions.ALLOW_UNESCAPED_CHARACTERS_IN_URL has no effect for HTTP/2, but as of this reply AFAIK is not yet released in a Wildfly build.
Setting enable-http2="false" on the listeners - while not ideal - worked around the problem for me.
It could be that your load balancer is doing http/1.1 on the backend which would be why you don't encounter the problem when routing through it.
I'm in the process of creating a simple Mule flow in Anypoint Studio - it polls a directory periodically, and when a file is placed in the directory it sends it to an SFTP server. However, when the application starts negotiating a secure connection with the server, it fails with this error:
java.io.IOException: Error during login to username#host:
Session.connect: java.security.InvalidAlgorithmParameterException: DH
key size must be multiple of 64, and can only range from 512 to 8192
(inclusive). The specific key size 2047 is not supported
The stack trace references several files from the jsch library. The solutions in previous questions recommended upgrading to Java 8, using a different version of jsch, or editing the jsch jars themselves. My Mule server (version 3.9.0 EE) is already on Java 8, I've tried a few different versions of jsch, and editing the jars is not practical, since this application will be deployed to a few different environments.
I'm able to log in to the sftp server using the same credentials as the application via WinSCP. A coworker has tried modifying a working flow to use the same credentials to move the same file, and they get the same error. Here is the XML of my flow:
<flow name="ClCoFlow">
<file:inbound-endpoint path="${file.from}"
moveToDirectory="${file.backup}" responseTimeout="10000"
doc:name="Get File to Transfer" />
<logger
message="#[flowVars.originalFilename] being moved to #[flowVars.moveToDirectory]"
level="INFO" doc:name="File In" />
<sftp:outbound-endpoint exchange-pattern="one-way"
host="${sftp.host}" port="${sftp.port}" path="${sftp.path}" user="${sftp.user}"
password="${sftp.password}" responseTimeout="10000" doc:name="SFTP" />
<logger message="#[flowVars.originalFilename] sent to sftp service"
level="INFO" doc:name="File sent" />
</flow>
Thanks in advance for any help you can provide
EDIT
Though Mule is built on Java, and Mule applications are built behind the scenes using Java and Spring, there is no writing of actual Java code involved in creating a Mule flow.
Changing the provider seems to be the way to go here. Unfortunately, there is no way to do so with Mule connectors, so we kind of have to re-write the sftp connector in plain Java. After downloading the bouncycastle .jars, put them in src/main/app/lib, then add them to the build path. You should be able to import them (for some reason I had to import org.python.bouncycastle.jce.provider rather than org.bouncycastle.jce.provider). At the top of my code I put :
Security.insertProviderAt(new BouncyCastleProvider(), 1);
and when the flow runs, the dh key is properly negotiated and no errors are thrown.
I'm a novice to SSL certifications. I created a web service with Java on a cloud WebSphere Liberty server. I also created certificates by adding the following tags to server.xml
<featureManager>
<feature>webProfile-7.0</feature>
<feature>localConnector-1.0</feature>
<feature>ssl-1.0</feature>
</featureManager>
<keyStore id="defaultKeyStore" location="squery.keystore" type="JCEKS" password="forget1t"/>
However, when my application which is hosted on a different server makes a request to the websphere server, it gets an error Failed to load resource: net::ERR_INSECURE_RESPONSE
I also tried to open the websphere server by Google Chrome, and it responded with NET::ERR_CERT_AUTHORITY_INVALID. What was I missing with the configuration? I really could not find any documents about that. Thanks
I have secured apache reverse proxy configured in front of my websphere 8 application server. I have set generic JVM arguments -Dhttps.proxyHost and -Dhttps.proxyPort but the requests on response.sendRedirect are not directed to peoxy server. It is directed to defualt port 9080.
How to solve this issue ?
I have solved this issue on Tomcat & Jboss by modifying my connector port as follows
connector name="http" protocol="HTTP/1.1" socket-binding="http" scheme="https" proxy-name=" 192.168.1.1 " proxy-port="443" secure="true"
How do I solve this for Websphere ?
I assume that you are using like below
response.sendRedirect(request.getContextPath() +
"/my/main.jsp");
Here - request.getContextPath gives the proxied server info.
As a quick fix I resolved it using the proxy server values from properties files.
response.sendRedirect("get proxy server name from prop file" +
"/my/main.jsp");
Solved this problem by following below steps.
Add following in Apache web server's virtual host tag . What you actually need is to forward along the protocol that was used to access the server.
VirtualHost *:443>
RequestHeader set X-Forwarded-Proto "https"
….
/VirtualHost>
For more explanation refer site
https://www.nczonline.net/blog/2012/08/08/setting-up-apache-as-a-ssl-front-end-for-play/
Following properties needs be added in Websphere webcontainer properties through admin console.
Go to Application servers > server1 > Web container > Custom properties
Add Following properties
httpsIndicatorHeader -
X-Forwarded-Proto (Request header value set in web server (in our case it is https) )
com.ibm.ws.webcontainer.extractHostHeaderPort -
true (To obey request port no)
trusthostheaderport -
true (To obey request port no)
Refered the below site for this settings
http://www-01.ibm.com/support/docview.wss?uid=swg21569667
http://129.33.205.81/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.iseries.doc/ae/rweb_custom_props.html
In our case (Websphere Liberty 21.0.0.9), we simply added a couple of directives in the corresponding Apache virtual host configuration:
RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost On`
These directives are valid only from Apache 2.3.3 on
Both are mentioned in the article mentioned below by #Darshan Shah
I'm having regarding a java web app running on apache.
One of the pages is invoking an applet which code is an external server.
The company responsible of the applet told us to use HTTPS when invoking the page showing the applet as we had problems when we invoked the page using HTTP.
The problem is that when I browse the page in HTTPS , I have an ssl_error_rx_record_too_long error.
The address I want to browse looks like :
https://www.myurl.com:8084/myWebApp/pageContainingApplet.jsp?parameter1=value1¶meter2=value2
I looked for the server.xml file under /conf and added this tag:
<Connector port="8084" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" />
Still nothing
Error code: ssl_error_rx_record_too_long
This usually means the implementation of SSL on your server is not correct. The error is usually caused by a server side problem which the server administrator will need to investigate. Below are some things we recommend trying.
Ensure that port 443 is open and enabled on your server. This is the
standard port for https communications.
If SSL is using a non-standard port then FireFox 3 can sometimes give
this error. Ensure SSL is running on port 443.
If using Apache2 check that you are using port 443 for SSL. This can
be done by setting the ports.conf file as follows
Listen 80 Listen 443 https Make sure you do not have more than one
SSL certificate sharing the same IP. Please ensure that all SSL
certificates utilise their own dedicated IP.
If using Apache2 check your vhost config. Some users have reported
changing to default resolved the error.
Make sure that your SSL certificate is not expired
Try to specify the Cipher:
SSLCipherSuite
ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:+SSLv3
Also check this : https://support.servertastic.com/error-code-ssl-error-rx-record-too-long/