PHP curl get negotiated TLS version - php

I am trying to check whether my requests are using TLS version >1. While curl command line gives me this information in the verbose output, php does not seem to be.
This is my PHP curl verbose output when the connection is initiated
* About to connect() to *** port 443 (#0)
* Trying 88.*.*.*... * connected
* Connected to *** (88.*.*.*) port 443 (#0)
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL connection using TLS_RSA_WITH_AES_256_CBC_SHA
* Server certificate:
* subject: ***
* start date: Dec 21 18:43:21 2015 GMT
* expire date: Dec 21 18:38:18 2016 GMT
* common name: ***
* issuer: CN=Verizon Akamai SureServer CA G14-SHA2,OU=Cybertrust,O=Verizon Enterprise Solutions,L=Amsterdam,C=NL
* Server auth using Basic with user '***'
> GET /my/path HTTP/1.1
Authorization: ***
Host: ***
Accept: */*
< HTTP/1.1 200 OK
< Server: ***
< Content-Type: application/json;charset=utf-8
< Content-Length: 3733
< Expires: Wed, 03 Feb 2016 15:24:49 GMT
< Cache-Control: max-age=0, no-cache, no-store
< Pragma: no-cache
< Date: Wed, 03 Feb 2016 15:24:49 GMT
< Connection: keep-alive
<
* Connection #0 to host *** left intact
* Closing connection #0
How can I say what is the TLS used in a connection? I would like to avoid using any 3rd party options like making request to https://www.howsmyssl.com/a/check

Related

Issue with Laravel Route and POST

I'm having an issue submitting post requests using Laravel. The following works locally using docker with Laravel 9.21.6 and PHP 8.1.0. When I try on the live server running NGINX with Laravel 9.21.6 and PHP 8.1.8, I get nothing. What am I missing?
Route::post('orders', function (Request $request) {
return ($request);
});
If I try the following curl request:
curl -v -X POST -d "{'order':18}" "http://localhost/api/orders"
I get order printed:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#0)
> POST /api/orders HTTP/1.1
> Host: localhost
> User-Agent: curl/7.79.1
> Accept: */*
> Content-Length: 12
> Content-Type: application/x-www-form-urlencoded
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Host: localhost
< Date: Sun, 31 Jul 2022 18:41:08 GMT
< Connection: close
< X-Powered-By: PHP/8.1.0
< Cache-Control: no-cache, private
< Date: Sun, 31 Jul 2022 18:41:08 GMT
< Content-Type: application/json
< X-RateLimit-Limit: 60
< X-RateLimit-Remaining: 59
< Access-Control-Allow-Origin: *
<
* Closing connection 0
{"{'order':18}":null}%
But if I try on the server:
curl -v -X POST -d "{'order':18}" "https://server.com/api/orders"
I get nothing:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 54.145.34.166:443...
* Connected to api.wenusvi.com (54.145.34.166) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=wenusvi.com
* start date: Jun 18 19:22:18 2022 GMT
* expire date: Sep 16 19:22:17 2022 GMT
* subjectAltName: host "api.wenusvi.com" matched cert's "api.wenusvi.com"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
> POST /api/orders HTTP/1.1
> Host: api.wenusvi.com
> User-Agent: curl/7.79.1
> Accept: */*
> Connection: close
> Content-Length: 12
> Content-Type: application/x-www-form-urlencoded
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.18.0 (Ubuntu)
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: close
< Cache-Control: no-cache, private
< Date: Sun, 31 Jul 2022 18:40:55 GMT
< X-RateLimit-Limit: 60
< X-RateLimit-Remaining: 59
< Access-Control-Allow-Origin: *
<
* Closing connection 0
After much trial and error, the issue had to do with php-fpm. It seems the server was caching the output. Initially, this URL did not output any results, so the server cached that "data" and any further calls returned the empty data. Restarting php-fpm worked so I did some more searching and came across an article that advised changing opcache to 0. See https://serverfault.com/questions/991843/why-does-php-fpm-sometimes-get-stuck-serving-old-files

PHP curl_errno returns 7 even when request is successful

I'm trying to integrate authorize.net (AIM) using the official PHP SDK v2.0.0 and I'm seeing some strange behaviors:
curl_exec() returns false even when the request is successful and CURLOPT_RETURNTRANSFER is set to true.
curl_errno is returns 7 (Failed to connect() to host or proxy) for the same request.
I know request is successful since:
I can see the transaction is successfully recorded at authorize.net
Setting CURLOPT_RETURNTRANSFER to false causes the JSON response from authorize.net to be printed
curl_getinfo() shows HTTP status code = 200
Anyone experience this type of behavior with cURL? I'm not sure what I'm missing.
EDIT: Added output with CURLOPT_VERBOSE set
* Trying 198.241.206.22:443...
* Connected to apitest.authorize.net (198.241.206.22) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /home/app/demo/assets/lib/anet_sdk_2.0.0/lib/ssl/cert.pem
CApath: none
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=Foster City; O=Authorize.Net; CN=*.authorize.net
* start date: Feb 5 20:44:08 2020 GMT
* expire date: Mar 15 21:14:08 2021 GMT
* subjectAltName: host "apitest.authorize.net" matched cert's "*.authorize.net"
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1K
* SSL certificate verify ok.
> POST /xml/v1/request.api HTTP/1.1
Host: apitest.authorize.net
Accept: */*
Content-Type: text/json
Content-Length: 1458
* upload completely sent off: 1458 out of 1458 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Cache-Control: no-store
< Pragma: no-cache
< Content-Type: application/json; charset=utf-8
< X-OPNET-Transaction-Trace: a2_fe4a070f-cf07-47d7-8e9e-c8a703920de5-5628-7089051
< Access-Control-Allow-Credentials: true
< Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction
< Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET
< Access-Control-Allow-Origin: *
< Strict-Transport-Security: max-age=31536000
< X-Cnection: close
< Date: Sat, 12 Sep 2020 10:40:48 GMT
< Content-Length: 512
<
* Connection #0 to host apitest.authorize.net left intact

send a terminal curl post request to a login

I've been trying to send a post request to this login page https://njit2.mrooms.net/auth/saml2/login.php but it doesn't successfully log me in even though the credentials are correct.
here is the full command I'm using in my terminal:
curl --data "j_username=user&j_password=pass&_eventId_proceed=" https://njit2.mrooms.net/auth/saml2/login.php
If you can spot anything that I'm not getting then it'll be much appreciated. Thanks.
edit: with -v flag this is what I get in the beginning of the response:
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 34.192.104.23...
* Connected to njit2.mrooms.net (34.192.104.23) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 597 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* server certificate verification OK
* server certificate status verification SKIPPED
* common name: *.mrooms.net (matched)
* server certificate expiration date OK
* server certificate activation date OK
* certificate public key: RSA
* certificate version: #3
* subject: OU=Domain Control Validated,OU=PositiveSSL Wildcard,CN=*.mrooms.net
* start date: Thu, 30 Nov 2017 00:00:00 GMT
* expire date: Thu, 17 Jan 2019 23:59:59 GMT
* issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Domain Validation Secure Server CA
* compression: NULL
* ALPN, server did not agree to a protocol
> POST /auth/saml2/login.php HTTP/1.1
> Host: njit2.mrooms.net
> User-Agent: curl/7.47.0
> Accept: */*
> Content-Length: 54
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 54 out of 54 bytes
< HTTP/1.1 200 OK
< Cache-Control: no-store, no-cache, must-revalidate
< Content-Type: text/html; charset=utf-8
< Date: Mon, 17 Sep 2018 05:54:50 GMT
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Pragma: no-cache
< Server: Apache
< Set-Cookie: MoodleSession=fe6dc1b41104b83d391d8700d60f9308; path=/
< Set-Cookie: MDL_SSP_SessID=402ef69749885fa74956365b087e5747; path=/; HttpOnly
< Vary: Accept-Encoding
< X-Powered-By: PHP/7.1.15-1+ubuntu14.04.1+deb.sury.org+2
< transfer-encoding: chunked
< Connection: keep-alive

Paypal connection fails in PHP (Dockerized website)

In my php website the page redirection associated with paypal is not working by giving the following in the apache error log. I have exposed port 80 as well as 443 in Dockerfile. Rest of the things are working fine in the site and the site with the same code is running fine in my local apache server.
* Trying 173.0.82.83...
* Connected to api-3t.sandbox.paypal.com (173.0.82.83) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* SSL connection using TLSv1.2 / AES256-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=US; ST=California; L=San Jose; O=PayPal, Inc.; OU=PayPal
Production; CN=api-3t.sandbox.paypal.com
* start date: Jan 14 00:00:00 2016 GMT
* expire date: Jan 14 23:59:59 2018 GMT
* subjectAltName: api-3t.sandbox.paypal.com matched
* issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network;
CN=Symantec Class 3 Secure Server CA - G4
* SSL certificate verify ok.
> POST /nvp HTTP/1.1
Host: api-3t.sandbox.paypal.com
Accept: */*
Content-Length: 655
Content-Type: application/x-www-form-urlencoded
* upload completely sent off: 655 out of 655 bytes
< HTTP/1.1 200 OK
< Date: Mon, 04 Sep 2017 08:07:48 GMT
< Server: Apache
< X-SLR-RETRY-API: SetExpressCheckout
< X-PAYPAL-OPERATION-NAME: SetExpressCheckout
< X-PAYPAL-API-RC:
< Connection: close
< HTTP_X_PP_AZ_LOCATOR: sandbox.slc
< Paypal-Debug-Id: 6692e8ec22b4a
< Set-Cookie: X-PP SILOVER=name%3DSANDBOX3.API.1%26silo_version%3D1880%26app%3Dappdispatcher_apit%26TIME%3D3691621721%26HTTP_X_PP_AZ_LOCATOR%3Dsandbox.slc; Expires=Mon, 04 Sep 2017 08:37:56 GMT; domain=.paypal.com; path=/; Secure; HttpOnly
< Set-Cookie: X-PP-SILOVER=; Expires=Thu, 01 Jan 1970 00:00:01 GMT
< Content-Length: 137
< Content-Type: text/plain; charset=utf-8
<
* Closing connection 0
Please help me in fixing this error.
I can find error logs under apache in my local and in case of success scenarios nothing is being logged
I am using Ubuntu 17.04 installed in oracle VM. I am not able to ping paypal sandbox URL from my server in VM. If I am trying to ping the URL from my local commandprompt, I am getting Request Timed out inspite of successful paypal connection in my local apache (from XAMP).

Looping HTTP post starts to fail for Amazon SES

I originally posted this at the Amazon SES forums here: https://forums.aws.amazon.com/thread.jspa?threadID=74561&tstart=0
But since the stackoverflow community is more active, I'll post it here :)
Basically I have a forecah loop around a cURL post (see bottom of post for script snippet). It works for a couple hundred posts, but then starts to fail for all the others. Here's the last successful post followed by the first of 100's of unsuccessful posts...
* About to connect() to email.us-east-1.amazonaws.com port 443 (#0)
* Trying 207.171.162.2... * connected
* Connected to email.us-east-1.amazonaws.com (207.171.162.2) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
* start date: 2010-10-08 00:00:00 GMT
* expire date: 2013-10-07 23:59:59 GMT
* subjectAltName: email.us-east-1.amazonaws.com matched
* issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
POST / HTTP/1.1
Accept: */*
Host: email.us-east-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded
Date: Sat, 20 Aug 2011 18:59:56 UTC
X-Amzn-Authorization: AWS3-HTTPS AWSAccessKeyId=LKIABMH7PT8SO4YBRDQA,Algorithm=HmacSHA1,Signature=/0HFVEsTBGqUUSQGy9jvmsft2k4=
Content-Length: 5810
Expect: 100-continue
< HTTP/1.1 200 OK
< x-amzn-RequestId: 4a0f8f18-cb5f-11e0-8364-b14fdafc0888
< Content-Type: text/xml
< Content-Length: 326
< Date: Sat, 20 Aug 2011 19:04:55 GMT
<
* Connection #0 to host email.us-east-1.amazonaws.com left intact
* Closing connection #0
The the failures start....
* About to connect() to email.us-east-1.amazonaws.com port 443 (#0)
* Trying 207.171.162.2... * connected
* Connected to email.us-east-1.amazonaws.com (207.171.162.2) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSL connection using RC4-MD5
* Server certificate:
* subject: /C=US/ST=Washington/L=Seattle/O=Amazon.com Inc./CN=email.us-east-1.amazonaws.com
* start date: 2010-10-08 00:00:00 GMT
* expire date: 2013-10-07 23:59:59 GMT
* subjectAltName: email.us-east-1.amazonaws.com matched
* issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)09/CN=VeriSign Class 3 Secure Server CA - G2
* SSL certificate verify ok.
POST / HTTP/1.1
Accept: */*
Host: email.us-east-1.amazonaws.com
Content-Type: application/x-www-form-urlencoded
Date: Sat, 20 Aug 2011 18:59:56 UTC
X-Amzn-Authorization: AWS3-HTTPS AWSAccessKeyId=LKIABMH7PT8SO4YBRDQA,Algorithm=HmacSHA1,Signature=/0HFVEsTBGqUUSQGy9jvmsft2k4=
Content-Length: 5806
Expect: 100-continue
< HTTP/1.1 400 Bad Request
< x-amzn-RequestId: 4b8f29db-cb5f-11e0-b9af-33e5c8fc863b
< Content-Type: text/xml
< Content-Length: 347
< Date: Sat, 20 Aug 2011 19:04:58 GMT
<
* Connection #0 to host email.us-east-1.amazonaws.com left intact
* Closing connection #0
Here's the script snippet
foreach($JSONarray['DATABASE'] as $E)
{
if ((array_diff($E['LISTS'], $FILTER) != $E['LISTS']) && $E['STATUS'] == "CONF")
{
$MAIL = "Action=SendEmail&Source=".$FROME."&ReturnPath=".$BOUNCE."&Destination.ToAddresses.member.1=".$TOE."&Message.Subject.Data=".$SUBE."&Message.Body.Html.Data=".$BODYE;
//curl
$aws = curl_init();
curl_setopt($aws, CURLOPT_POSTFIELDS, $MAIL);
curl_setopt($aws, CURLOPT_HTTPHEADER, $headers);
curl_setopt($aws, CURLOPT_HEADER, false);
curl_setopt($aws, CURLOPT_URL, $url);
curl_setopt($aws, CURLOPT_RETURNTRANSFER, true);
curl_setopt($aws, CURLOPT_VERBOSE, true);
curl_setopt($aws, CURLOPT_STDERR, $SESLOG);
curl_exec($aws);
curl_close($aws);
}
}
Any ideas?
Could it be a DOS prevention mecanism kicking in? How about putting some sleeps into your code? I would definitely put some safeguards against potential DOS attacks if I were Amazon..
Just a guess, though...
I figured out the problem:
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>RequestExpired</Code>
<Message>Request timestamp: Mon, 22 Aug 2011 15:49:11 UTC expired. It must be within 300 secs/ of server time.</Message>
</Error>
<RequestId>0e3899cb-ccd7-11e0-9f09-c5d12d442026</RequestId>
</ErrorResponse>
My headers were set-up outside the forecah loop around curl. Doh! So I just moved that bit of code into the loop to solve the time-out problem.

Categories