I have local server in my home, which runs website, which provides some service, thanks the use of PHP. Right now I'm using the HTTP protocol, which doesn't not provide security, due to the clear-text (the is a authentication service with username and password to access the protected page). I want to upgrade to HTTPS and of course I need to use the SSL. I know what is, so I know the differences between a self-certificate, and the one issued by a company. There are different kind of class. Because I don't want that my users/friends are alerted by the browser that the SSL certificate isn't trusted, I'm asking if there is some free trusted certificate for a non-domain web server (I use my static IP to let the user access the website). In case I bought a domain (it is very cheaper), can I have a free trusted certificate from someone ? Thank you.
Regarding SSL certificates for an IP address, see the linked SO thread: Is it possible to have SSL certificate for IP address, not domain name?
If you register a domain name for your site, then you can obtain a free SSL certificate from StartSSL (https://www.startssl.com/?app=1)
Related
So for some background, I've been hosting a website on Microsoft Azure ("https://..."), and finally got a custom domain, but this domain does not have an ssl certificate.
Is it "safe" (I'm no expert in cyber security, so I'm sure its not as safe as possible, but is it at least pretty safe) to send password and other information from the unsecured domain to the azure server, which is still secured?
I would always say every website should have SSL and you can use Let's Encrypt - Free SSL/TLS Certificates https://letsencrypt.org/ its free
If you're using a good reverse proxy, their SSL is the important one and should be CA verified. You can connect to them with self-signed.
Not sure of your exact query. Are you looking not to buy a certificate or use the default azure secure domain for your login section.
The former letsencrypt is an awesome solution for a free certifcate. You definitely dont want to send password un encrypted.
We have an website which is used to administrate users. There is one payment section on this website which we use to make payments for our clients with their CC. I would like to secure this section by using HTTPS. So the goal is to make the connection secure.
What type of certificate should we use? Is https://www.openssl.org/ a good solution for this? Any other option?
Do we need an dedicated IP for this domain?
Creating all of the certificates on your own will not instill confidence. If credit cards are involved, you should probably work with a well-known Certificate Authority in order to provide a trustworthy, signed certificate.
Otherwise, your customers will get warnings and errors telling them not to trust your service!
Most Certificate Authorities have tutorials on how to purchase their SSL products and use them to get a certificate for your site. Here is an example product from Symantec.
SSL (the 'S' in HTTPS) does not generally place any restrictions on how your IPs work. The SSL certificates are often issued to domains and/or hostnames. If the certificate is issued to "payments.mysite.com" it will theoretically work for any server that the DNS server resolves for "payments.mysite.com"
Self-signed SSL certificates are just as good/safe/secure as SSL certificates from trusted suppliers. But they have a down-side in that unless they are installed on the users machine the browser will give warnings, and/or not go to the page with the certificate without explicit approval from the user (Chrome does this).
So IF you are able to distribute the SSL to the users, or they are able to install it them selves, or they are willing to ignore warnings, then a self-signed certificate is a good choice. If these are not options you have then you need a trusted SSL certificate.
EDIT: If you need a dedicated IP is dependent on how you resolve the address to the site (dns?).
I have this web app that is served via https, and now it needs to use a websocket service that is served from another server. Chrome, Firefox and Internet Explorer complain right away that if the application is secure (https), then it is not allowed to connect to an insecure websocket service (ws:// URI). Strangely, Apple Safari doesn't complain so.
Well, fair enough, I assumed any globally trusted certificate would be fine to be installed at the websocket server side, to enable secure service (wss:// URI). However the company that maintains the socket server claims that they have to install there the very same certificate that secures my web application. I read in webs that the wss will not run with self-signed certificate, but nowhere that it must be the same certificate that the calling web site runs on.
Since we are talking sharing a certificate key file with 3rd party, I wanted to double check this. If my secure site runs at domain first.com, and the websocket server at IP address a.b.c.d, what kind of certificate should be installed on the websocket server to enable the communication? On one hand, that would be a kind of cross-site scripting, but perhaps the browser security model allows it, assuming the user knows what they want?
What I understand from above, the browser connects to your web application and is then redirected to the other server. If that be the case, then browser would complain about being redirected to unsecured site from a secured URL. The way forward actually depends on the domain of the server that the redirect is happening to, for example, if your main site has URL form www.mainsite.com and the target site has URL form abc.secondsite.com or an IP, the second server must have configured an SSL certificate that has been issued to either abc.secondsite.com of the IP i.e. the name of the host requested must match exactly with the SSL ceritficate that is provided by the secondsite.
The secondsite technically does not have to have the same certificate as your mainsite, it just have to be a certificate issued by a trusted source (like Verisign etc.).
On the other hand, if you have a wildcard subdomain certificate i.e. a certificate issues is valid for all the *.mainsite.com domains and the URL form of the secondsite is sub_domain.mainsite.com, then the same certificate can be used on both the servers.
Hope this helps.
thanks
Since we are talking sharing a certificate key file with 3rd party, I
wanted to double check this. If my secure site runs at domain
first.com, and the websocket server at IP address a.b.c.d, what kind
of certificate should be installed on the websocket server to enable
the communication? On one hand, that would be a kind of cross-site
scripting, but perhaps the browser security model allows it, assuming
the user knows what they want?
You cannot provide a certificate for an IP address. In order to use WSS:// you need to connect to a domain name, and have a valid certificate for that domain name. So you need a SSL certificate for the domain name of your WebSocket server.
As far as I know, it does not need to be the same than the one on the site. You can check by entering here: http://vtortola.github.io/ng-terminal-emulator/ and executing the command websocket wss://echo.websocket.org, you will connect to a WebSocket in websocket.org that echoes your inputs.
WebSockets are not constrained by the SOP (Same Origin Policy), you can connect anywhere, and the server is responsible of checking the HTTP request header "Origin" and accept or refuse the connection.
Is it possible to spoof or impersonate a server's IP?
So that clients wanting to connect to that Server's IP, would actually connect to the attacker's machine?
But the attacker would still be able to contact the actual server.
This is all TCP/IP based, no name resolution, and all machines are on the same network or the internet (No NAT-ing).
I am working on a networking application, and I would like to build in some authentication.
What I need to do is to authenticate the server by IP. In other words, I want to make sure that when I open a HTTPS URL to an IP Address, it will go to the machine that has that IP.
Other notes:
All communication would be over TLS, but certificates would be blindly accepted.
What I need to do is to authenticate the server by IP. In other words, I want to make sure that when I open a HTTPS URL to an IP Address, it will go to the machine that has that IP.
This is one of the features of HTTPS (SSL/TLS) - it can prevent a MITM attack and prevent the destination server from being impersonated.
Other notes: All communication would be over TLS, but certificates would be blindly accepted.
This is great, however you will need to stop certificates from being blindly accepted. You should check that the common name or subject of the certificate matches the server that you are expecting to make contact with. You should also check that the root certificate is one that you choose to trust (you could make your own root certificate that is trusted). This will prevent the server certificate being spoofed by an attacker as they will not be able to sign the certificate with the root certificate.
An alternative is certificate pinning. This will enable your application to only communicate with a pre-set list of trusted certificates that are either hard coded into your application, or that are otherwise inaccessible to outsiders on your application server.
Yes, if you can perform man-in-the-middle attack. Evil transparent proxy in your LAN can do it.
One great advantage of using Azure Websites is that I can get secure HTTP (HTTPS) without doing nothing: I simply type https://xyz.azurewebsites.net and it works. I don't have to worry about certificates because I use the subdomain that Azure gives me (in the example it would be xyz)
So, what I usually do is that people come by through some registered domain I have, eg. http://www.my-application-homepage.com, and there, if they want to use my application, I redirect them to the subdomain at azurewebsites.net, using HTTPS.
Now, having said that:
I'm in need of upgrading to Azure Cloud Services or Azure Virtual Machines, because these have capabilities that Azure Websites don't . These two also offer a free subdomain: xyz.cloudapp.net, but my question is: will I get HTTPS there too? and how?
I searched in google for some cloudapp examples and what I tested was the following:
1) Connect through HTTP (ie. type http://xyz.cloudapp.net). Result: worked
2) Connect through HTTPS (ie. type https://xyz.cloudapp.net). Result: didn't work (chrome gave ERR_CONNECTION_TIMED_OUT)
No. HTTPS is not offered for .cloudapp.net domain as of today. Also since you don't own .cloudapp.net domain, I don't think you can buy a SSL certificate for that. If you want you could create a self-signed certificate and use that.
I would walk through the documentation listed here:
http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/
Since you're getting a timeout with HTTPS (rather than a certificate error), check that you have a HTTPS endpoint defined in ServiceDefinition.csdef.
Additionally, be aware that the redirect-to-subdomain approach isn't much more secure than using a self-signed certificate. The reason browsers reject self-signed certs is that they are vulnerable to spoofing attacks: a user can't detect if an attacker has, for example, hijacked the DNS to point to his IP address instead of yours, where he hosts a facade of your site that just collects passwords or whatever.
In your scenario, the cloned site could redirect to another a second clone, one that is a facade of your cloudapp.net site. It could be even be secured with the attacker's SSL certificate. Unless the user was trained to recognize the host name of the real cloudapp.net, she wouldn't know she was on the attacker's "secure" site.
** Update: This method is not valid as well, we got the certificate revoked after one week using it **
We use this approach for staging/dev servers:
If you don't want to use a self-signed certificate, one option is to purchase a cheap SSL certificate, e.g.:
https://www.ssls.com/comodo-ssl-certificates/positivessl.html
Then once you need to approve it you have to ask support to change the approver validation process: instead of sending an email to a admin#mydomain.cloudapp.net you can ask to change the validation process to placing a given file with a given file in the root of your website (you have to ask in the support / chat room about that option).
More info:
https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/791/16/alternative-methods-of-domain-control-validation-dcv