drupal_http_request fails when remote server is using openssl v1.0.0

Hello Community.
I've had the same problem with ssl requests.
I've applied this patch to my D7.x core and tested. Works good.
I beleave, we should have this patch #1 in core.

Regards, Vitaliy

#1: http_request_openssl-1879970-1.patch queued for re-testing.

Automated QA tests also have been completed without any errors.

This needs to be fixed on 8 first.

Given #1862398: [meta] Replace drupal_http_request() with Guzzle I don't think it makes sense to fix this in 8.x. I believe Guzzle (via curl) supports this already.

The code from #1 still applies and still works great.

I've just tested the approach with a D7 installation to fix this related issue: #1959840: Unable to connect to the OHT service (OpenSSL 0.9.8 vs. OpenSSL 1.0.0)
Works like a charm! Thanks.

Updated title to make it easier to find.

Yeah, it looks like Drupal 8 can probably do this already (not sure if anyone has verified though).

The basic approach seems OK, but it's a very non-standard way to add an option to this function - the documentation in this patch implies that you can never use 'ssl' (which is in fact the default and the most common case), and similarly the $options array is going to be lying most of the time about which one is being used? I also don't understand why the variable is called 'ssl_version' (and is documented as storing an SSL version) when in fact that's not what it stores at all.

The attached Drupal 7 patch tries to clean this up a bit.

I'm not 100% sure curl (what guzzle uses) will support that if php is less than 5.5
https://bugs.php.net/bug.php?id=62318
https://github.com/php/php-src/blob/74394733ed36f642fa52e10b73284e3ad2d3...

The commit that added this in on 2011-12-01
https://github.com/php/php-src/commit/e69f987948982d4259a574ca824398c261...

EDIT:
looks like this might do it
curl_setopt($curl, CURLOPT_SSLVERSION, 3);
http://guzzlephp.org/tour/http.html#low-level-curl-access

I've committed #13 to htttprl #1977160: Integrate this patch: allow calling code to specify sslv2 sslv3 tls

I looked into this issue.

The problem seems to be that newer versions of OpenSSL send a warning-level alert in some cases (most notably: SNI name unrecognized), which older versions of OpenSSL trips on. There is a now a suggested patch.

The PHP documentation (and the naming of the transports) is misleading. Here is the exact definition of the transports:

• ssl: negotiates TLSv1, SSLv3 or SSLv2 in this order (uses SSLv23_method internally);
• tls: negotiates only TLSv1 (uses TLSv1_method internally)
• sslv2: negotiates only SSLv2 (uses SSLv2_method internally)
• sslv3: negotiates only SSLv3 (uses SSLv3_method internally)

Specifying an explicit SSLv2 or SSLv3 version solves the problem in this case, but just because it avoids TLS (and as a consequence SNI) altogether.

The problem probably comes from the fact that PHP sends a SNI host name unconditionally (the "SNI_enabled" context option actually defaults to TRUE), so an arguably better fix would be to disable SNI completely. We don't verify the peer certificate anyway.

re #17 - it looks like SNI_enabled is only available in PHP 5.3.2+ so it's not an option for Drupal 7 (right?).

@greggles: I assume that older PHP versions don't support SNI and as a consequence are just not affected.

Same problem here for me after updating openssl from 0.9.8 to 1.0.1, fix in #13 works when using tls as transport.

I have applied the patch in #13 and tested it on PHP 5.3.10-1ubuntu3.9 in a pre-production environment. Changing the status to RTBC.

Just confirming the RTBC for this.

13: ssl-socket-transports-1879970-13.patch queued for re-testing.

Test went fatal on this
The test did not complete due to a fatal error. Completion check form.test 261 FormsTestCase->testSelect()

Setting back to RTBC

It doesn't look like Damien Tournoud's comments above have been fully addressed? So I think this should be "needs review". (It certainly would be nice to be able to fix the problem directly rather than adding yet another confusing option to this function. Although verifying the peer certificate is something that might eventually be added at #1081192: Verify peer on HTTPS if cURL available (but be careful of built-in cert bundles in the codebase).)

I did some research and from what I can tell, PHP 5.2 could have SNI support available if it is compiled. There just isn't any way to turn it off until 5.3.2+. This gets fixed by simply upgrading the OpenSSL stack. A fix is now in OpenSSL 0.9.8za per http://git.openssl.org/gitweb/?p=openssl.git;a=blob_plain;f=CHANGES;hb=r.... However, the stable release of 0.9.8 for some distros is older (see ubuntu), not 0.9.8za, so its going to be a while. Thankfully, using Ubuntu as an example, LTS support for 10.04 ends April 2015 so if we just sit on this the problem will go away on its own.

I'm still trying to confirm what versions of PHP and OpenSSL are installed on my prod LAMP stack, but this is hitting me with linkchecker module. It keeps throwing

Error opening socket ssl://example.com:443

. We can't use the cURL options from D8, since D7 still uses dhr(). If we go with #13, this doesn't help thinks like linkchecker, because we don't really know if the end-point is running SSL2 or SSL3. Long story short, upgrading OpenSSL is probably the best solution, not trying to solve this in Drupal.

While upgrading the OpenSSL version is ideal, the client isn't able to for various reason. They are however running PHP 5.3.x. So, let's see if this fixes the problem for them. This follows the approach proposed in #17. It doesn't solve the problem for earlier versions of PHP, but then I'm not sure there actually are any solutions unless OpenSSL is upgraded or PHP is upgraded.

After second though, I'm removing the else logic. If someone is providing a context, they know what they are doing and might not want SNI disabled.

Re-titling.

A similar approach was committed to httprl, could we do similar to core?

#2337071: Disable Server Name Indication (SNI) by default

This doesn't need to go to D8 first, since we don't want to disable SNI over there. Just in D7.

Just tagging.. This seems fairly straight forward though...

If we disable SNI we will run with fastly into issues. Update.d.o need to move to a native ip without SNI.

Fastly does not use SNI, but a SAN cert on a dedicated IP.

I wonder if this is a won't fix now that PHP 5.3 is sunset?

I have issues automatically updating modules and translations for the website due to SSL errors the site encounters when trying to connect to Drupal FTP. The site runs on an ancient PHP 5.3 version with SSL 1.0.0p installed.

I have contacted my hosting provider and they told me that there is no problem with SSL connection. I tried applying the patches from this thread, but that gave no result.

Since this fix was never implemented, could you please point me to the part of documentation I have to read to fix it? It drives me nuts at times trying to figure out the fix as a non-developer.

I still have this issue with PHP 7.2 and OpenSSL 1.0.2k-fips for Drupal linkchecker.

Could this happen if SSL versions 2 and 3 are both disabled? It's not considered secure anymore, and the socket doesn't seem to have an option to use tls:// instead...

Also, the error is happening more frequently since that root cert expired a few weeks ago.