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:
AE0FA5291957492495B7B3424CD4283FEA113727919D393AA19318516827E9AB074BCBC2A445584FE5C01DC59424B6F3
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
