I've been looking for information about SSL certificates and encryption protocols. I got very good answers, especially on this website.
There's only one thing I don't get. If I got this right, the verification of the identity (I mean the verification of the server identity, not the certificate identity) is made using asymmetric cryptography.
That means the steps would be (stop me if I'm wrong):
Client uses verified public key to encrypt a random challenge string and send it to server.
Server decrypts it using its private key and sends it back to the client.
Client checks if the response from server matches the random challenge string it just sent.
What prevents a fake server to do it like this, with a real certificate for, say, www.example.com but without having the private key?
Client uses verified public key to encrypt a random challenge string and send it to server.
Fake server sends the encrypted random challenge string to www.example.com, as a client wanting to check its identity.
www.example.com sends back the decrypted random challenge string to fake server.
Fake server sends it back to client.
Identity is confirmed?
Client uses verified public key to encrypt a random challenge string
and send it to server.
The key exchange mode where the client encrypts something with the server's public key is the RSA key exchange mode. There's a full description of it in section F.1.1.2 of the TLS specification.
Essentially, the client generates the pre-master secret, encrypts it with the server's public key (found in the server certificate the server has sent), and sends it to the server (in a Client Key Exchange Message). That's it. Only the server with the matching private key can decipher it. The server doesn't send any deciphered version back to the client, so couldn't ask for a 3rd party to do whatever operation you seem to have in mind with it.
This is just a straw-man argument. The steps you have listed are completely imaginary. The actual steps are:
The server sends its certificate as part of the TLS handshake.
The server sends a digital signature over its certificate and the other handshake messages, signed by its private key.
The client uses the public key in the certificate to verify the digital signature.
Only a server that has the private key corresponding to the public key in the certificate can succeed.
I suggest you do some reading, and not of random postings on the Internet: try the normative reference: RFC 2246.
Related
Please help me fill out the blanks here -
The server keeps its private key and the public key is shared to the users. So the client trusts the content thats coming from the server using the public key. How does the client encrypt the contents he is sending back to the server ?. Using the public key of the server ? or does the client send a autogenerated private key and encrypts it using the public key which is then decypted by the server along with the message and used for furthter communication by both parties.
A Public and a Private key is required to do ssl communication. This Key pair is generated using a self signed certificate ?. How can a single self signed certificate contain both public and private keys.
One more thing On message level security -- im looking at a current configuration and am pulling my hair out -- Using IBM Ikeyman to look at the producer and Consumer JKS files-- for Message level security(Digital Signing) there is a Personal certificate at the Consumer and a Signer certificate at the Producer ... Isnt this the other way around? Is this current configuration incorrect --- Both the keys are same by the way.
The server keeps its private key and the public key is shared to the users.
Correct.
So the client trusts the content thats coming from the server using the public key.
No. There is no 'so' about it. The client trusts the server certificate because it is signed by someone he trusts, and he knows it belongs to the server because the server provides a digital signature that the client can verify, which only the private key owner can do. Therefore he knows that the server owns that public key.
How does the client encrypt the contents he is sending back to the server ?.
The client and server negotiate a shared session key independently using techniques described in RFC 2246. For the most part they don't involve PKI at all.
Using the public key of the server? or does the client send a autogenerated private key and encrypts it using the public key which is then decypted by the server along with the message and used for furthter communication by both parties.
Neither, see above. This is quite a large subject.
A Public and a Private key is required to do ssl communication.
No. One of the parties must have a private key and a corresponding certificate that the other party trusts, otherwise the communication is insecure.
This Key pair is generated using a self signed certificate
No. The statement doesn't even make sense. Key pairs are generated first, nothing to do with certificates yet. The certificate is a wrapper for the public key.
How can a single self signed certificate contain both public and private keys.
It can't, and it doesn't. Self-signing doesn't have anything to do with it either.
Public-key encryption 101:
The public and private keys form a pair: each key in the pair can decrypt messages encrypted with the other, but cannot decrypt messages encrypted with itself. If the client can decrypt a message with the public key, it knows the message was encrypted by the owner of the public key. Conversely, a message encrypted with the public key can only be decrypted by the owner of the private key.
The basic idea is that the client generates a key for a symmetric-key cypher, encrypts it with the public key, and sends that to the server. Both sides then use that symmetric key and cypher for the majority of the communication.
In SSL communication,when the client wants to interact with some server, the server sends its public key. Always remember a certificate is nothing but a public key with a bunch of supporting information.
The problem here is any hacker can masquerade as a server and can block the communication between server and client. So the server certificate must be signed by some certificate authority. The client only believes the server certificate if it is signed by a certificate authority.In that case the hacker in between can not masquerade as a server because its certificate will not be authenticated by the certificate authority.
So client accepts the certificate and gets the public key of server. Now the client can send its public key encrypted by the public key of the server. Since this encrypted message can only be decrypted by the private key of the server so only server can decrypt it.
But the use of public key and private key over the ssl communication can slow down the connection very much because these keys lengths are 1024 or 2048 bits.
So practically what happens is instead of sending its own public key, the client sends the symmetric key encrypted by the public key of the server. Server decrypts it with its private key and it gets to know the symmetric key. Now the further communication happens with this symmetric key encryption and decryption.Since no third party gets to know the symmetric key, the communication will be secure.
Remember symmetric key lengths are generally 64-128 unlike public keys hence less the time for encryption and decryption.
I am working with a WCF service with mutual SSL security and I want to check my understanding of what certificate is used when.
Is this correct?
Client hands the server the client public certificate
Server hands the client the server public certificate
Client sends request encrypted using the server public certificate
Server decrypts request using the server private certificate
Server sends response encrypted using the client public certificate
Client decrypts response using the client private certificate
Or does it work in some other way?
RFC 2246, Section 7.4 details the handshake. Other versions of SSL/TLS work pretty similarly with regards to your question.
SSL/TLS involves two types of encryption. Asymmetric-key encryption and Symmetric-key encryption. The certificates are used for asymmetric-key encryption, and are used solely in the handshake process.
The encryption used by the certificates is very brief in time, used in the handshake. The server public/private key pair (asymmetric keys) is used to protect the session key (symmetric key). The client public/private key pair is used to prove to the server that the client is who it says it is. It knows this because the client is able to encrypt data (data known by both sides) using the client private key (that only it knows) and the server may decrypt it using the client public key.
For the ordering, I've bolded the parts of your question in the summary list below. Here's a nice summary from MSDN:
The TLS Handshake Protocol involves the following steps:
The client sends a "Client hello" message to the server, along with the client's random value and supported cipher suites.
The server responds by sending a "Server hello" message to the client, along with the server's random value.
The server sends its certificate to the client for authentication and may request a certificate from the client. The server sends the "Server hello done" message.
If the server has requested a certificate from the client, the client sends it.
The client creates a random Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server.
The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret.
The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends "Client finished" message.
Server receives "Change cipher spec" and switches its record layer security state to symmetric encryption using the session keys. Server sends "Server finished" message to the client.
Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.
The WCF request/responses will all be after the client/server have switched to using the session key (symmetric key) for encryption. It won't be using the certificate private/public keys at this point.
I was looking into SSL and some of the steps that are involved to set up an encrypted connection between a server and a client computer.
I understand that a server key and certificate is sent to the browser, and that a secret code is being calculated, like they say in the following video:
http://www.youtube.com/watch?v=iQsKdtjwtYI
around 5:22, they talk about a master secret code that is being calculated to start talking in an encrypted way.
My question now is: before the connection is actually encrypted (the handshake phase), all communication between the server and the client can be sniffed by a packet sniffer. Isn't it then possible to sniff the encryption key or other data that is used to set up a secure connection?
From the Wikipedia summary, I think the key part you're interested in is:
The client responds with a ClientKeyExchange message, which may
contain a PreMasterSecret, public key, or nothing. (Again, this
depends on the selected cipher.) This PreMasterSecret is encrypted
using the public key of the server certificate.
This is why the public key is so important. If you use the wrong public key, you're vulnerable to man in middle attacks.
Witness the justified worry whenever bogus SSL certificate issues (e.g. DigiNotar).
The secret key itself isn't transmitted at all, so it can't be sniffed. It is computed independently at both ends. The materials it is computed from is called a PreMasterSecret which is encrypted with the public key of the server certificate. So unless the server's private key has been compromised the secret key can be neither sniffed nor calculated independently.
Mostly, my confusion seems to be eminating from my attempts to understand security within the context of WCF. In WCF, it looks like certificates can be used for the purpose of authentication, as well as encryption. Basically, I am trying to understand:
How can an X509 certificate be used as an authentication token? Aren't ssl certificates usually made to be publically available? Wouldn't this make it impossible for them to be used for authentication purposes? If not, are there some protocols which are commonly used for this purpose?
When encrypting messages with WCF, are certificates used which have been issued only to the client, only to the server, or to both? If certificates from the client and server are both used, I'm a little unclear as to why. This mostly stems from my understanding of https, in which case only a certificate issued to the server (and chained to some certificate issued by a root CA) would be necessary to establish an encrypted connection and authenticate the server.
I'm not entirely sure this is the correct forum. My questions stemmed from trying to understand WCF, but I guess I would like to understand the theory behind this in general. If it's a good idea, please suggest the correct forum for me. I'd be happy to try to get this question migrated, if necessary.
Thanks in advance!
Well this is pretty complex question. I will try to explain some parts but avoiding as much detail as possible (even after that it will be pretty long).
How does authentication with certificate work?
If a holder of the private key signs some data, other participants can use the public key of the signer to validate the signature. This mechanism can be used for authentication. Private and public keys are stored in certificate where private key is kept safe on the holder machine whereas certificate with public key can be publicly available.
How does it relate to HTTPS?
WCF offers transport and message security. The difference between them is described here. The transport security in case of HTTP is HTTPS where only server needs issued certificate and client must to trust this certificate. This certificate is used both for authenticating server to the client and for establishing secure channel (which uses symmetric encryption).
HTTPS also offers variant called Mutual HTTPS where client must have also issued certificate and client uses the certificate to authenticate to the server.
How does message security work and what is a purpose of two certificates in that scenario?
In case of message security each message is signed, encrypted and authenticated separately = all these security informations are part of the message. In case of SOAP this is described by many specifications but generally you are interested in security bindings and X.509 Token profile.
Security binding is part of WS-SecurityPolicy assertions and it is describes how the message is secured. We have three bindings:
Symmetric security binding - symmetric encryption
Asymmetric security binding - asymmetric encryption
Transport security binding - assertion that message must be send over HTTPS or other secured transport
X.509 Token profile specifies how to transport certificates (public keys) in messages and how to use them.
Now if you have symmetric security binding you need only server certificate because
When client wants to send message to the server it will first generate random key.
It will use this key to encrypt and sign request
It will use service certificate to encrypt derived key and pass it to the request as well.
When the server receives the message it will first use its private key to decrypt that key.
It will use decrypted key to decrypt the rest of the message.
It will also use the key to encrypt the response because client knows that key.
Client will use the same key generated for request to decrypt the response
This is symmetric encryption which is much more faster then asymmetric encryption but key derivation should not be available in WS-Security 1.0. It is available in WS-Security 1.1. HTTPS internally works in similar way but the key is the same for the whole connection lifetime.
If you have asymmetric security binding you need two certificates:
Initiator must have its own certificate used to sign requests and decrypt responses
Recipient must have its own certificate used to decrypt requests and sign responses
That means following algorithm
Initiator encrypts request with recipient's public key
Initiator signs request with its private key
Recipient uses initiator's public key to validate request signature
Recipient uses its private key to decrypt request
Recipient uses initiator's public key to encrypt response
Recipient uses its private key to sign response
Initiator uses recipient's public key to validate response signature
Initiator uses its private key to decrypt response
The order of signing and encrypting can be changed - there is another WS-SecurityPolicy assertion which says what should be done first.
These were basics. It can be much more complex because message security actually allow you as many certificates as you want - you can for example use endorsing token to sign primary signature with another certificate etc.
The certificate only has the public key of a public/private key pair. It does not have the private key -- this is separate from the certificate proper. When you connect to an HTTPS server, you can trust that the server is the owner of that certificate because the server must be holding the private key (and hopefully nobody else has it) because otherwise the SSL connection is not possible. If the server did not hold the private key that pairs with the public key of its certificate, it could not present you with a valid SSL connection.
You then can decide whether or not you trust that particular certificate based on one or more certificate authorities (CA) that have signed the chain of certificates. For example, there may be just one CA that has signed this certificate. You have a trusted CA root certificate locally, and so you know that it in fact was your trusted CA that signed that server certificate, because that signature would not be possible unless that CA held the private key to the CA certificate. Once again it is merely holding the private key, in this case that proves who signed the certificate. This is how you can trust the certificate.
When you present the optional client certificate on the SSL connection, the server can trust you because 1) it can see the CA (or CA's) that sign your client certificate, and 2) it can tell that you have your private key in your possession because otherwise the SSL connection would not be possible. So it also works in reverse for the server trusting the client.
You can tell that everybody is honest if you trust that the server and client are keeping their private keys private, and if you trust the source of your root certificates that sign the server and client certificates (or chains of certificates.)
This question already has answers here:
How does browser generate symmetric key during SSL handshake
(2 answers)
Closed 2 years ago.
I have been reading on HTTPS, trying to figure out how exactly it works. To me it doesn't seem to make sense, for example, I was reading this
https://ssl.trustwave.com/support/support-how-ssl-works.php
And notice it says this in the page
Step 4: xyz.com will next create a
unique hash and encrypt it using both
the customer's public key and
xyz.com's private key, and send this
back to the client.
Step 5: Customer's browser will decrypt the hash. This process shows
that the xyz.com sent the hash and
only the customer is able to read it.
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can?
Thanks for any response
Why is HTTPS required?
To verify whether the website is authenticated/certified or not (uncertified websites can do evil things). An authenticated website has a unique personal certificate purchased from one of the CA’s.
Who are CA’s (Certificate Authorities)?
CA’s are globally trusted companies like GoDaddy, GeoTrust, VeriSign etc who provide digital certificates to the websites.
What are public keys and private keys?
Keys are nothing but long random numbers used to encrypt/decrypt data.
Public keys are keys which can be shared with others. Private keys are meant to be kept private.
Suppose Jerry generates a private key and public key. He makes many copies of that public key and shares with others.
Now, others can only encrypt the data using the public key and that data can only be decrypted by the private key of Jerry.
Another approach is to use public keys to only decrypt the data and private keys to only encrypt the data.
How does a company get a certificate?
Website owner first generates a public key and private key, keeping the private key secret.
He gives a Certificate Signing Request file (CSR) and his public key to the CA.
CA then creates a personal certificate based on CSR including domain name, owner name, expiry date, serial no. etc and also adds an encrypted text (= digital signature) to the certificate and finally encrypts the whole certificate with the public key of the server and sends it back to the website owner.
This certificate is then decrypted with the private key of the website owner and finally, he installs it on the website.
Note: That encrypted text is the digital signature of the CA. That
text is encrypted by the private key of the CA and can only be
decrypted by a public key of CA.
When you install your operating
system or Browser, root-certificates from many trusted CA's like
GeoTrust, VeriSign, GoDaddy etc. come with it. These root-certificates
contain the public key of that CA provider which helps decrypt the
signature.
HTTPS security can be split into 2 parts (Handshakes):
1. To validate the certificate of a website:
1) When you enter the URL www.Google.com, Google’s server gives its public key and certificate (which was signed by GeoTrust) to the Browser.
2) Now browser has to verify the authenticity of the certificate i.e. it’s actually signed from GeoTrust or not.
As browsers come with a pre-installed list of public keys from all the major CA’s, it picks the public key of the GeoTrust and tries to decrypt the digital signature of the certificate which was encrypted by the private key of GeoTrust.
3) If it’s able to decrypt the signature (which means it’s a trustworthy website) then it proceeds to the next step else it stops and shows a red cross before the URL.
2. To create a secure connection (encrypts outgoing and incoming data) so that no one else can read it:
1) As I mentioned, Google sends its public key when you enter www.Google.com . Any data encrypted with this public key can only be decrypted by Google’s private key which Google doesn’t share with anyone.
2) After validating the certificate, browser creates a new key let’s call it Session Key and make 2 copies of it. These keys can encrypt as well as decrypt the data.
3) The browser then encrypts (1 copy of session key + other request data) with the Google's public key . Then it sends it back to the Google server.
4) Google’s server decrypts the encrypted data using its private key and gets the session key , and other request data.
Now, see, server and browser both have got the same copies of session
key of the browser. No one else has this key, therefore, only server
and browser can encrypt and decrypt the data. This key will now be
used for both to decrypt and to encrypt the data.
5) When Google sends the data like requested HTML document and other HTTP data to the browser it first encrypts the data with this session key and browser decrypts the data with the other copy of the session key.
6) Similarly, when browser sends the data to the Google server it encrypts it with the session key which server decrypts on the other side.
Note: This session key is only used for that session only. If the user
closes the website and opens again, a new session key would be
created.
can't get enough of web? behind the scenes when u type www.google.com in browser
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.
First, understand that there are generally two steps of HTTPs communication.
1) Generate a shared symmetric key which can only be known between client and server, no one else knows it
2) With this shared symmetric key, client and server is able to safely communicate with each other without worrying about information being intercepted and decrypted by others.
So the question becomes, how can the client and server generate a secret shared key without being known by others in this open internet? This is the asymmetric algorithm coming to play, a demo flow is like below:
-- Client receives public key from server.
-- Client generates a key string "DummySharedKey" which will be later used as shared key, and encrypt it into "7$&^^%####LDD!!#" with server's public key, Man-in-the-middle may have the public key and might be able to intercept the encrypted data, but the data is useless to him as the data can only be decrypted by sever's private key.
-- Server receives the encrypted key string "7$&^^%####LDD!!#", and decrypt it into "DummySharedKey" with its private key
Above key exchange steps makes sure that only Client and Server can know the shared key is "DummySharedKey", no one else knows it.
So it's critical to understand that it is Client's responsibility to generate the shared key, NOT SERVER! (i think this is what confused you)
I also recommend you to take a look at this video which explains HTTPs very well.
https://www.youtube.com/watch?v=JCvPnwpWVUQ&list=FLt15cp4Q09BpKVUryBOg2hQ&index=3
What I don't understand is, couldn't a hacker just intercept the public key it sends back to the "customer's browser", and be able to decrypt anything the customer can.
Public/private key encryption is based on modulo arithmetics using prime numbers.
Such asymmetric encryption was only discovered in the mid-1970s. It is credited to Diffie and Hellman, and to Rivest, Shamir and Adleman. (Though, both actually rediscovered things already known by the British secret services.)
The wikipedia page on Diffie-Hellman has a detailed example of a secret key exchange through a public channel. While it does not describe SSL itself, it should be handy to make sense of why knowing a public key doesn't reveal the contents of a message.
You might also find this simple RSA example interesting.
I'm studying related topics and read several blogs like how-https-works and how-does-https-work-rsa-encryption-explained/.
I have summarized a sequence diagram based on my study and hope it can be helpful to someone who comes to this thread.
For more details, you can check the blog mentioned.
I have written a small blog post around SSL Handshake between the server/client. 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."
It also describes the symmetric/asymmetric encryption which is used for SSL certificates and data transfer once secure transport is established.
For detailed explanation of SSL, see https://www.ietf.org/rfc/rfc2246.txt
Here are the brief ideas of SSL to answer your question:
1) Using certificates to authenticate. Server certificate is a must and client certificate is optional (only when the server requests it). A certificate is like something to prove who you are and it also contains a public key for asymmetric encryption.
2) Using asymmetric encryption (with public key in the server certificate) to establish a shared symmetric key which is used to transfer data between client and server securely by symmetric encryption (for performance reason because symmetric encryption is faster than asymmetric encryption).
The shared symmetric key is established by exchanging a premaster secret from client side (encrypted with server public key) and is derived from the pre-master secret together with client random and server random (thanks #EJP for pointing this out in the comment):
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
We need the server random and client random to prevent replay attacks that an attacker can capture the previous session and replay it for the new session.
What I don't understand is, couldn't a hacker just intercept the
public key it sends back to the "customer's browser", and be able to
decrypt anything the customer can.
The hacker cannot decrypt the message since he does not know the server private key. Be aware that public key cannot be used to decrypt the message.