This is just a general question regarding the debate between self-signed certificates and CA certificates...
I understand the benefits for a CA certificate due to the avoided warnings generated in most browsers, but how does a CA certificate benefit actual security? I commonly hear the biggest threat is man-in-the-middle attacks, and while I understand this threat using a self-signed certificate, I don't understand how a CA certificate prevents this. I know CAs perform their own security algorithms couldn't the same algorithms be used on self-signed certificates?
I guess I'm just a little irritated by the big business revolving around the need for CA certificates but can't seem to find anything different about them other then these supposed additional security checks they perform. Is there anything a CA can provide from a security point-of-view that self-signed certificates cannot?
Spoofing. If the other party fakes a self-signed certificate, you have no way to check this. In order to check that you have received the valid certificate and not a forged one, you need third-party check which can not be easily spoofed. This is done by carrying the list of root CA certificates (and some intermediate certificates) with your client-side software (Windows includes such certificates for you and major browsers do the same) and verifying the certificate you receive from the server using those CA certificates. With self-signed certificates such verification is not possible.
Of course, you can carry the self-signed certificate with your client application (and this is what some developers do, especially for in-house applications) but this doesn't work with browsers.
The difference isn't in the algorithm, it's in whether people trust the certificate authority or not.
The point of a certificate is to verify that you are making the connection with whoever it is that you intend to make the connection with.
If I say to you "I'm the right server, trust me on this", you may choose not to believe me (after all, you don't know me).
If I say to you "I'm the right server, and I have a certificate to prove it", you could say "ok, and who gave you this certificate?" If my reply is "Joe from around the corner", you may still choose not to believe me.
But if I say "I have a certificate, and you can confirm it with a third party that you trust", you may decide that this is a good proof of identity.
How you confirm it is what the standard is all about (e.g. as described in RFC 5280). But that's just technicalities. You could use the exact same algorithm for a certificate that originated from VeriSign and for a certificate you generate yourself.
The real question is about trust: do you trust whoever is giving you the "proof of identity". We trust VeriSign enough to allow any proof of identity from them to be accepted by every browser. Should we trust individuals that generate their own self-signed certificates? We might do in some cases (in which case you can install their certificates in your browser manually), but not as a general rule.
Related
I have done extensive research on this topic and my knowledge is still pretty ambiguous. I'm looking to get a basic DV for a simple site, but I see every SSL online has three levels, Root->Intermidiate (that acts as a proxy for the Root ) and a regular certificate i guess?
Here is Googles:
I see their Root is issued from GeoTrust but their intermediate is one of their own, so do you purchase the root separately or does it come with the purchase of an SSL? and Does the root create the intermediate thus signing the purchased SSL or? Some clarity would be nice..
It is very simple, when you order SSL certificate from vendor or Certificate Authority. CA will provide a zip file that contains root, intermediate and primary certificate. The reason behind to install root certificate is to avoid the browser warnings generally occurred while visiting website. You don’t need to order above mentioned certificate individually as it comes altogether.
The reason behind intermediate certificate is to create a chain of trust between browser of visitors and the web server. All three certificates should be copy and paste in a simple text file (check below example) and to be placed on server that will be used while installing the SSL later on. Hope this will clear your doubts.
Example:
—–BEGIN CERTIFICATE—–
(Primary certificate: yourdomain.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Intermediate certificate: ca.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Root certificate: root.crt)
—–END CERTIFICATE—–
A certificate serves two purposes:
Encrypt connection
Prove that the site owner is who claims to be
If we were just going to encrypt data any certificate would do (even a self-signed) but that's not enough in real life because we also need to ensure that we aren't connecting to a fake site (there's no point in keeping information secure and then deliver it to the bad guys) and that's where the trust chain concept comes in. In your example:
You have a certificate for www.google.com, but you can't really say whether it's genuine. After all, anyone can generate a cert for www.google.com.
Someone who claims to be Google guarantees that the above certificate is genuine, but you can't really say whether they are the real Google.
Someone who claims to be GeoTrust guarantees that the above certificate has been really issued to the real Google. But this time you trust GeoTrust because it is configured as root authority in your browser. Either it comes with the browser (and you trust your browser) or you installed the CA yourself (that's typical in Spain when you need to access government sites).
It's also worth noting that we could have an arbitrary number of levels, not necessarily three.
To sum up:
You don't own any certificate in the trust chain except the last one you've paid for.
The company you get the cert from should have already done all the paperwork to be part of the bundled CAs in major browsers (after all, they charge for the service). Otherwise, your site visitors will get an untrusted certificate error message because they won't have the root CA.
Optionally, you might need to download and install some additional intermediate certificates (but you still don't own them).
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've just recently learned a bit about how encrypted messages are sent across the Internet, and it seems that it relies a lot on "trusted third parties" My problem is that I don't trust anyone, is there some way to form an encrypted connection between two computers without prior secrets or the need to trust anyone?
Yes, by creating a "Certificate Authority" (CA) and installing its certificates on the machines.
The third parties you're talking about issue certificates, and sign those certificates using a CA certificate that is included in popular operating systems and/or web browsers. You can create your own CA certificate and install it onto the machines in question alongside those third party certificates. Then you can issue your own SSL certificates which will be recognised by those machines without any third party involvement.
Note that the CA certificates aren't "prior secrets" - there's nothing secret about the certificate itself. It has a private key, which you use to sign your SSL certificates, but that key doesn't need to be on the machines in question (and shouldn't be).
There are plenty of sites that will walk you through the process - a quick Google turned up this one for example: Creating Your Own SSL Certificate Authority.
I am working on a project that requires an ECDH key exchange. I am trying to understand how to protect against MITM attacks. I can sign the public key and send a signature along with the public key transfer to ensure that the key has not been tampered with but that doesn't stop a MITM attack from just doing the same thing. I understand that the key exchange must be verified somehow by a third party but I'm having a hard time understanding how it is that a third party can be the solution assuming that someone can do an MITM attack. Why couldn't they just do an MITM on the third party verification too? Is there really a fail proof way of completely eliminating all possible MITM attacks without some kind of pre-known by both parties?
You need a¹ trusted third party to sign both keys.
Without any knowledge or assertions about the identity of the intended partner, there's simply no way to distinguish him² from anyone else.
¹ one or multiple
² Bob
In a PKI system, "certifying authorities" are an important part of the infrastructure. Certifying authorities sign the public key and the identifying information, so that you know the corresponding private really belongs to the purported identity. This is true for EC keys just as it is for RSA.
By the way, I've looked for CAs that issue EC certificates, and apparently they aren't in practical use.
Most people obtain certificates for their certifying authorities as part of their operating system or security application. They trust these certificates implicitly. There are several dangers here, though.
First, most users don't have an effective way to verify the integrity of these certificates. This is a pretty hard problem, because, at the root of it, you have to have a 100% trustworthy channel for the verification—channel between the authority and the user with which an attacker cannot tamper. When a user downloads a new browser with an collection of root certificates, he can't know that the software wasn't tampered with in transit, or even built with a bogus CA certificate in the collection.
Even if the certificate collection is received intact as the provider intended, there have been questions raised about the integrity of many certifying authorities included by default in popular software. For example, some have pointed out that telecommunications companies in states that have been linked to terror sponsorship have their certificates included in popular browsers. Any trusted authority can issue a certificate for any domain name, and a browser will accept it without question.
In short, no, there is no way to establish a secure channel without first sharing some information on a secure channel. The benefit of PKI and asymmetric cryptography is that one exchange on a secure channel (the receipt of a trusted authority's certificate) permits the establishment of secure channels with many parties. But you have to bootstrap the system somehow.
It sounds like you are heading down a path of rolling your own crypto protocol. Don't do that. It's a bad idea. It leads to insecure systems.
Instead, use SSL or TLS. That is designed to take care of the subtle issues in designing this kind of crypto protocol -- and it has been well-vetted. You'll need a way to verify the other endpoint's certificate. You could use a certification authority, or in some cases it might be feasible to hardcode the public key of the entity you expect to talk to.
You may get better answers if you ask on the Crypto stack exchange.
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).