When I use setcookie,security error is showing in Microsoft Edge.
'A 'set-cookie' header doesn't have the 'secure' directive.'
My connection is insecure http connection.
How to prevent it ?
I used php setcookie function with various patterns.
Related
If I start a session like below for a server and a localhost client try to request the server via HTTP, does it response with the session cookie?
or must it go through HTTPS?
I read the doc and it did say only through HTTPS, but I wonder if localhost is an exception.
session_start([
'cookie_secure' => true
]);
Yes, it does:
If you try this in a browser, you'll also see a warning saying that the cookie was rejected.
This makes sense because PHP has no control on the entire communication channel and it's possible that the end-user is connecting to a secure proxy that redirects internally to a non-encrypted HTTP server.
I am developing an Oauth 2 authentication server and I have a problem with endpoint redirection.
Here is what the RFC says that I try to follow scrupulously:
3.1.2.1. Endpoint Request Confidentiality
The redirection endpoint SHOULD require the use of TLS as described
in Section 1.6 when the requested response type is "code" or "token",
or when the redirection request will result in the transmission of
sensitive credentials over an open network.
https://www.rfc-editor.org/rfc/rfc6749#section-3.1.2.1
Here is my question:
I know if the current request uses HTTPS with the $_SERVER ['HTTPS'] superglobal, but how do I determine if the url I'm going to redirect is using TLS
?
header("Location: $redirectUri");
Do I only rely on the protocol (https: // at the beginning of the URL)? On headers returned by a CURL request made before redirection (check the presence of the Strict-Transport-Security header) ? If not how should I do it?
PS: Normally it is not necessary but in case. Here is the complete code:
https://github.com/alexandre-le-borgne/oauth-server/blob/master/src/OAuth2/Endpoints/AuthorizationEndpoint.php#L185
My conclusion is that it is enough to check the presence of the https at the beginning of the URL.
Once upon a time, there was a normalish error in PHP land:
Warning: ftp_nlist(): data_accept: SSL/TLS handshake failed in [path] on line 29
But here's the catch, "line 29" is not the connection or login, note how it referenced the ftp_nlist() function:
$ftp = ftp_ssl_connect($cred['host'], $cred['port'], 180);
if (!ftp_login($ftp, $cred['user'], $cred['pass'])) {die("Login Failed");}
ftp_pasv($ftp, true);
$files = ftp_nlist($ftp, '');
OpenSSL is compiled and enabled in phpinfo() as suggested here:
ftp_login() : SSL/TLS handshake failed
Other posts I've seen all seem to reference error in the ftp_ssl_connect() or ftp_login() commands which work for me. What can I check when ftp_login() returns true?
Or... are there any logs to get more details on what is wrong?
I'm using php 5.3.29. The code does work properly on my desktop (php 7), but I'm hoping I don't have to upgrade the server to 7 for this to work
12-28-2017 update:
Upgrading to 5.6 resolved, so looks like Martin is on point.
Although this question is quite old, but in case someone else hits this problem:
If your ftp_ssl_connect and ftp_login works fine but functions like ftp_nlist, ftp_put, ftp_fput don't works the problem might be that your FTP server is using port 21 for Connection but different port ranges for data transfer, that explains why you can connect and login but you can't upload or download data, and you need to allow the Out-going connections to those port range in your firewall
The ftp_nlist opens a data connection. That connection needs TLS/SSL handshake too.
As the control connection handshake succeeded, the problem indeed cannot be with an absent TLS/SSL support in PHP. Neither the problem can be with anything like the server and PHP not being able to find a cipher to agree on.
When TLS/SSL handshake on data connection fails after handshake on control connection succeeded, it's quite usually because the client (PHP) did not reuse TLS/SSL session from control connection on the data connection (see Why is session reuse useful in FTPS?). Some servers do require that. PHP supports the reuse only since 5.6.26. See PHP Bug 70195. So make sure you use that version of PHP at least.
Have encountered an issue where email should be sent from an mail server which has self signed certificate, the error which I get is :
PHP Warning: stream_socket_enable_crypto(): SSL operation failed with code 1. OpenSSL Error messages:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in class.smtp.php on line 327.
Has anyone encountered anything similar?
EDIT:
I have also tried to set the stream_context params (params: SSL context options):
$options['ssl']['verify_peer'] = false;
$options['ssl']['verify_peer_name'] = false;
$options['ssl']['allow_self_signed'] = true;
No luck, it still fails with the same error as pointed above.
Thanks.
PHP 5.6 introduces SSL certificate verification, so if your config is broken, it will fail with this error. You should fix your SSL, but you can revert to the old behaviour by setting the SMTPOptions property to not verify certificates:
$mail->SMTPOptions = array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false,
'allow_self_signed' => true
)
);
Editing the library defeats the entire point of libraries - and if you do as Kaf's answer suggests, your code will break when you upgrade. Really, don't do that.
Editor's note: disabling SSL verification has security implications. Without verification of the authenticity of SSL/HTTPS connections, a malicious attacker can impersonate a trusted endpoint (such as GitHub or some other remote Git host), and you'll be vulnerable to a Man-in-the-Middle Attack. Be sure you fully understand the security issues before using this as a solution.
I have the same problem. So i changed the file class.smtp.php in line 238:
public function connect($host, $port = null, $timeout = 30, $options = array()) {
if (count($options) == 0) {
$options['ssl'] = array('verify_peer' => false, 'verify_peer_name' => false, 'allow_self_signed' => true);
}
now it works fine!
Editor's note: disabling SSL verification has security implications. Without verification of the authenticity of SSL/HTTPS connections, a malicious attacker can impersonate a trusted endpoint (such as GitHub or some other remote Git host), and you'll be vulnerable to a Man-in-the-Middle Attack. Be sure you fully understand the security issues before using this as a solution.
I had the same problem. It turned out that my Postfix config was missing the intermediates and root certificates setting:
smtpd_tls_CAfile=/etc/ssl/certs/intermediate-root-bundle.crt
Even though this Postfix config has worked for years with Outlook and Thunderbird, PHP was more picky and failed the SSL check.
So even though you might be tempted to hack PHPMailer, please don't, and fix the underlying problem.
Just wanted to put my 2 cents in since I've been looking for a fix for days until I tried Kaf's solution and it worked!! Thanks #Kaf
Anyways... For me, PHPMailer was working fine until I decided to upgrade PHP to PHP5.6
Changes were made to open ssl in PHP 5.6. Here is the official docs:
http://php.net/manual/en/migration56.openssl.php
From the docs it says to set verify_peer and verify_peer_name to false
So just follow Kaf's answer and see if that works for you.
Editor's note: The doc also says this is not recommended! Disabling SSL verification has security implications. Without verification of the authenticity of SSL/HTTPS connections, a malicious attacker can impersonate a trusted endpoint (such as GitHub or some other remote Git host), and you'll be vulnerable to a Man-in-the-Middle Attack. Be sure you fully understand the security issues before using this as a solution.
If I use PHP's fopen() function to retrieve data from a HTTPS website, is that what one would call a secure HTTPS connection. i.e. Does it provide protection against man-in-the-middle and eavesdropping attacks?
Not by default, no.
It will always provide some form of protection against simple eavesdropping attacks as the data will always be encrypted (as long as the SSL server you are connecting to allows at least one encrypted cipher to be used - yes, null-encryption ciphers are allowed in HTTPS connections :roll-eyes:) However, by default, it will not protect against man-in-the-middle as it doesn't validate the server's certificates, therefore you cannot have any confidence that you have connected to the intended server.
Certificate validation can be switched on. To do so, you will need to provide a root certificate bundle and use the fourth argument to fopen that allows you to specify a stream context. The stream context allows you to modify the behaviour of the stream. The example below switches causes certificates to be validated against the root certificates in the specified bundle file.
$context = stream_context_create( array(
'ssl' => array(
'cafile' => 'ca_bundle.crt',
'verify_peer' => true
)
));
$file = fopen( $url, 'r', false, $context );