[Pkg-ace-devel] SSLv2

Thomas Girard thomas.g.girard at free.fr
Sat May 7 07:33:50 UTC 2011


Hello,

Le 01/05/2011 21:18, Thomas Girard a écrit :
>>> b) Completely remove SSLv2
>>>
>>> Meaning: including removal from the enumerations, but keeping the
>>> blanks for the former SSLv2 values (to avoid renumerating the
>>> enumerations).
>>>
>>> Advantage: it makes explicit SSLv2 is no longer supported.
>>>
>>> Disadvantage: I need to check what happens with SSLv23 calls, I can't
>>> remember if the code is easy transformable to SSLv3 calls
>>>
>>> I think this is the best choice.
>>
>> My understanding of this is that when using set_mode({1,2,3}) for SSLv2
>> or set_mode({7,8,9}) for SSLv23 then the mode will be silently changed
>> to SSLv3 method. Am I correct?
>>
>> The enum members were removed, but there are cases were it could harm:
>>
>>  - if there is a client-server mode negotiation, and the other side
>>    sends this now removed value (e.g. another ORB, or an unpatched TAO
>>    on Windows).
>>
>>    => is there a client-server mode negotiation?
>>
>>  - if a program was compiled with the previous header version, then it
>>    would have captured the enum value, hence switching to v3
>>    automatically.
>>
>> I'm also quite surprised by the default: clause in the original code.
>> Not defensive: if you pass any garbage input, you get SSLv3.
>>
>> After thinking about this, I'm not sure solution b) is the right
>> approach.
>>
>>> c) Just disable SSLv2
>>>
>>> Meaning: keep the enumerations, keep the methods, but instead of
>>> making the calls to OpenSSL, fail. IMHO we should completely discard
>>> this.
>>
>> Why should it be a bad idea?
> 
> The package builds fine.
> 
> I'll wait for further discussion on this issue before proceeding to an
> upload.

@Pau: what was the rationale for avoiding solution c)?
@Johnny: any opinion on this?

If we don't reach consensus I guess I'll post this question to
devo-group@

Thanks,
Regards,

Thomas



More information about the Pkg-ace-devel mailing list