Hello internals!
I've added a major new section to the Improved TLS Defaults RFC which can
be found here:
https://wiki.php.net/rfc/improved-tls-defaults#stream_wrapper_creep
I was initially hesitant to include these changes in the RFC because they
have no BC implications. However, upon further contemplation I think the
proposed deprecations in the new "Stream Wrapper Creep" section are
important to incorporate as part of the larger theme of improving the
default level of TLS security in 5.6. In my opinion it's only sensible to
apply as many TLS improvements as possible in one release instead of
stringing them out across multiples.
I don't yet have a patch publicly available however I've implemented all of
the proposed changes locally without failures in the existing test suite.
The relevant patch will be made available once I'm able to add new tests
for the proposed functionality.
As usual, any and all comments are welcome and appreciated.
Cheers!
Daniel
Hi Daniel,
As usual, any and all comments are welcome and appreciated.
IIRC, any RFC that is included in 5.6 should be approved by Feb, 22.
I would like to see this change in 5.6, so don't be late.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Daniel,
As usual, any and all comments are welcome and appreciated.
IIRC, any RFC that is included in 5.6 should be approved by Feb, 22.
I would like to see this change in 5.6, so don't be late.
Totally agree. My plan is to start the vote on Feb 11 (two weeks after the
initial RFC announcement) with a ten-day voting period to slide in before
the deadline should the RFC be accepted. I should have a patch available
online with accompanying tests this week.
If anyone has any issues or questions please ask so I can address them and
initiate the vote in time for potential 5.6 inclusion.
Hi Daniel,
As usual, any and all comments are welcome and appreciated.
IIRC, any RFC that is included in 5.6 should be approved by Feb, 22.
I would like to see this change in 5.6, so don't be late.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Daniel,
Hello internals!
I've added a major new section to the Improved TLS Defaults RFC which can
be found here:https://wiki.php.net/rfc/improved-tls-defaults#stream_wrapper_creep
I was initially hesitant to include these changes in the RFC because they
have no BC implications. However, upon further contemplation I think the
proposed deprecations in the new "Stream Wrapper Creep" section are
important to incorporate as part of the larger theme of improving the
default level of TLS security in 5.6. In my opinion it's only sensible to
apply as many TLS improvements as possible in one release instead of
stringing them out across multiples.
Here's a good recent study on SSL/TLS use in the Alexa Top 1,000,000 sites:
https://jve.linuxwall.info/blog/index.php?post/TLS_Survey
What I took away from it was that SSLv2 was exclusively used by only 38
sites (so time for that to go in line with everyone else out there!). SSLv3
has an exclusive use rate of just under 1%. These are likely holdouts that
will fade in time, but a 1% rate isn't quite to the point of extinction. I
think we should hold off on throwing errors until v3 drops to a more
negligible level. The current supported range on Firefox, for example, has
a minimum of SSLv3. Yes, this is hardly paradise, but so long as we're
negotiated from TLS 1.2 down (presumably the case at present!) then we
should let users accept the risk for SSLv3 only sites without kicking up
too much of a fuss for now.
SSLv2 - nuke it :P
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
I think we should hold off on throwing errors until v3 drops to a
more negligible level. The current supported range on Firefox,
for example, has a minimum of SSLv3. Yes, this is hardly
paradise, but so long as we're negotiated from TLS 1.2 down
(presumably the case at present!) then we should let users
accept the risk for SSLv3 only sites without kicking up too much
of a fuss for now.
After thinking about it a bit I think I agree on this front and will strike
the recommendations for E_WARNING from the RFC. However, I so still think
it makes sense to issue an E_DEPRECATED on the use of the sslv2:// and
sslv3:// stream wrappers in an effort to funnel users into the more
generalized ssl:// and tls:// wrappers. As I mentioned in the updated RFC
text I think it makes sense to deprecate the specific wrappers in 5.6 and
look to remove them in 5.7 as they're really unnecessary in light of the
ability to specify flags for the specific individual protocols you wish to
use on a given stream.
As I mentioned in the updated RFC
text I think it makes sense to deprecate the specific wrappers in 5.6 and
look to remove them in 5.7 as they're really unnecessary in light of the
ability to specify flags for the specific individual protocols you wish to
use on a given stream.
Please don't. By deprecating in 5.6 and removing in 5.7 (which would be faster than anything before) you'd royally screw everyone skipping a version - something that gets increasingly likely with the faster release cycle.
I'd suggest deprecating them now with this RFC and remove it in PHP 6, if PHP6 doesn't come around they could still be removed in a future RFC.
Best regards
Rouven
On Thu, Jan 30, 2014 at 12:11 PM, Rouven Weßling me@rouvenwessling.dewrote:
As I mentioned in the updated RFC
text I think it makes sense to deprecate the specific wrappers in 5.6 and
look to remove them in 5.7 as they're really unnecessary in light of the
ability to specify flags for the specific individual protocols you wish to
use on a given stream.Please don't. By deprecating in 5.6 and removing in 5.7 (which would be
faster than anything before) you'd royally screw everyone skipping a
version - something that gets increasingly likely with the faster release
cycle.I'd suggest deprecating them now with this RFC and remove it in PHP 6, if
PHP6 doesn't come around they could still be removed in a future RFC.Best regards
Rouven
Sounds good to me. Will update the RFC for deprecation of the sslv2:// and
sslv3:// stream wrappers in 5.6 with removal planned for PHP 6.
Hi Daniel,
On Thu, Jan 30, 2014 at 12:11 PM, Rouven Weßling <me@rouvenwessling.de
wrote:
As I mentioned in the updated RFC
text I think it makes sense to deprecate the specific wrappers in 5.6 and
look to remove them in 5.7 as they're really unnecessary in light of the
ability to specify flags for the specific individual protocols you wish
to
use on a given stream.Please don't. By deprecating in 5.6 and removing in 5.7 (which would be
faster than anything before) you'd royally screw everyone skipping a
version - something that gets increasingly likely with the faster release
cycle.I'd suggest deprecating them now with this RFC and remove it in PHP 6, if
PHP6 doesn't come around they could still be removed in a future RFC.Best regards
RouvenSounds good to me. Will update the RFC for deprecation of the sslv2:// and
sslv3:// stream wrappers in 5.6 with removal planned for PHP 6.
I agree that obsolete protocol should be deprecated.
However, removal is totally different. I would like to have long period
before
removing any feature from PHP whenever it is possible. It could be used as
toy
for security experiments as well as for incredibly old internal servers
never updated.
Perhaps, remove them for PHP 7 or even 8?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Daniel,
On Thu, Jan 30, 2014 at 12:11 PM, Rouven Weßling <me@rouvenwessling.de
wrote:
As I mentioned in the updated RFC
text I think it makes sense to deprecate the specific wrappers in 5.6
and
look to remove them in 5.7 as they're really unnecessary in light of the
ability to specify flags for the specific individual protocols you wish
to
use on a given stream.Please don't. By deprecating in 5.6 and removing in 5.7 (which would be
faster than anything before) you'd royally screw everyone skipping a
version - something that gets increasingly likely with the faster
release
cycle.I'd suggest deprecating them now with this RFC and remove it in PHP 6,
if
PHP6 doesn't come around they could still be removed in a future RFC.Best regards
RouvenSounds good to me. Will update the RFC for deprecation of the sslv2:// and
sslv3:// stream wrappers in 5.6 with removal planned for PHP 6.I agree that obsolete protocol should be deprecated.
However, removal is totally different. I would like to have long period
before
removing any feature from PHP whenever it is possible. It could be used as
toy
for security experiments as well as for incredibly old internal servers
never updated.
Perhaps, remove them for PHP 7 or even 8?Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I'm perfectly fine with a long period for removal. However I don't see any
reason to persist deprecated features into a PHP 6 version because all the
existing functionality is retained. I'm only deprecating the potentially
confusing protocol-specific stream wrappers -- not the ability to use the
old protocols. Even when the deprecated wrappers are removed the old
protocols will still be available.
I understand that it's a bit difficult to see the difference in the current
RFC version because I haven't added code examples yet. However, I finished
the implementation patch with tests today and will update the RFC either
this evening or tomorrow with a fully mature proposal. I've taken into
account everything that has been discussed to this point and am pleased
with the resulting solution (I think everyone else will be as well). I'll
mail the list when the "final" (subject to input) RFC is live on the wiki
and we can revisit the conversation if necessary.
As always, the input is greatly appreciated!
I finished the implementation patch with tests today and will
update the RFC either this evening or tomorrow with a fully mature
proposal
Greetings, internals.
As promised, the mature proposal for Improved TLS Defaults is now live:
https://wiki.php.net/rfc/improved-tls-defaults
If you're short on time I've added a TL;DR section:
https://wiki.php.net/rfc/improved-tls-defaults#tldr_definitive_progress
There are a number of improvements and changes from the previous iterations
as well as code examples. So, even if you've read earlier versions of the
RFC I would encourage you to take a few minutes to read this (final?)
version.
The full patch with tests is now available and can be dropped directly into
the current 5.6 branch:
https://wiki.php.net/rfc/improved-tls-defaults#patches_and_tests
Thanks for your time and feedback. A vote is planned for Feb. 11, so please
pose any questions or suggestions you may have in the coming days to avoid
any hiccups during the actual voting process.
Hi Daniel,
Looking at the openssl output, this eliminates all weak ciphersuites. I'm
testing using the Qualys service at:
https://www.ssllabs.com/ssltest/viewMyClient.html
I have two things to be considered on top of this:
- If you check the ciphersuite order of the proposed ciphers vs cURL
(current HEAD) vs Mozilla (https://wiki.mozilla.org/Security/Server_Side_TLS),
the ciphers which support perfect forward secrecy are dispersed throughout
the list for the RFC and cURL so numerous non-PRS ciphers will gain
preference over PFS ciphers. PFS has become a big deal recently with people
worried about companies having their private keys stolen or handed over on
foot of a warrant by a three letter agency. I think we should take this
opportunity to follow the trend and that's basically why Mozilla have such
a long explicit ordering in their suite. - There has been some questions raised about the efficacy of stronger 256
ciphers vs 128 ciphers. The Mozilla list therefore reorders the ciphers to
prefer the faster 128 ciphers while still maintaining the preference for
PFS first. The base reference for this is:
https://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html. This
describes an attack valid for AES256 but NOT for AES128. To be fair, the
attack should be beyond anyone's computational resources at this time but
as the old pessimist's view goes, if it breaks once, it'll probably break
again, and again, ad infinitum. So if we were to be extremely cautious,
preferring AES128 would be the ticket.
Looking around, it's clear that choosing a cipher suite is not an easy
task. Mozilla, IE and Chromium all differ. cURL and openssl also differ
from the browsers. cURL recently amended its list away from the openssl
DEFAULT on foot of a security report but I don't think they put sufficient
thought into it and basically relied on openssl's judgement for the most
part. In the absence of openssl amending DEFAULT (which may well happen at
some point - it was reported to them afterall), I think Mozilla has the
better approach.
The other outcome of the Mozilla ciphersuite is that it removes all ciphers
below 128 (there's about 15 or so below that waterline). These are not
reported as weak on the Qualys site or howsmyssl.com, however, so not sure
if it's necessary in our case at this time.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://phpsecurity.readthedocs.org
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
it's clear that choosing a cipher suite is not an easy task.
I agree that choosing exactly the right cipher order is a difficult (and
not entirely objective) decision. Much like maintaining our own CA certs, I
think it's probably best to delegate such decisions to people who sit
around and think about them all day. I would prefer to re-use the current
Mozilla recommendation with the addition that RC4 suites are disabled and
will make this change to the RFC.
it removes all ciphers below 128
This is a pretty standard demarcation line these days. I don't personally
have an issue with using 128-bit cipher key-lengths as the cut-off line.
Also, remember that users always have the option to specify their own
explicit cipher list should the need arise. I think that if 128-bit cipher
use is ubiquitous enough for mainstream browsers (where users would be
upset if they couldn't connect to their favorite sites) then it should be
fine as a (configurable) default PHP setting.
Cheers,
Daniel