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 <aser...@cloudera.com> 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 that e-mail. > Sorry for the noise. > > On Fri, Feb 10, 2017 at 10:30 AM, Todd Lipcon <t...@cloudera.com> wrote: > > > On Fri, Feb 10, 2017 at 10:14 AM, Alexey Serbin <aser...@cloudera.com> > > 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. > > > > > > > Compression was off: > > > > todd@todd-ThinkPad-T540p:~/sw/openssl-1.0.1f$ perf stat bash -c 'dd > > if=/dev/zero bs=1M count=5000 | openssl s_client -cipher ADH-AES128-SHA' > > CONNECTED(00000003) > > --- > > no peer certificate available > > --- > > No client certificate CA names sent > > Server Temp Key: DH, 2048 bits > > --- > > SSL handshake has read 850 bytes and written 441 bytes > > --- > > New, TLSv1/SSLv3, Cipher is ADH-AES128-SHA > > Secure Renegotiation IS supported > > Compression: NONE > > Expansion: NONE > > No ALPN negotiated > > SSL-Session: > > Protocol : TLSv1.2 > > Cipher : ADH-AES128-SHA > > Session-ID: > > 5FE2AA31BC78C5578DE5FE95D3380E4D7094B1040A7D6E9C6A5EC15929F04564 > > Session-ID-ctx: > > Master-Key: > > AE0FA5291957492495B7B3424CD4283FEA113727919D393AA19318516827 > > E9AB074BCBC2A445584FE5C01DC59424B6F3 > > Key-Arg : None > > PSK identity: None > > PSK identity hint: None > > SRP username: None > > TLS session ticket lifetime hint: 300 (seconds) > > TLS session ticket: > > 0000 - 8f 7e 92 27 06 5f 24 7c-3c a0 20 5d 7e a3 f8 d1 .~.'._$|<. > > ]~... > > 0010 - 4f 49 ad fc 52 30 e3 89-e0 a8 3a 53 29 e1 07 d4 > > OI..R0....:S)... > > 0020 - 22 01 4b 95 40 5d 27 77-cf 6c b5 77 41 97 3a 88 ".K.@ > > ]'w.l.wA.:. > > 0030 - 35 23 6e c4 c7 66 36 0b-aa b5 ef d5 eb d8 3e cf > > 5#n..f6.......>. > > 0040 - 34 c3 38 2a 0d b3 f9 26-1c a2 49 fe bc 27 b1 74 > > 4.8*...&..I..'.t > > 0050 - 89 96 42 69 af 11 c9 6c-da 3d 65 bc 85 dd 64 d7 > > ..Bi...l.=e...d. > > 0060 - 39 0f 78 34 6a c6 27 7e-57 37 b3 eb 60 cc c0 2d > > 9.x4j.'~W7..`..- > > 0070 - 3a a2 12 bc e6 d6 85 8e-ba 9d 7a 9e e2 e7 a0 ab > > :.........z..... > > 0080 - 47 1a d9 67 ec be 78 2a-d4 91 57 75 93 e1 28 a3 > > G..g..x*..Wu..(. > > 0090 - 30 24 c9 8f d1 37 bd e1-69 4b 18 43 85 f6 7e 63 > > 0$...7..iK.C..~c > > > > Start Time: 1486707067 > > Timeout : 300 (sec) > > Verify return code: 0 (ok) > > > > > > > > > > > > I think that from performance perspective dropping TLS wrapping around > > the > > > connection just after authentication is the best solution. > > > > > > 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?). > > > > > > > I think the assumption we're going on is that we can't protect against > root > > on the same machine. (if you're root you could also just read the > process's > > memory, or edit the process, or dump the WAL, etc) > > > > > > > > > > BTW, if dropping encryption, are we concerned about leaking authz > tokens > > > when they are introduced? > > > > > > > > Same answer as above -- I don't think we're attempting to protect against > > local root in our threat model. > > > > -Todd > > > > > > > > > > On Thu, Feb 9, 2017 at 10:22 PM, Todd Lipcon <t...@cloudera.com> > wrote: > > > > > > > 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 > Impala > > > > which typically schedule tasks local to the data on the tablet > servers, > > > and > > > > we think that enabling TLS for these localhost connections will have > an > > > > unacceptable performance hit. > > > > > > > > Our thinking was to continue to use TLS *authentication* to prevent > > MITM > > > > attacks (possible because we typically don't bind to low ports). But, > > we > > > > don't need TLS *encryption*. > > > > > > > > This is possible using the various TLS "NULL" ciphers -- we can have > > both > > > > the client and server notice that the remote peer is local and enable > > the > > > > NULL cipher suite. However, I did some research this evening and it > > looks > > > > like the NULL ciphers disable encryption but don't disable the MAC > > > > integrity portion of TLS. Best I can tell, there is no API to do so. > > > > > > > > I did some brief checks using openssl s_client and s_server on my > > laptop > > > > (openssl 1.0.2g, haswell), and got the following numbers for > > transferring > > > > 5GB: > > > > > > > > ADH-AES128-SHA > > > > Client: 42.2M cycles > > > > Server: 35.3M cycles > > > > > > > > AECDH-NULL-SHA: (closest NULL I could find to the above) > > > > Client: 36.2M cycles > > > > Server: 28.6M cycles > > > > > > > > no TLS at all (using netcat to a local TCP port): > > > > Client: 20.8M cycles > > > > Server: 10.0M cycles > > > > > > > > baseline: iperf -n 5000M localhost > > > > Client: 2.3M cycles > > > > Server: 1.8M cycles > > > > [not sure why this is so much faster than netcat - I guess because > with > > > > netcat I was piping to /dev/null which still requires more syscalls?] > > > > > > > > (note that the client in all of these cases includes the 'dd' command > > to > > > > generate the data, which probably explains why it's 7-10M cycles more > > > than > > > > the server in every case) > > > > > > > > To summarize, just disabling encryption has not much improvement, > given > > > > that Intel chips now optimize AES. The checksumming itself adds more > > > > significant overhead than the encryption. This agrees with numbers > I've > > > > seen around the web that crypto-strength checksums only go 1GB/sec or > > so > > > > max, typically much slower. > > > > > > > > Thinking about the best solution here, I think we should consider > using > > > TLS > > > > during negotiation, and then just completely dropping the TLS (i.e > not > > > > wrapping the sockets in TlsSockets). I think this still gives us the > > > > protection against the localhost MITM (because the handshake would > > fail) > > > > and be trivially zero-overhead. Am I missing any big issues with this > > > idea? > > > > Anyone got a better one? > > > > > > > > -Todd > > > > -- > > > > Todd Lipcon > > > > Software Engineer, Cloudera > > > > > > > > > > > > > > > -- > > Todd Lipcon > > Software Engineer, Cloudera > > > -- Todd Lipcon Software Engineer, Cloudera
