zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Kelly <iv...@apache.org>
Subject Re: QOP SASL property
Date Fri, 09 Oct 2015 18:55:00 GMT
Just to add, digest-md5 is obselete now[1], due to vulnerability to MITM
attacks, so that case would need SSL in any case.

krb is still safe though.

[1] http://tools.ietf.org/html/rfc6331

On Fri, Oct 9, 2015 at 7:10 PM Chris Nauroth <cnauroth@hortonworks.com>
wrote:

> Ivan is right.  Thank you!  I forgot about this part.
>
> When QOP is "auth" (the default), then SASL is just a one-time handshake
> at the front of the connection, and the subsequent transfer of bytes
> between client and server remain the same.  When QOP is "auth-int", SASL
> needs to inspect the transferred bytes for digest-MD5 verification to
> guard against man-in-the-middle tampering.  When QOP is "auth-conf", SASL
> needs to encrypt the bytes for privacy against a man-in-the-middle.  The
> latter two cases require the wrap/unwrap calls that Ivan mentioned.
>
> In Hadoop, we encapsulate the wrap/unwrap behind special stream subclasses
> that wrap over the underlying "raw" stream.
>
> https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/ha
> doop-common/src/main/java/org/apache/hadoop/security/SaslInputStream.java
> <https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SaslInputStream.java>
>
>
> https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/ha
> doop-common/src/main/java/org/apache/hadoop/security/SaslOutputStream.java
> <https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/SaslOutputStream.java>
>
>
> That's nice, because the code consuming the streams doesn't need to worry
> about repeated wrapping and unwrapping.  However, even if we set up
> something like these classes in ZooKeeper, it appears the ZooKeeper
> codebase isn't structured to make inserting those wrappers easy.
>
> This does look like it would be more invasive than I originally described.
>
> --Chris Nauroth
>
>
>
>
> On 10/9/15, 7:57 AM, "Ivan Kelly" <ivank@apache.org> wrote:
>
> >I think it's a fairly big change, especially since we'd then have a lot of
> >conditional if (sasl) { wrap_bytes } else { dont_wrap }. And then it
> >affects all communication between server and client, which is quite risky.
> >
> >On Fri, Oct 9, 2015 at 4:54 PM Flavio Junqueira <fpj@apache.org> wrote:
> >
> >> Ok, got it, but it sounds like we can just wrap and unwrap the bytes we
> >> are sending, no? Do you think that will end up being a lot of changes?
> >>
> >> -Flavio
> >>
> >> > On 09 Oct 2015, at 15:38, Ivan Kelly <ivank@apache.org> wrote:
> >> >
> >> > To protect the integrity of each packet, each packet needs to be
> >>wrapped
> >> by
> >> > SaslClient/SaslServer (see wrap/unwrap in
> >> >
> >>
> >>
> http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/SaslClient.h
> >>tml
> >> ).
> >> > Currently sasl is only used to initialize the connection, and then we
> >> send
> >> > over the raw socket. This changes the lifetime of the sasl
> >>components, as
> >> > it needs to be used with all communication. It's not like SSL, where
> >>we
> >> > negotiate SSL at the start and then the SSL engine provides a socket
> >> which
> >> > we use to send data.
> >> >
> >> > -Ivan
> >> >
> >> > On Fri, Oct 9, 2015 at 4:33 PM Flavio Junqueira <fpj@apache.org>
> >>wrote:
> >> >
> >> >> I'm not sure based on what you say that it'd be invasive. Enabling
> >> >> different types of QOP seems to be relatively straightforward, unless
> >> I'm
> >> >> missing something here. Chris did a good job describing what needs
> >>to be
> >> >> done, and this far I have the same understanding of the changes.
> >> >>
> >> >> -Flavio
> >> >>
> >> >>> On 09 Oct 2015, at 15:30, Ivan Kelly <ivank@apache.org> wrote:
> >> >>>
> >> >>> IMO, adding QOP to 3.4 would be a fairly large and invasive change,
> >> which
> >> >>> is something which shouldn't be done on the stable branch.
> >> >>>
> >> >>> -Ivan
> >> >>>
> >> >>> On Fri, Oct 9, 2015 at 4:02 PM Flavio Junqueira <fpj@apache.org>
> >> wrote:
> >> >>>
> >> >>>> Not in the 3.4 branch, which is the latest stable branch at
the
> >> moment.
> >> >>>>
> >> >>>> -Flavio
> >> >>>>
> >> >>>>> On 09 Oct 2015, at 15:00, Ivan Kelly <ivank@apache.org>
wrote:
> >> >>>>>
> >> >>>>> Is auth-int necessary if we have SSL on the client (as
there is in
> >> >>>> trunk)?
> >> >>>>> My understanding is that all comms would have to be wrapped
by
> >>sasl
> >> if
> >> >>>> you
> >> >>>>> have QOP enabled.
> >> >>>>>
> >> >>>>> -Ivan
> >> >>>>>
> >> >>>>> On Fri, Oct 9, 2015 at 9:42 AM Flavio Junqueira <fpj@apache.org>
> >> >> wrote:
> >> >>>>>
> >> >>>>>> Hi Chris,
> >> >>>>>>
> >> >>>>>> Yeah, I was thinking along the same lines, so sounds
like a
> >>plan. I
> >> >> know
> >> >>>>>> Raul is going to hate me for this, but I'd really like
to have
> >>this
> >> in
> >> >>>>>> 3.4.7. It sounds like a simple enough change that we
can have in
> >> >>>> shortly,
> >> >>>>>> does it sound right?
> >> >>>>>>
> >> >>>>>> Please go ahead with the jira if you have time, and
if you don't
> >> have
> >> >>>> time
> >> >>>>>> to work on the patch, just assign it to me.
> >> >>>>>>
> >> >>>>>> -Flavio
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> On 08 Oct 2015, at 23:16, Chris Nauroth
> >><cnauroth@hortonworks.com>
> >> >>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>> Hi Flavio,
> >> >>>>>>>
> >> >>>>>>> It appears that the current code doesn't give us
any way to
> >>control
> >> >> the
> >> >>>>>>> QOP, so it must be always using the default QOP
of "auth"
> >> >>>> (authentication
> >> >>>>>>> only).  This is because the calls to Sasl#createSaslClient
and
> >> >>>>>>> Sasl#createSaslServer pass a hard-coded null for
the properties
> >> map.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>oo
> >> >>>>>>> keeper/client/ZooKeeperSaslClient.java#L240
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>oo
> >> >>>>>>> keeper/client/ZooKeeperSaslClient.java#L288
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>oo
> >> >>>>>>> keeper/server/ZooKeeperSaslServer.java#L118
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> >>
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/z
> >>oo
> >> >>>>>>> keeper/server/ZooKeeperSaslServer.java#L144
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> If we want to support setting QOP to "auth-int"
(authentication
> >>+
> >> >>>>>>> integrity/man-in-the-middle tampering protection)
or "auth-conf"
> >> >>>>>>> (authentication + integrity + confidentiality/encryption),
then
> >>I
> >> >> think
> >> >>>>>>> we'll need to make code changes to read a new QOP
configuration
> >> >>>> property,
> >> >>>>>>> put it into a Map using Sasl#QOP as the key, and
then pass it
> >>along
> >> >> to
> >> >>>>>> the
> >> >>>>>>> Sasl#createSaslClient and Sasl#createSaslServer
calls.
> >> >>>>>>>
> >> >>>>>>> Is this what you need?  If so, then I'd be happy
to write up the
> >> >>>> proposal
> >> >>>>>>> in a new JIRA.  I didn't find any existing open
JIRAs that look
> >> >>>> relevant.
> >> >>>>>>>
> >> >>>>>>> --Chris Nauroth
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On 10/8/15, 2:06 PM, "Flavio Junqueira" <fpj@apache.org>
wrote:
> >> >>>>>>>
> >> >>>>>>>> Has anyone tried to use the QOP (Quality of
Protection)
> >>property
> >> for
> >> >>>>>> SASL
> >> >>>>>>>> when running ZooKeeper?
> >> >>>>>>>>
> >> >>>>>>>> -Flavio
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>
> >> >>>>
> >> >>
> >> >>
> >>
> >>
>
>

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