Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.php > #4302 > unrolled thread

php/curl Verbindungsproblem

Back to article view | Back to de.comp.lang.php

Contents

  php/curl Verbindungsproblem Stefan Mayer <meniskus@gmx.net> - 2017-11-05 13:48 +0100
    Re: php/curl Verbindungsproblem "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-11-05 13:59 +0100
      Re: php/curl Verbindungsproblem Stefan Mayer <meniskus@gmx.net> - 2017-11-06 20:41 +0100
        Re: php/curl Verbindungsproblem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-11-07 17:54 +0100
          Re: php/curl Verbindungsproblem Stefan Mayer <meniskus@gmx.net> - 2017-11-10 00:27 +0100
            Re: php/curl Verbindungsproblem Tom <weiksch@gmail.com> - 2018-10-06 08:26 -0700
    Re: php/curl Verbindungsproblem Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-11-05 20:26 +0100

#4302 — php/curl Verbindungsproblem

Hallo Leute,

das Ziel ist ein client, natürlich in PHP, für das API von mobile.de.

In der offiziellen Dokumentation gibt es folgenden Aufruf:

curl -vs \
     -u user:pass \
     -x https://api.test.sandbox.mobile.de:8080 \
     -H "Accept: application/vnd.de.mobile.api+json" \
     https://services.mobile.de/seller-api/sellers

Das Testscript sollte dem Aufruf entsprechen.

<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_VERBOSE, true);
curl_setopt($ch, CURLOPT_URL,
    'https://service.mobile.de/seller-api'
);
curl_setopt($ch, CURLOPT_HTTPHEADER,[
    'Accept' =>'application/vnd.de.mobile.api+json'
]);
curl_setopt($ch, CURLOPT_USERPWD, 'user:pass');
curl_setopt($ch, CURLOPT_PROXY, 'api.test.sandbox.mobile.de');
curl_setopt($ch, CURLOPT_PROXYPORT, 8080);
curl_setopt($ch, CURLOPT_PROXYTYPE, CURLPROXY_HTTP);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
$result=curl_exec ($ch);
var_dump($result);
echo curl_error($ch). PHP_EOL;
exit();

Leider gibt es Probleme mit dem Verbindungsaufbau und mir fehlt grade das
tiefere Verständnis der Zusammenhänge. Im Wesentlichen funktioniert das
Testscript nicht. Über curl und openssl (auf unterschiedlichen Systemen die
Aufgabenstellung ausprobiert) lande ich bei den diffusen Fragenzeichen:

Wie sind die Zusammenhänge? php/curl benutzt das curl vom System? Das curl vom
System wiederum benutzt OpenSSL oder auch nicht (dann z.B. lib_ssh?). PHP
benutzt ebenfalls OpenSSL? OpenSSL (oder curl?) kann es mit oder ohne
Unterstützung für z.B. sslv3 geben? OpenSSL leht verbindungen ab wenn Sie … was
genau nicht erfüllen?

Etwas konkreter:

Wer bzw. welche Komponente im System hat das letzte Wort über eine gewünscht
Verbindung und zu welchen Bedingungen?

Wie kann ich ermitteln, was die Gegenstellen anzubieten hat und was mein (das
fragende) System wünscht bzw. ebenfalls anzubieten hat.

Kann ich diese ermittelten Daten überhaupt für mein php/curl beim Hoster
anwenden?

Gerne liefere ich Meldungen, oder Angaben zu den verwendeten Systemen,
Programmversionen, etc. und/oder Weitere Beobachtungen, allerdings dreht sich
das alles im Kreis und an Ende lade ich wieder bei den obigen Fragen :-)

Würde mir mal jemand auf die Sprünge helfen?

Vielen Dank.

ciao, Stefan

[toc] | [next] | [standalone]

#4303

Am 05.11.2017 um 13:48 schrieb Stefan Mayer:

> In der offiziellen Dokumentation gibt es folgenden Aufruf:
> 
> curl -vs \
>      -u user:pass \
>      -x https://api.test.sandbox.mobile.de:8080 \
>      -H "Accept: application/vnd.de.mobile.api+json" \
>      https://services.mobile.de/seller-api/sellers
> 
> Das Testscript sollte dem Aufruf entsprechen.
> 
> <?php
> $ch = curl_init();
> curl_setopt($ch, CURLOPT_VERBOSE, true);
> curl_setopt($ch, CURLOPT_URL,
>     'https://service.mobile.de/seller-api'
> );

Hm, die URI stimmt nicht überein.  Tippfehler nur in diesem Thread, oder
im Script?

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#4305

