TLS/SSL methods and protocol version selection

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS/SSL methods and protocol version selection

Kurt Roeckx
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?


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: TLS/SSL methods and protocol version selection

Tomas Mraz-2
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                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: TLS/SSL methods and protocol version selection

Matt Caswell-2
In reply to this post by Kurt Roeckx


On 10/11/14 12:38, Kurt Roeckx wrote:
> 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.

The default should assume the maximum supported (probably with an option
to override that if you really do wish to specify a maximum).

That way as the OpenSSL gets updated over time (e.g. to support TLS1.3)
then code will not have to be updated...just update to the latest
library version.

Matt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: TLS/SSL methods and protocol version selection

Kurt Roeckx
In reply to this post by Tomas Mraz-2
On Mon, Nov 10, 2014 at 02:02:35PM +0100, Tomas Mraz wrote:
>
> 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.

I don't think we'll have an other 1.0.x other than 1.0.2, so this
would be an 1.1 thing.  There would be no need to keep the
SSLv23_method() as symbol in the library.


Kurt

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: TLS/SSL methods and protocol version selection

Salz, Rich
In reply to this post by Kurt Roeckx
> Does this look like a good idea?

Yes, very.  I think the min/max versions should be two explicit parameters, where '0' means the highest(lowest) supported by the library.

--  
Principal Security Engineer, Akamai Technologies
IM: [hidden email] Twitter: RichSalz


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]