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 <[email protected]> wrote: > On Fri, Feb 10, 2017 at 10:14 AM, Alexey Serbin <[email protected]> > 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 <[email protected]> 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 >
