We have 2 Rails app (one for front end and other for backend(api) hosted on 2 different servers. User comes to our front end app and fills the order form. We then send json request to backend and backend send confirmation json response to front end. Backend is only accessible from our office address and is setup to communicate to only our front end app.
Today we purchased EV ssl certificate for our front end app from DigiCert and everything is work fine. But since we don't have ssl certificate on backend, does that means that what ever data we are passing from our front end to backend will be unencrypted?
Do we need ssl certificate for both front end and back end servers?
Our backend only servers request to our front end app and no other clients are connect to our backend? So can I use a self-signed or cheap SSL certificate for backend?
Or shall I buy another ssl certificate from DigiCert? (bit expensive)
I have already gone through couple of stack overflow questions, and looks like suggestion is to install ssl in both servers. This is my first time trying to set up ssl certificates on servers, so just want to double check before I buy another ssl certificate for our backend app.
Update
I found few cheap ssl certificate provides, what are people suggestions towards cheaper provider like this one https://cheapsslsecurity.com.au/
SSL only encrypts data between the server and the client.
It does not make a server secure.
It only prevents sending unencrypted data over the all the little hops that data makes between client and server.
Your back-end may be in a completely separate geo location or in the the server farm next door. But, it still may travel through several routers to get there. Without SSL, the data is sent in the raw. I have a few servers, some in a different rack with the same host, and some are hundreds of miles apart. Going from rack to rack in the same geo loaction still requires hops over various routers -assuming no VPN. So, yes, if you are very paranoid and do not have a VPN between the front end and back-end, then secure the back-end. But all this does is encrypt the data between the two. It does not make a server 'secure'.
What does this mean? Asuming your back end has no http presence (not discoverable on the web) then SSL on the backend is probably overkill. Why? Becaue the only people who know it exists are employees - and no amount of SSL is gonna protect the server from anyone who knows it exists or how to access it.
Neither will SSL protect you against other attacks such as SQL Injection. For example, the Equifax breach which Equifax claim was a bug in Apache Struts (although my guess is that there was more to that than meets the eye).
SSL is a band-aid on a flawed system. It does not make a server secure. All it does is encrypt data between the server and the client.
Yes, you will need SSL for your backend. that is the important place where all the logic and data is being stored. On the front-end not so important, but if you are tackling with payment or any other confidential information yes, you do need it in front-end.
Risk of Using Self-Signed on Public Sites
The security warnings associated with self-signed SSL Certificates
drive away potential clients for fear that the website does not secure
their credentials. Both brand reputation and customer trust are
damaged.
I will totally agree with this article, not to use self-signed SSL, especially when dealing with payment. For internal testing, you may. But while in production, highly recommended not to use it. Instead go with SSLs that are with Certificate Authority
Ref: https://www.thawte.com/ssl/
Related
I was studying Websockets (wss) and I am a little confused about their use of SSL. I hope some of you will be able to clarify some things that cause the most confusion to me.
Use scenario
Let's say I have an HTTPS secured website with a certificate signed by CA. I would like to communicate with a custom app in real-time (using the WebSockets) running on an external server that is not using the same domain (the site is for example www.mysite.com and the server is www.notmysite.com).
The confusion part
When the WebSocket client (wss) is connecting to the remote server, what SSL certificate does it use? Is it of the origin website, or of the server it is trying to connect to?
Given the scenario, can a connection be established with a single-domain SSL certificate - only for the website (www.mysite.com) where we know the private key and therefore we should be able to decrypt the encrypted data?
If question no. 2 is false, would multi-domain certificate containing both urls fix the problem?
The background story
I was trying to make a WebSocket server in .NET C#. I managed to get it working with HTTP however when I tried the code on HTTPS secured website I was presented with an encrypted text I could not really work with. That is why I bought an SSL certificate and put it on the website thinking that if I have the private key I can decrypt the data and communicate with the client (basically question no.2). Though I was only presented with different errors regarding cryptography. I was trying to figure this out for over a week and my progress and frustration can be seen in my other questions such as:
C# RSA decrypt parameter is incorrect and
AuthenticateAsServer() error
Then I figured out I may need to look at it from a different point and that's when I came up with this theory. I hope some of you will be able to end my suffering with an explanation of why what I did was wrong. I appreciate any help. Thank you very much.
I am not 100% sure if the multi-domain SSL certificate solved this issue since I combined it with using a premade library (WebsocketsSharp) which along with the new multi-domain certificate works perfectly. In my opinion, the multi-domain certificate is needed if you want to communicate between two different servers (either website and server or two servers).
I hope I will save some future headaches.
I have a website that run under a H2O Proxy, let's call it A server. The backend is WordPress site running with EasyEngine script, let's call it B server.
Now it running like this:
User --(Let's Encrypt SSL)--> A (H2O Proxy) --(self-signed SSL)--> B (nginx backend).
I wonder if attackers know my backend's IP address, so can he decrypt or do harmful thing or see what user send to proxy? And how to setup a better strategy?
I have thought to setup Let's Encrypt SSL from A server to B server too. But I think the problem will occur when Let's Encrypt can only renew certificate on A server because the domain is pointing to A's IP address. And the backend (B server) can't renew it.
Found this answer but I don't really know how to do it: https://serverfault.com/a/735977.
It sounds like what you're trying to do is to put LetsEncrypt into as many places as possible, possibly facing the issues of not having the desired Fully-Qualified-Domain-Name for the applicable backend on the backend itself in order to get the certificate, especially for automated renewal.
But the whole and only purpose of LetsEncrypt is that it gives you certificates that would expectedly be recognised by all the major browsers, such that the users would not have to manually verify and install your certificate into their respective cacert.pem.
But if you just need a secure connection between your own backend and front-end server, then you're not facing the same issue; as such, using LetsEncrypt provides little, if any, extra protections. What you have to do is use something like proxy_ssl_trusted_certificate, together with proxy_ssl_verify, both on the front-end, to pin the backend's certificate and/or certificate authority on the front-end, which will be an order of magnitude more secure (due to the pinning) than using LetsEncrypt on the backend.
Background:
Imagine a website, visible to the world, https://www.example.com, with a static IP address, 1.1.1.1. This site is hosted in an Apache server and it already possess an SSL Server Certificate.
On the other hand, inside a protected internal network, not visible to the world, a server (https://www.myinternalserver.com), with a static IP address (2.2.2.2), also running Apache, runs some internal web-based applications.
A static IP address (3.3.3.3), that maps to a subdomain (myapps) of the external site (https://myapps.example.com) serves as an entry point to the server where the internal web-based applications reside.
A firewall that protects the internal network does the redirect/proxying so all external traffic going to 3.3.3.3 is redirected internally to 2.2.2.2.
The firewall also limits all external traffic so any calls going to 3.3.3.3 must have been originated at 1.1.1.1, in essence, making the external website (https://www.example.com) the only authorized caller to the internal server (https://www.myinternalserver.com).
Scenario
With this infrastructure in place, I can make REST calls from the external website into the internal network and send back data to use in the pages. So, in this scenario, the external site is the client and the internal application, the server.
Question:
But beyond that, I want the server in the internal network to issue an "SSL Client Certificate" that would be "installed" (I don't know if this is the correct term), in the external website so all calls from the external site would have to be authenticated against this certificate.
How do I accomplish this?
Breaking the question:
I know that the question above is very broad, so let me try to break it into three (not so) "smaller" questions:
1 - How to I create the key/certificate? Using OPENSSL and some online recipes (this is one of them: http://www.impetus.us/~rjmooney/projects/misc/clientcertauth.html), I was able to generate the certificate file and learned (or so I believe) what I have to do with it and what to change in the httpd.conf file. In any case, I would like to feel more secure about what I have done so any suggestions/guidance here would be highly appreciated. For example, is the recipe I used any good?
2 - How to "install/transfer" this certificate to the external site? Do I simply copy/send one of the files created when generating the certificate? If so, which one? Where specifically does it go in the client server (external site)? Do they have to do anything at their end? If not, what is the process? I tried to contact the hosting company but I don't know if Icouldn't explain it to them or if they don't have experience with "SSL Client Certificate". All they told me is that there's already an SSL Certificate installed (SSL Server Certificate). They don't even seem to know what a "SSL Client Certificate" is.
3 - Once the certificate in place, what can I do to guarantee that ALL calls to the internal server, by default, come with the Certificate, without the need to code it into each API I create? I know very little about certificates so it might be possible that it happens "by default" always, but I read online about certificates that are "embedded" in the header of the API call, so I just want to be sure.
Thank you.
After some more research, this is what I found...
1 - How do I create the key/certificate?
I had to try other recipes and use a combination of them to get what I wanted. What I learned is that I have to create a certificate (CA Certificate) first, and generate the Server and Client certificates based on that first one. So look for recipes that encompass all three certificates: CA, Server, Client.
2 - How to install/transfer this certificate to the external site?
Actually you simply copy the necessary ones (client/CA) to a safe place in your share of the external site. A place outside the "www" tree.
3 - Once the certificate in place, what can I do to guarantee that ALL calls...
Well, here is what I did.
I "objectified my API call using php/libcURL and place it too, outside the "www" tree. For any developer in my site to use it, all they have to do is create an instance of the object and make the call by passing the URL as a parameter. In other words, you don't install the certificate. Instead, you make a call to the certificates each time you make a call to the internal server.
I hope it helps someone out there.
I'm trying to figure out the best way to send info back and forth between my server and another company's server. Basically, the other company processes the sales of my software, then goes to my server to activate the software. My software hits my server every time it loads to get the activated license. My server is blocked from external SQL queries (won't run queries from the other companies server), so I somehow have to pass data back and forth with their server.
Being new to this kind of thing, I'm looking for opinions on how best to do this regarding how to do this securely (I already know how to write code). For example, is an encrypted GET request sufficient where I can just decrypt info passing in a link? SSL with data in XML? I appreciate any thoughts and direction you can give.
Thanks in advance!
It sounds like you can put up a web or web services server? Have your server only accept connections by HTTPS, and require client authentication. Have the other company's server contact your server using HTTPS with a POST request.
Your server will need to present an SSL certificate that the other company's server recognizes as authentic - either you need to get a certificate issued from a CA, or you can create a self signed certificate and have the other company install that certificate in their server's trust store. The other company will also need to present an SSL certificate that your server recognizes - in this case, it should be a self signed certificate that you install in your trust store, so you aren't accepting connections from just anyone who has a CA issued certificate.
Your software can contact your server with an HTTPS GET request. The certificate requirements for your client software will be the same as for the other company's server, as described above.
This arrangement will prevent (a) anyone from impersonating your server, (b) anyone from impersonating your partner's server when posting to your server, (c ) anyone from eavesdropping on your client software's connections to your server and getting their user keys that way.
I have a client that needs SSL to protect online donations, but I have limited experience with how/when to use SSL.
I understand that in purchasing a certificate that I am assigning that certificate to an entire domain (IP address really). Is there a way to isolate the encryption to only a single page of the website, or should I just go ahead and secure the entire site even though only one page needs it?
Unsure of best practice here. Please advise.
SSL incurs quite a bit of extra processing time. For low bandwidth sites, the extra processing required by SSL is not really noticeable. But for sites with heavy traffic like Facebook, Twitter and Flickr, the load caused by SSL is heavy enough that they would have to use dedicated SSL encoding/decoding hardware.
So basically yes, it makes sense to minimize the number of pages using SSL. That is why you often see banking sites only protect the actual account pages via https. The home/landing page is usually plain old http.
On the other hand, unless you really are a site like Twitter or Facebook or Gmail, worrying about this is a bit of a premature optimization. First do it simple if you can. Be aware of this issue and be aware of upgrade strategies when your site finally get heavy traffic.
My boss has a saying:
This is a happy problem to have. First solve the sad problem of
not having enough users then you'd be happy to have a problem that
requires you to refactor your architecture.
You don't encrypt a website with SSL. you encrypt the connection. Therefore if you have SSL enabled for the webserver simply adding https:// to the url will encrypt the connection and whatever page the url points to will be encrypted while in transit.
so
https://www.website.com/index.html is encrypted and http://www.website.com/index.html is NOT encrypted
I prefer for that to never happen so I always put my encrypted pages in a subdomain eg.
https://secure.website.com/index.html
SSL comes with a couple of gotcha's
1/ a basic SSL certificate will only be valid for a specific domain name so if the certificate for is www.website.com and someone follows a link for website.com a warning will be displayed. (see note below)
2/ SSL requires a dedicated IP (which you appear to have). that means you may have problems if you are on a shared platform. this is because in HTTP the host or domain name is part of the headers but the headers are encrypted so the server can't know where to route the request to. (see note below)
It sounds like you really need to employ the services of someone familiar with ecommerce and SSL to help you. navigating the minefield with limited knowledge and forum responses is not the safest thing to do. especially if financial transactions are taking place because there are other requirements that must be considered such as the legal requirements in storing and using financial information such as credit card numbers.
DC
Addendum:
For donations consider Paypal. They have a complete donation solution and more people will trust it than a roll your own solution.
EDIT 2016:
The world moves on and some of the advice above is not as true as it was when originally answered.
SSL no longer requires a dedicated IP address. SNI (Server name indication) resolves that and is almost universal now (IE8 on winXP does not support it and a few phones).
You will find most certificate vendors now include the main domain name as a SAN (subject alternative name) in a certificate. Which is to say they will provide a certificate for both www.website.moc and website.moc if you get a certificate for www.website.moc. Do not assume this, make sure your certification authority specifies it.
also, you mentioned that an SSL certificate protects an IP address. This is incorrect. An SSL certificate corresponds to a domain. Many schemes exist where several domains share a single IP address. If one of these shared domains has an SSL certificate, that certificate is only good for that domain, not the others.
Cookie security is the main thing that I'd point to for your approach.
A user that logs in on your secure login page gets a cookie for their session, right? That cookie's then being transmitted in plain text for someone watching the wire (Firesheep) to intercept and steal the session.
There is additional overhead in terms of negotiation time and CPU load from SSL, but it's rather minimal. If there's anything sensitive going on on your site, just use SSL everywhere.
The other answers are inaccurate in this regard: An SSL certificate binds to BOTH a dedicated IP address that is assigned to a static single domain name, unless you purchase a wild card SSL. Both the domain name and IP must match the certificate.