php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21905 fopen/fsockopen via HTTPS
Submitted: 2003-01-27 11:24 UTC Modified: 2003-02-06 15:44 UTC
From: mike dot duncan at sonopress dot com Assigned:
Status: Closed Package: Sockets related
PHP Version: 4.3.0 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
13 - 12 = ?
Subscribe to this entry?

 
 [2003-01-27 11:24 UTC] mike dot duncan at sonopress dot com
The problem I am experiencing is close to, but not exactly, the same problem in bug #21642. That problem was not fully explained or understood by me and since the conversation went offline, I may never know what actually was resolved.

I am trying to access a Outlook Web Access box via SSL (HTTPS). Because the fsockopen() does not support SSL directly (because it starts in the clear initially) I tried to use fopen() but because you are not allowed to write to a HTTP-schemed, fopen()connection, I cannot see how to get around POST'ing info to the site. 

Am I missing an easier way to do this?

The error I receive with fopen() is: "failed to create stream: HTTP wrapper does not support writeable connections". Here is a snippit of code:
----------
$fp = fopen("https://webmail.domain.com", "w+");
if(! $fp)  {
  echo "Could not connect to server.\n";
  exit;
}

fputs($fp, "POST /exchange/logon.asp HTTP/1.1\r\n");
fputs($fp, ...various HTTP headers and info...);

while(! feof($fp))
  echo fgets($fp, 1024);

fclose($fp);
------------

I know it may not always be necessary to POST data, but I need to know if I must use Perl (which I can use LWP) for this. I would really like to stick with PHP because everything else is already written in it. 


Some system info...
---------
$ php -v
PHP 4.3.0 (cli) (built: Jan 24 2003 15:12:37)
Copyright (c) 1997-2002 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies

$ php -m
[PHP Modules]
ctype
ftp
ldap
mysql
oci8
openssl
overload
pcre
posix
saprfc
session
standard
tokenizer
xml
[Zend Modules]
----------

TIA for help, comments, and/or suggestions.

Mike Duncan
Web Master/Developer
Sonopress LLC
mike.duncan@sonopress.com

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-27 12:21 UTC] wez@php.net
This is not a support forum, and this is not a bug in PHP (marking as bogus).

fsockopen("ssl://webmail.domain.com", 443) should function exactly how you need it to for this task.
 [2003-01-28 12:27 UTC] mike dot duncan at sonopress dot com
I think you are misunderstanding me. I tried fsockopen() and it failed with "php_stream_sock_ssl_activate_with_method: SSL handshake/connection failed...fsockopen() [http://www.php.net/function.fsockopen]: failed to activate SSL mode 1 in..." error. This is exactly the same error reported in the Bug link given above. 

After reading that report, you suggested he use fopen() instead. This is what I did too, but unfortunately I got the error I reported above. 

What did you work out with him? 

After looking into other options, I noticed that cURL lib could be used to curl_init() the SSL first, but I think this beating around the subject. I do not want to have to install extranious libraries all over for this option. You state in the documentation that SSL support is in streams for PHP v4.3.0 as long as I build in support for OpenSSL. Which I did (see php -m above). Is there something I am missing?
 [2003-01-28 14:54 UTC] mike dot duncan at sonopress dot com
Could this whole mess be hanging on the certificate passed back by the server? I am using a self-signed cert., not a valid certificate.
 [2003-01-29 03:58 UTC] wez@php.net
PHP does not perform certificate verification, so self-signed certs should work just fine.

The error message implies that the handshake failed, which in turn implies that the remote server could be using a different version of the SSL "protocol".

PHP will by default attempt versions 2 and 3 of the SSL protocol.  If the remote server is using something else, such as TLS, then it is quite possible that you would encounter this error.
If that is the case, then you can attempt to use
fsockopen("tls://nameofyourhost") and see if that helps.

Bug 21642 is NOT related to this issue, and your understanding of the that bug report is not correct.
PHP does NOT fsockopen "ssl://" or "tls://" connections in-the clear; the issue in that report was that the user was expecting them to open in the clear.

 [2003-02-06 12:48 UTC] mike dot duncan at sonopress dot com
To solve this issue in the time frame given, I had to rewrite the HTTP client class I wrote to incorporate cURL instead of using sockets. I am NOT in favor of this, but it seems to be working well.

I did not try the latest CVS version of PHP to see if it would handle the SSL handshake any better. But the way I understand SSL is that it does start in the clear to exchange certificate and setup the connection (ciphers and such). I think this is deferred to OpenSSL for handling, but in any case, it was not working as planned. 

It is ok to close this report. Thanks for the help.
 [2003-02-06 15:44 UTC] sniper@php.net
closed per user request.

 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Sun Aug 14 10:05:44 2022 UTC