Here's the situation:
I'm working on an open source web application (in PHP) that will be distributed to domain owners (abbit like WordPress).
Now I (my server) needs to communicate with my users (users server). I'm going to be using cURL to transfer data between servers (using POST).
The only problem is, I have a SSL certificate, but the users won't have one. So the users server will be able to talk to my server without some evil b***** eavesdropping, but my server will not be able to talk to my users server, securely.
And I certainly do not want to require users to purchase SSL certificates in order to use the application.
I was wondering if there is a way to get away with only using one SSL certificate and still manage to POST data to and from securely?
I'm also open to any alternative suggestions.
Thanks!
You can post a request to call your server back (and pass some unique ID of the data to be requested from your server), so that servers connect to your server as clients, pass the ID and get their information.
The question, though, is what you need the certificate for. If you want to authenticate those servers (or ensure that your data only reaches legitimate servers), then you need those servers to have valid certificates (BTW They are not called SSL certificates, the naming is wrong). Otherwise spoofing the server is easy.
Related
If run a Web application on a web server in one location and inside my php code I use OpenSSL to encrypt data, will the data be secured when transmitted to my SQL Server on my Server.
I am working on a Web application but it is being hosted on 3rd Party Web hosting Service but User Data is being Stored in SQL On my Personal Server. All Data will be encrypted Using OpenSSL on the web Server where web Server ask for the Users personal encryption key stored SQL One Time Per Session. I plan on Using a Second OpenSSL Encyption to Encrypt the User Encryption Keys. Users will also only be able to use the app via a Secured HTTPS Connection to Web Server.
I Just want to find out What I need to do to ensure User Data will be Secured to the Best of My Ablilities form mainly Man In Middle Attacks.
The Web Hosting Service is a Well Know Service with Secured Connections, I Will Have an upgraded SSL Certificate.
My SQL Server Will Only Except Connection from Web Server IP on a Non Standard SQL Port.
It sounds like you have the front-end encryption taken care of, but what you are asking about is the connection to the back-end, or your SQL server. You need to make sure that you are properly defining a secure connection as that is the default, BUT MySQL will drop down to an unsecured connection if there are any issues in that config (past auth, of course).
Here is a link to the MySQL doc page, https://dev.mysql.com/doc/refman/5.7/en/encrypted-connections.html
You should be able to get some info there more specific to how you are trying to configure your connection string and user account.
-Tango
Background : I am creating a website (in the typical LAMP environment) that connects to a database via a PHP/XML based API on a different domain (but on the same server). The reason for this is that I do not want to have database connection details sitting on the domain I am working on. In order for this to work I've enabled "allow-url-fopen" setting for that domain.
My question is, since this is the only way I know how to do this, does anyone know a better i.e. safer and more secure method of achieivng this result?
If both the domains reside on the same server you do not need to use HTTP to get connected to MySQL, you can still login to your MySQL server locally providing the right credentials for your domain where the connection information is stored.
But it does not really serve a great security purpose, as if your connection details reside even on the same domain it is not a security loop hole as your PHP pages will not be server in any raw form as long as your webserver is configured to use PHP fine. You can and probably should keep them on same domain. In fact having a publically accessible API for database connection is a bigger loophole
I have a JavaFX-2.2 application, that uses a webengine to load some php and html pages from a web server. My application and the web server are not in the same machine. My login php page uses a self-signed certificate. In my client side where the webengine is, i want to connect to that php using the client certificate which is signed by the same CA, as the server's certificate. I want with that way, only my application to have access to the servers pages.
I have read the webengine api but i have not found yet a way to do so. Also a google search returns a few lemmas .
Can i do that?
Thanks in advance
You may be able to add one but every time a visitor visits your site, it will show the "This site's security can not be trusted" page.
As I understand you want to use SSL authorization.
1. Your server signed as server.
2. Your application signed as client.
Only both sign can connect. No other servers, no other clients.
In that case you must integrate server public key in client. And client public key in server. (different API and methods use for it) almost all language and servers work fine with SSL authorization.
You can use Self signed keys, or you may generate free pair here: www.startssl.com
Is it possible to authenticate a web browser using an ssl certificate.
Say i store a private key in my application, is there any way to read a key from a browser and try to authenticate based on that?
You can authenticate a browser/user using SSL/TLS client-certificate authentication.
The client certificate must be requested by the server, so you'd need access to the server configuration (not just installing some PHP code on a shared server). This is done at the SSL/TLS layer (in fact, the mechanism is not specific to HTTPS): the server requests the client-certificate during the SSL/TLS handshake (sometimes via a renegotiated handshake). In Apache Httpd, this is typically done via SSLVerifyClient (although you'll need to specify other options too).
The server will then verify the certificate against the CAs you've configured it with (possibly your own, and possibly independent of the CAs used for the server certificate itself). (Alternatively, you could disable certificate verification at the server level in some cases, and have the PHP application do it, but this is a bit more advanced and you'd need to know what you're doing.)
You can access the client certificate from your application and obtains its Subject DN (or alternative names), to identify the client.
It's not clear whether you're after identifying a browser or a user. In the end, everything goes through the browser anyway, but client certificates tend to be allocated to users. Users would have to install that certificate into their browser.
EDIT: For further details, it would help if you could clarify your question and what you intend to do with this.
Is it possible to authenticate a web browser using an ssl certificate.
Say i store a private key in my application, is there any way to read
a key from a browser and try to authenticate based on that?
Firstly, strictly speaking, there's no such thing as an "SSL certificate", since multiple types of certificates can be used for SSL/TLS, and some of these same certificates can also be used for other purposes than SSL/TLS. Typically, "SSL certificate" means "X.509 certificate in the context of SSL/TLS".
Therefore, authenticating a web browser using an SSL certificate implies doing it at the SSL/TLS layer. (There have been attempts to implement message-level security using X.509 certificates at the HTTP layer, but they're not widely supported by browsers.)
Secondly, the private key is held by the remote party that you authenticate. The local party that authenticates the remote party doesn't see any private key. If you (as a server) want to authenticate a web browser, it's the browser that needs to have the private key, not your (presumably PHP) application. In this context, it's not quite clear why your (PHP?) application would have/need a private key if it's the browser that you want to authenticate.
What your verifying application may need (if it's not done by the server itself) is a CA certificate to be able to verify the client certificate it is presented with (or at least some form of trust anchors with which to verify the client certificate). There's no private key required here, just public keys and certificates, unless you want your application to be a CA too.
Indeed, you could have your application be a mini CA. It could make the browser generate a key-pair and send a certificate request to the server (there are mechanisms to have a web page make the browser do all that). Then the server would generate the certificate and make the browser import it back against its private key. Subsequently, the browser could use this certificate for authentication with that server (or other servers that would recognise these certificates).
No, you cannot do that.
There is some development going on, and a few day ago W3C has made a proposal for a encryption standard.
You can however put a key in a cookie and use that to identify. This is the default PHP session id behavior.
I have following scenario:
The Android clients communicate with a PHP server via HTTP Post. The PHP server is communicating with mySQL database and sends the output as JSON to the Android client.
Now I am concerned that people sniffing the traffic, find out the URL and will post a lot of grap in my database.
I have no concern of sniffing the payload. So it does not necessarily be encrypted.
I was thinking of TLS/SSL which comes in mind because of the HTTP connection. But I am not sure what is the prefered way to go in this scenario.
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. You can use the keytool included with the Android SDK for this purpose. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android, both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.
SSL won't help you, as the traffic can be sniffed before the data hits the wire, and people will STILL be able to figure out your API calls and fill the DB with crap.
You can "secure" the service with access tokens and username/password requirements. But again, they won't prevent a malicious user from flooding your system with bad data. However, it would let you track down WHICH user was doing so, as they'd have to be using a unique access token of some sort to get at your system.