Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

TLS renegotiation attack, mod_ssl and OpenSSL

 

 

First page Previous page 1 2 Next page Last page  View All Apache dev RSS feed   Index | Next | Previous | View Threaded


jorton at redhat

Nov 10, 2009, 6:25 AM

Post #26 of 29 (1537 views)
Permalink
Re: TLS renegotiation attack, mod_ssl and OpenSSL [In reply to]

On Tue, Nov 10, 2009 at 03:19:39PM +0100, Jean-Marc Desperrier wrote:
> Joe Orton wrote:
>> On Fri, Nov 06, 2009 at 12:00:06AM +0000, Joe Orton wrote:
>>> > On Thu, Nov 05, 2009 at 09:31:00PM +0000, Joe Orton wrote:
>>> >
>>> > Here is a very rough first hack (for discussion/testing purposes only!):
>> A second hack, slightly less rough hack:
>
> Joe, instead of hard coding this, a very nice solution would be to have
> a new directive "SSLServerRenegociation Allow" or even more flexible
> "SSLRenegociation disabled/serveronly/enabled" with disabled as default
> value.

Yes, sure. What is possible in mod_ssl will depend on what interfaces
OpenSSL will expose for this, which is not yet clear.

Regards, Joe


fredk2 at gmail

Jan 26, 2010, 12:05 PM

Post #27 of 29 (1400 views)
Permalink
Re: TLS renegotiation attack, mod_ssl and OpenSSL [In reply to]

Hi,


Joe Orton wrote:
>
> On Tue, Nov 10, 2009 at 03:19:39PM +0100, Jean-Marc Desperrier wrote:
>> Joe Orton wrote:
>>> On Fri, Nov 06, 2009 at 12:00:06AM +0000, Joe Orton wrote:
>>>> > On Thu, Nov 05, 2009 at 09:31:00PM +0000, Joe Orton wrote:
>>>>> > > * we can detect in mod_ssl when the client is renegotiating by
>>>>> using the
>>>>> > > callback installed using SSL_CTX_set_info_callback(), in
>>>>> conjunction
>>>>> > > with suitable flags in the SSLConnRec to detect the cases where
>>>>> this is
>>>>> > > either a server-initiated renegotiation or the initial handshake
>>>>> on the
>>>>> > > connection.
>>>> >
>>>> > Here is a very rough first hack (for discussion/testing purposes
>>>> only!):
>>> A second hack, slightly less rough hack:
>>
>> Joe, instead of hard coding this, a very nice solution would be to have
>> a new directive "SSLServerRenegociation Allow" or even more flexible
>> "SSLRenegociation disabled/serveronly/enabled" with disabled as default
>> value.
>
> Yes, sure. What is possible in mod_ssl will depend on what interfaces
> OpenSSL will expose for this, which is not yet clear.
>
> Regards, Joe
>
>

Now that 0.9.8m-beta1 is available, what is likely to happen with Apache
2.2.15?
I looked at the svn tree, but I could not see if anyone was working on
adding this excellent idea for a new directive SSLRenegociation
disabled/serveronly/enabled.
If the server does not require renegotiation it seems perfect if the apache
closed the connection upon receipt of the R instead of the current 5 min
(default) timeout wait.

Thank you - Fred
--
View this message in context: http://old.nabble.com/TLS-renegotiation-attack%2C-mod_ssl-and-OpenSSL-tp26215127p27328884.html
Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.


shenson at oss-institute

Jan 27, 2010, 2:41 PM

Post #28 of 29 (1398 views)
Permalink
Re: TLS renegotiation attack, mod_ssl and OpenSSL [In reply to]

fredk2 wrote:
> Hi,
>
>
> Joe Orton wrote:
>> On Tue, Nov 10, 2009 at 03:19:39PM +0100, Jean-Marc Desperrier wrote:
>>> Joe Orton wrote:
>>>> On Fri, Nov 06, 2009 at 12:00:06AM +0000, Joe Orton wrote:
>>>>>> On Thu, Nov 05, 2009 at 09:31:00PM +0000, Joe Orton wrote:
>>>>>>> > * we can detect in mod_ssl when the client is renegotiating by
>>>>>> using the
>>>>>>> > callback installed using SSL_CTX_set_info_callback(), in
>>>>>> conjunction
>>>>>>> > with suitable flags in the SSLConnRec to detect the cases where
>>>>>> this is
>>>>>>> > either a server-initiated renegotiation or the initial handshake
>>>>>> on the
>>>>>>> > connection.
>>>>>> Here is a very rough first hack (for discussion/testing purposes
>>>>> only!):
>>>> A second hack, slightly less rough hack:
>>> Joe, instead of hard coding this, a very nice solution would be to have
>>> a new directive "SSLServerRenegociation Allow" or even more flexible
>>> "SSLRenegociation disabled/serveronly/enabled" with disabled as default
>>> value.
>> Yes, sure. What is possible in mod_ssl will depend on what interfaces
>> OpenSSL will expose for this, which is not yet clear.
>>
>> Regards, Joe
>>
>>
>
> Now that 0.9.8m-beta1 is available, what is likely to happen with Apache
> 2.2.15?
> I looked at the svn tree, but I could not see if anyone was working on
> adding this excellent idea for a new directive SSLRenegociation
> disabled/serveronly/enabled.
> If the server does not require renegotiation it seems perfect if the apache
> closed the connection upon receipt of the R instead of the current 5 min
> (default) timeout wait.
>

FYI the initial documentation is here:

http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION

there are currently only two flags to set in an SSL/SSL_CTX structure. Though
servers might want to make use of SSL_get_secure_renegotiation_support() too.

Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org


jorton at redhat

Feb 3, 2010, 5:44 AM

Post #29 of 29 (1229 views)
Permalink
Re: TLS renegotiation attack, mod_ssl and OpenSSL [In reply to]

On Wed, Jan 27, 2010 at 10:41:02PM +0000, Dr Stephen Henson wrote:
> FYI the initial documentation is here:
>
> http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html#SECURE_RENEGOTIATION
>
> there are currently only two flags to set in an SSL/SSL_CTX structure. Though
> servers might want to make use of SSL_get_secure_renegotiation_support() too.

Thanks a lot for doing all that work!

I've added an "SSLInsecureRenegotiation" directive which will flip that
flag on, here: http://svn.apache.org/viewvc?rev=906039&view=rev

It seems to all work as expected with 1.0.0 beta 5.

Regards, Joe

First page Previous page 1 2 Next page Last page  View All Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.