I think a lot of people here are confusing 'network with "world wide web' and therefore NULL ciphers are unsafe
This is just a bunch of hardware, with connections between it's nodes.The whole thing/cluster is not connected to anything 'internet', not even LAN. I worry about those connections being secure as much as I worry about security between a disk-controller and a hard drive.
On 12/08/2015 12:15 PM, Jacob Champion wrote:
On 12/07/2015 09:54 PM, William A Rowe Jr wrote:On Dec 7, 2015 11:36 PM, "Marat Khalili" <mkh@xxxxxx <mailto:mkh@xxxxxx>> wrote: >> >> Everything *after* that handshake, in cleartext, is open for inspection or for manipulation > > Are you sure about the manipulation part? Why do you think encryption helps here then? To turn the question around, what gives you the suggestion that the user agent or the httpd server would notice any modification of plaintext bytes in transit through a router or other network intermediate?I would _expect_ that clients using an eNULL ciphersuite would check the MAC that is transferred as part of the TLS record. I would further expect the MAC to have been computed using a secret that was set up during the initial handshake, so that it cannot be faked by an intermediary who has been watching the stream. That's what I meant when I said that NULL encryption should have (AFAIK) no effect on the authn and integrity characteristics of the ciphersuites. It should only affect the confidentiality. But I'm not an expert in TLS -- do you know of a reason that eNULL ciphersuites have weaker guarantees on their integrity checks? If so, I'd really like to know... This is the second time in a week that someone has told me that eNULL ciphers provide effectively no security, and up to this point I have believed otherwise. (As an experiment, I compiled httpd to allow eNULL ciphersuites and captured an s_client conversation with dumpcap. Wireshark immediately "decrypted" the plaintext data but showed that there was still a MAC appended to each record. Modifying a single byte of that data caused Wireshark to fail its "decryption" of that record.) --Jacob --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|