Re: SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, harmless??

[Jacques A. Vidrine]

On Fri, Sep 17, 2004 at 12:39:23AM +0200, Frédéric Giudicelli wrote:
 Jacques A. Vidrine wrote:
 Thanks!  What did you use for this test?  If you are using OpenSSL,
 did the client do SSL_get_session and SSL_set_session?  I'm assuming
 that the handshake completed because your second connection used the
 previously generated master_secret.
 
 You're right, when I unset the master key, the connection fails !

Oh good, then the behavior is as expected.

 But there is still a question I wonder about, how come when 
 SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG is set, the list of acceptable 
 ciphers is ignored ?
 If I did set ALL:!NULL, do I really want the user to be allowed to 
 specify RSA-NULL as the new cipher ?

Actually, I am not familiar with the history, but I assume that it is
required to work around quirks in some version of Netscape.  Maybe
someone else will be able to tell us more.

Cheers,
-- 
Jacques A Vidrine / NTT/Verio
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #926]

[Geoff Thorpe via RT]

Sorry for the delay, this ticket slipped through the net, and Nils
Larsch recently brought it to my attention.

Vadim Fedukovich wrote:
[snip]
 I'm particular interested exactly why it is believed that
 gcd(p-1,e)==1 and gcd(q-1,e)==1 (according to comments
 in the source).
[snip]

The gcd() check is redundant because p and q are already generated such
that gcd([p|q]-1,e) is 1. As 'e' is prime, this amounts to stating
([p|q]-1) not divisible by 'e'. As neither is divisible by e, neither
will (p-1)(q-1) be.

Thanks for keeping an eye open, I'm cleaning out the commented code and
the misleading commentry.

-- 
Geoff Thorpe, RT/openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]