river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: Security & Re: Discovery V2 migration
Date Fri, 10 Jun 2011 15:53:36 GMT
At risk of aligning myself with the flamebait ;-),  this isn't a bad idea.
We've got a number of major version number style changes in the pipeline.
Lets talk about the possibility of rolling this into that.

Lets also make sure such discussions find their way onto users@ as well
though.

Cheers Dan.

On 10 Jun 2011 16:47, "Dan Creswell" <dan.creswell@gmail.com> wrote:
> Controversial position: Why don't we just deprecate the entirety of V1?
>
> That means less work to do, no nasty dark corner workarounds as we try
> and retain compatibility, a clear policy on what will work with what
> etc. Fact is V2 has been around so long that most people are surely
> using it by now?
>
> I just am not a fan of backward compatibility without some very good
> reasons, history shows this sort of "holding onto the past" to be a
> nightmare for all concerned. One needs to look no further than the JDK
> itself which is full of cruft and cut corners for the sake of
> compatibility.
>
> On 10 June 2011 08:51, Peter Firmstone <jini@zeus.net.au> wrote:
>> _Unicast Discovery v2 - Unmarshalling Attack with Registrar proxy._
>>
>> During unicast discovery, we have the option of using SSL, Kerberos or
x500
>> discovery implementations, unfortunately, if the unicast discovery
>> implementation being used doesn't comply with constraints for
Authentication
>> and Confidentiality, the constraints are re tried against the
unmarshalled
>> registrar proxy, bypassing the security benefits these implementations
>> provide.
>>
>> I believe this was an oversight to allow codebase integrity constraints
to
>> bubble up as Unfulfilled Constraints to the upper layer, where they're
>> checked against the unmarshalled proxy, unfortunately it appears to be a
>> mistake to allow Authentication and Confidentiality constraints to bubble
up
>> during discovery.
>>
>> I think we should change this specifically for Authentication and
>> Confidentiality constraints, if these are requested but not satisfied
during
>> discovery we should throw an UnsupportedConstraintException.
>>
>> Doing so avoids the DOS unmarshalling attack which is possible during
>> unmarshalling of an unauthenticated registrar proxy.
>>
>> _Unicast Discovery v1_
>>
>> In light of Unicast Discovery v1's total lack of support for security, I
>> believe we should deprecate it, for this to happen we also need to
provide a
>> way for existing deployments to migrate.
>>
>> LookupLocator performs unicast discovery v1.   ConstrainableLookupLocator
>> extends LookupLocator and is used for v2 unicast discovery constraints.
>>
>>
>> _But what about Multicast Discovery?
>>
>> _Multicast discovery produces a LookupLocator which is used by Unicast
>> Discovery to retrieve a registrar proxy.
>>
>> _Multicast Request Protocol v1
>>
>> _Please add any security concerns here.
>>
>> No integrity support - how much of a problem is this?
>>
>> _Multicast Request Protocol v2
>>
>> _x500 integrity supported_
>>
>> __Multicast Announcement Protocol v1
>>
>> _Please add any security concerns here.
>>
>> No integrity support, packets can be modified in transit, but this
doesn't
>> seem to be much of a concern for announcement anyway.
>> _
>> __Multicast Announcement Protocol v2
>>
>> _x500 integrity supported.
>>
>> Note that Multicast v2 supports x500 integrity constraints, in addition
to
>> plain text, while it doesn't prevent someone viewing the contents of the
>> packet, it ensures the packets contents haven't been tampered with.
>>
>> I don't see a reason to deprecate Multicast Discovery v1 for existing
>> deployments,  x500 integrity is an obvious advantage, but the real threat
to
>> security occurs during Unicast Discovery, when unmarshalling attacks can
>> occur.
>>
>> So we could, in theory at least, use a LookupLocator from Multicast v1
>> discovery with Unicast v2 discovery in newly deployed clients  and
>> registrars to remain network compatible with existing clients that only
>> support D v1.
>>
>> Figuring out how to solve the migration problem?
>>
>> I think most of the migration problem exists with Multicast, so for
legacy
>> support reasons a djinn could employ Multicast v1 with a combination of
>> Unicast v1 (for older clients) and v2 for the latter.
>>
>> Registrar's could have providers for both v1 and v2 discovery and thus
reply
>> to both.
>>
>> This will require some revisions to discovery utilities (implementing
>> DiscoveryGroupManagement) for our next release, in order to provide an
>> upgrade path for existing djinn's.
>>
>> Any ideas?
>>
>> Cheers,
>>
>> Peter.
>> *
>> *_
>> _
>>
>>
>>
>>
>> Hi Peter.
>>
>> I don't remember enough about this to know for sure if this problem is as
>> stated. I thought the resources were defined in the default Jini 2.0 JAR
>> files, but that could have changed after my time. Mike Warres was the
>> initial author of this stuff, but others at Sun took over from him before
>> the effort stopped. I don't know if any of those guys are still following
>> the conversation.
>>
>> - Tim
>>
>> On Dec 12, 2010, at 2:31 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>>
>>> Tim,
>>>
>>> Do you know of an alternative plan to Chris' suggestion, for migration
>>> from Discovery V1 to V2?
>>>
>>> It probably all happened too long ago to remember now, just wondering if
>>> anything comes to mind?
>>>
>>> I'll look into it further too.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>> Since its inception, my project has been using DiscoveryV1 and we've
>>>> never dealt with Jini constraints.  Peter's comments last week about
the
>>>> flexibility of DiscoveryV2 inspired me to learn more about it and to
>>>> experiment a bit.  To my surprised, I found it very difficult to figure
>>>> out how to turn V2 on (I ended up reading a lot of source code), and it
>>>> looks like it's nearly impossible to migrate in a backward compatible
>>>> way, i.e. continuing to fully interact with services that were deployed
>>>> with the default preference for V1.  I would LOVE to be told that I've
>>>> made a mistake or missed something important...
>>>>
>>>> * To switch Reggie to use V2 for multicast announcements:
>>>>
>>>> com.sun.jini.reggie {
>>>>   discoveryConstraints = new BasicMethodConstraints(new
>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>>>> }
>>>>
>>>> * To switch group discovery to use V2 for multicast requests:
>>>>
>>>> net.jini.discovery.LookupDiscovery {
>>>>   discoveryConstraints = new BasicMethodConstraints(new
>>>> InvocationConstraints(null, DiscoveryProtocolVersion.TWO));
>>>> }
>>>>
>>>> * To create a locator that uses V2 for directed unicast discovery:
>>>>
>>>>   new ConstrainableLookupLocator(host, port,          new
>>>> BasicMethodConstraints(new InvocationConstraints(null,
>>>> DiscoveryProtocolVersion.TWO)));
>>>>
>>>>
>>>> * To tell DiscoveryV2 how to encode and decode the messages, create a
>>>> file called
>>>> "META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider" and
>>>> put in lines (for example):
>>>>
>>>>  com.sun.jini.discovery.plaintext.Client
>>>>  com.sun.jini.discovery.plaintext.Server
>>>>
>>>> However (and this is the key problem), any deployed clients or Reggies
>>>> which lack the
>>>> META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file
>>>> will not be able to decode the incoming messages and will drop them
with
>>>> an error message about unknown format IDs.
>>>>
>>>> So, the only solution I can see is to start shipping new services with
>>>> the DiscoveryFormatProvider file in place, and then wait several
>>>> releases until all of my old deployments have been retired, and then
>>>> turn on the V2 preference.  Am I wrong?  Is there a trick to get
>>>> already-deployed clients to use a format ID that they don't know about?
>>>> Surely other people have had similar problems deploying brand-new
>>>> DiscoveryFormatProvider implementations?
>>>>
>>>> Is there a way to make services send out both V1 and V2 multicasts?  Is
>>>> there a way to tell LookupDiscovery.UnicastDiscoveryTask to try V2
first
>>>> and then retry with V1?
>>>>
>>>> I feel like I'm missing some central point...
>>>>
>>>> Chris
>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message