[Pkg-ace-devel] SSLv2

[Thomas Girard]

Hello,

it's a bit late to look into this, sorry about that.

Le 25/04/2011 10:00, Pau Garcia i Quiles a écrit :
> I am not sure how to disable it:
> 
> a) Keep the SSLv2 entries in the enumerations but make them actually use SSLv3.
> 
> This is what I did yesterday but after doing it I am not sure it's the
> best choice.
> 
> It has the advantage if the application uses Debian on both sides,
> there is no need for changes in the application. On the other hand, it
> may lead to very weird to debug situations if you are connecting to an
> SSLv2-only service that is not using Debian on the other side ("hey,
> I'm telling it to use SSLv2 yet it fails", yeah, it's because ACE
> SSLv2 is actually ACE SSLv3).
> 
> 
> 
> 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?

Regards,

Thomas