I'd like to gauge support for another update in the spirit of the openssl
changes scheduled for 5.6. Currently the http fopen wrapper defaults to the
ssl:// scheme when retrieving an https:// resource as seen here:
http://lxr.php.net/xref/PHP_5_6/ext/standard/http_fopen_wrapper.c#196
What this means to the underlying openssl lib is that the SSLv23 crypto
method is used for handshake negotiation. The SSLv23 handshake method
provides compatibility for SSL2, SSL3 and TLS1.0 protocols.
Citing the "SSL/TLS Deployment Best Practices" report linked at the end of
this message:
- SSL v2 is insecure and must not be used.
- SSL v3 is very old and obsolete. Because it lacks some key features and
because virtually all clients support TLS 1.0 and better, you should not
support SSL v3 unless you have a very good reason. - TLS v1.0 is largely still secure; we do not know of major security flaws
when they are used for protocols other than HTTP. When used with HTTP, it
can almost be made secure with careful configuration. - TLS v1.1 and v1.2 are without known security issues.
While this allows more transfers to succeed in the wild it's also insecure.
I personally don't believe it's a good idea to enable the use of SSL2 and
SSL3 by default. Instead, I think the http fopen wrapper should use the
tls:// scheme and send the TLS1.0 handshake by default. Will this cause
some transfers that worked previously to fail? Yes. However, potential
breakage when requesting resources from servers still using the (very)
outdated protocols can be eliminated because as of 5.6 encrypted stream
transports can be configured to use a specific crypto method (see link in
references section) via the stream context at call time, e.g.:
// Override the default with a specific protocol for this call
$context = stream_context_create(['ssl' => [
"crypto_method" => STREAM_CRYPTO_METHOD_SSLv3_CLIENT
]]);
file_get_contents('https://somesite', FALSE, $context);
To me, this change is a necessary one. Most users should not notice the
change as TLSv1.0 is well established and supported by virtually all
servers. Default to the more secure protocols here would dovetail nicely
alongside the other security enhancements in 5.6.
Thoughts?
-- References --
SSL/TLS Deployment Best Practices:
https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf
Encrypted stream transports can now be configured in the stream context:
https://github.com/php/php-src/commit/ce2789558a970057539094ca9019d98ff09e831e
- SSL v2 is insecure and must not be used.
On the bright side, pretty much every browser no longer enables SSLv2
support, so that one's definitely safe to remove.
To me, this change is a necessary one. Most users should not notice the
change as TLSv1.0 is well established and supported by virtually all
servers. Default to the more secure protocols here would dovetail nicely
alongside the other security enhancements in 5.6.
I agree with all of the above, but wanted to track down some rough
numbers to figure out if we'd be causing significant pain by no longer
supporting SSLv3 by default in https:// URLs. I found a couple of
surveys:
-
http://blog.ivanristic.com/2011/09/ssl-survey-protocol-support.html
— from September 2011, surveying 298604 sites from Alexa's top
million. 5315 (1.8%) of those servers two years ago had no support for
TLS. That alone might have been enough to sway me, but then I found: -
https://www.trustworthyinternet.org/ssl-pulse/ — from 2½ weeks ago,
indicating that 0.7% of the ~200k surveyed sites have no support for
TLS.
Every remotely supported Linux distro ships a version of OpenSSL that
supports at least TLS 1.0 (yes, even RHEL 4), so I don't see that as
an impediment.
Thoughts?
I think we should do it. It will need to be documented clearly, and
hopefully we can put a good error message on top of this for users who
do run into problems with SSLv3-only servers, but I think the increase
in security is worthwhile, just as I did for the peer verification
work.
Great work, Daniel!
Thanks,
Adam
To me, this change is a necessary one. Most users should not notice the
change as TLSv1.0 is well established and supported by virtually all
servers. Default to the more secure protocols here would dovetail nicely
alongside the other security enhancements in 5.6.I think we should do it. It will need to be documented clearly, and
hopefully we can put a good error message on top of this for users who
do run into problems with SSLv3-only servers, but I think the increase
I agree with that. Part of the reasoning for my change to
stream_context_set_option() that Daniel mentions was to make it
possible to swap the default transport in the future while giving
people a way to go back to the old SSLv23 behaviour if they really
need it.
- Martin
To me, this change is a necessary one. Most users should not notice the
change as TLSv1.0 is well established and supported by virtually all
servers. Default to the more secure protocols here would dovetail
nicely
alongside the other security enhancements in 5.6.I think we should do it. It will need to be documented clearly, and
hopefully we can put a good error message on top of this for users who
do run into problems with SSLv3-only servers, but I think the increaseI agree with that. Part of the reasoning for my change to
stream_context_set_option()that Daniel mentions was to make it
possible to swap the default transport in the future while giving
people a way to go back to the old SSLv23 behaviour if they really
need it.
- Martin
Yes, the in-context crypto method assignment is an extremely helpful
addition. I failed to fully appreciate its importance at first but for what
we're doing now (gently nudging people into the more secure protocols) it
makes it possible to significantly improve security without breaking
everything for the few stragglers still stuck with SSLv3. Kudos!