I haven't used an SSL certificate before and was curious to whether this is a Certificate issue or something I am doing incorrect.
I have purchased an SSL certificate which is running on my server. I am using Laravel 5. I am using the MCRYPT_RIJNDAEL_256 cipher.
In Google chrome is displays the following
Your connection to ... is encrypted with obsolete technology.
The connection is encrypted using AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism.
Is there something I need to change, or do I not need to worry about this?
10 days ago this question was answered here: https://security.stackexchange.com/questions/83831/google-chrome-your-connection-to-website-is-encrypted-with-obsolete-cryptograph
For "modern cryptography" you should use authenticated encryption. Google Chrome supports AES_128_GCM and CHACHA20_POLY1305.
Google is killing SHA1 as a certificate signature algorithm, not a message authentication code. Currently, when Chrome sees obsolete cryptography, its behaviour doesn't change.
#lukasgeiter actually hold the answer in the comments:
Google blog states:
Chrome will start the process of sunsetting SHA-1 (as used in certificate signatures for HTTPS) with Chrome 39 in November. HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.
In November 2014, code was checked into the chromium project that changes the messages shown in the Connection dialog.
Previously, the wording stated the bit level of the encryption of the connection, which could be misleading.
Now, Chrome will label the connection as modern if it is >= TLS 1.2 AND uses Forward Secrecy (e.g. ECDHE_RSA) AND an AEAD cipher (either AES-GCM or CHACHA20_POLY1305). Otherwise, it will be labeled as obsolete.
If you are able to configure the server yourself, and have determined you want to configure it to support a modern profile, Mozilla's SSL Configuration Generator is a good place to start.
See also Mozilla's Security/Server Side TLS wiki page for more information.
Related
I am currently managing two servers that have a shared secret key.
I would like to be able to send data between the servers in a manner that even if someone is listening in the middle, the data will be only read if someone has the secret key.
My requirements are:
encryption
authentication
But also:
freshness: so that old encrypted data that has been intercepted in
the past will not be accepted if transmitted now by someone else.
I was wondering if defuse/php-encryption is applicable to this scenario given that it provides encryption and authentication.
I also took a look at libsodium but I want to stay away from PECL if possible.
Thank you.
I would suggest that you use an existing cipher suite that can "blanket secure" the entire connection between the two parties. Then, in any case, use digital certificates (they can be self-signed ...) to secure the connection. (Do not use "shared secrets," a.k.a. "passwords.")
TLS (the successor to SSL) is used by HTTPS secure web-sites. (Be sure to use the current version of this protocol!)
VPN (as "OpenVPN" or "IPSec") provides "a secure router" between two subnets. The advantage of this strategy is that the two parties don't have to do anything to obtain a secure, reliable connection: it’s just there.
SSH is also able to do "tunneling," but it's too-easy (IMHO) for data to wind up actually being passed insecurely, and it really doesn't provide identity-verification.
These cipher suites will provide you with three very important guarantees:
The data is not intelligible to any other party.
There is no "man in the middle." The parties can identify exactly with whom they are communicating.
Messages received are known to be "exactly what the sender sent."
Nothing in-secure is passing "out of band" between the two parties.
... and yet, they operate completely "in the background," just as you routinely see TLS doing when you connect to a secure web-site. "It is secure, and 'it just works.'" It is very important that your scheme be unobtrusive to authorized users.
I currently use only payment buttons, and an IPN php script I got from https://github.com/paypal/ipn-code-samples that is dated Nov 10, 2014.
My script simply posts back to www.paypal.com without encryption.
Is encryption becoming mandatory ?
Your IPN listener will be responsible to recieve PayPal call-backs and POST them to PayPal for verification. On that point, connection between your server to PayPal endpoint will need encryption with SHA-2.
So literally yes, you would need to check your server key store / trust store and make sure it includes SHA-2 compatible certs.
You may refer to this PayPal microsite for detailed instructions, these information are open to merchants seeing any impact
You have to verify that your Server supports SHA-2 (SHA-256). Use of SSL with SHA-2 would be manditory.
Since Chrome is deprecating support for SHA-1 by the end of 2015, all PayPal support for SHA-1 will be deprecated by the end of 2016.
You can test your server compatibility here shaaa..
PayPal sandbox environment is supporting SHA2(SHA-256) only. You may make test in below link (need to login with your Live credential) to check if your server could deal with the upgrade now.
https://developer.paypal.com/developer/ipnSimulator/
If the test passes, that means your server is able to deal with SHA-2 and you do not need to upgrade the certificate any more. If it fails, please contact your server provider to help you upgrade the SSL certificate.
I'm not very used to oAuth or using SSL certificates and was just recently forced to look into it for put.io API access. oAuth seems complicated, some methods ever require the end user to fill out their credientials.
So I went to search for a ready made PHP lib that has the full put.io API implemented and noticed he used a method where not even the "application secret" or "client ID" was needed.
All I had to do was feed it my "Oauth Token" value and it connected with ssl vertifypeer and a cafile - StarFieldSecureCertificationAuthority.crt
Now the question I guess is what this certificate really does or proves, and if I can really use his - or if this is something I should generate myself for the target deployment server?
Suprisingly, Google didn't help much at all - and I have still no idea how this oAuth with a certificate works, why it works, and how I can make sure that it does work. Any pointers?
Presumption
I take it this is the "ready made PHP lib" you refer to? If you have a question on what some code does with some file, it's helpful to post a link to the code and even more helpful to post your breakdown of it. If you try to read the code, you'll get better Google terms, and clearer narrower more easily answered SO questions, that have a wider application for other future visitors: A question "What does some code do" is easier to answer and may be found by people in the future that search for the same function.
SSL certificates
It's hard to understand what some API code does with a certificate if we have no understanding of what certificates are for. So lets try to get ssl explained to us. If reading the explaining answer on security.stackexchange.com comes hard to you, youtube is the dyslexics best friend.
So now we know that certificates are used to confirm identity or, in other words, for authentication.
OAuth tokens
OAuth tokens are like car keys; a secret that grants access to a car. In your case the car is put.io (the Resource Server). Some cars have separate keys for starting it, opening the trunk and opening the glove compartment. Some tokens only grant access to some of all the Owners Resources.
Basic idea is here, that we shouldn't leave carkeys left in our care out in the open and we shouldn't stick them in just any car we see. Because it's pretty easy to make a device that looks like a car and reacts like a car, but in fact is a car key copier. Trust me, it's the next big thing after credit card skimming. So we need to confirm the identity of the car, before stick our keys in. We need to authenticate the car.
It's pretty easy to make a device that looks like put.io and reacts like put.io, but in fact is a man-in-the-middle that copies tokens. So we need to authenticate put.io before we send the precious token.
Authenticating put.io
That is where the SSL certificates come in. Without repeating what we learned from the SSL section, we know we should carefully check the authenticity of the server certificate we get from, what we believe is, put.io. We need to check if the signature on that certificate comes from an authority (a CA) we trust. To do that we need the certificate of the CA. Many operating systems and browsers come pre-packed with trusted CA certificates.
Just open https://put.io in your browser and look for the certificate. Often by (right) clicking some padlock icon and some click for more information. You'll see that it is issued by 'Starfield Technologies, Inc.'
Using StarFieldSecureCertificationAuthority.crt
Now in NativeEngine.php we see:
$context = stream_context_create($contextOptions);
The ssl options require either a cafile or a capath. The easiest way for the API maintainer to be cross-platform is supplying a cafile. OS package maintainers will likely patch this and exchange it with the capath to the CA files they supply in their OS.
Can you trust it?
Now if the API maintainer has created that crt himself, he can impersonate any server if you use it. Luckily, you can easily check the fingerprint and see if it corresponds with the one in your browser. You can export the one in your browser if it doesn't.
The OAuth token is what authenticates you against the put.io API. (As you can see in this example, where no additional CA certificate is used.)
The CA certificate and the VerifyPeer setting are there to protect the integrity of the connection between your application and put.io: The library uses it to verify that the server it connected to really is put.io's, before proceeding to submit the OAuth token. Your code should also work if you disable the verification; but then your application would be vulnerable to a MITM attack and an attacker could obtain your OAuth token – and would then have access to your put.io account. (The same technique is used in HTTPS. See this question at ISSE for further details on the verification process.)
Note that your solution works for now, but the put.io API documentation states that they might start to expire OAuth tokens in the future, so in the long term you should switch to a library which is able to obtain new tokens (there's a list in this question):
Although at this time we do not expire OAuth access tokens, you should be prepared for this possibility in the future. Also remember that a user may revoke access via the put.io settings page at any time. Using /authorize will ask the user to re-authenticate their identity and reauthorize your app while giving the user the option to login under a different account.
I have Php based Application. which works perfect with login and password. Now i want to implement authenticate using OpenSSL along with login and password.
I have generated the OpenSSL in Linux server and i have to use the generated openSSL.cert file as certificated. I installed that in my browser and my DNS is set with https so it should promte for certificate,
Now what i need is, When somebody tries to login wihtout certificate it should not now allow to login. I should check the certificated to authenticate the login.
Is they any way to do this or am i being more ambitious ?
if yes, How can i do this i php ?
Thanks all.
SSL uses Diffie-Hellman (or similar) key exchange to negotiate a connection meaning that the certificate is provided to any client that does not already have it. What you want to do is probably best done by using a license key file. Were I doing it I should create a hashed key using something company specific that only I knew and have the string passed across to authenticate. The benefit of it over preventing key exchange in SSL and sending out certificates is that the hashed string is easier to create on a per client basis. This means that you can uniquely identify a client easily and give specific limitation, such as an expiry time, by client.
i have client-server application (objective-c and php).
how can i encrypt data on client and then decrypt on server?
the simpler the better
The simplest way to encrypt data traveling over the network is going to be to simply always use TLS to connect to your server running your PHP app. You could verify a particular certificate from within your app if you're afraid of sophisticated man in the middle attacks, though that will make your app fail to work without an update when your certificate changes.
If you truly need encryption/decryption at the application level, not just transport, then you should probably use RSA public-key encryption. Your client will have the public key, your server will have the private key. Apple has documentation on RSA encryption.
Okay, rule number 1: DO NOT write your own cryptographic routines.
Given that, there are some standard cryptographic libraries available. OpenSSL is recommended in this SO article.
Use SSL/TLS protocol, OpenSLL have the implementation of both, check this tutorial, its in c but may be a good start to you.