@welting, are you able to reproduce this?

@laruence, thanks for the ping. Yep, can reproduce.

It's in both 32 and 64-bit. But the investigation shows that it's likely a site misconfiguration.

Here on Windows:

> curl.exe -V
curl 7.47.1 (x86_64-pc-win32) libcurl/7.47.1 OpenSSL/1.0.2g zlib/1.2.8 WinIDN libssh2/1.7.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz

> curl.exe -v -o /dev/null https://wswhomo.afip.gov.ar/wsfe/service.asmx?wsdl
.....
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* Unknown SSL protocol error in connection to wswhomo.afip.gov.ar:443
.....

Here on Jessie:
$ curl -V
curl 7.38.0 (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1k zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP

$ curl -v -o /dev/null 'https://wswhomo.afip.gov.ar/wsfe/service.asmx?wsdl'
......
* SSLv3, TLS handshake, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Server hello (2):
{ [data not shown]
* SSLv3, TLS handshake, CERT (11):
{ [data not shown]
* SSLv3, TLS handshake, Server finished (14):
{ [data not shown]
* SSLv3, TLS handshake, Client key exchange (16):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
} [data not shown]
* SSLv3, TLS handshake, Finished (20):
} [data not shown]
* SSLv3, TLS change cipher, Client hello (1):
{ [data not shown]
* SSLv3, TLS handshake, Finished (20):
{ [data not shown]
* SSL connection using TLSv1.0 / DES-CBC3-SHA
........

The latest OpenSSL release disables SSLv2 and many SSLv3 algorithms by default. Those can be enabled by using extra configurations. The Windows builds however don't do it. The full info is documented in the the latest security advisory https://openssl.org/news/secadv/20160301.txt .

Notable in the Windows output is this line:

Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

OpenSSL supports SSLv3 in my case on Jessie, the negotiation succeeds. The Windows variant tries to negotiate right ahead with TLSv1.2, but the site seems to not to be ready for that. Ever more fun that the target site is a goverment site that doesn't support the latest encryption :)

By the way, SSLv3 is already completely disabled since Fedora 23, so not even every Linux is supposed to show expected (but have no Fedora at hand to test).

@alejosimon, to connect to the site it's enough to enforce TLSv1.0. You can create a stream context for that.

Thanks.

I php x32 (5.6.20 and 5.6.20) work ok... only in x64 is the problem, and into win 7 x64 course.

Sorry, In php x32 (5.6.17 and 5.6.20) work ok... only in x64 is the problem, and into win 7 x64 course.

My loaded modules in PHP 7.0.5 win64...

[PHP Modules]
bcmath
bz2
calendar
com_dotnet
Core
ctype
curl
date
dom
exif
filter
ftp
gd
gettext
gmp
hash
iconv
imap
intl
json
ldap
libxml
mbstring
mcrypt
mysqli
mysqlnd
openssl
pcre
PDO
pdo_mysql
PDO_ODBC
pdo_pgsql
pdo_sqlite
pgsql
Phar
pthreads
Reflection
session
SimpleXML
soap
sockets
SPL
sqlite3
standard
tidy
tokenizer
wddx
xml
xmlreader
xmlrpc
xmlwriter
xsl
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

Sorry and thanks!

@alejosimon, I reproduce with both x86 and x64, and it actually should be so as they have the same OpenSSL version. We've OpenSSL 1.0.1 in 5.6 vs 1.0.2 in 7.0.

Testing with even earlier 7.0 version with OpenSSL preceding the latest security advisory, the issue is actually the same. So more about some OpenSSL 1.0.2 behavior change.

You need to create a stream context enforcing TLSv1. IIS6 is a very old and already unsupported software, so i'd barely see this as a bug anyway. 

Thanks.

@ab, Sorry, but we still have the error :( My test into TLSv1.0 context.

<?php

error_reporting(E_ALL);
ini_set("display_errors", 1);

$context = stream_context_create(
  array(
    'ssl' => array(
      'protocol_version' => 'tls1',
    ),
  ));

$url = 'https://wswhomo.afip.gov.ar/wsfe/service.asmx?wsdl' ; // FAIL!!!
//$url = 'https://wsaahomo.afip.gov.ar/ws/services/LoginCms?wsdl' ; // OK
//$url = 'https://servicios1.afip.gov.ar/wsfe/service.asmx?wsdl' ; // OK
//$url = 'https://www.google.com.ar' ; // OK

$response = file_get_contents( $url, false, $context );

print_r( $http_response_header );

?>

Result in php 7.0.5 win64:
Array(
)

--------------------------

Result in php 5.6.20 win32:
Array
(
    [0] => HTTP/1.1 200 OK
    [1] => Connection: close
    [2] => Date: Mon, 25 Apr 2016 12:51:29 GMT
    [3] => Server: Microsoft-IIS/6.0
    [4] => MicrosoftOfficeWebServer: 5.0_Pub
    [5] => X-Powered-By: ASP.NET
    [6] => X-AspNet-Version: 2.0.50727
    [7] => Cache-Control: private, max-age=0
    [8] => Content-Type: text/xml; charset=utf-8
    [9] => Content-Length: 24646
)

Thanks!

@alejosimon, thanks for staying on this. Yeah, you've used the wrong option. Here's how it should be:

$url = 'https://wswhomo.afip.gov.ar/wsfe/service.asmx?wsdl' ;

$opts = array(
        "ssl" => array(
                "ciphers" => "TLSv1",
        )
);
$context = stream_context_create($opts);
$response = file_get_contents($url, false, $context);

var_dump( $http_response_header );

Thanks.

Hahahaaaaa, sorry for my stupidity ... now it works !!!!!! You were right! THANK YOU VERY MUCH!!!

...but why that difference between x64 and x32 ???

Now results in all versions of PHP:

Array
(
    [0] => HTTP/1.1 200 OK
    [1] => Connection: close
    [2] => Date: Mon, 25 Apr 2016 13:30:01 GMT
    [3] => Server: Microsoft-IIS/6.0
    [4] => MicrosoftOfficeWebServer: 5.0_Pub
    [5] => X-Powered-By: ASP.NET
    [6] => X-AspNet-Version: 2.0.50727
    [7] => Cache-Control: private, max-age=0
    [8] => Content-Type: text/xml; charset=utf-8
    [9] => Content-Length: 24646
)

THANKS 2

Thanks for the check.

Not sure about the x86/x64 diff, i was able to reproduce with both. I guess it's some environment issue on your side. You should check that it loads the correct OpenSSL, etc.

And, I'd really suggest to report this to the corresponding admins. Even Firefox blocks if I go to https://afip.gov.ar/ . The encryption there is just insecure. For the Windows deps, we have no other choice that to follow the security advisory.

With this, time to close.

Thanks

Sure... in my linux (fedora 23 php 7.0.5 x64) also it works well, so I clarify that the problem is win64 only, but.. but equally it would be prudent to review this difference as a matter of safe portability between platforms.

Thanks for you help.

Yes, if you have a stable scenarion to reproduce that difference - please post. As mentioned, I see no difference between x86/x64.

Thanks.