river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: Security & Re: Discovery V2 migration
Date Mon, 13 Jun 2011 13:50:46 GMT
Dan,

I have no idea what would be a pragmatic migration, and that's the problem. I spent a couple
of days last Decemeber trying to migrate from V1 to V2 (see http://www.mail-archive.com/river-user@incubator.apache.org/msg00197.html
and followup messages). The blocker for me, ultimately, was that I had V1 clients in the field
that lacked a META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider file. Those
clients will never (NEVER!) be able to speak to a V2 registrar because those clients will
not accept any DiscoveryFormatProvider that the server offers. Currently, there's no way for
Reggie to simultaneously support V1 and V2 clients (you probably wouldn't want that anyway
because it would allow a downgrade attack).

My own sad migration strategy has been to roll out V1 clients with a very basic META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider
file and hope that within a couple of years all of my old clients will be retired and I can
push out an incompatible change to V2. But that seems unlikely because I still have clients
dating back to 2006 released code (increasingly rare, thankfully).

Chris

-----Original Message-----
From: Dan Creswell [mailto:dan.creswell@gmail.com] 
Sent: Friday, June 10, 2011 1:01 PM
To: dev@river.apache.org
Subject: Re: Security & Re: Discovery V2 migration

Okay, so what is a pragmatic migration then?

That tells us something about potential solutions. Although there
probably isn't one if we're saying we can't ever disrupt clients....

On 10 June 2011 18:28, Christopher Dolan <christopher.dolan@avid.com> wrote:
> But v2 isn't backward compatible with anything, even itself if you're missing the META-INF/services/com.sun.jini.discovery.DiscoveryFormatProvider
file. I've tried to upgrade my djinn to v2, but it requires a flag day because any existing
v1 clients will never be able to speak to v2 servers if the clients lack the provider file.
>
> I think a prerequisite for deprecation of v1 would be a pragmatic migration path to v2.
With the current v2 implementation, I don't think such a migration is possible.
>
> Chris
>
> -----Original Message-----
> From: Dan Creswell [mailto:dan.creswell@gmail.com]
> Sent: Friday, June 10, 2011 10:47 AM
> To: dev@river.apache.org
> Subject: Re: Security & Re: Discovery V2 migration
>
> 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