I think a bunch of people confuse "network" with "world wide web"The thing I am building is an appliance, it uses an internal network and it is not connected to anything 'internet', WAN or 'LAN'
It is storage, sort of a file system, I worry about security of that internal network as much as I worry about the security of the cable between my disk controller and the hard drive.
Also, no encryption is needed if the data you send is already encrypted, that would only be a waste of performance.
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
|