You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Jan Høydahl <ja...@cominvent.com> on 2018/09/27 09:12:44 UTC

Digest auth with classic TCP transport

Hi

We use ZK 3.4.13, and unfortunately cannot use Netty transport and SSL.
We plan to use digest authentication and Zookeeper ACL protection.

Question is, since we cannot use SSL, is there some other way to make sure the user credentials are not sniffed over the network and thus let an attacker impersonate our application and cange the content in Zookeeper? Does the Zookeeper client do some smart moves to protect/hash the password over the network? I suppose the binary transport is easy to decipher for those who try.

--
Jan Høydahl
Cominvent AS - www.cominvent.com


回复: Digest auth with classic TCP transport

Posted by liuxuelong <im...@qq.com>.
------------------
海纳百川,有容乃大;壁立千仞,无欲则刚


 




------------------ 原始邮件 ------------------
发件人: "Michael Han"<ha...@apache.org>;
发送时间: 2018年9月28日(星期五) 凌晨4:25
收件人: "user"<us...@zookeeper.apache.org>;

主题: Re: Digest auth with classic TCP transport



>> I have not found any evidence that Zookeeper server nor (Java) client
supports TLS in version 3.4.13.

We support TLS for client-server (and soon server-server) connections on
3.5 releases. There is no plan to back port these features to 3.4 which is
the current stable branch, because we only back port bug fixes to stable
branch.

>> So what do people typically do to mitigate this?

