Re: Apacher River over Internet

[Peter]

Some final thoughts; in order to achieve a secure service, as previously 
stated, the client must be authenticated, ie use a CA signed X509 
certificate, this requirement, does tend to place a significant 
inconvenience and burden on clients, limiting River's appeal for the 
internet.  The ObjectInputStream validation prototype I had put forward 
was intended to address this problem, allowing clients to remain 
anonymous, or at least not require a public certificate and instead have 
the connections themselves perform input validation.  Fixing this 
security issue isn't a technical problem, rather it's limited by a 
segment of the development community that believes River is for private 
networks and http restful web services are for the internet.

I'm not sure what advantages restful web services provide (apart from 
clients not requiring CA signed certs for security), given that restful 
service clients are also limited by NAT.  My thoughts are that if I need 
to go to the effort of using resful services for the internet, then I 
should use them for local networks as well.

You've already got River services, provided your clients don't 
themselves export remote objects or need to provide services from behind 
firewalls you don't administer, River should be up to the task.

Cheers,

Peter.




On 15/06/2015 11:43 PM, Peter wrote:
Alternatively, instead of SSLServerEndpoint, HttpsServerEndpoint can 
be used to traverse firewalls and routers, although clients behind 
firewalls must initiate connections to servers due to NAT, the 
following properties, when set at the client allow network ports on 
firewalls the be kept open, to allow the server to contact the client 
for remote events.

   * |com.sun.jini.jeri.https.pingProxyConnections| - If the value is
     case-insensitive equal to |true|, then if an HTTP proxy is being
     used, ping the server endpoint to verify whether it is alive and
     reachable. The ping occurs before the first request and before
     each subsequent request which follows the expiration of the ping
     proxy timeout period (below) following the previous ping. When
     using an HTTP proxy it is often impossible to distinguish between
     inability to reach the server endpoint (such as because the server
     process refused a connection by the HTTP proxy) and the lack of
     response from a delivered request (which might result in an
     UnmarshalException). The ping increases the likelihood that the
     inability to reach the server endpoint can be explicitly
     identified. The default value is |false|, and no pings are done.
   * |com.sun.jini.jeri.https.pingProxyConnectionTimeout| - The number
     of milliseconds from the time a server endpoint was last pinged
     before a ping will precede the next request. The default is
     |Long.MAX_VALUE| (essentially meaning, ping only before the first
     request).


So for example, you could write a distributed taxi program, that 
tracks taxi's and customers, using an internet visible Javaspaces 
services, where the taxi's and customers put and take from the 
javaspace and taxi's can receive event notifications, when new 
customers put requests into the javaspace.

Hope you find this useful.

Cheers,

Peter.


On 15/06/2015 5:51 PM, Peter wrote:
Sergio,

Some additional notes:

  1. Use the BasicJeriExporter (via your configuration) with the
     SSLServerExporter and BasicILFactory
  2. Look at the javadoc in the net.jini.jeri.ssl package, this
     requires SSL certificates.
  3. Set your constraints:
        1. ConfidentialityStrength to strong.
        2. Confidentiality to yes.
        3. ClientAuthentication to yes.
  4. Make sure DGC is disabled (it's insecure), you'll need to retain a
     strong reference locally to your server, to keep your service
     alive; so it doesn't get garbage collected after exporting.

If you grant permissions to your codebase signers (optionally you may 
also configure it to be running with specific Principal's) then you 
don't need to worry about proxy preparation and granting permissions 
dynamically.   Sufficient permissions for the proxy to contact the 
server host will be granted automatically.

Regards,

Peter.

On 14/06/2015 3:36 PM, Peter wrote:
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.