Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

it's an extra layer of security, an imposed requirement

On 12/08/2015 04:14 PM, Yann Ylavic wrote:

On Tue, Dec 8, 2015 at 8:51 PM, Ron Croonenberg  wrote:


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.


So why authentication/integrity?
Any fear that the hardware becomes malicious?
CRCs are cheaper and good enough for detecting harware errors...

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



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Yann Ylavic]

On Tue, Dec 8, 2015 at 8:51 PM, Ron Croonenberg  wrote:
>
> 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.

So why authentication/integrity?
Any fear that the hardware becomes malicious?
CRCs are cheaper and good enough for detecting harware errors...

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

Re: [users@httpd] explicitly including other ciphers for use with https

[Eric Covener]

On Tue, Dec 8, 2015 at 3:25 PM, Eric Covener  wrote:
> On Tue, Dec 8, 2015 at 3:05 PM, Ron Croonenberg  wrote:
>> also, " ... cipher strings are complex and we're protecting people from
>> inadvertently .. "  ..   that is why we have MS-windows and Mac-OS out
>> there. Most Linux installations are work horses, mostly run by people that
>> know what they are doing.
>
> Not my experience on this list, stack overflow, IRC, or day job.

To clarify, that users know what they're doing _to the extent
that things like the SSL config is not daunting/challenging_.

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

Re: [users@httpd] explicitly including other ciphers for use with https

[Eric Covener]

On Tue, Dec 8, 2015 at 3:05 PM, Ron Croonenberg  wrote:
> also, " ... cipher strings are complex and we're protecting people from
> inadvertently .. "  ..   that is why we have MS-windows and Mac-OS out
> there. Most Linux installations are work horses, mostly run by people that
> know what they are doing.

Not my experience on this list, stack overflow, IRC, or day job.

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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

There are a bunch of applications for using  http with encrypted 
authentication without encrypted data.


For example, in 'cloud computing application'  (which what I am build 
somewhat is), you want  password protection/checking for checking at a 
different stage. However if you have to move TBs of data, you really 
don't want payload encryption, if needed there are better ways.


also, " ... cipher strings are complex and we're protecting people from 
inadvertently .. "  ..   that is why we have MS-windows and Mac-OS out 
there. Most Linux installations are work horses, mostly run by people 
that know what they are doing.



On 12/08/2015 12:20 PM, Eric Covener wrote:

On Tue, Dec 8, 2015 at 2:19 PM, Eric Covener  wrote:

On Tue, Dec 8, 2015 at 11:41 AM, Ron Croonenberg  wrote:

P.S:  why not make it an option that can be configured and where the default
'setting' is "no NULL ciphers" ?


I think the rational ie that the cipher strings are complex and we're
protecting people from inadvertently enabling null and export ciphers.


That part was probably obvious, the reason it's not configurable is that
nobody has made it a priority to develop/test/review something better.

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



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

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" mailto:m...@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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

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" mailto:m...@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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Eric Covener]

On Tue, Dec 8, 2015 at 2:19 PM, Eric Covener  wrote:
> On Tue, Dec 8, 2015 at 11:41 AM, Ron Croonenberg  wrote:
>> P.S:  why not make it an option that can be configured and where the default
>> 'setting' is "no NULL ciphers" ?
>
> I think the rational ie that the cipher strings are complex and we're
> protecting people from inadvertently enabling null and export ciphers.

That part was probably obvious, the reason it's not configurable is that
nobody has made it a priority to develop/test/review something better.

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

Re: [users@httpd] explicitly including other ciphers for use with https

[Eric Covener]

On Tue, Dec 8, 2015 at 11:41 AM, Ron Croonenberg  wrote:
> P.S:  why not make it an option that can be configured and where the default
> 'setting' is "no NULL ciphers" ?

I think the rational ie that the cipher strings are complex and we're
protecting people from inadvertently enabling null and export ciphers.

-- 
Eric Covener
cove...@gmail.com

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

Re: [users@httpd] explicitly including other ciphers for use with https

[Jacob Champion]

On 12/07/2015 09:54 PM, William A Rowe Jr wrote:

On Dec 7, 2015 11:36 PM, "Marat Khalili" mailto:m...@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-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org

Re: [users@httpd] explicitly including other ciphers for use with https

[Marat Khalili]

Can't you just use stunnel for the TLS part? According to some information on 
the net it can be configured to use null cipher without recompilation. IMO it 
should be compatible with 'normal' HTTPS, save for things like virtualhost name 
extension. If HTTPS compatibility matters to you at all, because you can use 
stunnel on both sides.
--

