JDK-4967123 : RMI HTTP tunneling without client-side HTTP proxy
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • CPU: x86
  • Submitted: 2003-12-11
  • Updated: 2013-10-25
  • Resolved: 2013-10-25
Related Reports
Relates :  
Description

Name: gm110360			Date: 12/11/2003


FULL PRODUCT VERSION :
> java -version
java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)


FULL OPERATING SYSTEM VERSION :
> rpm -q glibc
glibc-2.2.5-164

> uname -a
Linux i40pc30 2.4.19-4GB #1 Wed Nov 27 00:56:40 UTC 2002
i686 unknown

ADDITIONAL OPERATING SYSTEMS :
Operating system independent


A DESCRIPTION OF THE PROBLEM :
RMI HTTP tunneling

After 4476239 "Clarification needed on HTTP-tunneling info
in JDK
1.3.0 RMI specification" will be fixed, the RMI
specification should
  state that for HTTP-tunneling to work one needs to use a
HTTP proxy
(e.g. the client virtual machine must specify at least the
property
http.proxyHost).

While an HTTP proxy on the client-side is necessary for the
RMI-Http-To-Port method to be effective, it is not necessary
for the
RMI-Http-To-CGI method. While in the first case there is a
firewall
around the client, in the second case, there is a firewall
around the
server (and possibly additionally around the client).

In a situation, where a firewall only exists around the
server, there
is no need for the client to use an HTTP proxy to access the
server
through the RMI-Http-To-CGI method. There may be situations,
where the
client even does not have such proxy.

The property "java.rmi.server.disableHttp" should be
replaced with a
property "java.rmi.server.enableHttp" which is set to true by
default. Then the RMI-Http-To-CGI method should the used if

  (
    java.rmi.server.enableHttp &&
    (
      (
        "The connection attempt failed with
UnknownHostException or
         NoRouteToHostException"
      ) ||
      sun.rmi.transport.proxy.eagerHttpFallback
    )
  )

The RMI specification should be updated accordingly.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Uses two linux hosts hosta and hostb

2. Install a firewall on hostb that blocks access to port
1099 form hosta

iptables -t filter -I INPUT -s hosta --protocol tcp
--destination-port 1099 -j REJECT --reject-with
icmp-host-unreachable

3. Install a webserver on hostb with "the" CGI script
/cgi-bin/java-rmi.cgi

4. Start an RMI server application on hostb

5. Start an RMI client on hosta that does not have an HTTP proxy


EXPECTED VERSUS ACTUAL BEHAVIOR :
According to the specification, the connection attempt
fails, because the RMI client on hosta does not specify an
HTTP proxy.

Since the firewall is only "around" the server, the client
should try the CGI connection method, and the connection
should succeed.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
If no HTTP proxy is available to the client, one can specify
a dummy host, and prevent it from being used by setting the
following properties:

-Dhttp.proxyHost=nohost.nowhere.com
-Dhttp.proxyPort=4711
-Dhttp.nonProxyHosts="*"

Works, but is not the intuitive way...
(Incident Review ID: 179758) 
======================================================================

Comments
We've deprecated HTTP tunneling; see JDK-8023862. Closing as Won't Fix.
25-10-2013

EVALUATION Note that the "HTTP-to-CGI" tunnelling scheme used by RMI's default global socket factory was not intended as a way to support server-side firewalls. This feature could be considered for a future (post-Tiger) release. ###@###.### 2003-12-12
12-12-2003