Christoph M. Becker am Sonntag, 5. November 2017 (13:59):

> Am 05.11.2017 um 13:48 schrieb Stefan Mayer:

>> In der offiziellen Dokumentation gibt es folgenden Aufruf:
>> 
>> curl -vs \
>>      -u user:pass \
>>      -x https://api.test.sandbox.mobile.de:8080 \
>>      -H "Accept: application/vnd.de.mobile.api+json" \
>>      https://services.mobile.de/seller-api/sellers
>> 
>> Das Testscript sollte dem Aufruf entsprechen.
>> 
>> <?php
>> $ch = curl_init();
>> curl_setopt($ch, CURLOPT_VERBOSE, true);
>> curl_setopt($ch, CURLOPT_URL,
>>     'https://service.mobile.de/seller-api'
>> );

> Hm, die URI stimmt nicht überein.  Tippfehler nur in diesem Thread, oder
> im Script?

Der URI und die Angabe zu den HTTP-Kopfzeilen stimmen nicht.

Richtig ist: https://services.mobile.de/seller-api/[sellers]
                            ^
Ebenso die Notierung der HTTP Kopfzeilen.
Falsch:  ['Accept' => 'application/vnd.de.mobile.api+json']
Richtig: ['Accept: application/vnd.de.mobile.api+json']

Wie auch immer, beides kommt erst zu tragen, _wenn_ eine Verbindung steht.

# Das System auf dem der Client laufen soll ist Webspace bei Hetzner.

