I'm trying to setup my springboot app on Debian Stretch production server. App uses TLS 1.2 and HTTP2 so I ran it with embedded Undertow and it worked flawlessly on Windows, however it seems to just drop connection after Client Hello on Linux.
this is what it looks like in wireshark:
I was able to connect over insecure http/1.1 with no problems though. I'm pretty sure it has something to do with TLS, because turning it off in application.properties allows Undertow to fallback to http/1.1. (I need multiplexing though)
And I can't find anything that could cause such behaviour. It's not keystore because I get no errors in Java.
The only thing I had to change from Windows were JVM parameters I had to change to make it use IPv4:
java -Xbootclasspath/p:/home/dptools/alpn-boot-8.1.11.v20170118.jar -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses -jar dpTools-0.0.1-SNAPSHOT.jar
Turns out it was keystore after all, not exactly keystore, but keypair inside. Apparently putting special characters in alias is not a good idea. after switching to alphanumeric alias it works. What concerns me is lack of any error on socket binding.
Related
We have a spring-boot application that runs perfectly fine by itself on both Java 11 and Java 17.
The spring-boot application is packaged as a docker container and runs inside gcp/gke kubernetes.
We use the nginx ingress to forward the traffic with tls-passthrough.
We use a Let's Encrypt certificate for our application.
The nginx does not have access to it (AFAICT), but considers it valid.
When using Java 11 everything works fine.
However, when using Java 17 the first (few) requests pass fine, but then I get a certificate error. The nginx generates/has a default ingress certificate, that it uses for the later requests. But I don't understand why it does serve that (sometimes) in the first place.
The error is reproducible with browsers and Java applications.
I did not manage to preproduce it with curl/openssl though.
After a short time/few minutes the error vanishes for the next (few) requests before it emerges again.
When adding the ingress certificate to the trusted certs in browsers I can see that the ingress requests are upgraded to HTTP2, the first few HTTP1 requests all use the correct certificate.
We tried with different java 17 base images (openjdk/eclipse-temurin + alpine/ununtu).
We tried to explicitly disable http2 in Java and the browser.
Nothing seems to work except for adding the self-signed certificate to the trust-store (which is obviously a no go for production).
We weren't able to reproduce this locally, but might be due to our local dev setup being only a simplified version of the cloud environments.
If I use kubectl port-forward into the java app container, I cannot reproduce the issue.
We use the following versions:
nginx-ingress-1.41.3
gke v1.21.6-gke.1500
eclipse-temurin 17
spring-boot 2.6.3 with the default tomcat
TLDR: The nginx-ingress sometimes does not tls-passthrough to our Java 17 app correctly and thus serves an invalid certificate for those requests. (All responses contain the expected/same/valid content except for the certificate).
Has anyone an idea what is happening and how to fix/avoid that?
I'm setting up a new dev environment on a windows 10 pro installation. Therefore i am exporting my spring-boot applications as .jar file and start it as windows service on different ports.
Spring boot app 1 on port 10001
Spring boot app 2 on port 10002
and so on
I already unlocked those ports in my firewall and everything seems working perfectly fine.
When I log into the application with port 10001, everything seems fine as well. However as soon as i log into another application (10002) i get automatically logged off on the 10001 application.
To sum it up, I am only able to be logged into one application at a time.
I am using a MySql8 Server installation. All applications have their own databaseschema. Additionally i am using spring security for authentication.
Because all those applications are running perfectly fine on our productive server (jelastic web hosting) it should have something to do with my dev environment instead of a code issue.
I'm happy you solved your problem. I don't think that using SSL and subdomains is the most simplistic solution to your problem though, especially if you are running automated tests in that environment, ssl might slow you down a bit.
There is a well known address you can bind your application to: 127.0.0.1. However, most people don't know, that your loop back device is actually listening to 127.0.0.1/8 in other numbers 127.0.0.1 with a netmask of 255.0.0.0 which means you can bind your services to any address in a whole class a subnet.
TLDR: try binding your application 1 to 127.0.0.2 and application 2 to 127.0.0.3. That should help with the cookies and later on, if you add monitoring ports, will make your life of managing port numbers easier.
As already mentioned in my comment above, the problem is not related to any software bug, instead its just how http is defined:
"Cookies do not provide isolation by port. If a cookie is readable by a service running on one port, the cookie is also readable by a service running on another port of the same server."
Are HTTP cookies port specific?
I solved my issue by using SSL encryption and different subdomains.
So, I have been using the Java Websockets API to create a WebSocket server in Java, which worked just fine, until I realized I should be using an SSL encrypted connection using "wss:myurl.tld". Basically, the API wants an SSLContext object to work with SSL, but I can't for the life of me figure out how to make one of those.
I looked at some examples and found out that if I could make a Java KeyStore file with a certificate I could make it work, so I tried to do that.
I started fiddling around with trying to get a "Let's Encrypt" certificate following these instructions but I ran into to some problems.
I run windows and I could find no software using the Let's Encrypt system that worked the same as in the instructions, and homebrew on my mac machine is broken, and it's running a too old OS to update.
Being rather inexperienced with SSL I had no real idea what to put in as parameters.
So, in short, how do I make my Java Websocket server use a secure SSL connection?
Oh, and pardon my messy English and lack of question-writing skills, I'm a bit new to these sorts of things.
I spent a lot of time developing an application that would use JSch and connect to a remote machine thru ssh to perform some command-line operations. However I learned that these operations can be performed at the localhost as well (my app is running on localhost). Now... I am too lazy to rewrite all the code and honestly I feel bad since I got really attached to JSch. Is there a way to trick JSch to connect to localhost instead or tell it in some way to just use localhost even though the code says otherwise? :)
P.S. in case it's not possible, how come the regular Proccess class doesnt support setOutputStream and setErrStream like JSch does, but only getInputStream and getErrorStream ??
As long as your local machine has an SSH server running (and your application has the necessary login credentials), you can use JSch to connect to your local machine, too - simply indicate localhost (or 127.0.0.1) as the host name for the connection.
This will have some overhead, though, since you are encrypting and decrypting all the data, which is not really necessary to execute some command locally. (On the other hand, this would allow you to run the commands as another user, for which you otherwise would need something like sudo or su, or RunAs under Windows.)
JSch implements the setOutputStream and setErrStream on top of the corresponding get... methods - it uses something similar to a PipedInputStream internally and a separate thread which shovels the data between those streams.
As JSch is open source, you can simply look how this is done (in the Channel class, if I remember right), and copy the relevant methods to your class which does the same things for a Process.
Is there a way to tell JSch not to encrypt the data?
You can use the none cipher, e.g. no encryption. This is by default disabled in all general-purpose clients and servers (as it defeats half of the purpose of SSH), but with the right configuration you can enable it. In JSch you can use
session.setConfig("cipher.s2c", "none,..."); // server to client
session.setConfig("cipher.c2s", "none,..."); // client to server
(This configuration option is the list of all options the client supports - see the documentation of setConfig for all supported values. The server will normally select the first one of this list that it also supports. To force no encryption (or canceling the connection), list only none.)
I don't know how to enable this in the SSH server - read your server's documentation. (And enable it only for localhost, if possible.)
The recommended way of using it is to switch to the none cipher only after authentication (so the authentication is still encrypted), but for localhost this might not be necessary. (You can use session.rekey() to switch the cipher (and key) after changing the configuration.)
I have a requirement to use client/server architecture and with Open SSL authentication.
Here, how server to know the connect client using their OPen SSL certificate?
Anyone knows the link, sample then please reply me.We have to develop it in Java.
OpenSSL is not Java, so your solution cannot be both - but I think I know what is intended.
Normally OpenSSL is used as part of Apache http as part of mod_ssl. This in turn uses a "connector" to send the requests to an application server, e.g. Apache Tomcat. You can configure this connector to also send the SSL certificates to tomcat if that is required, but normally the authentication/verification is handled within the deamon.
All this is pretty easy to Google, although you should factor in some time to fully understand the connectors. You've the keywords, now use them :)