With Best Regards,
Marat Khalili

On December 7, 2015 11:39:30 PM GMT+03:00, Ron Croonenberg  
wrote:
>Hello,
>
>I a building a storage system, using HTTP/HTTPS for ingesting data.
>
>I would like to use the authentication over HTTPS, while after that I 
>want no encryption on the data because of peformance.
>
>I think using  null ciphers, like eNULL would work, but how do I change
>
>the configurations is httpd.conf/ssl.conf ?
>
>The NULL cipher keys are in openssl,  I just want to use them.
>
>
>thanks,
>
>Ron
>
>-
>To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
>For additional commands, e-mail: users-h...@httpd.apache.org

RE: [users@httpd] explicitly including other ciphers for use with https

[IdealGourmet]

This is an error email !! don’t send more email here !!

 

De: William A Rowe Jr [mailto:wr...@rowe-clan.net] 
Enviado el: mardi 8 décembre 2015 18:36
Para: users@httpd.apache.org
Asunto: Re: [users@httpd] explicitly including other ciphers for use with https

 

On Tue, Dec 8, 2015 at 10:45 AM, Ron Croonenberg  wrote:

I forgot,  is there a "standard way" to create an rpm so I can install the 
binaries somewhere?

 

Well, all the major linux distributions have their own forks, their own 'one 
right

way' to package rpm/deb/etc, but have a look in the build/ directory of your

source tarball.

 

On 12/08/2015 09:41 AM, Ron Croonenberg wrote:

so in the source tree:

modules/ssl


in: ssl_engine_config.c
I see two lines:
arg = apr_pstrcat(cmd->pool, "!aNULL:!eNULL:!EXP:", arg, NULL);

and tossed eNULL out