curl --version (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t libssh2/1.4.3

Per curl oder (korrektem) script endet beides in:

Failed to connect to api.test.sandbox.mobile.de port 8080: Connection refused

$ openssl s_client -connect api.test.sandbox.mobile.de:8080 -ssl3
$ openssl s_client -connect api.test.sandbox.mobile.de:8080 -tls1_2

socket: Connection refused
connect:errno=111

Keine weitere Ausgabe.

Zum Vergleich:

$ openssl s_client -connect google.com:443 -tls1_2
Secure Renegotiation IS supported

$ openssl s_client -connect google.com:443 -ssl3
140365874095760:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:348:
Secure Renegotiation IS NOT supported

Zur Fehlermeldung war das https://access.redhat.com/solutions/56428 für mich am
Aussagekräfigsten.

TLS 1.2 wird unterstützt SSLv3 nicht. Der Sandkasten (proxy) von mobile
unterstützt beides nicht? Wieso wirft google den Fehler, die Sandbox aber nicht?


# Ein Testsystem in der lokalen VM, schon älter.

curl --version (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t libssh2/1.4.3

Die curl/openssl Versionen sind gleich wie bei Hetzner?

$ openssl s_client -connect api.test.sandbox.mobile.de:8080 -ssl3
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:348:
Secure Renegotiation IS NOT supported

$ openssl s_client -connect api.test.sandbox.mobile.de:8080 -tls1_2
error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:348:
Secure Renegotiation IS NOT supported

Allerdings, der direkte Aufruf per curl oder script verbindet wie folgt.

$ curl -vs ...
* Establish HTTP proxy tunnel to services.mobile.de:443
> CONNECT services.mobile.de:443 HTTP/1.1
< HTTP/1.1 200 Connection established
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES256-SHA
* Server certificate:
*  issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 EV SSL CA - G3

"SSLv3" Handschlag vs. "connection using TLSv1.2"?

Welches Protokoll ist den nun für die Verbindung in ausgehandelt?

Also mein Testsystem akzeptiert SSLv3? Mit welchen Argumenten ruft curl dann openssl
auf, bzw. tut es das überhaupt?


# Es gibt noch ein Ubuntu

curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3

Dieses curl benutzt nicht OpenSSL. PHP gibt's da nicht, aber der curl Aufruf verbindet.

* Proxy replied OK to CONNECT request
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 596 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / RSA_AES_256_CBC_SHA1

Im Gegensatz zum Testsystem sieht die Protokollierung anders aus, es gibt kein
Angaben zum Handshake und Kein "Server hello". Aber wieder "SSL connection using
TLS1.2".

# Ich arbeite auf Windows und per MinGW Umgebung:

curl 7.55.1 (x86_64-pc-msys) libcurl/7.55.1 OpenSSL/1.0.2l libssh2/1.8.0

* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

https://stackoverflow.com/questions/15166950/unable-to-establish-ssl-connection-how-do-i-fix-my-ssl-cert#answer-15168180

OK. Es wird versucht mit TLS 1.2 zu verbinden, aber der Server sendet kein
"Server hello" Kann der jetzt TLS 1.2 oder nicht?


Die alles entscheidende Frage lautet: Wieso verbindet der Server bei Hetzner
nicht? Meine Vermutung: Es ist das Fehlen der SSLv3 Unterstützung bei Hetzner.
Mein Testumgebung, weil nicht so gut gepflegt, akzeptiert das. MinGW ist neuer
und unterstützt ebenfalls kein SSLv3.

Nur, was hat dann "SSL connection using TLSv1.2" zu bedeuten?
Was hat der SSLv3 Handshake mit anschließendem "using TLSv1.2" zu bedeuten?
Wie bekomme ich raus, welches Protokoll den nun verlangt, bzw. welches Angeboten wird.
Wie bekomme ich raus welche Protokolle von meinen Rechnern akzeptiert werden.
Welche Komponente ist den jetzt letztlich dafür zuständig?
[...]

Wie ich es geschrieben habe, mir fehlt das grundsätzliche Verständnis, um die
Beobachtungen zu überhaupt zu deuten. Was zur Folge hat, dass ich nicht weiß
welche Informationen ich überhaupt, womit und wo suchen sollte um mir den
Sachverhalt zu erschließen.

Ich muss mich wohl damit zufrieden geben, dass meine Vermutung zur Ursache
vielleicht richtig ist und die Produktiv-Umgebung bei mobile.de wahrscheinlich
schon "funktionieren" wird.


Schönen Tag noch.
ciao, Stefan

[toc] | [prev] | [next] | [standalone]

#4306

Stefan Mayer wrote:

> […]
> Ebenso die Notierung der HTTP Kopfzeilen.
> Falsch:  ['Accept' => 'application/vnd.de.mobile.api+json']
> Richtig: ['Accept: application/vnd.de.mobile.api+json']

ACK, siehe auch <http://php.net/curl_setopt>.
 
> $ openssl s_client -connect api.test.sandbox.mobile.de:8080 -ssl3
> $ openssl s_client -connect api.test.sandbox.mobile.de:8080 -tls1_2
> 
> socket: Connection refused
> connect:errno=111
> 
> Keine weitere Ausgabe.
> 
> Zum Vergleich:
> 
> $ openssl s_client -connect google.com:443 -tls1_2
> Secure Renegotiation IS supported
> 
> $ openssl s_client -connect google.com:443 -ssl3
> 140365874095760:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
> number:s3_pkt.c:348: Secure Renegotiation IS NOT supported
> 
> Zur Fehlermeldung war das https://access.redhat.com/solutions/56428 für
> mich am Aussagekräfigsten.
> 
> TLS 1.2 wird unterstützt SSLv3 nicht.
                          ^ ,

SSLv3 ist veraltet und unsicher.  TLS ist der sicherere Nachfolger von SSL.

<https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0.2C_2.0_and_3.0>

> Der Sandkasten (proxy) von mobile unterstützt beides nicht?

Kann ich nicht bestädtchen.

> Wieso wirft google den Fehler, die Sandbox aber nicht?

$ openssl s_client -connect api.test.sandbox.mobile.de:8080 -ssl3
CONNECTED(00000003)
139907876908568:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version 
number:s3_pkt.c:365:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1510072342
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

$ curl --version
curl 7.50.1 (x86_64-pc-linux-gnu) libcurl/7.50.1 GnuTLS/3.5.3 zlib/1.2.8 
libidn/1.33 libssh2/1.7.0 nghttp2/1.14.0 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 
pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB 
SSL libz TLS-SRP HTTP2 UnixSockets 
 
> # Ein Testsystem in der lokalen VM, schon älter.
> 
> curl --version (x86_64-pc-linux-gnu) libcurl/7.38.0 OpenSSL/1.0.1t
> libssh2/1.4.3

Bitte Eingabe und Ausgabe beim Posten ebenso voneinander trennen wie 
Hauptsätze.
 
> Die curl/openssl Versionen sind gleich wie bei Hetzner?

Das ist eine sinnlose Frage.
 
> […]
> Allerdings, der direkte Aufruf per curl oder script verbindet wie folgt.
> 
> $ curl -vs ...
> * Establish HTTP proxy tunnel to services.mobile.de:443
>> CONNECT services.mobile.de:443 HTTP/1.1
> < HTTP/1.1 200 Connection established
> * SSLv3, TLS handshake, Client hello (1):
> * SSLv3, TLS handshake, Server hello (2):
> * SSLv3, TLS handshake, Finished (20):
                          ^^^^^^^^
> * SSL connection using TLSv1.2 / AES256-SHA
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> * Server certificate:
> *  issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network;
> CN=Symantec Class 3 EV SSL CA - G3
> 
> "SSLv3" Handschlag vs. "connection using TLSv1.2"?
> 
> Welches Protokoll ist den nun für die Verbindung in ausgehandelt?

TLS 1.2, wie man sieht.
 
> Also mein Testsystem akzeptiert SSLv3?

Möglich.

> Mit welchen Argumenten ruft curl dann openssl auf, bzw. tut es das
> überhaupt?

man strace
 
> # Es gibt noch ein Ubuntu
> 
> curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8
> libidn/1.32 librtmp/2.3
> 
> Dieses curl benutzt nicht OpenSSL.

Unwahrscheinlich.

> Die alles entscheidende Frage lautet: Wieso verbindet der Server bei
> Hetzner nicht? Meine Vermutung: Es ist das Fehlen der SSLv3 Unterstützung
> bei Hetzner. Mein Testumgebung, weil nicht so gut gepflegt, akzeptiert
> das. MinGW ist neuer und unterstützt ebenfalls kein SSLv3.

Das hat alles nichts mit PHP-Programmierung zu tun.  Frag in einer Netzwerk- 
oder Security-Gruppe.
 
> Nur, was hat dann "SSL connection using TLSv1.2" zu bedeuten?
> Was hat der SSLv3 Handshake mit anschließendem "using TLSv1.2" zu
> bedeuten? 

Wer lesen kann, ist hier klar im Vorteil.

> Ich muss mich wohl damit zufrieden geben, dass meine Vermutung zur Ursache
> vielleicht richtig ist und die Produktiv-Umgebung bei mobile.de
> wahrscheinlich schon "funktionieren" wird.

Nein, musst Du nicht.  Du musst Dich informieren gehen, bevor Du etwas tust.
Derlei planloses Herumgestochere führt höchstens *zufällig* zu sinnvollen 
Ergebnissen.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4307

Thomas 'PointedEars' Lahn am Dienstag, 7. November 2017 (17:54):

> Stefan Mayer wrote:

>> [planloses zu curl, gefolgt von:]

>> Ich muss mich wohl damit zufrieden geben, dass meine Vermutung zur Ursache
>> vielleicht richtig ist und die Produktiv-Umgebung bei mobile.de
>> wahrscheinlich schon "funktionieren" wird.

> Nein, musst Du nicht.  Du musst Dich informieren gehen, bevor Du etwas tust.
> Derlei planloses Herumgestochere führt höchstens *zufällig* zu sinnvollen 
> Ergebnissen.

Natürlich gehe ich mich informieren. Nur findet man besser wenn man weiß wonach
man sucht. Und da ich in dem Falle mit allen Beteiligten - php/curl, curl (und
verwendeten Paketen), TLS, Proxy, etc - nur wenig vertraut bin, erschien mir
eine Auseinandersetzung zu dem Zeitpunkt, mangels Peilung, als sehr mächtig.
Mittlerweile bin ich schlauer.

Danke für Deine Einlassungen. Gerne wäre ich noch darauf eingegangen, aber ich
fürchte es wäre sinnlos.


ciao, Stefan

[toc] | [prev] | [next] | [standalone]

#4423

@Stefan Mayer
Konntest du das Problem denn inzwischen lösen und würdest uns an deiner Hetzner/mobilede/curl Lösung teilhaben lassen? Das wäre super freundlich und scheinbar für noch mehr Leute hilfreich... wie mich z.B..

Danke dir :)

[toc] | [prev] | [next] | [standalone]

#4304

Stefan Mayer wrote:

> das Ziel ist ein client, natürlich in PHP, für das API von mobile.de.
> 
> In der offiziellen Dokumentation gibt es folgenden Aufruf:
> 
> curl -vs \
>      -u user:pass \
>      -x https://api.test.sandbox.mobile.de:8080 \
>      -H "Accept: application/vnd.de.mobile.api+json" \
>      https://services.mobile.de/seller-api/sellers
> 
> Das Testscript sollte dem Aufruf entsprechen. [Fragen]

Ich habe vor kurzem hier oder in comp.lang.php ein PHP-Script gepostet, mit 
dem man den mit “curl --libcurl” ausgebbaren C-Code nach PHP konvertieren 
kann.  Alles weitere sollte sich den einschlägigen Dokumentationen entnehmen 
lassen.

Dies ist eine *News*group.  Bitte erst lesen, dann denken, dann posten.
 
-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.php

csiph-web