On Fri, Feb 26, 2010, Victor Duchovni wrote:
On Fri, Feb 26, 2010 at 02:45:19AM +0100, Dr. Stephen Henson wrote:
On Thu, Feb 25, 2010, Victor Duchovni wrote:
If I field a patched server, and sufficiently many unpatched pre-0.9.8m
OpenSSL clients attempt re-negotiation under
The documentation about renegotiation between an unpatched client and
a patched server reads:
Unpatched client and patched OpenSSL server
---
The initial connection suceeds but client renegotiation is denied
by the server with a
On Thu, Feb 25, 2010, Victor Duchovni wrote:
If I am reading this correctly, unpatched OpenSSL clients will definitely
hang if the client initiates renegotiation to a patched server? If so,
why not send a fatal alert (especially if non-buggy clients treat it
as fatal)? What is the point of
On Thu, Feb 25, 2010, Dr. Stephen Henson wrote:
On Thu, Feb 25, 2010, Victor Duchovni wrote:
OpenSSL clients treat the warning as fatal because there is no API provision
to renegotiate and then continue if it is refused. So to be cautious we assume
that if an application wants a
On Thu, Feb 25, 2010 at 11:45:14PM +0100, Dr. Stephen Henson wrote:
This isn't a DoS issue as such it's just the client sending a message and
never getting the reply it expects. You'd get exactly the same behaviour by
connecting to a server and either never sending any data or deliberately not
On Thu, Feb 25, 2010, Victor Duchovni wrote:
If I field a patched server, and sufficiently many unpatched pre-0.9.8m
OpenSSL clients attempt re-negotiation under normal conditions, I have
a resource starvation problem and unhappy users who are more annoyed at
stuck connections than failed
On Fri, Feb 26, 2010 at 02:45:19AM +0100, Dr. Stephen Henson wrote:
On Thu, Feb 25, 2010, Victor Duchovni wrote:
If I field a patched server, and sufficiently many unpatched pre-0.9.8m
OpenSSL clients attempt re-negotiation under normal conditions, I have
a resource starvation problem
