Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101233
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.179 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <CAESVnVoWeNdh2R4KROe=CfACQVQJP9sf66iJASPp73nURi9ouw@mail.gmail.com>
References: <a64088a5-e93b-3450-fe8c-8ba6ac9d851a@php.net> <CADNQb0VA+-E2B21EZCfzau7v0_0=SeheHB+cxZCsx7RoVNn8jA@mail.gmail.com>
 <41630a4e-8772-bdfb-e859-831a36dc67ea@rhsoft.net> <CANUQDCjsz31t-VqbLeUOc-qJd=wzQ8Tbk2UGhY-74xw+JaGHUA@mail.gmail.com>
 <e8b900c3-3d76-9fe0-7b96-3c1f468d160e@rhsoft.net> <CAESVnVqhNgge2dzHTbf1bCR0unGCYwEeDqS2ErWdyK34M26k6g@mail.gmail.com>
 <9f3d28e1-cc6d-d5dc-da04-7e3791070be8@rhsoft.net> <CAESVnVoWeNdh2R4KROe=CfACQVQJP9sf66iJASPp73nURi9ouw@mail.gmail.com>
Date: Mon, 4 Dec 2017 21:36:04 +0000
Message-ID: <CAEKnhAF0wgG6vGDux4zrEzFg1HtO_RLuFM2oRino_8Z75OGMWA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: "lists@rhsoft.net" <lists@rhsoft.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11491540652964055f8a810c"
Subject: Re: [PHP-DEV] PHP 7.2.0 Released
From: bukka@php.net (Jakub Zelenka)

--001a11491540652964055f8a810c
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 4, 2017 at 5:36 PM, Sara Golemon <pollita@php.net> wrote:

> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:
> > the main question is why does PHP need to to *anything* here instead hand
> > the TLS handshake completly over to openssl? in that case even PHP5 could
> > perfer TLS1.2 ciphers against a sevrer that orders them on top without
> touch
> > any line of PHP's code
> >
> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
> "Just give me the best method you can".
>
> SSL_CTX *SSL_CTX_new(const SSL_METHOD *method);
>  const SSL_METHOD *SSLv23_method(void);
>  const SSL_METHOD *SSLv23_server_method(void);
>  const SSL_METHOD *SSLv23_client_method(void);
>  const SSL_METHOD *TLSv1_2_method(void);
>  const SSL_METHOD *TLSv1_2_server_method(void);
>  const SSL_METHOD *TLSv1_2_client_method(void);
>  const SSL_METHOD *TLSv1_1_method(void);
>  const SSL_METHOD *TLSv1_1_server_method(void);
>  const SSL_METHOD *TLSv1_1_client_method(void);
>  const SSL_METHOD *TLSv1_method(void);
>  const SSL_METHOD *TLSv1_server_method(void);
>  const SSL_METHOD *TLSv1_client_method(void);
>  #ifndef OPENSSL_NO_SSL3_METHOD
>  const SSL_METHOD *SSLv3_method(void);
>  const SSL_METHOD *SSLv3_server_method(void);
>  const SSL_METHOD *SSLv3_client_method(void);
>  #endif
>  #ifndef OPENSSL_NO_SSL2
>  const SSL_METHOD *SSLv2_method(void);
>  const SSL_METHOD *SSLv2_server_method(void);
>  const SSL_METHOD *SSLv2_client_method(void);
>  #endif
>
> There may be another SSL API that does, but that's more than just "set
> the value to any and be done with it".
>

Yep there is SSL_CTX_set_min_proto_version
and SSL_CTX_set_max_proto_version in OpenSSL 1.1.0+ which is the preferred
way how to set the protocol. The version specific method are all now
deprecated and should not be used. I have got it on my TODO list so
hopefully will find time to implement it. It would be ideal to just
introduce min and max protocol version context options for tls and possibly
ssl (which is tls alias now) streams. It is of course backportable to 1.0.1
and 1.0.2 using SSL_OP_NO_* which is how it is basically working now but
for 1.1.0+ it will use more flexible min and max. I think it would also
make sense to deprecate tlsv* and sslv* streams but don't feel so strongly
about it.

The c part implementation is not too difficult but we should probably
improve and extend the version tests (that are really slow atm.) so it
might take a bit. Anyway I really hope to have it in 7.3.

Cheers

Jakub

--001a11491540652964055f8a810c--