river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Security & Re: Discovery V2 migration
Date Fri, 10 Jun 2011 15:58:38 GMT
:)

Agree re: users@

For a bit more context of where I'm coming from: "opinionated
software" (http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php)

We can potentially improve River's appeal by making some tough choices....

On 10 June 2011 16:53, Tom Hobbs <tvhobbs@googlemail.com> wrote:
> 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
View raw message