I put up a patch with the proposed solution here:
https://gerrit.cloudera.org/#/c/5976/
On Fri, Feb 10, 2017 at 10:50 AM, Alexey Serbin
wrote:
> ok, thanks.
>
> Yep -- the realization of the simple fact that we should not protect
> against super-user on a local machine came to me after I sent t
ok, thanks.
Yep -- the realization of the simple fact that we should not protect
against super-user on a local machine came to me after I sent that e-mail.
Sorry for the noise.
On Fri, Feb 10, 2017 at 10:30 AM, Todd Lipcon wrote:
> On Fri, Feb 10, 2017 at 10:14 AM, Alexey Serbin
> wrote:
>
> >
On Fri, Feb 10, 2017 at 10:32 AM, Dan Burkert wrote:
> On Fri, Feb 10, 2017 at 10:14 AM, Alexey Serbin
> wrote:
> >
> > From the other side, I think dropping TLS opens a door for localhost MITM
> > attacks if an attacker can control access to ipfilter (fiddling with data
> > like rewriting traff
On Fri, Feb 10, 2017 at 10:14 AM, Alexey Serbin
wrote:
>
> From the other side, I think dropping TLS opens a door for localhost MITM
> attacks if an attacker can control access to ipfilter (fiddling with data
> like rewriting traffic?).
>
This would require root, right?
>
> BTW, if dropping enc
On Fri, Feb 10, 2017 at 10:29 AM, Dan Burkert wrote:
> On Fri, Feb 10, 2017 at 10:02 AM, Todd Lipcon wrote:
> >
> > Yea, but still the best number here is 685MB/sec. Assuming 2ghz, that's
> > around 3 cycles/byte (~25x slower than crc32). According to Intel, AES
> > encryption with AESNI can be
An an afterthought, it seems that concerns about localhost MITM attacks
involving super-user access to the machine do not make much sense. :)
On Fri, Feb 10, 2017 at 10:14 AM, Alexey Serbin
wrote:
> Hi Todd,
>
> Thank you for sharing the perf stats you observed. I'm curious: during
> those s_cl
On Fri, Feb 10, 2017 at 10:14 AM, Alexey Serbin
wrote:
> Hi Todd,
>
> Thank you for sharing the perf stats you observed. I'm curious: during
> those s_client/s_server tests, was the TLS/SSL compression on or off? I
> don't think it would change the result a lot but it's interesting to know.
>
On Fri, Feb 10, 2017 at 10:02 AM, Todd Lipcon wrote:
>
> Yea, I figured that both sides would check the remote peer, and if they
> both agree that the other side is local, they'd offer TLS_NEGOTIATION_ONLY
> or somesuch. This could also be used in a scenario where a user needs
> authentication but
Hi Todd,
Thank you for sharing the perf stats you observed. I'm curious: during
those s_client/s_server tests, was the TLS/SSL compression on or off? I
don't think it would change the result a lot but it's interesting to know.
I think that from performance perspective dropping TLS wrapping arou
On Thu, Feb 9, 2017 at 10:50 PM, Dan Burkert wrote:
> A couple thoughts:
>
> * You had to explicitly turn on the ADH and AECDH ciphers, right? We
> shouldn't be using those in any circumstances, but I don't think it would
> change the results of your test.
>
Right, I was just too lazy to set up
A couple thoughts:
* You had to explicitly turn on the ADH and AECDH ciphers, right? We
shouldn't be using those in any circumstances, but I don't think it would
change the results of your test.
* We've discussed adding checksums to the RPC system in the past, but
punted since we would get it 'f
Hey folks,
For those not following along, we're very close to the point where we'll be
enabling TLS for all wire communication done by a Kudu cluster (at least
when security features are enabled). One thing we've decided is important
is to preserve good performance for applications like Spark and
12 matches
Mail list logo
