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 Mon, 15 Jun 2015 13:43:25 GMT
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.
>
>


Mime
View raw message