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?).
Related
I recently used node.js to create a HTTPS server. The certificate was created free from this website.
http://www.selfsignedcertificate.com/
The chrome browser always prompts with a message that the HTTPS website is not secure when using this self-signed certificate. I did some research on the net and it seems that proper certificates cost money. Is it possible to generate a certificate free of charge and accepted by browsers as secure?
No
Certificates are generally only trusted when they are signed by a highly-trusted Certificate Authority. This is what makes SSL Certificates work. If everyone could sign their own certificates, anyone could claim to be any server they wanted.
To get a (trusted) Certification Authority to sign your certificate, you will generally need to pay.
Good news for you. Go to this website https://letsencrypt.org/. It is in limited mode and offer free certificate.
https://letsencrypt.org/about/
Let’s Encrypt is a free, automated, and open certificate authority
(CA), run for the public’s benefit. Let’s Encrypt is a service
provided by the Internet Security Research Group (ISRG).
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)
I've been tasked with development of an intranet interface for command line software, and now I'm researching security options. Our command line application is finished, but I haven't started writing the web interface. I don't know exactly what the security requirements are for potential customers, although I believe ssh is generally acceptable for the command line interface. With this in mind, I'm asking for help developing a menu of choices with their associated pros/cons. Some day, we may consider releasing our web interface to the internet, so I'm willing to consider more security than currently necessary if it's easy and/or free.
I've been doing a lot of reading, and my tentative conclusion is that SSL security with no certificate is the best approach, not because less security is unacceptable, but because SSL is the standard and because it doesn't appear to be difficult to set up. I, a security non-expert, wouldn't need to explain why less security is acceptable to security non-experts. I could upgrade my application to use a certificate in the future if necessary.
Here's a list of SSL related security choices, sorted by my perception of security level with my comments. What level of protection do I need?
No SSL. This might be acceptable if our customers aren't worried about their employees seeing/changing each others' data. Their employees might want to share results with each other anyway, and I could use IP based access control and/or passwords for security.
Do SSL with no certificate. This encrypts the communication, which at least protects the data from being read by unauthorized employees. Using a password, this is the same level of security as ssh on the command line, right? I don't need to worry about man-in-the-middle attacks in an intranet, right? A con for this approach would be if there were loads of browser warning messages.
Do SSL with a self-signed certificate. What does this give me that no certificate gives me? If the DNS can be changed inappropriately, then the customer then my application is the least of their concerns. Worded another way, if the DNS can change, then I think ssh would be vulnerable too.
Do SSL with a local Certificate Authority. OpenSSL lets me make my own Certificate Authority. What does this give me that a self-signed certificate does not? I'm assuming that on a LAN, it's less important for the server to be verified.
Do SSL with an external Certificate Authority. Is there ever a reason to go this route for an intranet? I found some "intranet certificates" for sale online -- but it's not clear what they're offering I can't do myself.
For reference, this page might be useful for comparing certificates:
http://httpd.apache.org/docs/trunk/ssl/ssl_faq.html#aboutcerts
[update]
Here's an article discussing the risks and rules of obtaining an internal certificate from a public CA.
Yes, certificates are still useful for Intranet SSL.
There's an important difference between SSH and SSL-without-a-certificate: when you first connect to a server with SSH, your SSH stores the server's fingerprint. If you then try to connect to what the SSH client believes to be the same machine but gets back a different fingerprint, it alerts you that there might be someone intercepting your communications.
SSL-without-a-certificate, on the other hand, does not store the server's fingerprint. Your communications will still be encrypted, but if someone somehow hijacks the DNS server as you mentioned, or, as Rushyo notes, does ARP poisoning or something similar, they would be able to perform a man-in-the-middle attack. SSH, as previously mentioned, would (supposing you had connected to the correct server some time in the past) notice that the fingerprint had changed and alert you.
A self-signed certificate would be comparable in security to SSH. A man in the middle could generate their own self-signed certificate, but as long as your applications are configured to only accept that self-signed certificate, you should get an alert similar to that that SSH will give you.
A local certificate authority gives you security similar to self-signed certificates, but may be more scalable. Should you have multiple servers, each can have their own certificate, but a client only needs the top-level one to trust all of them. If a server is compromised, you can revoke its certificate rather than having to change every server's certificate.
I don't believe an external certificate authority has any advantages, other than possibly less configuration if your machines already have the certificate authority trusted.
Lastly, I don't know enough about two-factor authentication to evaluate it, but for most applications, SSL should be sufficient.
Disclaimer: I am not a security expert.
Do SSL with an external Certificate Authority. Is there ever a reason to go this route for an intranet? I found some "intranet certificates" for sale online -- but it's not clear what they're offering I can't do myself.
The benefit is that you don't need to learn how to setup your own Certificate Authority if you need to manage a decent number of certificates and/or machines. Such a certificate would already be trusted by all browsers without you needing to install your own certificates into the trusted store.
However, this is actually less secure because somebody could purchase a certificate for a different intranet and use it on your network. For this reason, SSL vendors no longer offer this service. For more information, see: https://www.godaddy.com/help/phasing-out-intranet-names-and-ip-addresses-in-ssls-6935
If you only have a very small intranet, then I would recommend using a self-signed certificate, and then just add each self-signed certificate to each computer's trusted store.
However, it quickly becomes impractical to install a new certificate on every computer in your intranet whenever you want to add a new computer. At this point, you want to setup your own Certificate Authority so that you only need to install a single CA certificate in each computer's trusted store.
I'm working on an app which uses NodeJS to (among other things) download some unencrypted PDF reports from the main website. Those resources are very much confidential so I need to make sure traffic is secured.
So from what I understand I need to buy and install an SSL certificate from a trusted CA and use https.request(...) in NodeJS to download the PDF files. But I have no idea how to ensure that the hosts file hasn't been tampered, or there's no on-going MITM attack, or even that the certificate is still valid, hadn't expired and is the one it has to be. How do I do this? Are there any config parameters?
Bonus if someone can please explain what prevents an attacker from buying an SSL certificate himself, host a local server with the same IP as the original site's external IP, and tamper a DNS's target to fool the user?
The idea is that you open the SSL connection, check the peer certificate, and only if it hasn't expired, is the one you expect, etc., do you proceed. Once you're happy that you're talking to who you should be talking to, SSL provides security against replays, men-in-the-middle, etc. HTTPs does a little bit of that for you by insisting that the certificate subject match the hostname you connected to. But most of it is up to you.
Whenever I see it being talked about, it sounds like one simply 'turns on' SSL and then all requests/responses to/from an online server are magically secure.
Is that right? Is SSL just about code - can I write two apps and make them communicate via SSL, or do you have to somehow register/certificate them externally?
Secure web pages are requested on port 443 instead of the normal port 80. The SSL protocol (plenty complicated in and of itself) is responsible for securing communication, and using the certificate information on both the SERVER and the BROWSER to authenticate the server as being who they say they are.
Generating an SSL certificate is easy. Generating one that is based on the information embedded in 99% of web browsers costs money. But the technical aspects are not different.
You see, there are organizations (Verisign, Globalsign, etc...) that have had their certificate authority information INCLUDED with browsers for many years. That way, when you visit a site that has a certificate that they produced (signed), your browser says:
"well, if Verisign trusts XYZ.com, and I trust Verisign, then I trust XYZ.com"
The process is easy:
Go to a competent SSL vendor, such as GlobalSign. Create a KEY and Certificate Request on the webserver. Use them (and your credit card) to buy a certificate. Install it on the server. Point the web-browser to HTTPS (port 443). The rest is done for you.
SSL is a protocol for encrypted communications over a TCP connection (or some other reliable scheme). The encryption uses public key encryption using X.509 certificates. SSL handles both privacy and trust. These are related: if you don't trust the server, you don't believe that the server hasn't handed out its private key to everyone in North America.
Thus, the client has to trust the server's certificate. For public sites, this is arranged via a hierarchy of certificate authorities, with the root authorities trusted, automatically, by browsers and things like the JRE's socket implementation.
Anyone can generate a self-signed certificate for a server, but then the client has to be manually configured to trust it.
SSL is not, in itself, a magic bullet that makes everything secure. Security has no such things.
SSL is, however, an already-designed, ready-to-use system for solving a common problem: secure stream communication over a network connection.
There are two things you need to do to secure your application with SSL:
Modify the application's code to use SSL.
Determine the certificate trust model (and deploy and configure the application respectively).
Other answers and documentation provide better answers to how to do each of these things than I could provide.
I'll throw caution to the wind and attempt to condense an enormous subject.
SSL attempts to solve two problems:
1) Authentication and hence trust i.e can the client trust the server and vice versa
2) Communication without eavesdropping
1) Is handled by means of an intermediary i.e a trusted 3rd party - these are called 'Root Certificate Authorities' ( or Root CAs ) examples include Verisign, RSA etc
If a company wants to authenticate users and more importantly if a user wants to authenticate the company's website it's connecting to i.e your bank then the Root CA issues the company a certificate which effectively says 'I the trusted Root CA verify that I trust that Company X are who they say they are and am issuing a certificate accordingly'. So you get a chain of trust i.e I trust the certificate from ACME Co because Root CA Verisign created and issued it.
2) Once the two parties have authenticated then the certificate ( typically X590 ) is used to form a secure connection using public/private key encryption.
Hopelessly simple and incomplete but hope that gives a rough idea
Yes and no. You should self-sign a certificate and test the site with SSL internally before deploying it with SSL, first of all. To make the public site secure under SSL, you will need to purchase a certificate from one of any number of certificate providers. Then you will have a certificate signed by a trusted third party, tied to your domain name, so that users' browsers won't complain that the certificate is invalid, etc. Turning SSL on is pretty much just flipping a switch, otherwise.
For the most part you need to buy and register a certificate externally.
You need to have your server certificate signed by a Certificate Authority (CA), for which they will charge you. The client needs to trust that CA and have a copy of the relevant CA public key. The client can then check that you are who you claim to be (including domain name (from DNS) and display name for https).
This is a good tutorial on how to create self signed certificates for Apache.
If you want to know how SSL works on either the Server or the Client, then I suggest Googling it. As you suspected, it is a ridiculesly complex procedure, with lots of communication between the client and server, a lot of very peculiar math, and tons of processing. There is also a lot of theory involved, several protocols and many different algorithms and encryption standards. It's quite incredible how changing http:// to https:// is so simple to the user, but results in so much work for both sides, and is so secure. To really understand it you need to take a security course (multiple courses to fully understand it), as the entire history of encryption goes into making your login to Gmail secure.
Turning on TLS (colloquially "SSL") does not make your site magically secure. You may still be vulnerable to application-level vulnerabilities like stack overflows, SQL injection, XSS, and CSRF.
As other answers have explained, TLS only protects against a man in the middle. Traffic between a client and a properly-configured TLS server cannot be intercepted or modified, and the client can reliably confirm the identity of the server by validating the X.509 certificate. This prevents an attacker from impersonating your TLS server.
SSL actually does two things:
Encrypts the communication so that an observer seeing the data stream will not be able to read the conversation.
Guarantees that you are talking to who you think you are talking to.
It is only for #2 that you need to get official certificates. If you only care to encrypt the communication without setting up a trust relationship, you can use self-signed certificates or you can use an algorithm that does not require certificates (i.e. Diffie-Hellman).