Typical solution is to use Stunnel (https://www.stunnel.org/).


On Thu, Sep 27, 2018 at 8:17 AM, Andor Molnar <an...@cloudera.com.invalid>
wrote:

> I think they do the latter. ZooKeeper 3.4 is highly recommended to run on a
> network which is isolated from the internet.
> VPN could be an option, but we don't do any testing on VPN networks.
>
> Andor
>
>
>
> On Thu, Sep 27, 2018 at 5:14 PM, Jan Høydahl <ja...@cominvent.com>
> wrote:
>
> > Thanks.
> >
> > So what do people typically do to mitigate this? Other than restricting
> > who has access to this network?
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> > > 27. sep. 2018 kl. 17:10 skrev Andor Molnar <andor@cloudera.com.INVALID
> >:
> > >
> > > Right. It's plaintext.
> > >
> > >
> > > On Thu, Sep 27, 2018 at 4:54 PM, Jan Høydahl <ja...@cominvent.com>
> > wrote:
> > >
> > >> I am *explicitly* asking about old-style 3.4.x socket protocol, not
> the
> > >> new Netty transport which I know supports SSL.
> > >>
> > >> My original question was whether authentication credentials are passed
> > in
> > >> plaintext across the wire and thus being easy to pickup by an
> attacker.
> > >> And if that is true, if there are know ways of working around the lack
> > of
> > >> SSL support for the TCP transport.
> > >>
> > >> Martin Gainty, I cannot see how I can easily plug in TLS1.3 in my
> > existing
> > >> connection between client and Zookeeper 3.4.x, but if there is a
> simple
> > way
> > >> to do so then please share how you did it.
> > >>
> > >> The only solution I see, as we're stuck with 3.4.x, is to setup IPSec
> > >> tunnels on OS level on all client/server traffic. I wanted to avoid
> > that.
> > >>
> > >> --
> > >> Jan Høydahl, search solution architect
> > >> Cominvent AS - www.cominvent.com
> > >>
> > >>> 27. sep. 2018 kl. 16:14 skrev Andor Molnar
> <andor@cloudera.com.INVALID
> > >:
> > >>>
> > >>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > >> ZooKeeper+SSL+User+Guide
> > >>>
> > >>> SSL (client-server) has been added in 3.5.1
> > >>> SSL server-server support is being reviewed on GitHub.
> > >>>
> > >>> Regards,
> > >>> Andor
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Sep 27, 2018 at 3:46 PM, Jan Høydahl <ja...@cominvent.com>
> > >> wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>>> if you're prevented from implementing SSL why not use TLSv1.3?
> > >>>>
> > >>>>
> > >>>> I have not found any evidence that Zookeeper server nor (Java)
> client
> > >>>> supports TLS in version 3.4.13. Please point me to some docs or
> > >> tutorial.
> > >>>> We don't want to fork Zookeeper to implement this stuff ourselves :)
> > >>>>
> > >>>> --
> > >>>> Jan Høydahl, search solution architect
> > >>>> Cominvent AS - www.cominvent.com
> > >>>>
> > >>>>> 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
> > >>>>>
> > >>>>>
> > >>>>> ________________________________
> > >>>>> From: Jan Høydahl <ja...@cominvent.com>
> > >>>>> Sent: Thursday, September 27, 2018 5:12 AM
> > >>>>> To: user@zookeeper.apache.org
> > >>>>> Subject: Digest auth with classic TCP transport
> > >>>>>
> > >>>>> Hi
> > >>>>>
> > >>>>> We use ZK 3.4.13, and unfortunately cannot use Netty transport and
> > SSL.
> > >>>>> We plan to use digest authentication and Zookeeper ACL protection.
> > >>>>>
> > >>>>> Question is, since we cannot use SSL, is there some other way to
> make
> > >>>> sure the user credentials are not sniffed over the network and thus
> > let
> > >> an
> > >>>> attacker impersonate our application and cange the content in
> > Zookeeper?
> > >>>> Does the Zookeeper client do some smart moves to protect/hash the
> > >> password
> > >>>> over the network? I suppose the binary transport is easy to decipher
> > for
> > >>>> those who try.
> > >>>>>
> > >>>>> MG>if you're prevented from implementing SSL why not use TLSv1.3?
> > >>>>> MG>with TLSv1.3 you can implement encryption/decryption with crypto
> > >>>> private/public keys and x509 certs
> > >>>>> https://en.wikipedia.org/wiki/Transport_Layer_Security
> > >>>>> Transport Layer Security - Wikipedia<https://en.
> > >>>> wikipedia.org/wiki/Transport_Layer_Security>
> > >>>>> Transport Layer Security (TLS) – and its predecessor, Secure
> Sockets
> > >>>> Layer (SSL), which is now deprecated by the Internet Engineering
> Task
> > >> Force
> > >>>> (IETF) – are cryptographic protocols that provide communications
> > >> security
> > >>>> over a computer network. Several versions of the protocols find
> > >> widespread
> > >>>> use in applications such as web browsing, email, instant messaging,
> > and
> > >>>> voice over IP (VoIP).
> > >>>>> en.wikipedia.org
> > >>>>>
> > >>>>>
> > >>>>> MG>path of least resistance is to contact verisign and ask them to
> > >>>> generate keys, certs and allow them to act as CA
> > >>>>> MG>Caveat: tls1.3 implementation is slow and is supported by
> Mozilla
> > >>>> v60...and some versions of chrome
> > >>>>> MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon
> and
> > >>>> TLS_ECDH_anon key agreement methods MG>do not authenticate the
> server
> > >>>>> MG>you will want public key size to be min 2048bit to conform to
> > chrome
> > >>>> secure transmission requirements
> > >>>>> MG>securing message is done thru MD5 or SHA but you will need to
> > >>>> incorporate selected algo into
> > >>>>> MG>supported cipher-suite(s)
> > >>>>> https://en.wikipedia.org/wiki/Cipher_suite
> > >>>>> Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_
> suite>
> > >>>>> A cipher suite is a set of algorithms that help secure a network
> > >>>> connection that uses Transport Layer Security (TLS) or Secure Socket
> > >> Layer
> > >>>> (SSL). The set of algorithms that cipher suites usually contain
> > >> include: a
> > >>>> key exchange algorithm, a bulk encryption algorithm, and a message
> > >>>> authentication code (MAC) algorithm.. The key exchange algorithm is
> > >> used to
> > >>>> exchange a key between two devices.
> > >>>>> en.wikipedia.org
> > >>>>>
> > >>>>>
> > >>>>> HTH
> > >>>>> Martin
> > >>>>> --
> > >>>>> Jan Høydahl
> > >>>>> Cominvent AS - www.cominvent.com<http://www.cominvent.com>
> > >>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>

Re: Digest auth with classic TCP transport

Posted by Michael Han <ha...@apache.org>.
>> I have not found any evidence that Zookeeper server nor (Java) client
supports TLS in version 3.4.13.

We support TLS for client-server (and soon server-server) connections on
3.5 releases. There is no plan to back port these features to 3.4 which is
the current stable branch, because we only back port bug fixes to stable
branch.

>> So what do people typically do to mitigate this?

Typical solution is to use Stunnel (https://www.stunnel.org/).


On Thu, Sep 27, 2018 at 8:17 AM, Andor Molnar <an...@cloudera.com.invalid>
wrote:

> I think they do the latter. ZooKeeper 3.4 is highly recommended to run on a
> network which is isolated from the internet.
> VPN could be an option, but we don't do any testing on VPN networks.
>
> Andor
>
>
>
> On Thu, Sep 27, 2018 at 5:14 PM, Jan Høydahl <ja...@cominvent.com>
> wrote:
>
> > Thanks.
> >
> > So what do people typically do to mitigate this? Other than restricting
> > who has access to this network?
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> > > 27. sep. 2018 kl. 17:10 skrev Andor Molnar <andor@cloudera.com.INVALID
> >:
> > >
> > > Right. It's plaintext.
> > >
> > >
> > > On Thu, Sep 27, 2018 at 4:54 PM, Jan Høydahl <ja...@cominvent.com>
> > wrote:
> > >
> > >> I am *explicitly* asking about old-style 3.4.x socket protocol, not
> the
> > >> new Netty transport which I know supports SSL.
> > >>
> > >> My original question was whether authentication credentials are passed
> > in
> > >> plaintext across the wire and thus being easy to pickup by an
> attacker.
> > >> And if that is true, if there are know ways of working around the lack
> > of
> > >> SSL support for the TCP transport.
> > >>
> > >> Martin Gainty, I cannot see how I can easily plug in TLS1.3 in my
> > existing
> > >> connection between client and Zookeeper 3.4.x, but if there is a
> simple
> > way
> > >> to do so then please share how you did it.
> > >>
> > >> The only solution I see, as we're stuck with 3.4.x, is to setup IPSec
> > >> tunnels on OS level on all client/server traffic. I wanted to avoid
> > that.
> > >>
> > >> --
> > >> Jan Høydahl, search solution architect
> > >> Cominvent AS - www.cominvent.com
> > >>
> > >>> 27. sep. 2018 kl. 16:14 skrev Andor Molnar
> <andor@cloudera.com.INVALID
> > >:
> > >>>
> > >>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > >> ZooKeeper+SSL+User+Guide
> > >>>
> > >>> SSL (client-server) has been added in 3.5.1
> > >>> SSL server-server support is being reviewed on GitHub.
> > >>>
> > >>> Regards,
> > >>> Andor
> > >>>
> > >>>
> > >>>
> > >>> On Thu, Sep 27, 2018 at 3:46 PM, Jan Høydahl <ja...@cominvent.com>
> > >> wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>>> if you're prevented from implementing SSL why not use TLSv1.3?
> > >>>>
> > >>>>
> > >>>> I have not found any evidence that Zookeeper server nor (Java)
> client
> > >>>> supports TLS in version 3.4.13. Please point me to some docs or
> > >> tutorial.
> > >>>> We don't want to fork Zookeeper to implement this stuff ourselves :)
> > >>>>
> > >>>> --
> > >>>> Jan Høydahl, search solution architect
> > >>>> Cominvent AS - www.cominvent.com
> > >>>>
> > >>>>> 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
> > >>>>>
> > >>>>>
> > >>>>> ________________________________
> > >>>>> From: Jan Høydahl <ja...@cominvent.com>
> > >>>>> Sent: Thursday, September 27, 2018 5:12 AM
> > >>>>> To: user@zookeeper.apache.org
> > >>>>> Subject: Digest auth with classic TCP transport
> > >>>>>
> > >>>>> Hi
> > >>>>>
> > >>>>> We use ZK 3.4.13, and unfortunately cannot use Netty transport and
> > SSL.
> > >>>>> We plan to use digest authentication and Zookeeper ACL protection.
> > >>>>>
> > >>>>> Question is, since we cannot use SSL, is there some other way to
> make
> > >>>> sure the user credentials are not sniffed over the network and thus
> > let
> > >> an
> > >>>> attacker impersonate our application and cange the content in
> > Zookeeper?
> > >>>> Does the Zookeeper client do some smart moves to protect/hash the
> > >> password
> > >>>> over the network? I suppose the binary transport is easy to decipher
> > for
> > >>>> those who try.
> > >>>>>
> > >>>>> MG>if you're prevented from implementing SSL why not use TLSv1.3?
> > >>>>> MG>with TLSv1.3 you can implement encryption/decryption with crypto
> > >>>> private/public keys and x509 certs
> > >>>>> https://en.wikipedia.org/wiki/Transport_Layer_Security
> > >>>>> Transport Layer Security - Wikipedia<https://en.
> > >>>> wikipedia.org/wiki/Transport_Layer_Security>
> > >>>>> Transport Layer Security (TLS) – and its predecessor, Secure
> Sockets
> > >>>> Layer (SSL), which is now deprecated by the Internet Engineering
> Task
> > >> Force
> > >>>> (IETF) – are cryptographic protocols that provide communications
> > >> security
> > >>>> over a computer network. Several versions of the protocols find
> > >> widespread
> > >>>> use in applications such as web browsing, email, instant messaging,
> > and
> > >>>> voice over IP (VoIP).
> > >>>>> en.wikipedia.org
> > >>>>>
> > >>>>>
> > >>>>> MG>path of least resistance is to contact verisign and ask them to
> > >>>> generate keys, certs and allow them to act as CA
> > >>>>> MG>Caveat: tls1.3 implementation is slow and is supported by
> Mozilla
> > >>>> v60...and some versions of chrome
> > >>>>> MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon
> and
> > >>>> TLS_ECDH_anon key agreement methods MG>do not authenticate the
> server
> > >>>>> MG>you will want public key size to be min 2048bit to conform to
> > chrome
> > >>>> secure transmission requirements
> > >>>>> MG>securing message is done thru MD5 or SHA but you will need to
> > >>>> incorporate selected algo into
> > >>>>> MG>supported cipher-suite(s)
> > >>>>> https://en.wikipedia.org/wiki/Cipher_suite
> > >>>>> Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_
> suite>
> > >>>>> A cipher suite is a set of algorithms that help secure a network
> > >>>> connection that uses Transport Layer Security (TLS) or Secure Socket
> > >> Layer
> > >>>> (SSL). The set of algorithms that cipher suites usually contain
> > >> include: a
> > >>>> key exchange algorithm, a bulk encryption algorithm, and a message
> > >>>> authentication code (MAC) algorithm.. The key exchange algorithm is
> > >> used to
> > >>>> exchange a key between two devices.
> > >>>>> en.wikipedia.org
> > >>>>>
> > >>>>>
> > >>>>> HTH
> > >>>>> Martin
> > >>>>> --
> > >>>>> Jan Høydahl
> > >>>>> Cominvent AS - www.cominvent.com<http://www.cominvent.com>
> > >>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>

Re: Digest auth with classic TCP transport

Posted by Andor Molnar <an...@cloudera.com.INVALID>.
I think they do the latter. ZooKeeper 3.4 is highly recommended to run on a
network which is isolated from the internet.
VPN could be an option, but we don't do any testing on VPN networks.

Andor



On Thu, Sep 27, 2018 at 5:14 PM, Jan Høydahl <ja...@cominvent.com> wrote:

> Thanks.
>
> So what do people typically do to mitigate this? Other than restricting
> who has access to this network?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 27. sep. 2018 kl. 17:10 skrev Andor Molnar <an...@cloudera.com.INVALID>:
> >
> > Right. It's plaintext.
> >
> >
> > On Thu, Sep 27, 2018 at 4:54 PM, Jan Høydahl <ja...@cominvent.com>
> wrote:
> >
> >> I am *explicitly* asking about old-style 3.4.x socket protocol, not the
> >> new Netty transport which I know supports SSL.
> >>
> >> My original question was whether authentication credentials are passed
> in
> >> plaintext across the wire and thus being easy to pickup by an attacker.
> >> And if that is true, if there are know ways of working around the lack
> of
> >> SSL support for the TCP transport.
> >>
> >> Martin Gainty, I cannot see how I can easily plug in TLS1.3 in my
> existing
> >> connection between client and Zookeeper 3.4.x, but if there is a simple
> way
> >> to do so then please share how you did it.
> >>
> >> The only solution I see, as we're stuck with 3.4.x, is to setup IPSec
> >> tunnels on OS level on all client/server traffic. I wanted to avoid
> that.
> >>
> >> --
> >> Jan Høydahl, search solution architect
> >> Cominvent AS - www.cominvent.com
> >>
> >>> 27. sep. 2018 kl. 16:14 skrev Andor Molnar <andor@cloudera.com.INVALID
> >:
> >>>
> >>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >> ZooKeeper+SSL+User+Guide
> >>>
> >>> SSL (client-server) has been added in 3.5.1
> >>> SSL server-server support is being reviewed on GitHub.
> >>>
> >>> Regards,
> >>> Andor
> >>>
> >>>
> >>>
> >>> On Thu, Sep 27, 2018 at 3:46 PM, Jan Høydahl <ja...@cominvent.com>
> >> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>>> if you're prevented from implementing SSL why not use TLSv1.3?
> >>>>
> >>>>
> >>>> I have not found any evidence that Zookeeper server nor (Java) client
> >>>> supports TLS in version 3.4.13. Please point me to some docs or
> >> tutorial.
> >>>> We don't want to fork Zookeeper to implement this stuff ourselves :)
> >>>>
> >>>> --
> >>>> Jan Høydahl, search solution architect
> >>>> Cominvent AS - www.cominvent.com
> >>>>
> >>>>> 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
> >>>>>
> >>>>>
> >>>>> ________________________________
> >>>>> From: Jan Høydahl <ja...@cominvent.com>
> >>>>> Sent: Thursday, September 27, 2018 5:12 AM
> >>>>> To: user@zookeeper.apache.org
> >>>>> Subject: Digest auth with classic TCP transport
> >>>>>
> >>>>> Hi
> >>>>>
> >>>>> We use ZK 3.4.13, and unfortunately cannot use Netty transport and
> SSL.
> >>>>> We plan to use digest authentication and Zookeeper ACL protection.
> >>>>>
> >>>>> Question is, since we cannot use SSL, is there some other way to make
> >>>> sure the user credentials are not sniffed over the network and thus
> let
> >> an
> >>>> attacker impersonate our application and cange the content in
> Zookeeper?
> >>>> Does the Zookeeper client do some smart moves to protect/hash the
> >> password
> >>>> over the network? I suppose the binary transport is easy to decipher
> for
> >>>> those who try.
> >>>>>
> >>>>> MG>if you're prevented from implementing SSL why not use TLSv1.3?
> >>>>> MG>with TLSv1.3 you can implement encryption/decryption with crypto
> >>>> private/public keys and x509 certs
> >>>>> https://en.wikipedia.org/wiki/Transport_Layer_Security
> >>>>> Transport Layer Security - Wikipedia<https://en.
> >>>> wikipedia.org/wiki/Transport_Layer_Security>
> >>>>> Transport Layer Security (TLS) – and its predecessor, Secure Sockets
> >>>> Layer (SSL), which is now deprecated by the Internet Engineering Task
> >> Force
> >>>> (IETF) – are cryptographic protocols that provide communications
> >> security
> >>>> over a computer network. Several versions of the protocols find
> >> widespread
> >>>> use in applications such as web browsing, email, instant messaging,
> and
> >>>> voice over IP (VoIP).
> >>>>> en.wikipedia.org
> >>>>>
> >>>>>
> >>>>> MG>path of least resistance is to contact verisign and ask them to
> >>>> generate keys, certs and allow them to act as CA
> >>>>> MG>Caveat: tls1.3 implementation is slow and is supported by Mozilla
> >>>> v60...and some versions of chrome
> >>>>> MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon and
> >>>> TLS_ECDH_anon key agreement methods MG>do not authenticate the server
> >>>>> MG>you will want public key size to be min 2048bit to conform to
> chrome
> >>>> secure transmission requirements
> >>>>> MG>securing message is done thru MD5 or SHA but you will need to
> >>>> incorporate selected algo into
> >>>>> MG>supported cipher-suite(s)
> >>>>> https://en.wikipedia.org/wiki/Cipher_suite
> >>>>> Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_suite>
> >>>>> A cipher suite is a set of algorithms that help secure a network
> >>>> connection that uses Transport Layer Security (TLS) or Secure Socket
> >> Layer
> >>>> (SSL). The set of algorithms that cipher suites usually contain
> >> include: a
> >>>> key exchange algorithm, a bulk encryption algorithm, and a message
> >>>> authentication code (MAC) algorithm.. The key exchange algorithm is
> >> used to
> >>>> exchange a key between two devices.
> >>>>> en.wikipedia.org
> >>>>>
> >>>>>
> >>>>> HTH
> >>>>> Martin
> >>>>> --
> >>>>> Jan Høydahl
> >>>>> Cominvent AS - www.cominvent.com<http://www.cominvent.com>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>

Re: Digest auth with classic TCP transport

Posted by Jan Høydahl <ja...@cominvent.com>.
Thanks.

So what do people typically do to mitigate this? Other than restricting who has access to this network?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 27. sep. 2018 kl. 17:10 skrev Andor Molnar <an...@cloudera.com.INVALID>:
> 
> Right. It's plaintext.
> 
> 
> On Thu, Sep 27, 2018 at 4:54 PM, Jan Høydahl <ja...@cominvent.com> wrote:
> 
>> I am *explicitly* asking about old-style 3.4.x socket protocol, not the
>> new Netty transport which I know supports SSL.
>> 
>> My original question was whether authentication credentials are passed in
>> plaintext across the wire and thus being easy to pickup by an attacker.
>> And if that is true, if there are know ways of working around the lack of
>> SSL support for the TCP transport.
>> 
>> Martin Gainty, I cannot see how I can easily plug in TLS1.3 in my existing
>> connection between client and Zookeeper 3.4.x, but if there is a simple way
>> to do so then please share how you did it.
>> 
>> The only solution I see, as we're stuck with 3.4.x, is to setup IPSec
>> tunnels on OS level on all client/server traffic. I wanted to avoid that.
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>>> 27. sep. 2018 kl. 16:14 skrev Andor Molnar <an...@cloudera.com.INVALID>:
>>> 
>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> ZooKeeper+SSL+User+Guide
>>> 
>>> SSL (client-server) has been added in 3.5.1
>>> SSL server-server support is being reviewed on GitHub.
>>> 
>>> Regards,
>>> Andor
>>> 
>>> 
>>> 
>>> On Thu, Sep 27, 2018 at 3:46 PM, Jan Høydahl <ja...@cominvent.com>
>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>>> if you're prevented from implementing SSL why not use TLSv1.3?
>>>> 
>>>> 
>>>> I have not found any evidence that Zookeeper server nor (Java) client
>>>> supports TLS in version 3.4.13. Please point me to some docs or
>> tutorial.
>>>> We don't want to fork Zookeeper to implement this stuff ourselves :)
>>>> 
>>>> --
>>>> Jan Høydahl, search solution architect
>>>> Cominvent AS - www.cominvent.com
>>>> 
>>>>> 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
>>>>> 
>>>>> 
>>>>> ________________________________
>>>>> From: Jan Høydahl <ja...@cominvent.com>
>>>>> Sent: Thursday, September 27, 2018 5:12 AM
>>>>> To: user@zookeeper.apache.org
>>>>> Subject: Digest auth with classic TCP transport
>>>>> 
>>>>> Hi
>>>>> 
>>>>> We use ZK 3.4.13, and unfortunately cannot use Netty transport and SSL.
>>>>> We plan to use digest authentication and Zookeeper ACL protection.
>>>>> 
>>>>> Question is, since we cannot use SSL, is there some other way to make
>>>> sure the user credentials are not sniffed over the network and thus let
>> an
>>>> attacker impersonate our application and cange the content in Zookeeper?
>>>> Does the Zookeeper client do some smart moves to protect/hash the
>> password
>>>> over the network? I suppose the binary transport is easy to decipher for
>>>> those who try.
>>>>> 
>>>>> MG>if you're prevented from implementing SSL why not use TLSv1.3?
>>>>> MG>with TLSv1.3 you can implement encryption/decryption with crypto
>>>> private/public keys and x509 certs
>>>>> https://en.wikipedia.org/wiki/Transport_Layer_Security
>>>>> Transport Layer Security - Wikipedia<https://en.
>>>> wikipedia.org/wiki/Transport_Layer_Security>
>>>>> Transport Layer Security (TLS) – and its predecessor, Secure Sockets
>>>> Layer (SSL), which is now deprecated by the Internet Engineering Task
>> Force
>>>> (IETF) – are cryptographic protocols that provide communications
>> security
>>>> over a computer network. Several versions of the protocols find
>> widespread
>>>> use in applications such as web browsing, email, instant messaging, and
>>>> voice over IP (VoIP).
>>>>> en.wikipedia.org
>>>>> 
>>>>> 
>>>>> MG>path of least resistance is to contact verisign and ask them to
>>>> generate keys, certs and allow them to act as CA
>>>>> MG>Caveat: tls1.3 implementation is slow and is supported by Mozilla
>>>> v60...and some versions of chrome
>>>>> MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon and
>>>> TLS_ECDH_anon key agreement methods MG>do not authenticate the server
>>>>> MG>you will want public key size to be min 2048bit to conform to chrome
>>>> secure transmission requirements
>>>>> MG>securing message is done thru MD5 or SHA but you will need to
>>>> incorporate selected algo into
>>>>> MG>supported cipher-suite(s)
>>>>> https://en.wikipedia.org/wiki/Cipher_suite
>>>>> Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_suite>
>>>>> A cipher suite is a set of algorithms that help secure a network
>>>> connection that uses Transport Layer Security (TLS) or Secure Socket
>> Layer
>>>> (SSL). The set of algorithms that cipher suites usually contain
>> include: a
>>>> key exchange algorithm, a bulk encryption algorithm, and a message
>>>> authentication code (MAC) algorithm.. The key exchange algorithm is
>> used to
>>>> exchange a key between two devices.
>>>>> en.wikipedia.org
>>>>> 
>>>>> 
>>>>> HTH
>>>>> Martin
>>>>> --
>>>>> Jan Høydahl
>>>>> Cominvent AS - www.cominvent.com<http://www.cominvent.com>
>>>>> 
>>>> 
>>>> 
>> 
>> 


Re: Digest auth with classic TCP transport

Posted by Andor Molnar <an...@cloudera.com.INVALID>.
Right. It's plaintext.


On Thu, Sep 27, 2018 at 4:54 PM, Jan Høydahl <ja...@cominvent.com> wrote:

> I am *explicitly* asking about old-style 3.4.x socket protocol, not the
> new Netty transport which I know supports SSL.
>
> My original question was whether authentication credentials are passed in
> plaintext across the wire and thus being easy to pickup by an attacker.
> And if that is true, if there are know ways of working around the lack of
> SSL support for the TCP transport.
>
> Martin Gainty, I cannot see how I can easily plug in TLS1.3 in my existing
> connection between client and Zookeeper 3.4.x, but if there is a simple way
> to do so then please share how you did it.
>
> The only solution I see, as we're stuck with 3.4.x, is to setup IPSec
> tunnels on OS level on all client/server traffic. I wanted to avoid that.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 27. sep. 2018 kl. 16:14 skrev Andor Molnar <an...@cloudera.com.INVALID>:
> >
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> ZooKeeper+SSL+User+Guide
> >
> > SSL (client-server) has been added in 3.5.1
> > SSL server-server support is being reviewed on GitHub.
> >
> > Regards,
> > Andor
> >
> >
> >
> > On Thu, Sep 27, 2018 at 3:46 PM, Jan Høydahl <ja...@cominvent.com>
> wrote:
> >
> >> Hi,
> >>
> >>> if you're prevented from implementing SSL why not use TLSv1.3?
> >>
> >>
> >> I have not found any evidence that Zookeeper server nor (Java) client
> >> supports TLS in version 3.4.13. Please point me to some docs or
> tutorial.
> >> We don't want to fork Zookeeper to implement this stuff ourselves :)
> >>
> >> --
> >> Jan Høydahl, search solution architect
> >> Cominvent AS - www.cominvent.com
> >>
> >>> 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
> >>>
> >>>
> >>> ________________________________
> >>> From: Jan Høydahl <ja...@cominvent.com>
> >>> Sent: Thursday, September 27, 2018 5:12 AM
> >>> To: user@zookeeper.apache.org
> >>> Subject: Digest auth with classic TCP transport
> >>>
> >>> Hi
> >>>
> >>> We use ZK 3.4.13, and unfortunately cannot use Netty transport and SSL.
> >>> We plan to use digest authentication and Zookeeper ACL protection.
> >>>
> >>> Question is, since we cannot use SSL, is there some other way to make
> >> sure the user credentials are not sniffed over the network and thus let
> an
> >> attacker impersonate our application and cange the content in Zookeeper?
> >> Does the Zookeeper client do some smart moves to protect/hash the
> password
> >> over the network? I suppose the binary transport is easy to decipher for
> >> those who try.
> >>>
> >>> MG>if you're prevented from implementing SSL why not use TLSv1.3?
> >>> MG>with TLSv1.3 you can implement encryption/decryption with crypto
> >> private/public keys and x509 certs
> >>> https://en.wikipedia.org/wiki/Transport_Layer_Security
> >>> Transport Layer Security - Wikipedia<https://en.
> >> wikipedia.org/wiki/Transport_Layer_Security>
> >>> Transport Layer Security (TLS) – and its predecessor, Secure Sockets
> >> Layer (SSL), which is now deprecated by the Internet Engineering Task
> Force
> >> (IETF) – are cryptographic protocols that provide communications
> security
> >> over a computer network. Several versions of the protocols find
> widespread
> >> use in applications such as web browsing, email, instant messaging, and
> >> voice over IP (VoIP).
> >>> en.wikipedia.org
> >>>
> >>>
> >>> MG>path of least resistance is to contact verisign and ask them to
> >> generate keys, certs and allow them to act as CA
> >>> MG>Caveat: tls1.3 implementation is slow and is supported by Mozilla
> >> v60...and some versions of chrome
> >>> MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon and
> >> TLS_ECDH_anon key agreement methods MG>do not authenticate the server
> >>> MG>you will want public key size to be min 2048bit to conform to chrome
> >> secure transmission requirements
> >>> MG>securing message is done thru MD5 or SHA but you will need to
> >> incorporate selected algo into
> >>> MG>supported cipher-suite(s)
> >>> https://en.wikipedia.org/wiki/Cipher_suite
> >>> Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_suite>
> >>> A cipher suite is a set of algorithms that help secure a network
> >> connection that uses Transport Layer Security (TLS) or Secure Socket
> Layer
> >> (SSL). The set of algorithms that cipher suites usually contain
> include: a
> >> key exchange algorithm, a bulk encryption algorithm, and a message
> >> authentication code (MAC) algorithm.. The key exchange algorithm is
> used to
> >> exchange a key between two devices.
> >>> en.wikipedia.org
> >>>
> >>>
> >>> HTH
> >>> Martin
> >>> --
> >>> Jan Høydahl
> >>> Cominvent AS - www.cominvent.com<http://www.cominvent.com>
> >>>
> >>
> >>
>
>

Re: Digest auth with classic TCP transport

Posted by Jan Høydahl <ja...@cominvent.com>.
I am *explicitly* asking about old-style 3.4.x socket protocol, not the new Netty transport which I know supports SSL.

My original question was whether authentication credentials are passed in plaintext across the wire and thus being easy to pickup by an attacker.
And if that is true, if there are know ways of working around the lack of SSL support for the TCP transport.

Martin Gainty, I cannot see how I can easily plug in TLS1.3 in my existing connection between client and Zookeeper 3.4.x, but if there is a simple way to do so then please share how you did it.

The only solution I see, as we're stuck with 3.4.x, is to setup IPSec tunnels on OS level on all client/server traffic. I wanted to avoid that.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 27. sep. 2018 kl. 16:14 skrev Andor Molnar <an...@cloudera.com.INVALID>:
> 
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide
> 
> SSL (client-server) has been added in 3.5.1
> SSL server-server support is being reviewed on GitHub.
> 
> Regards,
> Andor
> 
> 
> 
> On Thu, Sep 27, 2018 at 3:46 PM, Jan Høydahl <ja...@cominvent.com> wrote:
> 
>> Hi,
>> 
>>> if you're prevented from implementing SSL why not use TLSv1.3?
>> 
>> 
>> I have not found any evidence that Zookeeper server nor (Java) client
>> supports TLS in version 3.4.13. Please point me to some docs or tutorial.
>> We don't want to fork Zookeeper to implement this stuff ourselves :)
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>>> 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
>>> 
>>> 
>>> ________________________________
>>> From: Jan Høydahl <ja...@cominvent.com>
>>> Sent: Thursday, September 27, 2018 5:12 AM
>>> To: user@zookeeper.apache.org
>>> Subject: Digest auth with classic TCP transport
>>> 
>>> Hi
>>> 
>>> We use ZK 3.4.13, and unfortunately cannot use Netty transport and SSL.
>>> We plan to use digest authentication and Zookeeper ACL protection.
>>> 
>>> Question is, since we cannot use SSL, is there some other way to make
>> sure the user credentials are not sniffed over the network and thus let an
>> attacker impersonate our application and cange the content in Zookeeper?
>> Does the Zookeeper client do some smart moves to protect/hash the password
>> over the network? I suppose the binary transport is easy to decipher for
>> those who try.
>>> 
>>> MG>if you're prevented from implementing SSL why not use TLSv1.3?
>>> MG>with TLSv1.3 you can implement encryption/decryption with crypto
>> private/public keys and x509 certs
>>> https://en.wikipedia.org/wiki/Transport_Layer_Security
>>> Transport Layer Security - Wikipedia<https://en.
>> wikipedia.org/wiki/Transport_Layer_Security>
>>> Transport Layer Security (TLS) – and its predecessor, Secure Sockets
>> Layer (SSL), which is now deprecated by the Internet Engineering Task Force
>> (IETF) – are cryptographic protocols that provide communications security
>> over a computer network. Several versions of the protocols find widespread
>> use in applications such as web browsing, email, instant messaging, and
>> voice over IP (VoIP).
>>> en.wikipedia.org
>>> 
>>> 
>>> MG>path of least resistance is to contact verisign and ask them to
>> generate keys, certs and allow them to act as CA
>>> MG>Caveat: tls1.3 implementation is slow and is supported by Mozilla
>> v60...and some versions of chrome
>>> MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon and
>> TLS_ECDH_anon key agreement methods MG>do not authenticate the server
>>> MG>you will want public key size to be min 2048bit to conform to chrome
>> secure transmission requirements
>>> MG>securing message is done thru MD5 or SHA but you will need to
>> incorporate selected algo into
>>> MG>supported cipher-suite(s)
>>> https://en.wikipedia.org/wiki/Cipher_suite
>>> Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_suite>
>>> A cipher suite is a set of algorithms that help secure a network
>> connection that uses Transport Layer Security (TLS) or Secure Socket Layer
>> (SSL). The set of algorithms that cipher suites usually contain include: a
>> key exchange algorithm, a bulk encryption algorithm, and a message
>> authentication code (MAC) algorithm.. The key exchange algorithm is used to
>> exchange a key between two devices.
>>> en.wikipedia.org
>>> 
>>> 
>>> HTH
>>> Martin
>>> --
>>> Jan Høydahl
>>> Cominvent AS - www.cominvent.com<http://www.cominvent.com>
>>> 
>> 
>> 


Re: Digest auth with classic TCP transport

Posted by Andor Molnar <an...@cloudera.com.INVALID>.
https://cwiki.apache.org/confluence/display/ZOOKEEPER/ZooKeeper+SSL+User+Guide

SSL (client-server) has been added in 3.5.1
SSL server-server support is being reviewed on GitHub.

Regards,
Andor



On Thu, Sep 27, 2018 at 3:46 PM, Jan Høydahl <ja...@cominvent.com> wrote:

> Hi,
>
> > if you're prevented from implementing SSL why not use TLSv1.3?
>
>
> I have not found any evidence that Zookeeper server nor (Java) client
> supports TLS in version 3.4.13. Please point me to some docs or tutorial.
> We don't want to fork Zookeeper to implement this stuff ourselves :)
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
> >
> >
> > ________________________________
> > From: Jan Høydahl <ja...@cominvent.com>
> > Sent: Thursday, September 27, 2018 5:12 AM
> > To: user@zookeeper.apache.org
> > Subject: Digest auth with classic TCP transport
> >
> > Hi
> >
> > We use ZK 3.4.13, and unfortunately cannot use Netty transport and SSL.
> > We plan to use digest authentication and Zookeeper ACL protection.
> >
> > Question is, since we cannot use SSL, is there some other way to make
> sure the user credentials are not sniffed over the network and thus let an
> attacker impersonate our application and cange the content in Zookeeper?
> Does the Zookeeper client do some smart moves to protect/hash the password
> over the network? I suppose the binary transport is easy to decipher for
> those who try.
> >
> > MG>if you're prevented from implementing SSL why not use TLSv1.3?
> > MG>with TLSv1.3 you can implement encryption/decryption with crypto
> private/public keys and x509 certs
> > https://en.wikipedia.org/wiki/Transport_Layer_Security
> > Transport Layer Security - Wikipedia<https://en.
> wikipedia.org/wiki/Transport_Layer_Security>
> > Transport Layer Security (TLS) – and its predecessor, Secure Sockets
> Layer (SSL), which is now deprecated by the Internet Engineering Task Force
> (IETF) – are cryptographic protocols that provide communications security
> over a computer network. Several versions of the protocols find widespread
> use in applications such as web browsing, email, instant messaging, and
> voice over IP (VoIP).
> > en.wikipedia.org
> >
> >
> > MG>path of least resistance is to contact verisign and ask them to
> generate keys, certs and allow them to act as CA
> > MG>Caveat: tls1.3 implementation is slow and is supported by Mozilla
> v60...and some versions of chrome
> > MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon and
> TLS_ECDH_anon key agreement methods MG>do not authenticate the server
> > MG>you will want public key size to be min 2048bit to conform to chrome
> secure transmission requirements
> > MG>securing message is done thru MD5 or SHA but you will need to
> incorporate selected algo into
> > MG>supported cipher-suite(s)
> > https://en.wikipedia.org/wiki/Cipher_suite
> > Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_suite>
> > A cipher suite is a set of algorithms that help secure a network
> connection that uses Transport Layer Security (TLS) or Secure Socket Layer
> (SSL). The set of algorithms that cipher suites usually contain include: a
> key exchange algorithm, a bulk encryption algorithm, and a message
> authentication code (MAC) algorithm.. The key exchange algorithm is used to
> exchange a key between two devices.
> > en.wikipedia.org
> >
> >
> > HTH
> > Martin
> > --
> > Jan Høydahl
> > Cominvent AS - www.cominvent.com<http://www.cominvent.com>
> >
>
>

Re: Digest auth with classic TCP transport

Posted by Jan Høydahl <ja...@cominvent.com>.
Hi,

> if you're prevented from implementing SSL why not use TLSv1.3?


I have not found any evidence that Zookeeper server nor (Java) client supports TLS in version 3.4.13. Please point me to some docs or tutorial. We don't want to fork Zookeeper to implement this stuff ourselves :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 27. sep. 2018 kl. 15:17 skrev Martin Gainty <mg...@hotmail.com>:
> 
> 
> ________________________________
> From: Jan Høydahl <ja...@cominvent.com>
> Sent: Thursday, September 27, 2018 5:12 AM
> To: user@zookeeper.apache.org
> Subject: Digest auth with classic TCP transport
> 
> Hi
> 
> We use ZK 3.4.13, and unfortunately cannot use Netty transport and SSL.
> We plan to use digest authentication and Zookeeper ACL protection.
> 
> Question is, since we cannot use SSL, is there some other way to make sure the user credentials are not sniffed over the network and thus let an attacker impersonate our application and cange the content in Zookeeper? Does the Zookeeper client do some smart moves to protect/hash the password over the network? I suppose the binary transport is easy to decipher for those who try.
> 
> MG>if you're prevented from implementing SSL why not use TLSv1.3?
> MG>with TLSv1.3 you can implement encryption/decryption with crypto private/public keys and x509 certs
> https://en.wikipedia.org/wiki/Transport_Layer_Security
> Transport Layer Security - Wikipedia<https://en.wikipedia.org/wiki/Transport_Layer_Security>
> Transport Layer Security (TLS) – and its predecessor, Secure Sockets Layer (SSL), which is now deprecated by the Internet Engineering Task Force (IETF) – are cryptographic protocols that provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP).
> en.wikipedia.org
> 
> 
> MG>path of least resistance is to contact verisign and ask them to generate keys, certs and allow them to act as CA
> MG>Caveat: tls1.3 implementation is slow and is supported by Mozilla v60...and some versions of chrome
> MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon and TLS_ECDH_anon key agreement methods MG>do not authenticate the server
> MG>you will want public key size to be min 2048bit to conform to chrome secure transmission requirements
> MG>securing message is done thru MD5 or SHA but you will need to incorporate selected algo into
> MG>supported cipher-suite(s)
> https://en.wikipedia.org/wiki/Cipher_suite
> Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_suite>
> A cipher suite is a set of algorithms that help secure a network connection that uses Transport Layer Security (TLS) or Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.. The key exchange algorithm is used to exchange a key between two devices.
> en.wikipedia.org
> 
> 
> HTH
> Martin
> --
> Jan Høydahl
> Cominvent AS - www.cominvent.com<http://www.cominvent.com>
> 


Re: Digest auth with classic TCP transport

Posted by Martin Gainty <mg...@hotmail.com>.
________________________________
From: Jan Høydahl <ja...@cominvent.com>
Sent: Thursday, September 27, 2018 5:12 AM
To: user@zookeeper.apache.org
Subject: Digest auth with classic TCP transport

Hi

We use ZK 3.4.13, and unfortunately cannot use Netty transport and SSL.
We plan to use digest authentication and Zookeeper ACL protection.

Question is, since we cannot use SSL, is there some other way to make sure the user credentials are not sniffed over the network and thus let an attacker impersonate our application and cange the content in Zookeeper? Does the Zookeeper client do some smart moves to protect/hash the password over the network? I suppose the binary transport is easy to decipher for those who try.

MG>if you're prevented from implementing SSL why not use TLSv1.3?
MG>with TLSv1.3 you can implement encryption/decryption with crypto private/public keys and x509 certs
https://en.wikipedia.org/wiki/Transport_Layer_Security
Transport Layer Security - Wikipedia<https://en.wikipedia.org/wiki/Transport_Layer_Security>
Transport Layer Security (TLS) – and its predecessor, Secure Sockets Layer (SSL), which is now deprecated by the Internet Engineering Task Force (IETF) – are cryptographic protocols that provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP).
en.wikipedia.org


MG>path of least resistance is to contact verisign and ask them to generate keys, certs and allow them to act as CA
MG>Caveat: tls1.3 implementation is slow and is supported by Mozilla v60...and some versions of chrome
MG>as far as ciphers to prevent MIMA do not implement TLS_DH_anon and TLS_ECDH_anon key agreement methods MG>do not authenticate the server
MG>you will want public key size to be min 2048bit to conform to chrome secure transmission requirements
MG>securing message is done thru MD5 or SHA but you will need to incorporate selected algo into
MG>supported cipher-suite(s)
https://en.wikipedia.org/wiki/Cipher_suite
Cipher suite - Wikipedia<https://en.wikipedia.org/wiki/Cipher_suite>
A cipher suite is a set of algorithms that help secure a network connection that uses Transport Layer Security (TLS) or Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.. The key exchange algorithm is used to exchange a key between two devices.
en.wikipedia.org


HTH
Martin
--
Jan Høydahl
Cominvent AS - www.cominvent.com<http://www.cominvent.com>