We have an app running on tomcat port 8080, and we are fronting Apache httpd, SSL is installed and implemented, all the request are redirected to port 443, and proxy to tomcat 8080 by mod_proxy_httpd:
ProxyPass / http://localhost:8080/ retry=0 timeout=5
ProxyPassReverse / http://localhost:8080/
Everything works just fine, request from client to httpd is secured, however obviously communication between httpd and tomcat are not encrypted.
My question is:
1.would it be an issue if the communication between httpd and tomcat are not encrypted? provided httpd and tomcat are under same sever?
2.We are transmitting sensitive data, such as customer credit card information during payment processing, do we need to implement SSL on tomcat also (e.g.port 8443), and proxy the request from 443 to secured tomcat port 8443? So it is gonna be all secured from client to httpd to tomcat, however this could be affect the performance, since 2 way encryption/decryption is needed.
We have been searching on this issue, but found no clear answers. Any help is greatly appreciated.
If you stick to localhost (e.g. have Apache httpd on the same server as tomcat) this most likely is secure: If you don't trust the implementation of the "localhost" networking, you couldn't trust the TLS implementation on the same server as well.
You might gain performance by having Apache on a different server than tomcat. In that case you obviously depend on the network between both: Routers, cabling etc. If you don't trust your network, this might be something that you can work on. However, note that you probably also have some connection between tomcat and filesystems (temp files), databases, etc. - with transport encryption nailed, data can still leak out of this application if you can't trust your datacenter/network security.
We can't judge to what level you can trust your network, you'll have to do this by yourself.
Note that in the case you mention in the question, tomcat will have no idea that a connection has been made in https when you just forward on http (e.g.: Browser -> Apache is https, Apache -> tomcat is http)
You can configure tomcat's connector to assume that the connection was secure (look up the secure attribute on the connector's documentation), but this also means that you absolutely need to make sure never to allow a http connection to be forwarded to that connector. Check if AJP (a different protocol) is for you - it will forward all of the HTTP(S) connection's properties properly to tomcat. Some like it (me among them), some don't.
Related
A Tomcat server on my server is running on port 8080.
We are in need to use the Tomcat server to get user requests and forward those to corresponding proxy server running on another server (111.111.111.111:9090, user: XXX, pw: YYY).
So: We need to configure Tomcat to transfer requests to another server.
You can't do this out of the box with Tomcat. It does not include HTTP reverse proxy functionality. You'd either need to find a 3rd-party module to do this (I'm not aware of any) or code up something yourself - e.g. using Apache HttpClient.
We are using Embedded Jetty as our webserver running on port 8080 and want to monitor the application on Jconsole. We are using the following system property when starting the Jetty server specific to JMX:
-Dcom.sun.management.jmxremote.access.file=jmxremote.access
-Dcom.sun.management.jmxremote.password.file=jmxremote.password
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=8081
Although, JMX and Webserver are running on two different ports, is there a way for client to access JMX via Jconsole/JvisualVM using port 8080? Is JMX Proxy going to help me in anyway? Is it possible in any way?
Thanks in advance.
Ajay
Not without some effort. In a nutshell, there can always only be a single server on one port (or the other way around: Servers can't share a port).
If JMX was supporting HTTP requests, then you could run it as a servlet on the same HTTP server. There would be one port (used by the HTTP server) and then the HTTP URLs would allow the server to determine whether the client wanted to talk to JMX or the web application.
But JMX doesn't support HTTP requests directly. You can try Jolokia (see this question) or you can write servlets which allows a client to query certain mbeans (but without JMX protocol).
JMX specification have Connector that can use any protocol as transport, see http://en.wikipedia.org/wiki/File:Jmxarchitecture.png
I am running a web application on Tomcat (port 8080) with Apache (port 80) in front (on Ubuntu) using mod-proxy_http as the connector. The app is available through port 80 but also through port 8080. This is actually quite useful (when deploying/testing).
Are there are any particular disadvantages/vulnerabilities with keeping port 8080 open in this way?
My opinion is that you should close 8080 port, or at least allow it for certain host/IP. Less open ports, less problems. Opening port 8080 could let attacker to have more entry points (80 and 8080, using different technologies) and exploit different techniques. Also HTTPd server has much better security modules.
Have you consider using mod_ajp_proxy?
Hope this helps.
I know my RMI app works correctly - it works fine when the server is on localhost and inside the LAN but when connecting to an external RMI server it fails when trying to make stub calls
So the server is bound to localhost (an internal IP - 192.168.1.73) but the client is specifying an external IP (45.4.234.56) - which then gets forwarded to the internal server. How do you resolve this problem?
thanks
The "simplest" approach is for your network admin to add IP forwarding from a specific port on the firewall to your server.
Assuming this isn't an option (and it probably isn't), then RMI supports tunnelling over HTTP. The performance is poor, but it's much more firewall-friendly.
http://java.sun.com/javase/6/docs/technotes/guides/rmi/faq.html#firewallOut
This well-worn method is popular since
it requires almost no setup, and works
quite well in firewalled environments
which permit you to handle HTTP
through a proxy, but disallow regular
outbound TCP connections.
If Java RMI fails to make a normal (or
SOCKS) connection to the intended
server, and it notices that a HTTP
proxy server is configured, it will
attempt to tunnel Java RMI requests
through that proxy server, one at a
time.
I am using JBoss 4.0.4 GA, which has Tomcat Servlet Container 5.5.
I also have IIS 6.0 redirected to this JBoss. (via IIS tomcat connector, which is used as ISAPI filter in IIS).
All is working OK, configured the workers as described.
Here is a piece of workers.properties file of the connector:
#
# Defining a worker named ajp13 and of type ajp13
# Note that the name and the type do not have to match.
#
worker.jboss0_ajp13.port=8009
worker.jboss0_ajp13.type=ajp13
worker.jboss0_ajp13.host=localhost
worker.jboss0_ajp13.socket_keepalive=1
worker.jboss0_ajp13.socket_timeout=300
But when connecting to the application via IIS (port 80), for each completed HTTP response for HTTP request, the socket is closed (FIN is sent on the TCP layer).
This causes severe slowdowns, since the application is working over WAN. (for each closed socket, another one needed to be established, which takes 500ms).
This is not happening when connecting to JBoss web server directly, and also not happening when connecting to a different virtual directory on the same WebServer instanse of IIS (i.e. Keep-Alive in IIS is also configured).
This happens with the latest version of tomcat IIS connector.
Do you know if there is a bug in the connector, or there is a problem with my configuration?
Thanks in advance,
Henry.
I filed a bug in Bugzilla for tomcat IIS redirector, and this is the answer I've got:
Up until 1.2.27 this was the behaviour of the IIS connector (IIS forces all
ISAPI extensions to implement their own HTTP keep alive, and the IIS connector
didn't do this).
In 1.2.27 there's experimental, build-time, support for HTTP 1.1 chunked
encoding, which should permit persistent connections.
(I've been using pretty much the same code in production systems for about 4
years, but it should be considered experimental in the JK codebase until it's
been stable for a while).
Grab the -chunked binary from one of the download mirrors and read about how to
configure chunked encoding in the 1.2.27 release notes (you have to get the
right build, and enable it in your config).
You can verify that the connector is using chunked encoding with debug logging
on, and a TCP/Wireshark trace should show connections being reused.
If you're still getting closed connections, and the logs show that the
connector is attempting (or should be attempting) chunked encoding, then it's
probably best to discuss on the users list and then reopen with another
Wireshark trace + connector debug log once you're sure there's an issue.
So, what I did:
Put isapi_redirect.dll with chunking support.
Configured the isapi_redirect.properties with the following:
enable_chunked_encoding=1
Restarted IIS.
The socket is probably being closed by IIS. The connection between JBoss and IIS should be irrelevant to the HTTP socket being persisted or not. Ensure that IIS is configured to support persistent HTTP/1.1 sockets.
However, you point out that another virtual directory in IIS does not have the same problem. It could be a problem with the specific virtual directory that is having problems. However, it could also be something in the IIS/Tomcat connector.
To investigate whether it is the IIS/Tomcat connector, try setting
worker.jboss0_ajp13.connection_pool_size=10
worker.jboss0_ajp13.connection_pool_timeout=600
to see if it makes any difference at all. See Tomcat Workers Docs (including the section at the bottom "A sample worker.properties"). See if any of the parameters mentioned there help you out.