Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Patch v2] Added tls 1.3 support for PHP #3700

Closed
wants to merge 1 commit into from

Conversation

codarrenvelvindron
Copy link

@codarrenvelvindron codarrenvelvindron commented Dec 5, 2018

Compiled/Tested php with openssl 1.1.1/1.1.0 official
This is a clean version of original(in sync with current) with all changes made according to review by @bukka :
Original: #3650

  • Added tls 1.3 support for php
  • Added/Updated test files

Ran make tests - OK
Work done during IETF 103 hackathon

~ codarren at cyberstorm.mu ~

@bukka
Copy link
Member

bukka commented Dec 9, 2018

Look good, just one small NIT. Will try to test it during the week.

P.S. you don't need to create a new PR next time - just squashing (or commit amend for the NIT fix) and then push force should be ok ;)

@codarrenvelvindron
Copy link
Author

@bukka : Done. Thanks for the tip ! :)

@@ -171,6 +171,7 @@ typedef enum {
STREAM_CRYPTO_METHOD_TLSv1_0_CLIENT = (1 << 3 | 1),
STREAM_CRYPTO_METHOD_TLSv1_1_CLIENT = (1 << 4 | 1),
STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT = (1 << 5 | 1),
STREAM_CRYPTO_METHOD_TLSv1_3_CLIENT = (1 << 6 | 1),
/* TLS equates to TLS_ANY as of PHP 7.2 */
STREAM_CRYPTO_METHOD_TLS_CLIENT = ((1 << 3) | (1 << 4) | (1 << 5) | 1),
STREAM_CRYPTO_METHOD_TLS_ANY_CLIENT = ((1 << 3) | (1 << 4) | (1 << 5) | 1),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These generic constants for any version need to include TLS v1.3, too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have requested not to touch those as I don't want to negotiate 1.3 by default. It could break the existing clients so I would like to not do it at least for PHP 7.4. I think we could change that in PHP 8 though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not? Significant work has been put into TLS 1.3 to avoid breaking with broken TLS 1.2 implementations.

If you want to avoid TLS 1.3 by default, please update the default wrapper, but these constants specifically are for ANY TLS version, so the patch should reflect that.

@kelunik
Copy link
Member

kelunik commented Dec 31, 2018

Seems like there's a bug in stream_get_contents with TLS 1.3, IMO we should fix that before merging this PR: reactphp/socket#184

clue added a commit to clue-labs/socket that referenced this pull request Jan 2, 2019
This only simplifies some of unneeded assignments for legacy PHP
versions and should not affect usage otherwise. TLS 1.3 is implicitly
available despite being omitted in this assignment. The required crypto
flag is likely going to be added in PHP 7.2.x in the future via
php/php-src#3700 and should thus be covered by
the main crypto method constant in the future already.

Due to the way how PHP interfaces with OpenSSL, this means that TLS 1.3
is in fact already enabled by default when using a recent OpenSSL
version for all client and server connections even for older PHP
versions.
clue added a commit to clue-labs/socket that referenced this pull request Jan 2, 2019
This only simplifies some of unneeded assignments for legacy PHP
versions and should not affect usage otherwise. TLS 1.3 is implicitly
available despite being omitted in this assignment. The required crypto
flag is likely going to be added in PHP 7.2.x in the future via
php/php-src#3700 and should thus be covered by
the main crypto method constant in the future already.

Due to the way how PHP interfaces with OpenSSL, this means that TLS 1.3
is in fact already enabled by default when using a recent OpenSSL
version for all client and server connections even for older PHP
versions.
@SPhu
Copy link

SPhu commented Feb 19, 2019

This is a much desired feature to improve ssl performance. Just curious what the hold up is?

@bukka
Copy link
Member

bukka commented Feb 24, 2019

I plan to do some testing in the next weeks and then would like to merge it to 7.3 if @cmb69 is fine with that? It's a self-contained feature and it also allows to use TLS 1.3 in PHP 7.3. The thing is that 7.2 will negotiate TLS 1.3 with OpenSSL 1.1.1 (it's not on purpose but it's how it works in 7.2 and lower versions). So it would be useful to have an options to explicitly allow it in 7.3 as it's the first version with pre-set max version which is a bit safer (at least for non-blocking use) when migrating from OpenSSL before 1.1.1.

@cmb69
Copy link
Member

cmb69 commented Feb 24, 2019

if @cmb69 is fine with that?

Yes. :)

@clue
Copy link

clue commented Feb 24, 2019

Happy to see some action in this long awaited feature again! 👍

I'm trying to understand the rationale for why STREAM_CRYPTO_METHOD_TLS_ANY_CLIENT (+_SERVER) should not contain support for TLS 1.3, so it would be very much appreciate if anybody would care to shed some light on this? Significant work has been put into making sure TLS 1.3 is compatible with existing implementations in the wild, even including broken TLS 1.2 implementations. As such, it's my understanding that the default constant (which happens to be used for the tls:// stream wrapper) should target all TLS versions supported by the underlying OpenSSL version. If it were included, stream wrappers would automatically choose the best TLS version that is supported by the local OpenSSL library version and the remote peer.

The thing is that 7.2 will negotiate TLS 1.3 with OpenSSL 1.1.1 (it's not on purpose but it's how it works in 7.2 and lower versions). So it would be useful to have an options to explicitly allow it in 7.3 as it's the first version with pre-set max version which is a bit safer (at least for non-blocking use) when migrating from OpenSSL before 1.1.1.

I agree that this would lead us to this awkward situation where PHP 7.2 supports TLS 1.3 and PHP 7.3 doesn't by default. See also the above discussion, what exactly is gained by not including TLS 1.3 in the default methods? On top of this, are there any plans to change this default constant in the future to also include TLS 1.3 by default in PHP 7.x again and perhaps if so, what needs to change for this to happen?

@kelunik
Copy link
Member

kelunik commented Feb 24, 2019

Even if we don't make it the default, it should be in the constant as previously mentioned.

@kelunik
Copy link
Member

kelunik commented Feb 28, 2019

@bukka Not updating the constants works actively against the voting in https://wiki.php.net/rfc/improved-tls-constants.

STREAM_CRYPTO_METHOD_TLS_* will be changed in the future when newer versions of TLS are available without going through the RFC process.

@codarrenvelvindron Could you please change your PR and update the constants?

@bukka bukka mentioned this pull request Mar 3, 2019
@bukka
Copy link
Member

bukka commented Mar 3, 2019

Updated version in #3909 .

@clue @kelunik I will update the methods to add it to the generic ones as it really makes sense considering the current status in 7.2. I need to extend tests to cover it and want to speed up wrapper tests as well.

@bukka bukka closed this Mar 3, 2019
php-pulls pushed a commit to php/pecl-database-mysql_xdevapi that referenced this pull request Oct 14, 2019
- add support for following secure options: tls-versions, tls-ciphersuites, ssl-ciphers
- improve parsing Uri (e.g. previously in some cases ssl-mode has to always be in front of other secure options)
- improve error messages
- support trying open secure connections in loop for various TLS versions
- still waiting for patches related to TLSv1.3 support in PHP:
php/php-src#3650
php/php-src#3700
php/php-src#3909
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants