I've been reading a few sites on the internet on how SSL works, but I don't understand how exactly it makes things secure. Probably because I don't understand completely how it works.
Let me begin with the core idea of SSL. It is used to encrypt HTTP connections, but for the client and the server to communicate with encrypted data, surely an encryption key needs to be shared. If someone is eavesdropping on your connection, wouldn't they just be able to grab this key and continue listening while decrypting the data? I can image this technique would work if we're talking about a long term connection, but HTTP requests are often completed within half a second.
Let's assume this is somehow taken care of. The other utilisation of SSL is to verify if a server is exactly who it says it is. What prevents a rogue server from faking a certificate signed by a root certificate provider? In none of the descriptions I've read, the browser actually contacted one of these authorities to verify the certificate with them. Let's assume the certificate is encrypted with a private key by the root certificate authority, how is the browser able to verify the data in this certificate without knowing the decryption key? Or is the decryption key different from the encryption key?
One solution to these problems I can imagine is if the certificate and key are only sent once and are stored along with the domain and IP address in your browser.
Thanks for explaining in advance.
First, some basic concepts about public key cryptography:
This relies on a pair of keys. One is the public key (which can be distributed); the other one is the private key, intended to be kept private.
You can encrypt data using the public key, which the private key can decrypt/decipher.
You can sign data using the private key, and this signature can be verified using the public key.
To make sure you're communicating with the right entity, you need to bind an identity to a key-pair. This is where certificates come in. A public key certificate is a signed document containing both the subject's identity (name) and the subject's public key.
For example, the certificate for www.google.com contains its public key and the name www.google.com. It has been signed using the private key of a Certification Authority (in this case, Thawte). In the X.509 terminology (the common standard for certificates used for HTTPS), the CA is the issuer of the certificate, and it puts its name in the certificate too, alongside the subject's name, the subject's public key (and other attributes). The issuers are meant to verify the identity of who they issue a certificate for.
The reason you don't necessarily see your browser fetching information from the CAs is that a number of commercial (or governmental) CA certificates are bundled with your browser or your OS. You trust them by default. This can be considered as a "leap of faith", but any trust mechanism needs this sort of starting point.
You may want to read more about the TLS handshake, but in short:
The client gets the server's public key by looking into its certificate.
The client encrypts a secret using this public key and sends it to the server. The details of this depend on the cipher suite (could be Diffie-Hellman based), but the result of this should be a list of shared encryption keys (using symmetric cryptography, not public key cryptography).
These shared keys are only known to the client and the server, and they're used for encryption/decryption.
For SSL/TLS to be secure, you need at least 3 points:
A suitable cipher suite, and a successful handshake.
Verifying that the client trust the server certificate (typically, via a known CA in the PKI model).
Verifying that the certificate belongs to the server the client intended to contact (hostname verification).
(This is the case for the vast majority of usages of SSL/TLS (in particular HTTPS), but it's also possible to use other mechanisms than X.509 certificates with TLS, for example OpenPGP certificate or Kerberos cipher suites. This is less common as far as I know.)
In order to encrypt a connection you have to agree to some shared secret. This can be done with diffie-hellman. To prevent man in the middle attacks, so you also need a certificate mechanism.
For encrypting or signing (certificates) you can use asynchronous keys. This means you have two different keys (public and private key) to encrypt/decrypt. Usually you encrypt your data with a public key, and someone can decrypt it with his private key. Signing is done with your private key, and someone else can check it with a public key.
So you see, faking a certificate is not that easy, since you don't have the private key from a root certificate provider.
surely an encryption key needs to be shared. If someone is eavesdropping on your connection, wouldn't they just be able to grab this key
No. The key is never transmitted. It is computed at both ends independently via a key-agreement algorithm.
What prevents a rogue server from faking a certificate signed by a root certificate provider?
The certificate is sent along with its digital signature which is made with the private key, and verified by the peer via the certificate's own public key. The server would need the private key of the server it is spoofing.
When using protocols such as Diffie-Hellman key exchange, the two parties to a communication each generate a random number, transform it in some way, and send the transformed version to the other party. The transformation is such that combining the first number with the transformed version of the second will yield the same result as combining the second number with the transformed version of the first. An adversary who only had the transformed numbers, however, would have no way of finding the un-transformed version of either, nor a way of computing what the result would be if the (unavailable) untransformed version of one number were combined with the (available) transformed version of the other.
Diffie-Hellman key exchange by itself would be sufficient to protect against all forms of passive attack or historical attacks (meaning if an attacker hadn't taken steps to intercept a communication before it took place, it cannot later be compromised except by performing some calculations which could not, with anything resembling today's technology, be computed in any remotely feasible time). The problem with it is that it cannot very well protect against the situation where an attacker (e.g. Z) can intercept all communications between the participants (e.g. X and Y) and substitute his own. In that scenario, X would establish a connection with Z--thinking him to by Y--which nobody but he and Z could decode. Z would then--pretending to be X--establish a connection with Y.
If X and Y have any pre-existing means of sharing information with each other in such a way that they can decode it much faster than Z, even if it's not terribly secure, this may suffice to prevent the above-described man-in-the-middle attack. All that needs to happen is for X and Y to ask each other something about the key they're using. If Z can recognize that question and substitute its own answer, it would be able to continue the ruse. On the other hand, if the question were asked in such a way that a legitimate party would be able to respond much more quickly than an imposter, Z might be stumped. As an example, if a voice-phone application displayed for each participant information about the negotiated key, and one party asked the other "read off digits 12 to 18 of your key, doing your best impression of Elmer Fudd" (selecting, on the spot, the digits to read and the voice to use) a legitimate participant would be able to respond immediately, but an attacker would need time to produce a phony recording of the person speaking as indicated).
Related
I'm signing JWT's using the RS256 algorithm. To verify those tokens on the client, I somehow need to access the public key.
Are there security concerns (spoofing, ...) when I set up an unprotected API route ('/api/certificate') that returns the certificate containing the public key. And do I need to take any extra security measurements?
Several concepts are often mixed up, maybe not for you, but let me try to explain a few things in this answer.
Assymetric cryptography obviously needs a public and a private key, both are basically just numbers. The private key is kept secret, the public is, well, public, anybody can have it. When signing stuff, you use the private key to sign and then anybody can verify using the public key that the signature was made by somebody that had the corresponding private key (ie. you).
But the question is then how you distribute your public key, or in your jwt example, how clients get it. As you correctly pointed out in the question, simply downloading the public key over an insecure channel is not good enough as an attacker could replace it with his own, resulting in the attacker being able to sign tokens.
One solution to this could be getting it over https as you proposed, which practically means using a second set of public-private keypair (keys of the webserver) to secure sending the first one. The theoretical question is still the same btw, it's just inherently solved in the background for you: how does the browser know that the public key it receives from the server upon connection actually belongs to the server. There is no secure channel yet between them.
Enter certificates.
A certificate is a document that essentially ties a public key to its owner, and that is excactly what you want. When a browser connects to a website, the server sends its public key along with its certificate, so that the browser can verify that the public key actually belongs to the server (the domain name in this case) that sent it. How that verifies it is beyond the scope of this post, the point is that the certificate is signed by another public key, the certificate to which may be signed by another public key, etc., and the chain is terminated by a list of so called trusted root certificates already set up for your computer and/or browser by your OS/browser vendor.
And you too should verify the public key with the certificate the same way. You don't even need the burden of SSL (https) transport for this, verifying that a public key belongs to a particular subject is the main purpose of certificates.
So all you have to do is not just get the public key from the API, but get it along with its certificate. You are probably already doing this, bare public keys are very rarely used. You are most probably already receiving a pfx or cer or crt or whatever from the server. Depending on the technology stack that you are developing on, you can for sure use built in mechanisms to fully verify a certificate and make sure it's valid. Please don't implement your own validation though, as that's tricky business and quite hard to get right. If the certificate passes validation, you can trust that the public key you received from the API is authentic and belongs to whatever it claims to belong to. There may be caveats though (like for example make sure that beyond basic validation, you check a combination of fields from the certificate that others can't have).
As an additional security measure, you can also implement certificate pinning to make it even more secure against certain types of attacks by having a list of fingerprints for valid certificates in the client (less so in a browser client, but still the concept is the same).
Edit (what fields to check in the certificate after it passed general validation of expiry, etc):
In the general case it depends on who signed the certificate and what kind of certificate it is.
A server certificate signed by a real certificate authority (CA) can only have the server domain as its common name (CN) field, a real CA won't normally sign anything else, and they also won't sign a certificate for yourdomain.com unless you can prove you control yourdomain.com. So in this case it may be enough to check CN after the cert passed validation. You do need to check CN though, as anybody can have a valid certificate from say GlobalSign or Thawte or other trusted CAs, it just costs money. What they can't have is a certificate for yourdomain.com.
If you sign your own certificates, you also won't sign anything for anyone, so in that case it could be enough to check the issuer (that you signed it) and the CN (for whom). If the certificate otherwise passed validation (meaning a trusted root certificate signed it) it should be ok, as an attacker won't normally be able to have his CA certificate as trusted on your computer.
The point in general is that you want to check something that others can't have. It's easier, if you are relying on real CAs, and it's usually best to check the fingerprint.
First of all, I apologize for sending yet another question about this seeing as there are so many related posts. After reading through them and related sites I'm still not clear on a few points.
Browser connects to server through secure socket
Server responds with its public key with its certificate. This is the step I have the most trouble with. In this message from server to client, can the certificate be easily separated from the server's public key? If it's a root certificate (one which is already included in the browser) then a man-in-the-middle can't fake it, but what if it's not? Can't whatever this online mechanism the client uses to verify the certificate be hijacked? Furthermore, if the client's computer is compromised, the root CA's can be compromised, right? Any steps that avoid this? One last thing: It is said that a certificate is insecure until signed. I can't figure out what this means, especially since a certificate can sign itself. I think it's supposed to mean that someone is assuring the authenticity of the message, so a certificate signing itself sounds insecure ("Are you a REAL certificate?"..."ummm, sure, sure I am"). If the mechanism for authenticating a certificate is the internet, I'm wondering how is that secure. Is signing a certificate the same as thing (literally) as saying the client verifies the certificate?
Session key is encrypted with public key and sent to server. This session key is a symmetric key that both server and client will use for remainder of encrypted communication.
I must say, most information online is so vague. So many holes in explanations and hand-waving going on. My guess is that very few people know the actual mechanisms very well?
You've left out several steps. One of them is that the server sends a digital signature over the entire handshake so far, signed with its private key. Only the server can do that, with its own certificate. Nobody else's. The client verifies the digital signature using the public key in the certificate that was sent. That proves that the server owns the certificate. It also proves that the server is the same entity that sent all the other handshake messages.
BTW your step 3 is imaginary. The session key is never sent at all. It is computed independently at both ends.
EDIT Comments on your answer:
Server (from JoesGoods) gets a certificate from the CA via?
Usually via an Internet browser.
Can this be hijacked?
No more than any other secure SSL session can be.
The certificate is "signed"
Correct.
which means a bit of it is encrypted using the CA's private key.
No. You made that up.
Specifically the bit that has the web server's info (JoesGoods' server info)
No. You made that up.
The entire certificate is signed, and that does not mean 'encrypted', with the CA's private key.
Bob's browser connects to server through a secure socket and sends a "hello" packet.
The socket isn't secure at this point. It's just plaintext.
The server sends its public key and certificate to Bob.
No. The server sends its certificate. The public key is already inside the certificate.
the browser checks that the webserver (JoesGoods) matches what's in the signed portion of the certificate
The entire certificate is signed. The client checks that the server it is connecting to matches the subjectDN of the certificate.
The webserver's public key is also signed with the CA's private key
Because it's in the certificate. Otherwise there is no other way this can be accomplished. That's why it isn't sent separately, and it's also why the entire certificate is signed, not just the bits you like.
The browser sends a client key exchange packet to the webserver (JoesGoods) using the webserver's public key included in step (2).
This part is cipher suite-dependent. What you have described applies to RSA cipher suites. Diffie-Hellman is a different story, and there is room for expansion to include others.
This client key is used to generate symmetric keys to conduct the remainder of the exchange. This client key is called a "premaster secret" and is a random key. Since the symmetric keys are created using this key, I wonder why not just send the symmetric key itself since the connection is encrypted and validated at this point.
Because it wouldn't be nearly as secure.
You also have some of these steps out of order.
I really don't see the point of enumerating all these steps informally when they are already completely specified in RFC 2246. There's enough misinformation about TLS floating around the Internet already, such as this piece of unmaintained drivel.
I read an article about digital signature (link) and have question as follows.
Let's say Alice wants to send a message to Bob. She need to let Bob know the message is from her. So she encrypted the hashed message with her private key into a certificate. Then Bob can decrypted the message with public key when receiving it. Bob can know it is from Alice if the hash code of the message matches the hash code which is decrypted from certificate. Here we have the assumption that Bob already knows the public key. What if the transmission of public key is already attacked? Bob might use the wrong public key to decrypt the wrong message and get that the message if from Alice. Is there any protocal or policy to avoid the attack against public key? And shall we？
Yes, the authenticity of public keys is a key component of applied cryptography. I can issue a public key that says "I am the website of your bank, trust me", but you shouldn't really trust it. Different schemes have been developed to establish authentication of public keys. One approach is the web of trust model in PGP and GnuPG, others are PKI and Kerberos. One of the main difference between these approaches is where you place your trust. I provide a simplified description only, you have to read about them to learn about the exact details (you wouldn't base your security on an extremely short summary, would you?).
In the web of trust there are some people who you trust, and you (ideally) verified their public keys personally. You can trust other public keys if they have been signed by several people bearing your initial trust. Using these trusted individuals you can check more and more keys.
In PKI (Personal Key Infrastructure) you trust several Certificate Authorities (CAs) and accept their public keys. You trust them that they thoroughly check the identity of key holders before signing their public keys. The combination of public key + signature from a CA (and some other data) forms a certificate. The PKI is used in SSL/TLS, it is the underlying infrastructure of the secure web. You use it when you read your mail on a web interface, when you do online banking, etc. If a CA is compromised, then every certificate signed by the CA will be come insecure.
In Kerberos is designed for computer networks and the key server is the single point of trust. It provides mutual authentication and a unique symmetric encryption key for clients and servers. The key server checks the identity of clients by a secret shared only between the key server and the client. Kereberos is used, for example, in Windows, AFS, Grid computing.
your answer gave me much of insight into the question. And also, I would like to put the wikipedia link http://en.wikipedia.org/wiki/X.509#Security here. Coz there is one stentence in the article solve my question "who certificate the Certificate Authority"
This is an example of a self-signed certificate, as the issuer and subject are the same. There's no way to verify this certificate except by checking it against itself; instead, these top-level certificates are manually stored by web browsers. Thawte is one of the root certificate authorities recognized by both Microsoft and Netscape. This certificate comes with the web browser and is trusted by default.
Just in case some one has the same question.
My question is about certificates specifically in ssl but I think the questions should apply to all certificates. I have included the SSL procedure for the sake of clarity.
In SSL this is what I understand the procedure is:
1)Client
sends supported crypto algorithms
sends client nonce
Server
chooses (and sends) a
symmetric algorithm
a public key algorithm
a MAC algorithm
sends it's certificate
sends server nonce
Client
verifies certificate
Extracts public key
Generates a pre-master secret key (pms)
encrypts with servers public key and sends
Client and Server
compute master secrete (MS) from PMS and nonces
PMS sliced to generate two encryption & two mac keys
Client
sends a mac of all handshakes (to ensure they were not previously modifide)
Server
sends a mac of all handshakes
Question
What stops a man in the middle attack from happening at step two? Why can't a man in the middle, say trudy, capture the certificate sent by the server and change the public key in it (to something it has the private key to).
I assume that the certificate is encrypted somehow.
However the server cannot encrypt the certificate because the client does not have the public key yet. When the server gets the key from an authority (like veri-sign) would the key be pre-encrypted using verisign's public key? I think this should work because all web browsers should have the public keys of most authorities.
No, the certificate is not encrypted. But it is signed by a certification authority (CA). Since those check the information included in the certificate (especially the URL to which the cert belongs), there shouldn't be a second valid certificate for a given URL.
The cert of the CA is checked against a trust store (e.g. in your browser). If this truststore is compromised, or if you trust not valid certificates, there is no protection against man in the middle attacks
Certificates are signed by some trusted authority, such as Verisign.
The certificates for these root authorities are built right into the browsers when you download them. You can view the root certificates in Firefox, for example, by going to tools-->options-->advanced-->encryption-->view certificates-->authorities.
If any one of these root-certificate authorities is compromised, however, you are right that a certificate could be forged, making a man-in-the-middle attack possible.
You actually pointed out a weak spot of PKI.
Say Trudy is in the middle of you and yourbank (bank.com). Trudy can change the public key at will at step 2 but the certificate's signature will be invalid. So Trudy has to find a way to generate the signature again. It's safe to say that the trusted CAs will not do this for him. So he has to sign with a fake CA, which is not trusted by your browser. This is still safe theoretically.
However, most browsers (especially IE 6) display a vague security warning and most people don't understand and just ignore, according to some tests.
I'm currently developing a system to transmit data between client and server, and was wondering what the strength of the encryption I planned to use was.
My thought was to have a private/public RSA key pair and hand out the public key to each client (leaving the private key solely on the server). Each client would then generate their own AES key and RSA encrypt it. They would then AES encrypt their data and send the encrypted data and encrypted AES key to the server. The server would then decrypt the AES key using the private key, and then decrypt the data using the AES key.
Are there any security flaws I am missing and/or is there a better way to do this?
This is almost exactly how SSL/TLS works (check out the handshake section). The only thing to make it stronger is to generate the AES key for each connection, rather than using the same key each time. You might also want to digitally sign messages that go back and forth to avoid man-in-the-middle and other spoofing attacks.
Generally speaking, creating a good cryptosystem is very difficult. When possible, you should always favor an existing (trusted) application to help out. In this case, you might consider sending your messages using HTTPS, rather than creating your own system.
You should give us more information about the language and platform you are using, so that we can give you specific recommendations about libraries that already exist and wich will handle the details for you. Using cryptographic primitives directly is not trivial and difficult to get exactly right, and with cryptography, you have to be "not exactly right" only once for your security to be broken.
To answer your question, it's generally a better idea to create a session secret (the AES key) through a Diffie-Hellman exchange, and each side use its private RSA key to sign its key-exchange data.
Otherwise, if the session secret is not established through a DH exchange, an adversary that gains access to the private RSA key (which has to be stored somewhere) could decrypt all traffic that was ever sent between the client and server.
If the secret is established through a DH exchange, then only the authentication part of the protocol would be exposed. Although an adversary in possession of the private RSA key would then not be able to read any previous communication, he still could either enter an authenticated dialog with the client/server or launch a man-in-the-middle attack (which may or may not be easily done, depending on the network).
One vulnerability would be if an attacker substituted their public key for the "real" public key. Then they would be able to intercept traffic as a "man-in-the-middle."
Protocols like S/MIME, PGP, and TLS use RSA encryption to transport keys just as you propose. However, the public keys they use are in certificates signed by trusted authorities.
The integrity of these trusted authorities must be carefully protected. For example, they might be burned into a tamper-proof hardware token, or a MAC might be computed over them using a password.
I'm not sure your approach will protect anything! You're going to keep the private key on the server and the public key will be distributed. If I get a hold of your public key, I'll be able to interact with your server at will. I think you should reverse the key ownership; each client will hold it's-own private key and the server will have a list of public keys (ala SSH). The server will have to add 'authorized' public keys and only to holders of the private keys will be able to connect.
Hope this helps.