river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: Apacher River over Internet
Date Sun, 14 Jun 2015 05:36:51 GMT
Hi Sergio,

No IIOP isn't the right solution, IIOP is designed for intra language 
operability (eg C or C++) on local trusted networks.

Firstly there are some restrictions on internet communications due to 
firewalls and NAT (network address translation):

   1. Services (servers) must be visible, that is have a static IPv4
      address or an IPv6 address that is globally visible on a known
      port, or is a known port on a resolvable domain name address.
   2. Services behind firewalls with NAT, must be assigned a port on the
      firewall.
   3. It is possible for clients behind firewalls to contact an internet
      visible service, and be contacted by the service, but only after
      the client has initiated communications, so for instance, clients
      of javaspaces on separate private networks, may put and take from
      an internet visible javaspace service.

If you want security, use secure unicast discovery, clients and servers 
must be authenticated prior to any deserialization occurring, see 
javadoc for the following packages or classes:

   1. com.sun.jini.discovery.ssl
   2. net.jini.discovery.ConstrainableLookupLocator
   3. net.jini.discovery.LookupLocatorDiscovery
   4. net.jini.core.constraint.ClientAuthentication
   5. net.jini.core.constraint.ServerAuthentication
   6. com.sun.jini.discovery.DiscoveryProtocolVersion (TWO)

When you configure your lookup service (Reggie), you must configure it 
to always use client authentication, this strategy should also be 
adopted for any other services you have.

Your also need to sign your codebase jar files.

Don't concern yourself too much with proxy trust, this is performed 
after downloading, class loading and deserializing a proxy (too late), 
the only way to ensure security, is to authenticate servers and clients 
and sign codebases.  Do not allow anyone to register their services to 
your lookup service without authenticating.

Don't believe the outdated story that Reggie doesn't pose a security 
risk, it's only secure if clients are always authenticated.  If you 
don't authenticate your clients, over a secure connection, then Reggie 
is exposed to deserialization attacks.

For client security, make sure you always authenticate the lookup 
service (during discovery), also install the 
net.jini.loader.pref.RequireDLPermProvider and grant 
net.jini.loader.DownloadPermission to your codebase signers.

With regards to proxy trust, I recently investigated fixing security 
issues and developed a working prototype for community demonstration / 
discussion (doing so would allow the establishment of a service 
community where not all parties were known to each other and 
authentication of clients wasn't always desired or required):

   1. Input validation (similar to a web server validating html) of data
      streamed to an ObjectInputStream, which ultimately involved the
      replacement of the ObjectInputStream, to prevent deserialization
      attacks (Constraint based).
   2. Annotating jar files with permissions required by a service proxy
      (least privilege principle), to be granted during proxy trust
      establishment.
   3. Inversion of responsibility during proxy trust establishment,
      instead of performing untrusted class loading, for a smart proxy,
      prior to asking it for a bootstrap proxy, then determining proxy
      trust (too late).  Instead, obtain the bootstrap proxy (local code
      only, with input validation) and ask it for the smart proxy during
      proxy trust verification, this also allows for delayed
      unmarshalling during lookup and filtering on entry's locally,
      before any codebase downloading is performed.

However the prototype wasn't well received, the community expressed 
concern that River is well established on local networks and discussing 
security and its problems on the internet creates a perception that 
River is complex.  My original plan was to first fix security, then to 
create tools to streamline it.

There is an opportunity for River to remove proxy trust and simplify 
security, which fits well with expressed concerns, for limited internet 
connectivity (where all connections are securely authenticated and the 
lookup service authenticates clients and all clients know and trust each 
other), leaving proxy trust as is, without fixing however, leaves 
security complicated superfluously.

So as I said, don't be too concerned about proxy trust; it doesn't 
enhance security under current circumstances.

Regards,

Peter.

> Hi, I have an client/server application using Apache River using the
> BasicJeriExporter over tcp/ip. Now I have a requirement to use it across
> the Internet (currently using local network). How could be it done? I saw
> Apache River can communicate using IIOP, would it be a good approach? Has
> someone tried to use Apache River over IIOP?
>
> Thank you.

Mime
View raw message