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.
Related
I'm getting crazy with SSL certificates. After trying from lots of different providers I finally got one using SSL for free.
But there's one thing that I haven't understood yet.
Do I have to upload my certificate on my Domain provider (such as Register.it) or on my Host service (such as 000webhost or InfinityFree)?
The problem is that 000webhost offers a better service but not the possibility to upload an SSL certificate on a free plan, while InfinityFree (which offers a worse service) does.
I have the possibility to upload my certificate on the Domain provider (Register.it), but I can't understand if it works or it is overridden by InfinityFree one, and I have difficulties in trying switching from Host to Host because of the really slow DNS propagation.
Sorry if I made confusion, but it was to explain better my situation... My question remains one: Do I have to upload my certificate on my Domain provider or on my Host service?
You need to upload ssl certificate to your hosting. SSL for free is a Let's Encrypt certificate.
You can check which provider ssl running on your domain.
Step:
Tab your browser green lock icon then details
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.
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/
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.
im using silverlight 5 and WCF .. and the site is secured with HTTPS . however if i use fiddler , i can see this in the headers:
GET /ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
if i put that directly after my domain : https://www.mydom.com/ClientBin/XXXX-Web-MyService.svc/binary/GetUsers
it will download all data from tabel users. how can i hide and protect this information from being visible!! isn't using SSL enought ? why is this visible anyways if im using https!?
thank you.
EDIT: my initial question was kind of an 'uneducated' one and for that i apologies,
i found more info on the subject and did more research. in this Q on SO there is an explanation to why fiddler is able to decrypt and view requests and responses sent over https.
What is point of SSL if fiddler 2 can decrypt all calls over HTTPS?
and to make things even more difficult, the common solution to this problem is using
"Certificate Pinning"
which requires the use of System.Net.ServicePointManager which is not included in the silverlight implementation of System.Net namespace.
so here i am stuck with an SSL cert. that i paid for that can be "cracked" by anyone with basic knowledge of web debugging.
From a purely Theoretical Computer Science point of view, what you are asking for is near impossible to actually impossible. You would need to implement a trusted platform to protect against the attack.
Now for the Science bit, Concentrate
Okay, so lets start with some basic theory. SSL and thus by extension HTTPS solves a very very specific problem. How do you communicate information over an unsecure NETWORK confidential information with a party you have never communicated with before. In this case, the emphasis is on NETWORK. It does so by solving two problems,
Authentication of the server (the server is who it says it is)
Asymmetric Encryption of key exchange
There is some overlap, to ensure that this is one step. I will focus on the 1st, as this is where fiddler "attacks" your system.
The SSL authentication works on a concept of a web of trust. Your computer has a list of TRUSTED verifiers. These are companies like Verisign, Thawte, Geotrust etc. These companies verify certificates by signing them (complex asymmetric encryption term, but its very like a handwritten signature, hard to forge, easy to verify).
Fiddler works by inserting a new trusted CA (verifier) into your computer. From then on, when you visit an HTTPS site, it will send requests on your behalf, reads it then forwards it back on to you with its OWN SIGNATURE. Since your computer completely trusts this signature, it thinks nothing is wrong.
Now, you want to implement certificate pinning. This IMHO is "bloody awful". It works by telling your software to expect a specific SSL cert. Two reasons why this is bad.
If I can work Fiddler, I can work dotPeek and recompile WITHOUT certificate pinning.
When your certificate gets revoked, your clients won't be able to connect.
Why would your certificate be revoked? If your CA loses their private keys, then they will be obliged to make sure its revoked and a replacement sent to you. Also each and every certificate has a sell by date as well, and must be replaced before they start to smell.
So finally what can you do?
SSL is NOT designed for protecting against what you are doing on your machine. The simpliest way to do what you are asking is to simply wrap your WCF calls in an extra layer of symmetric (or even asymmetric) encryption. But once again. The keys must live somewhere, so your client WILL be able to get the keys from a simple disassemble of your binaries and be able to construct a proxy of their own.
In conclusion
This is pretty much exactly the same as the DRM problem. You want to give your customer access to something on their machine but not show them how it works. If you do manage to solve this problem, do post a follow up, since Sony, Nintendo and Microsoft (to name a few) would be very interested in your findings.