On Po, 2014-11-10 at 13:38 +0100, Kurt Roeckx wrote:
> There seems to be great confusion on which method to use set up a
> TLS/SSL connection and I guess most of that has to do with
> history. I would like to simplify things.
>
> We currently seem to have methods for SSLv2, SSLv3, TLSv1
> documented, and TLSv1_1 and TLSv1_2 undocumented, and then a
> SSLv23 method. At least some people seem to think that the SSLv23
> method will only do SSLv2 and SSLv3. There probably are also people
> who think that the TLSv1 method will TLS 1.1 and newer.
>
> Then there are options like SSL_OP_NO_SSLv2 that can control what
> protocols are actually supported.
>
> I would like to replace all those with 1 (or 3) methods that don't
> have a version in it's name, like TLS_method() or SSL_method(),
> and maybe make the SSLv23 methods a define to the new methods.
>
> I would also like to get rid of SSL_OP_NO_SSLv2 and instead have a
> way to specify the minimum and maximum supported version by those
> methods, because that's really what people want to do as far as I
> know.
>
> Does this look like a good idea?
I'd recommend doing all this but with such correction that the new
result will not break API/ABI backwards compatibility to OpenSSL 1.0.x
so it can be applied in some future 1.0.x branch.
Basically things should not be removed but only added and the new name
(TLS_method()) should be #define of SSLv23_method() and not the other
way around. Then in 1.x branch the legacy things might be removed if
appropriate.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
(You'll never know whether the road is wrong though.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
