I have a short question: why do I need a SSL certificate (I mean only the certificate not the SSL connection)?
In my case Google Chrome deteced, that the connection is encrypted and secure, but everything is red because I created the certificate by myself.
Why I need a SSL certificate, if the connection is secure?
Just because traffic to 192.168.xxx.xxx doesn't leave the boundary of your network doesn't mean that it's safe.
Especially if you have BYODs attached to the network (and even if not, you don't want to be a hard shell with a juicy interior), someone can bring a compromised laptop or phone, attach it to the network, and a virus can intercept everything going on the network (see firesheep).
So you have to assume that the network is malicious - treat your LAN as if it were the internet.
So now the question goes back - why can't I rely on a self-signed certificate (both on a local network as well as the internet)?
Well, what are you protecting against? TLS (SSL) protects against two things:
Interception - even if I MITM you (I become your router), I can't read what you're sending and receiving (so I can't read your Credit Card numbers or password)
Spoofing - I can't inject code between you and the server.
So how does it work?
I connect to the server and get a certificate signed by a CA. This CA is considered trusted by the browser (they have to go through all kinds of audits to get that trust, and they get evicted if they break it). They verify that you control the server and then sign your public key.
So when the client gets the signed public key from the server, he knows he's going to encrypt a message that only the destination server can decrypt, as the MITM wouldn't be able to substitute his own public key for the server's (his public key wouldn't be signed by a CA).
Now you can communicate securely with the server.
What would happen if the browser would accept any SSL cert (self signed)?
Remember how the browser can tell the official cert from a fake MITM cert? By being signed by a CA. If there's no CA, there's literally no way for the browser to know if it's talking to the official server or a MITM.
So self-signed certs are a big no-no.
What you can do, though, is you can generate a cert and make it a "root" cert (practically, start your own CA for your internal computers). You can then load it into your browsers CA store and you'll be able to communicate through SSL without having to go through something like letsencrypt (which, by the way, is how enterprise network monitoring tools work).
In cryptography, a certificate authority or certification authority
(CA) is an entity that issues digital certificates. A digital
certificate certifies the ownership of a public key by the named
subject of the certificate. This allows others (relying parties) to
rely upon signatures or on assertions made about the private key that
corresponds to the certified public key. A CA acts as a trusted third
party—trusted both by the subject (owner) of the certificate and by
the party relying upon the certificate. The format of these
certificates is specified by the X.509 standard.
(from https://en.wikipedia.org/wiki/Certificate_authority)
You are not a trusted CA. Basically, if you sign your own certificate then there is no one that is able to vouch that the server is truly what it is. If you had a valid, trusted third party vouch for you then the certificate would be "valid."
Having a self-signed certificate doesn't necessarily mean that the website is dangerous, its just that the identity of the server can't be verified and thus it is more risky for the vistor.
Self-created or Self Signing Certificate are not trusted by all browsers. As we know at this time all browsers are more strict towards security. Let’s be clear about something right up front, the browsers do not trust you. Period.
It may seem harsh but it’s just a fact, browsers’ jobs are to surf the internet while protecting their users and that requires them to be skeptical of everyone or everything.
The browsers do, however, trust a small set of recognized Certificate Authorities. This is because those CA’s follow certain guidelines, make available certain information are regular partners with the browsers. There’s even a forum, called the CA/B forum, where the CA’s and Browsers meet to discuss baseline requirements and new rules that all CA’s must abide to continue being recognized.
It’s highly regulated.
And you are not a part of the CA/B forum.
The better option is to obtain an SSL Certificate from a trusted certificate authority.
Here's what you need to know about a Self Signed SSL Certificate
Related
What is the series of steps needed to securely verify a ssl certificate? My (very limited) understanding is that when you visit an https site, the server sends a certificate to the client (the browser) and the browser gets the certificate's issuer information from that certificate, then uses that to contact the issuerer, and somehow compares certificates for validity.
How exactly is this done?
What about the process makes it immune to man-in-the-middle attacks?
What prevents some random person from setting up their own verification service to use in man-in-the-middle attacks, so everything "looks" secure?
Here is a very simplified explanation:
Your web browser downloads the web server's certificate, which contains the public key of the web server. This certificate is signed with the private key of a trusted certificate authority.
Your web browser comes installed with the public keys of all of the major certificate authorities. It uses this public key to verify that the web server's certificate was indeed signed by the trusted certificate authority.
The certificate contains the domain name and/or ip address of the web server. Your web browser confirms with the certificate authority that the address listed in the certificate is the one to which it has an open connection.
Your web browser generates a shared symmetric key which will be used to encrypt the HTTP traffic on this connection; this is much more efficient than using public/private key encryption for everything. Your browser encrypts the symmetric key with the public key of the web server then sends it back, thus ensuring that only the web server can decrypt it, since only the web server has its private key.
Note that the certificate authority (CA) is essential to preventing man-in-the-middle attacks. However, even an unsigned certificate will prevent someone from passively listening in on your encrypted traffic, since they have no way to gain access to your shared symmetric key.
You said that
the browser gets the certificate's issuer information from that
certificate, then uses that to contact the issuerer, and somehow
compares certificates for validity.
The client doesn't have to check with the issuer because two things :
all browsers have a pre-installed list of all major CAs public keys
the certificate is signed, and that signature itself is enough proof that the certificate is valid because the client can make sure, on his own, and without contacting the issuer's server, that that certificate is authentic. That's the beauty of asymmetric encryption.
Notice that 2. can't be done without 1.
This is better explained in this big diagram I made some time ago
(skip to "what's a signature ?" at the bottom)
It's worth noting that in addition to purchasing a certificate (as mentioned above), you can also create your own for free; this is referred to as a "self-signed certificate". The difference between a self-signed certificate and one that's purchased is simple: the purchased one has been signed by a Certificate Authority that your browser already knows about. In other words, your browser can easily validate the authenticity of a purchased certificate.
Unfortunately this has led to a common misconception that self-signed certificates are inherently less secure than those sold by commercial CA's like GoDaddy and Verisign, and that you have to live with browser warnings/exceptions if you use them; this is incorrect.
If you securely distribute a self-signed certificate (or CA cert, as bobince suggested) and install it in the browsers that will use your site, it's just as secure as one that's purchased and is not vulnerable to man-in-the-middle attacks and cert forgery. Obviously this means that it's only feasible if only a few people need secure access to your site (e.g., internal apps, personal blogs, etc.).
I KNOW THE BELOW IS LONG, BUT IT IS DETAILED, YET SIMPLIFIED ENOUGH. READ CAREFULLY AND I GUARANTEE YOU'LL START FINDING THIS TOPIC IS NOT ALL THAT COMPLICATED.
First of all, anyone can create 2 keys. One to encrypt data, and another to decrypt data. The former can be a private key, and the latter a public key, AND VICERZA.
Second of all, in simplest terms, a Certificate Authority (CA) offers the service of creating a certificate for you. How? They use certain values (the CA's issuer name, your server's public key, company name, domain, etc.) and they use their SUPER DUPER ULTRA SECURE SECRET private key and encrypt this data. The result of this encrypted data is a SIGNATURE.
So now the CA gives you back a certificate. The certificate is basically a file containing the values previously mentioned (CA's issuer name, company name, domain, your server's public key, etc.), INCLUDING the signature (i.e. an encrypted version of the latter values).
Now, with all that being said, here is a REALLY IMPORTANT part to remember: your device/OS (Windows, Android, etc.) pretty much keeps a list of all major/trusted CA's and their PUBLIC KEYS (if you're thinking that these public keys are used to decrypt the signatures inside the certificates, YOU ARE CORRECT!).
Ok, if you read the above, this sequential example will be a breeze now:
Example-Company asks Example-CA to create for them a certificate.
Example-CA uses their super private key to sign this certificate and gives Example-Company the certificate.
Tomorrow, internet-user-Bob uses Chrome/Firefox/etc. to browse to https://example-company.com. Most, if not all, browsers nowadays will expect a certificate back from the server.
The browser gets the certificate from example-company.com. The certificate says it's been issued by Example-CA. It just so happens to be that Bob's OS already has Example-CA in its list of trusted CA's, so the browser gets Example-CA's public key. Remember: this is all happening in Bob's computer/mobile/etc., not over the wire.
So now the browser decrypts the signature in the certificate. FINALLY, the browser compares the decrypted values with the contents of the certificate itself. IF THE CONTENTS MATCH, THAT MEANS THE SIGNATURE IS VALID!
Why? Think about it, only this public key can decrypt the signature in such a way that the contents look like they did before the private key encrypted them.
How about man in the middle attacks?
This is one of the main reasons (if not the main reason) why the above standard was created.
Let's say hacker-Jane intercepts internet-user-Bob's request, and replies with her own certificate. However, hacker-Jane is still careful enough to state in the certificate that the issuer was Example-CA. Lastly, hacker-Jane remembers that she has to include a signature on the certificate. But what key does Jane use to sign (i.e. create an encrypted value of the certificate main contents) the certificate?????
So even if hacker-Jane signed the certificate with her own key, you see what's gonna happen next. The browser is gonna say: "ok, this certificate is issued by Example-CA, let's decrypt the signature with Example-CA's public key". After decryption, the browser notices that the certificate contents don't match at all. Hence, the browser gives a very clear warning to the user, and it says it doesn't trust the connection.
The client has a pre-seeded store of SSL certificate authorities' public keys. There must be a chain of trust from the certificate for the server up through intermediate authorities up to one of the so-called "root" certificates in order for the server to be trusted.
You can examine and/or alter the list of trusted authorities. Often you do this to add a certificate for a local authority that you know you trust - like the company you work for or the school you attend or what not.
The pre-seeded list can vary depending on which client you use. The big SSL certificate vendors insure that their root certs are in all the major browsers ($$$).
Monkey-in-the-middle attacks are "impossible" unless the attacker has the private key of a trusted root certificate. Since the corresponding certificates are widely deployed, the exposure of such a private key would have serious implications for the security of eCommerce generally. Because of that, those private keys are very, very closely guarded.
if you're more technically minded, this site is probably what you want: http://www.zytrax.com/tech/survival/ssl.html
warning: the rabbit hole goes deep :).
I'm not quite understanding the necessity of certificate pinning in SSL connection establishment (to avoid Man in the Middle attacks).
SSL cert pinning requires embedding original server certificate in the host to verify with the one presented by server. what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
What is that I am missing here?
what is the difference between the server certificate embedded in the host and the one presented by server to be validated by client?
There should be none and that's exactly the point of certificate pinning.
Without certificate pinning an application commonly accepts any certificate which matches the requested hostname and is issued by a locally trusted CA (certificate authority). Given that there are usually more than 100 CA in the local trust store it is sufficient that one of these got successfully attacked as in the case of DigiNotar in 2011. Thus it makes sense to limit the certificate you accept to a specific one, i.e. pinning.
Besides the certificate pinning by comparing the certificate received with a locally stored certificate there are other ways of pinning: for example one might just check against a fingerprint (hash) and not the full certificate. In case the certificate can expire it might be more useful to check only the public key and not the whole certificate because the public key is often kept on certificate renewal. Or one might pin to a specific CA which one considers trusted to issue certificates for this domain.
Note that to understand pinning you might need to understand how the authentication of the server works. One part of this is that the server certificate is validated (hostname, expiration, trust chain ...). But this is not enough since the certificate itself is public, i.e. everybody can get it and could send it inside the TLS handshake. Thus the other major part of the authentication is that the server proves that it is the owner of the certificate. This is done by signing some data using the private key matching the certificate. Since only the owner of the certificate should have the private key this proves ownership. Because of this anybody could embed the servers certificate for pinning but only the server itself can prove ownership of the certificate.
What is SSL pinning
Applications are configured to trust a select few certificates or certificate authority (CA), instead of the default behaviour: to trust all CAs that are pre-configured on the device/ machine. SSL pinning is not required.
Why use SSL Pinning (Why not to)
In many cases, the certificate returned by a server could be tampered as long as any Root (or intermediate root) CA was compromised (happens very rarely). Threat actors could use this compromised CA to generate a certificate for your website, and show visitors their website instead. This is bad. SSL pinning was designed to prevent this in some cases, but there are better ways (IMHO).
Having said that, I don' t know any website which uses SSL pinning so SSL pinning seems primarily discussed for mobile apps. It seems like SSL pinning only works when you can trust the source of the application (e.g. App Store, Play Store) Why? Because if you have to visit a website to get the cert, by then its too late (you might have already used a dodgy cert and accessed the fake website or was MITM'd). Therefore, it seems like the benefits Steffen mentioned are not so compelling, especially when there are better solutions already:
Better solution
I'm not sure if any-CA-compromise is a threat vector, even for banks. Instead, banks and other security conscious organisations will pick their CA wisely, and also configure a CAA record.
By using a CAA DNS record, they can restrict clients (e.g. browsers, mobile apps) to trust only certain certificates when accessing their specific website.
They pick the CA and create a cert only from this CA
They will have a backup plan for if a CA is compromised. Don't want to go into that here, but the backup plan for CAA records is IMHO much better than that of SSL pinning.
For example, Monzo.com (I used whatsmydns to find this) has a CAA record which restricts certificates to only 4 CAs (digicert, amazon, comodoca, buypass):
0 iodef "mailto:security#monzo.com"
0 issue "amazon.com"
0 issue "buypass.com"
0 issue "comodoca.com"
0 issue "digicert.com"
0 issue "letsencrypt.org"
0 issuewild "amazon.com"
0 issuewild "comodoca.com"
0 issuewild "digicert.com"
0 issuewild "letsencrypt.org"
These are popular CAs which people trust, we hope they don't let us down. If they do, the whole internet would be a free for all. The only way to prevent this is to be your own CA/ use self-signed certificates.
Summary
I don't see how SSL pinning will become ubiquitous, especially since it adds more overhead (maintenance regarding ssl expiry, or trusting one CA anyway - SPoF, or emulating what a CAA record does but with additional code/ maintenance burden). It also only supports your pre-installed applications, not websites.
I have a portofolio website runing on a IIS Windows server if that matters.But some people complained that they get "website unsafe" when navigating the website.I personaly didnt get that error , and I tried the website on other diveces and they didnt get it either.
Could have something to do with SSL Certificate ? I didn't bought one ,but I have a self signed certificate according to ssl checker
.Do I need to buy a trusted SSL Certificate ? Or is there another problem ?
On my website i have a "Contact us" page with a web form that users should fill with name,email...
EDIT: I don't know if it's ok to post the website link here, if it's needed let me know .
EDIT: Link to website here.
This is a general problem with self-signed certificates, as the visitors of you website, or their browser, are not able to verify the identity of your server. The reason for this is, that there is no Certification Authority that signed it, thus the browser does not have a (root) certificate that is in the chain of trust linked to your certificate.
This problem with self-signed certificates is well explained in this post
The risks are for the client. The point of the SSL server certificate is that it is used by the client to know the server public key, with some level of guarantee that the key indeed belongs to the intended server. The guarantee comes from the CA: the CA is supposed to perform extensive verification of the requester identity before issuing the certificate.
When a client (the user and his Web browser) "accepts" a certificate which has not been issued by one of the CA that the client trusts (the CA which were embedded in Windows by Microsoft), then the risk is that the client is currently talking to a fake server, i.e. is under attack. Note that passive attacks (the attacker observes the data but does not alter it in any way) are thwarted by SSL regardless of whether the CA certificate was issued by a mainstream CA or not.
On a general basis, you do not want to train your users to ignore the scary security warning from the browser, because this makes them vulnerable to such server impersonation attacks (which are not that hard to mount, e.g. with DNS poisoning). On the other hand, if you can confirm, through some other way, that the certificate is genuine that one time, then the browser will remember the certificate and will not show warnings for subsequent visits as long as the same self-signed certificate is used. The newly proposed Convergence PKI is an extension of this principle. Note that this "remembered certificate" holds as long as the certificate is unchanged, so you really want to set the expiry date of your self-signed certificate in the far future (but not beyond 2038 if you want to avoid interoperability issues).
It shall be noted that since a self-signed certificate is not "managed" by a CA, there is no possible revocation. If an attacker steals your private key, you permanently lose, whereas CA-issued certificates still have the theoretical safety net of revocation (a way for the CA to declare that a given certificate is rotten). In practice, current Web browser do not check revocation status anyway.
A friend of mine asked me why we pay so much for SSL certificates if everyone could theoretically issue one. Why indeed? And how do we judge if the little lock in the browser is really trustworthy?
Certificates are cryptographically signed by something called a Certificate Authority(CA), and each browser has a list of CAs it implicitly trusts. These CAs are entities that have a set of cryptographic keys that can be used to sign any certificate, often for a fee. Any certificate signed by a CA in the trusted list will give a lock on a browser, because it's proven to be "trusted" and belongs to that domain.
You can self-sign a certificate, but the browser will warn you that the signer is not trusted, either by showing a big error box before allowing you in, or showing a broken lock icon.
In addition, even a trusted certificate will give an error if it's used for the wrong domain, or is modified to include another domain. This is ensured because the certificate includes the domains it is allowed to be used for, and it also has a cryptographic checksum/fingerprint that ensures its integrity.
This is not 100% safe at the moment, as there is the possibility to fake CA certificates that use MD5, see this link: http://www.phreedom.org/research/rogue-ca/. Though it has to be noted that this is pretty hard, as they exploited a weakness in an already existing CA, which may or may not have been closed by now.
In essence, we trust the certificates as much as we trust that our browser providers know how to select "proper" CAs. Those CAs are only trusted on virtue of their reputation, as a single misstep theoretically would be a very heavy blow on their trustworthiness if detected.
The whole CA business is amazing. I've purchased a couple of certificates from rapidssl.com, and all the "proof" they required was:
I could receive mail to the domain.
I could answer my phone.
That was it. Keep in mind, when trusting the little locks in the browser.
First, some background on strong public/private key cryptography, which SSL is based on:
A key has two parts, the private part and the public part. The public key can be used to encrypt material that requires the private key to decrypt. This allows the use of open communication channels to communicate securely.
One important aspect of public/private key cryptography is that the private key can be used to digitally sign a message which can be verified using the public key. This gives the receiver of a message the ability to verify concretely that the message they received was sent by the sender (the holder of the key).
The key to SSL certificates is that encryption keys themselves can be digitally signed.
A "certificate" is composed of a private/public key pair as well as digitally signed data. When someone buys an SSL certificate they generate a private/public key and submit the public key to a Certification Authority (CA) to be signed. The CA performs an appropriate level of due diligence on the buyer of the SSL certificate and signs the certificate with their private key. The SSL certificate will be bound to a particular website or set of websites and is essentially the CA indicating that they trust the owner of the private key of the certificate to be the proper owner of those websites.
The root certificates (public keys and other meta-data) for trusted CAs are included by default in major shipping browsers and operating systems (in windows, type "certmgr.msc" into a run prompt to see the certificate manager). When you connect to a web server using SSL the server will send you its SSL certificate including the public key and other meta data, all of which is signed by the CA. Your browser is able to verify the validity of the certificate, through the signature and the preloaded root certificates. This creates a chain of trust between the CA and the web server you are connecting to.
Because we have to trust someone.
Trusted SSL certificates have signatures of trusted authorities. For example, VeriSign has a deal with Microsoft, that their certificate is built in your browser. So you can trust every page with a VeriSign trusted certificate.
This graphic really picks the point:
RA = Registration Authority
CA = Certification Authority
VA = Validation Authority
Rough outline: A user applies for a
certificate with his public key at a
registration authority (RA). The
latter confirms the user's identity to
the certification authority (CA) which
in turn issues the certificate. The
user can then digitally sign a
contract using his new certificate.
His identity is then checked by the
contracting party with a validation
authority (VA) which again receives
information about issued certificates
by the certification authority.
If you are not using one of the accepted CAs people will get a message box when accessing the site talking about an untrusted certificate. That won't help to generate traffic to the site.
The lock only means that the site owner showed a CA some kind of proof that he really is who he claims to be. You must judge on your own if you trust that person/site.
It's like a stranger showing you a photo ID. Do you trust him more because you know for sure his name is John Doe? Probably not.
But when people you trust told you: "John Doe" is a good guy. The proof that the guy in front of you actually IS "John Doe", than you might choose to trust him as well.
Why? Because you're paying to ride along on someone elses reputation.... to vouch for you.
Its all about whose validating your claim to be you. Despite some of the documentaries Ive watched lately, and the recession, I'm still more likely to believe corporate America when they confirm your identity to me, than I am the Russian mafia. Even though both can just as easily issue certificates.
The amount you pay is basically just (how much it costs them to secure that reputation and/or suppress any security breaches) + (however much they can afford to gouge the market as a margin %).
Now the barriers to entry are quite high, cos its really expensive to earn that trust, so theres not a lot of competition. Therefore chances are the price isn't going to fall anytime soon.... unless Sony or GE etc decide to play.
You pay for a certificate so that when you go HTTPS (which you should for anything a little sensitive) your clients don’t get big warnings and go call your support saying that you have infected them & al…
Very little security, lot of FUD.
If you have the possibility of giving your clients your own certificate directly, do it. But it is a rare case.
Let's create an attack scenario.
Suppose the DNS was corrupted and https://facebook.com/ points to attacker's IP.
You sit down to your PC and open Facebook to loose few minutes on pointless scrolling. And then BANG, Certificate invalid error shows on your screen. Attacker signed https://facebook.com/ with his own cert to make sure no one will leave his copied facebook page because it's not encrypted so it looks suspicious. If browser wouldn't check certificate's authority, then attacker could sign corrupted page with his cert and you won't be aware you're connecting to the wrong IP.
So the attacker has 2 options to choose from:
Sign corrupted facebook page with his cert, so users will see an error.
Don't use https on his corrupted page.
Certificates are built on a chain of trust, and if let anyone be a signing authority, we would be implicitly trusting everyone. It's a bit scary today though, since there are over 200 so called "trusted authorities" whose certs are built into your browser!
There is one free CA that I know of though: StartCom. They issue free SSL certs, but they are only accepted in Firefox, not IE. (Not sure about Safari or Opera).
The other answers have explained the CA-system. The perspectives project aims to deploy a new approach to SSL, where you can choose whom to trust: http://perspectives-project.org/
How does SSL work?
Where is the certificate installed on the client (or browser?) and the server (or web server?)?
How does the trust/encryption/authentication process start when you enter the URL into the browser and get the page from the server?
How does the HTTPS protocol recognize the certificate? Why can't HTTP work with certificates when it is the certificates which do all the trust/encryption/authentication work?
Note: I wrote my original answer very hastily, but since then, this has turned into a fairly popular question/answer, so I have expanded it a bit and made it more precise.
TLS Capabilities
"SSL" is the name that is most often used to refer to this protocol, but SSL specifically refers to the proprietary protocol designed by Netscape in the mid 90's. "TLS" is an IETF standard that is based on SSL, so I will use TLS in my answer. These days, the odds are that nearly all of your secure connections on the web are really using TLS, not SSL.
TLS has several capabilities:
Encrypt your application layer data. (In your case, the application layer protocol is HTTP.)
Authenticate the server to the client.
Authenticate the client to the server.
#1 and #2 are very common. #3 is less common. You seem to be focusing on #2, so I'll explain that part.
Authentication
A server authenticates itself to a client using a certificate. A certificate is a blob of data[1] that contains information about a website:
Domain name
Public key
The company that owns it
When it was issued
When it expires
Who issued it
Etc.
You can achieve confidentiality (#1 above) by using the public key included in the certificate to encrypt messages that can only be decrypted by the corresponding private key, which should be stored safely on that server.[2] Let's call this key pair KP1, so that we won't get confused later on. You can also verify that the domain name on the certificate matches the site you're visiting (#2 above).
But what if an adversary could modify packets sent to and from the server, and what if that adversary modified the certificate you were presented with and inserted their own public key or changed any other important details? If that happened, the adversary could intercept and modify any messages that you thought were securely encrypted.
To prevent this very attack, the certificate is cryptographically signed by somebody else's private key in such a way that the signature can be verified by anybody who has the corresponding public key. Let's call this key pair KP2, to make it clear that these are not the same keys that the server is using.
Certificate Authorities
So who created KP2? Who signed the certificate?
Oversimplifying a bit, a certificate authority creates KP2, and they sell the service of using their private key to sign certificates for other organizations. For example, I create a certificate and I pay a company like Verisign to sign it with their private key.[3] Since nobody but Verisign has access to this private key, none of us can forge this signature.
And how would I personally get ahold of the public key in KP2 in order to verify that signature?
Well we've already seen that a certificate can hold a public key — and computer scientists love recursion — so why not put the KP2 public key into a certificate and distribute it that way? This sounds a little crazy at first, but in fact that's exactly how it works. Continuing with the Verisign example, Verisign produces a certificate that includes information about who they are, what types of things they are allowed to sign (other certificates), and their public key.
Now if I have a copy of that Verisign certificate, I can use that to validate the signature on the server certificate for the website I want to visit. Easy, right?!
Well, not so fast. I had to get the Verisign certificate from somewhere. What if somebody spoofs the Verisign certificate and puts their own public key in there? Then they can forge the signature on the server's certificate, and we're right back where we started: a man-in-the-middle attack.
Certificate Chains
Continuing to think recursively, we could of course introduce a third certificate and a third key pair (KP3) and use that to sign the Verisign certifcate. We call this a certificate chain: each certificate in the chain is used to verify the next certificate. Hopefully you can already see that this recursive approach is just turtles/certificates all the way down. Where does it stop?
Since we can't create an infinite number of certificates, the certificate chain obviously has to stop somewhere, and that's done by including a certificate in the chain that is self-signed.
I'll pause for a moment while you pick up the pieces of brain matter from your head exploding. Self-signed?!
Yes, at the end of the certificate chain (a.k.a. the "root"), there will be a certificate that uses it's own keypair to sign itself. This eliminates the infinite recursion problem, but it doesn't fix the authentication problem. Anybody can create a self-signed certificate that says anything on it, just like I can create a fake Princeton diploma that says I triple majored in politics, theoretical physics, and applied butt-kicking and then sign my own name at the bottom.
The [somewhat unexciting] solution to this problem is just to pick some set of self-signed certificates that you explicitly trust. For example, I might say, "I trust this Verisign self-signed certificate."
With that explicit trust in place, now I can validate the entire certificate chain. No matter how many certificates there are in the chain, I can validate each signature all the way down to the root. When I get to the root, I can check whether that root certificate is one that I explicitly trust. If so, then I can trust the entire chain.
Conferred Trust
Authentication in TLS uses a system of conferred trust. If I want to hire an auto mechanic, I may not trust any random mechanic that I find. But maybe my friend vouches for a particular mechanic. Since I trust my friend, then I can trust that mechanic.
When you buy a computer or download a browser, it comes with a few hundred root certificates that it explicitly trusts.[4] The companies that own and operate those certificates can confer that trust to other organizations by signing their certificates.
This is far from a perfect system. Some times a CA may issue a certificate erroneously. In those cases, the certificate may need to be revoked. Revocation is tricky since the issued certificate will always be cryptographically correct; an out-of-band protocol is necessary to find out which previously valid certificates have been revoked. In practice, some of these protocols aren't very secure, and many browsers don't check them anyway.
Sometimes an entire CA is compromised. For example, if you were to break into Verisign and steal their root signing key, then you could spoof any certificate in the world. Notice that this doesn't just affect Verisign customers: even if my certificate is signed by Thawte (a competitor to Verisign), that doesn't matter. My certificate can still be forged using the compromised signing key from Verisign.
This isn't just theoretical. It has happened in the wild. DigiNotar was famously hacked and subsequently went bankrupt. Comodo was also hacked, but inexplicably they remain in business to this day.
Even when CAs aren't directly compromised, there are other threats in this system. For example, a government use legal coercion to compel a CA to sign a forged certificate. Your employer may install their own CA certificate on your employee computer. In these various cases, traffic that you expect to be "secure" is actually completely visible/modifiable to the organization that controls that certificate.
Some replacements have been suggested, including Convergence, TACK, and DANE.
Endnotes
[1] TLS certificate data is formatted according to the X.509 standard. X.509 is based on ASN.1 ("Abstract Syntax Notation #1"), which means that it is not a binary data format. Therefore, X.509 must be encoded to a binary format. DER and PEM are the two most common encodings that I know of.
[2] In practice, the protocol actually switches over to a symmetric cipher, but that's a detail that's not relevant to your question.
[3] Presumable, the CA actually validates who you are before signing your certificate. If they didn't do that, then I could just create a certificate for google.com and ask a CA to sign it. With that certificiate, I could man-in-the-middle any "secure" connection to google.com. Therefore, the validation step is a very important factor in the operation of a CA. Unfortunately, it's not very clear how rigorous this validation process is at the hundreds of CAs around the world.
[4] See Mozilla's list of trusted CAs.
HTTPS is combination of HTTP and SSL(Secure Socket Layer) to provide encrypted communication between client (browser) and web server (application is hosted here).
Why is it needed?
HTTPS encrypts data that is transmitted from browser to server over the network. So, no one can sniff the data during transmission.
How HTTPS connection is established between browser and web server?
Browser tries to connect to the https://payment.com.
payment.com server sends a certificate to the browser. This certificate includes payment.com server's public key, and some evidence that this public key actually belongs to payment.com.
Browser verifies the certificate to confirm that it has the proper public key for payment.com.
Browser chooses a random new symmetric key K to use for its connection to payment.com server. It encrypts K under payment.com public key.
payment.com decrypts K using its private key. Now both browser and the payment server know K, but no one else does.
Anytime browser wants to send something to payment.com, it encrypts it under K; the payment.com server decrypts it upon receipt. Anytime the payment.com server wants to send something to your browser, it encrypts it under K.
This flow can be represented by the following diagram:
I have written a small blog post which discusses the process briefly. Please feel free to take a look.
SSL Handshake
A small snippet from the same is as follows:
"Client makes a request to the server over HTTPS. Server sends a copy of its SSL certificate + public key. After verifying the identity of the server with its local trusted CA store, client generates a secret session key, encrypts it using the server's public key and sends it. Server decrypts the secret session key using its private key and sends an acknowledgment to the client. Secure channel established."
Mehaase has explained it in details already. I will add my 2 cents to this series. I have many blogposts revolving around SSL handshake and certificates. While most of this revolves around IIS web server, the post is still relevant to SSL/TLS handshake in general. Here are few for your reference:
SSL Handshake and IIS
Client certificate Authentication in SSL Handshake
Do not treat CERTIFICATES & SSL as one topic. Treat them as 2 different topics and then try to see who they work in conjunction. This will help you answer the question.
Establishing trust between communicating parties via Certificate Store
SSL/TLS communication works solely on the basis of trust. Every computer (client/server) on the internet has a list of Root CA's and Intermediate CA's that it maintains. These are periodically updated. During SSL handshake this is used as a reference to establish trust. For exampe, during SSL handshake, when the client provides a certificate to the server. The server will try to cehck whether the CA who issued the cert is present in its list of CA's . When it cannot do this, it declares that it was unable to do the certificate chain verification. (This is a part of the answer. It also looks at AIA for this.) The client also does a similar verification for the server certificate which it receives in Server Hello.
On Windows, you can see the certificate stores for client & Server via PowerShell. Execute the below from a PowerShell console.
PS Cert:> ls Location : CurrentUser StoreNames : {TrustedPublisher, ClientAuthIssuer, Root, UserDS...}
Location : LocalMachine StoreNames : {TrustedPublisher,
ClientAuthIssuer, Remote Desktop, Root...}
Browsers like Firefox and Opera don't rely on underlying OS for certificate management. They maintain their own separate certificate stores.
The SSL handshake uses both Symmetric & Public Key Cryptography. Server Authentication happens by default. Client Authentication is optional and depends if the Server endpoint is configured to authenticate the client or not. Refer my blog post as I have explained this in detail.
Finally for this question
How does the HTTPS protocol recognize the certificate? Why can't HTTP work with certificates when it is the certificates which do all the trust/encryption/authentication work?
Certificates is simply a file whose format is defined by X.509 standard. It is a electronic document which proves the identity of a communicating party.
HTTPS = HTTP + SSL is a protocol which defines the guidelines as to how 2 parties should communicate with each other.
MORE INFORMATION
In order to understand certificates you will have to understand what certificates are and also read about Certificate Management. These is important.
Once this is understood, then proceed with TLS/SSL handshake. You may refer the RFC's for this. But they are skeleton which define the guidelines. There are several blogposts including mine which explain this in detail.
If the above activity is done, then you will have a fair understanding of Certificates and SSL.