in: ssl_engine_init.c
I see a line:
apr_pstrcat(ptemp, "!aNULL:!eNULL:!EXP:", SSL_DEFAULT_CIPHER_LIST,

these 3 locations are the only places where NULL ciphers are excluded,
right?

 

Offhand, yes. 

 

 

P.S:  why not make it an option that can be configured and where the
default 'setting' is "no NULL ciphers" ?

 

Because a very tiny fraction of the users who toggle such an option 

will know what they are doing.

 

You clearly do, however you may or may not find the performance gains

you are hoping for, there are more efficient auth mechanisms such as

digest authentication that will not pass passwords in the clear, and there

are others such as gssapi that perform the authentication function alone

using typical linux semantics.

 

Have you looked at https://github.com/modauthgssapi/mod_auth_gssapi

as an alternative for this particular use case?

 

No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2016.0.7227 / Base de datos de virus: 4477/11138 - Fecha de 
publicación: 12/08/15

Re: [users@httpd] explicitly including other ciphers for use with https

[William A Rowe Jr]

On Tue, Dec 8, 2015 at 10:45 AM, Ron Croonenberg  wrote:

> I forgot,  is there a "standard way" to create an rpm so I can install the
> binaries somewhere?
>

Well, all the major linux distributions have their own forks, their own
'one right
way' to package rpm/deb/etc, but have a look in the build/ directory of your
source tarball.


> On 12/08/2015 09:41 AM, Ron Croonenberg wrote:
>
>> so in the source tree:
>>
>> modules/ssl
>>
>>
>> in: ssl_engine_config.c
>> I see two lines:
>> arg = apr_pstrcat(cmd->pool, "!aNULL:!eNULL:!EXP:", arg, NULL);
>>
>> and tossed eNULL out
>>
>> in: ssl_engine_init.c
>> I see a line:
>> apr_pstrcat(ptemp, "!aNULL:!eNULL:!EXP:", SSL_DEFAULT_CIPHER_LIST,
>>
>> these 3 locations are the only places where NULL ciphers are excluded,
>> right?
>>
>
Offhand, yes.



> P.S:  why not make it an option that can be configured and where the
>> default 'setting' is "no NULL ciphers" ?
>>
>
Because a very tiny fraction of the users who toggle such an option
will know what they are doing.

You clearly do, however you may or may not find the performance gains
you are hoping for, there are more efficient auth mechanisms such as
digest authentication that will not pass passwords in the clear, and there
are others such as gssapi that perform the authentication function alone
using typical linux semantics.

Have you looked at https://github.com/modauthgssapi/mod_auth_gssapi
as an alternative for this particular use case?

RE: [users@httpd] explicitly including other ciphers for use with https

[IdealGourmet]

You make an error, don't send more email here please

-Mensaje original-
De: Ron Croonenberg [mailto:r...@lanl.gov] 
Enviado el: mardi 8 décembre 2015 17:46
Para: users@httpd.apache.org
Asunto: Re: [users@httpd] explicitly including other ciphers for use with https

I forgot,  is there a "standard way" to create an rpm so I can install the 
binaries somewhere?

thanks,

Ron


On 12/08/2015 09:41 AM, Ron Croonenberg wrote:
> so in the source tree:
>
> modules/ssl
>
>
> in: ssl_engine_config.c
> I see two lines:
> arg = apr_pstrcat(cmd->pool, "!aNULL:!eNULL:!EXP:", arg, NULL);
>
> and tossed eNULL out
>
> in: ssl_engine_init.c
> I see a line:
> apr_pstrcat(ptemp, "!aNULL:!eNULL:!EXP:", SSL_DEFAULT_CIPHER_LIST,
>
> these 3 locations are the only places where NULL ciphers are excluded, 
> right?
>
> Ron
>
>
> P.S:  why not make it an option that can be configured and where the 
> default 'setting' is "no NULL ciphers" ?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
> For additional commands, e-mail: users-h...@httpd.apache.org
>

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



-
No se encontraron virus en este mensaje.
Comprobado por AVG - www.avg.com
Versión: 2016.0.7227 / Base de datos de virus: 4477/11138 - Fecha de 
publicación: 12/08/15


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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

I forgot,  is there a "standard way" to create an rpm so I can install 
the binaries somewhere?


thanks,

Ron


On 12/08/2015 09:41 AM, Ron Croonenberg wrote:

so in the source tree:

modules/ssl


in: ssl_engine_config.c
I see two lines:
arg = apr_pstrcat(cmd->pool, "!aNULL:!eNULL:!EXP:", arg, NULL);

and tossed eNULL out

in: ssl_engine_init.c
I see a line:
apr_pstrcat(ptemp, "!aNULL:!eNULL:!EXP:", SSL_DEFAULT_CIPHER_LIST,

these 3 locations are the only places where NULL ciphers are excluded,
right?

Ron


P.S:  why not make it an option that can be configured and where the
default 'setting' is "no NULL ciphers" ?

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



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

so in the source tree:

modules/ssl


in: ssl_engine_config.c
I see two lines:
arg = apr_pstrcat(cmd->pool, "!aNULL:!eNULL:!EXP:", arg, NULL);

and tossed eNULL out

in: ssl_engine_init.c
I see a line:
apr_pstrcat(ptemp, "!aNULL:!eNULL:!EXP:", SSL_DEFAULT_CIPHER_LIST,

these 3 locations are the only places where NULL ciphers are excluded, 
right?


Ron


P.S:  why not make it an option that can be configured and where the 
default 'setting' is "no NULL ciphers" ?


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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

It should be straightforward to patch mod_ssl to accept null ciphers,
for such an unusual use case, but it isn't something we would likely
accept in the ASF distribution for the reasons I outlined.


that would be fine, this is cluster that needs to move a lot data 
internally in a very short amount of time..


where in mod_ssl would I be looking?



Otherwise,
any man-in-the-middle can observe the data in transit and alter
the data passed between your client and backend storage server


there are no men to be in the middle.  the servers have no logins/users. 
 Consider it an appliance,  in general people also don't worry about 
someone sniffing the wire between a HDU sas connector and the drive's 
chipset. This is the same thing, just a little bigger.




Wait, why does the use of NULL encryption have any effect on the
authenticity/integrity characteristics of the cipher? I asserted
otherwise on openssl-users and was not corrected...


I didn't suggest it that it would.  Everything *after* that handshake,
in cleartext, is open for inspection or for manipulation by every link
in between the user agent and server.


except in my case,  there is 'no one there' to do it. It is a separate, 
isolated network.


thanks,

Ron


--Jacob

[1] https://marc.info/?t=14490098273&r=1&w=2



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

consider it an appliance,  there are no user on this IB-fabric/network 
just machines with no users/logins that communicate with each other.


I am looking for speed at this point, safety is not a concern, I can 
solve that otherwise later.


Besides,  I am trying to have a discussion about if something is secure 
or not, I am trying to figure out how to use/compile mod_ssl/apache 
where I'll be able to use the eNULL cipher.



Ron


On 12/07/2015 06:40 PM, Jacob Champion wrote:

On 12/07/2015 05:06 PM, William A Rowe Jr wrote:

On Mon, Dec 7, 2015 at 2:39 PM, Ron Croonenberg mailto:r...@lanl.gov>> wrote:

Hello,

I a building a storage system, using HTTP/HTTPS for ingesting data.

I would like to use the authentication over HTTPS, while after that
I want no encryption on the data because of peformance.


Then you probably don't understand the performance impact of TLS.


To help Ron out a little... he's coming from this conversation [1] on
the openssl-users mailing list, where he's described his rather unusual
network topology already.

I'm still unsure as to whether or not his proposed solution is secure...
but I am convinced that his use case is atypical.


Otherwise,
any man-in-the-middle can observe the data in transit and alter
the data passed between your client and backend storage server


Wait, why does the use of NULL encryption have any effect on the
authenticity/integrity characteristics of the cipher? I asserted
otherwise on openssl-users and was not corrected...

--Jacob

[1] https://marc.info/?t=14490098273&r=1&w=2

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



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

Ok,  I want to use encrypted authentication BUT do not want to use any 
encryption of the data at all.


I do have 100% control over all off the IB fabric (and it is not in 
'user space', consider it an appliance'  this will be running on. I am 
not interested in something secure at this point, I am interested in 
performance.




On 12/07/2015 06:06 PM, William A Rowe Jr wrote:

On Mon, Dec 7, 2015 at 2:39 PM, Ron Croonenberg mailto:r...@lanl.gov>> wrote:

Hello,

I a building a storage system, using HTTP/HTTPS for ingesting data.

I would like to use the authentication over HTTPS, while after that
I want no encryption on the data because of peformance.


Then you probably don't understand the performance impact of TLS.

TLS is very expensive to negotiate between endpoints working from
elliptic curve or prime math.  There's no avoiding this initial hit if you
are going to use TLS whatsoever.

Once the endpoints have completed the handshake, they exchange
keys for a much simpler and more performant cipher such as the
AES-256 cipher (for faster performance, you could use AES-128
depending on the application).

You will measure very little benefit dropping TLS once the handshake
and your auth step is completed.

I think using  null ciphers, like eNULL would work, but how do I
change the configurations is httpd.conf/ssl.conf ?

The NULL cipher keys are in openssl,  I just want to use them.


Only if you have 100% faith in the end-to-end topography of your
network. That pretty much restricts you to localhost:. Otherwise,
any man-in-the-middle can observe the data in transit and alter
the data passed between your client and backend storage server,
which makes the entire point of authenticating rather silly, don't
you think?



.



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

Re: [users@httpd] explicitly including other ciphers for use with https

[Marat Khalili]

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?

Isn't this authentication is for?

--

With Best Regards,
Marat Khalili

On 08/12/15 08:54, William A Rowe Jr wrote:


On Dec 7, 2015 11:36 PM, "Marat Khalili" > 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?

Re: [users@httpd] explicitly including other ciphers for use with https

[William A Rowe Jr]

On Dec 7, 2015 11:36 PM, "Marat Khalili"  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?

Re: [users@httpd] explicitly including other ciphers for use with https

[Marat Khalili]

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?


--

With Best Regards,
Marat Khalili


On 08/12/15 05:30, William A Rowe Jr wrote:
On Mon, Dec 7, 2015 at 7:40 PM, Jacob Champion > wrote:


On 12/07/2015 05:06 PM, William A Rowe Jr wrote:

On Mon, Dec 7, 2015 at 2:39 PM, Ron Croonenberg mailto:r...@lanl.gov>
>> wrote:

Hello,

I a building a storage system, using HTTP/HTTPS for
ingesting data.

I would like to use the authentication over HTTPS, while
after that
I want no encryption on the data because of peformance.


Then you probably don't understand the performance impact of TLS.


To help Ron out a little... he's coming from this conversation [1]
on the openssl-users mailing list, where he's described his rather
unusual network topology already.

I'm still unsure as to whether or not his proposed solution is
secure... but I am convinced that his use case is atypical.


It should be straightforward to patch mod_ssl to accept null ciphers, 
for such an unusual use case, but it isn't something we would likely 
accept in the ASF distribution for the reasons I outlined.


Otherwise,
any man-in-the-middle can observe the data in transit and alter
the data passed between your client and backend storage server


Wait, why does the use of NULL encryption have any effect on the
authenticity/integrity characteristics of the cipher? I asserted
otherwise on openssl-users and was not corrected...


I didn't suggest it that it would.  Everything *after* that handshake, 
in cleartext, is open for inspection or for manipulation by every link 
in between the user agent and server.


--Jacob

[1] https://marc.info/?t=14490098273&r=1&w=2

Re: [users@httpd] explicitly including other ciphers for use with https

[William A Rowe Jr]

On Mon, Dec 7, 2015 at 7:40 PM, Jacob Champion  wrote:

> On 12/07/2015 05:06 PM, William A Rowe Jr wrote:
>
>> On Mon, Dec 7, 2015 at 2:39 PM, Ron Croonenberg > > wrote:
>>
>> Hello,
>>
>> I a building a storage system, using HTTP/HTTPS for ingesting data.
>>
>> I would like to use the authentication over HTTPS, while after that
>> I want no encryption on the data because of peformance.
>>
>>
>> Then you probably don't understand the performance impact of TLS.
>>
>
> To help Ron out a little... he's coming from this conversation [1] on the
> openssl-users mailing list, where he's described his rather unusual network
> topology already.
>
> I'm still unsure as to whether or not his proposed solution is secure...
> but I am convinced that his use case is atypical.


It should be straightforward to patch mod_ssl to accept null ciphers, for
such an unusual use case, but it isn't something we would likely accept in
the ASF distribution for the reasons I outlined.


> Otherwise,
>> any man-in-the-middle can observe the data in transit and alter
>> the data passed between your client and backend storage server
>>
>
> Wait, why does the use of NULL encryption have any effect on the
> authenticity/integrity characteristics of the cipher? I asserted otherwise
> on openssl-users and was not corrected...
>

I didn't suggest it that it would.  Everything *after* that handshake, in
cleartext, is open for inspection or for manipulation by every link in
between the user agent and server.


> --Jacob
>
> [1] https://marc.info/?t=14490098273&r=1&w=2

Re: [users@httpd] explicitly including other ciphers for use with https

[Jacob Champion]

On 12/07/2015 05:06 PM, William A Rowe Jr wrote:

On Mon, Dec 7, 2015 at 2:39 PM, Ron Croonenberg mailto:r...@lanl.gov>> wrote:

Hello,

I a building a storage system, using HTTP/HTTPS for ingesting data.

I would like to use the authentication over HTTPS, while after that
I want no encryption on the data because of peformance.


Then you probably don't understand the performance impact of TLS.


To help Ron out a little... he's coming from this conversation [1] on 
the openssl-users mailing list, where he's described his rather unusual 
network topology already.


I'm still unsure as to whether or not his proposed solution is secure... 
but I am convinced that his use case is atypical.



Otherwise,
any man-in-the-middle can observe the data in transit and alter
the data passed between your client and backend storage server


Wait, why does the use of NULL encryption have any effect on the 
authenticity/integrity characteristics of the cipher? I asserted 
otherwise on openssl-users and was not corrected...


--Jacob

[1] https://marc.info/?t=14490098273&r=1&w=2

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

Re: [users@httpd] explicitly including other ciphers for use with https

[William A Rowe Jr]

On Mon, Dec 7, 2015 at 2:39 PM, Ron Croonenberg  wrote:

> Hello,
>
> I a building a storage system, using HTTP/HTTPS for ingesting data.
>
> I would like to use the authentication over HTTPS, while after that I want
> no encryption on the data because of peformance.
>

Then you probably don't understand the performance impact of TLS.

TLS is very expensive to negotiate between endpoints working from
elliptic curve or prime math.  There's no avoiding this initial hit if you
are going to use TLS whatsoever.

Once the endpoints have completed the handshake, they exchange
keys for a much simpler and more performant cipher such as the
AES-256 cipher (for faster performance, you could use AES-128
depending on the application).

You will measure very little benefit dropping TLS once the handshake
and your auth step is completed.


> I think using  null ciphers, like eNULL would work, but how do I change
> the configurations is httpd.conf/ssl.conf ?
>
> The NULL cipher keys are in openssl,  I just want to use them.
>

Only if you have 100% faith in the end-to-end topography of your
network. That pretty much restricts you to localhost:. Otherwise,
any man-in-the-middle can observe the data in transit and alter
the data passed between your client and backend storage server,
which makes the entire point of authenticating rather silly, don't
you think?



.

[users@httpd] explicitly including other ciphers for use with https

[Ron Croonenberg]

Hello,

I a building a storage system, using HTTP/HTTPS for ingesting data.

I would like to use the authentication over HTTPS, while after that I 
want no encryption on the data because of peformance.


I think using  null ciphers, like eNULL would work, but how do I change 
the configurations is httpd.conf/ssl.conf ?


The NULL cipher keys are in openssl,  I just want to use them.


thanks,

Ron

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