Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
To: users@httpd.apache.org
References: <5665EE82.1040501@lanl.gov>
 <CACsi253AgSSO6sd5eDQ3BbgAz4rOVKsvE+iOT-HKojdNDpi4Kg@mail.gmail.com>
 <56663506.3020302@gmail.com>
 <CACsi250aH8_Lrp1c-PD0RkxHm83qanT+gyUrgZ_ikdZUpWb0Og@mail.gmail.com>
 <56666C30.8060501@rqc.ru>
 <CACsi253d6tKagEDMLyTvKt=yX1+9MSWs+JRzP4y4Wx1LWANuFQ@mail.gmail.com>
 <56672C62.4040200@gmail.com>
From: Ron Croonenberg <ronc@lanl.gov>
Message-ID: <566734C4.7010702@lanl.gov>
Date: Tue, 8 Dec 2015 12:51:32 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56672C62.4040200@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [users@httpd] explicitly including other ciphers for use with
 https

what if one simply doesn't care if the data is encrypted during 
transmission?.  The data I move to an object store, basically files, 
could already be stored encrypted. Also, hardware encrypters don't have 
a need for encrypting data again. Encrypting it again is just a waste of 
A LOT of bandwith. However the passwords still need to be encrypted and 
encrypting TBs of data because I need an 8-16 token password encrypted 
is just a little silly


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@rqc.ru
>> <mailto:mkh@rqc.ru>> 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@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org