As I was reading about this and got confused about the keys while trying to understand using the following scenario.
Let say:
-A server S1
-And 3 Clients, C1, C2, C3
Let say C1 want to communicate with server.
How server will authenticate C1 ?
Similarly all the clients want to communicate with the server
Will there be only one public key for all the clients to encrypt the data ?
How a client possess a private key ?
Is it sent by the server ? or self generated ?
I am not very sure whether the OP is asking about SSL in general or the client authentication in SSL. (Note that #zaph is wrong. Client authentication is an optional part of TLS. [2])
In client authentication, client generates its own public and private key pair locally. The client then sends the CSR to a certificate authority to obtain a certificate. This certificate is sent to the server when the server requests it. The server verifies the certificate in the usual way (similar as how browsers verify server certificates). If the client cert is valid, the server can use the identification info present in the cert to determine whether to allow the client or not.
[2] https://www.rfc-editor.org/rfc/rfc5246#section-7.4.6
How server will authenticate C1 ?
C1 will authenticate the server with the help of the servers certificate and by using public key cryptography based on the public key contained in the servers certificate in the CA certificates which signed directly or indirectly the servers certificate.
Will there be only one public key for all the clients to encrypt the data ?
The data will not be encrypted with the public key. Instead each of the client is doing a key exchange with the server which will results in keys for symmetric encryption (and HMAC) specific to the connection between client and server.
For way more details I recommend that you study How does SSL/TLS work? over at security.stackexchange.com which is also the more suitable site to ask such question.
Related
I came across a mbedTLS example on an embedded device and i see a server certificate validation (github.com as example) before downloading a firmware but the only certificate/key coded is the one of github (the CA chain, rather than the github cert itself).
My questions are:
If i perform a server CA verification do i only need the CA certs right?
After the verification of the server, is the communication between the two encrypted at all, meaning is the firmware file exposed in clear or is it crypted? Is the encryptiong done using the private key of the server? (which i suppose it is on the github server). If not what's the use of the server private key? Integrity?
Do i also need a client private key to establish an encrypted connection? If not is the client private key supposed to do the same thing of the server private key but on client side?
I've a general idea of what the answers are but i need certainties.
Regards,
If i perform a server CA verification do i only need the CA certs right?
correct
After the verification of the server, is the communication between the two encrypted at all, meaning is the firmware file exposed in clear or is it crypted? Is the encryptiong done using the private key of the server? (which i suppose it is on the github server). If not what's the use of the server private key? Integrity?
The validation of the servers certificate is part of the TLS handshake but not the end of the handshake. Only after the handshake is completed data are encrypted but also no application data are transferred before the handshake is completed. Thus, a firmware transferred over TLS is encrypted with whatever cipher client and server agreed on - which may be a weak or a strong cipher.
The application data are not encrypted by any private key but by symmetric cryptography. For more details see How does SSL/TLS work.
Do i also need a client private key to establish an encrypted connection? If not is the client private key supposed to do the same thing of the server private key but on client side?
A client does not need a private key for encryption. Apart from that the servers private key should be kept secret (private) and therefore it should not be possible that the client can just use the servers private key. Again, see How does SSL/TLS work for details.
I have some basic questions on certificates. Let me first explain my understanding on SSL authentication.
SSL/TLS basically has two main things,
Authentication - to make sure we are communicating to the correct party on both end.
Encryption - encrypt the actual data transferred between both end.
Certificates have the public key and some additional information. SSL communication between Client (say 'C') and Server (say 'S') works like this,
C initiates the request to S.
S sends its public key to C.
C verifies the identity of S. (Server identity verification or server authentication)
C sends its public key to S.
S verifies the identity of C. (Client identity verification or client authentication)
C generates symmetric or session key (say 'K') and encrypt it with S public key and send it to the server.
Now both C and S have the shared symmetric key which will be used for encrypting the data.
Here I believe steps 4 and 5 meant for Client Authentication is optional. Correct me If I am wrong.
Steps 1 to 5 involves asymmetric mode of encryption i.e only for 'Authentication' and after that it involves symmetric mode of encryption for actual data transfer between them.
My questions are as follows,
I have read from this link (related to IIS server) that there are two types of Certificates. One is client certificate and the other is server certificate. I thought the one in the client side who initiates the request is client certificate and the other is server certificate. What is the difference between client and server certificate w.r.to OpenSSL ?. Is there any difference in CN name in these certificates w.r.to OpenSSL ?
I was asked to use Client Certificates for authentication. Does it mean that we are bypassing server authentication and using only client certificates for authentication ?. I don't think so. As per my understanding, client authentication should be done in addition to the server authentication. Correct me if I am wrong here.
Server Certificates:
Server Certificates are identitiy of a Server to presented by it during SSL handshake.
Typically they are issued by a certificate authority (CA) well known to client, The basis on which the certificate is issued is possession of some publicly known Identifier of that server, for Webserver its the Hostname of the server, which is used to reach server
Example:- http://blog.8zero2.in/
Server certifictae
Server Certificates Purpose
clearly mention by the x509 extension parameter
Certificate Key usage
1. Signing
2. Key Encipherment
Signing :- It means that the key in the certificate can be used to prove the Identity of the server mentioned in the CN of the cerificate , that is entity Authentication .
Key Encipherment :- It means the key in the in the ceritificate can be used to encrypt the session key ( symmetic key ) derived for the session
Client Certificate :-
Client certificates as the name indicates are used to identify a client or a user.
They are meant for authenticating the client to the server.
Purpose of holding a client certificate varies
It may represent possession of email address or Mac-address , usually mapped to the serial number of the certificate
Client Certificates Purpose
clearly mention by the x509 extension parameter
Certificate Key usage
1. Signing
1) The article you link is a good one :-). To put it another way: there is a field in the certificate that says what use(s) it is allowed to be used for. When you create/request a certificate, you are asking for a certificate for a particular use, and the CA signs it on that basis.
It is more secure to use different certificates for different purposes and to ensure that each certificate can only be used for its intended purpose. (Or if you want to be cynical, CAs make you buy separate client and server certs so they get more sales.)
For instance, you might want your web server to be able to identify itself as your company for serving purposes, but not want that same certificate to be able to be used to sign outgoing connections to other businesses.
2) You are correct.
I am tring to figure out how a secure connection between client and server is established. I tried the SSL example provided by boost::asio library. My question is about the certifacte used by client and server. To be specific, I generated a private key(mykey.pem). Then I used this private key to generate a self-signed certificate(mycert.pem) and I used these files as follow:
Server side:
1)context_.use_certificate_chain_file("mycert.pem", error);
context_.use_private_key_file("mykey.pem", boost::asio::ssl::context::pem, error);
context_.use_tmp_dh_file("dHParam.pem",error);
Client side:
2)ctx.load_verify_file("mycert.pem",error);
With this code the handshake is done perfectly. My question is that how come both the server and client use the same certificate ("mycert.pem") in commands 1 and 2? With this approach a client can pretend to be a server easily.right? Do you think that I missed something here?
The certificate is public information.
It's the private key that allows the entity to prove its identity. The client is guaranteed by the SSL/TLS handshake that only the party with the private key matching the public key in the server certificate can be at the other end with the suitable master secret, so as to be able to decipher the communication. The problem it addresses is whether or not the remote party is indeed the one to which the certificate was issued. (This is similar to checking that the picture on the photo ID matches the person in front of you.)
Configuration of the certificate (and not the private key) on the client side is there to tell it which certificates you are willing to trust. The problem it addresses is whether or not to trust what the certificate say (in particular what it says about the identity of the server). This is normally done using a PKI, so as to build trust via 3rd parties (the CAs). (This is similar to checking that the photo ID itself is genuine, and that you can trust what it says.)
What you've done by trusting this specific server certificate is bypass the use of CAs to make an exception and indicate you were willing to trust this particular certificate to be genuine. (This is fine for a handful of certificates, but using a CA allows your trust structure to be more manageable and add other features, such as the ability to revoke certificates.)
I am somewhat confused as to how two-way SSL works. How does the client create its certificate to send to the server? Is it generated from the server and distributed to the client?
Also, what is the advantage of two-way SSL over one-way SSL?
Both certificates should exist prior to the connection. They're usually created by Certification Authorities (not necessarily the same). (There are alternative cases where verification can be done differently, but some verification will need to be made.)
The server certificate should be created by a CA that the client trusts (and following the naming conventions defined in RFC 6125).
The client certificate should be created by a CA that the server trusts.
It's up to each party to choose what it trusts.
There are online CA tools that will allow you to apply for a certificate within your browser and get it installed there once the CA has issued it. They need not be on the server that requests client-certificate authentication.
The certificate distribution and trust management is the role of the Public Key Infrastructure (PKI), implemented via the CAs. The SSL/TLS client and servers and then merely users of that PKI.
When the client connects to a server that requests client-certificate authentication, the server sends a list of CAs it's willing to accept as part of the client-certificate request. The client is then able to send its client certificate, if it wishes to and a suitable one is available.
The main advantages of client-certificate authentication are:
The private information (the private key) is never sent to the server. The client doesn't let its secret out at all during the authentication.
A server that doesn't know a user with that certificate can still authenticate that user, provided it trusts the CA that issued the certificate (and that the certificate is valid). This is very similar to the way passports are used: you may have never met a person showing you a passport, but because you trust the issuing authority, you're able to link the identity to the person.
You may be interested in Advantages of client certificates for client authentication? (on Security.SE).
What you call "Two-Way SSL" is usually called TLS/SSL with client certificate authentication.
In a "normal" TLS connection to example.com only the client verifies that it is indeed communicating with the server for example.com. The server doesn't know who the client is. If the server wants to authenticate the client the usual thing is to use passwords, so a client needs to send a user name and password to the server, but this happens inside the TLS connection as part of an inner protocol (e.g. HTTP) it's not part of the TLS protocol itself. The disadvantage is that you need a separate password for every site because you send the password to the server. So if you use the same password on for example PayPal and MyPonyForum then every time you log into MyPonyForum you send this password to the server of MyPonyForum so the operator of this server could intercept it and try it on PayPal and can issue payments in your name.
Client certificate authentication offers another way to authenticate the client in a TLS connection. In contrast to password login, client certificate authentication is specified as part of the TLS protocol. It works analogous to the way the client authenticates the server: The client generates a public private key pair and submits the public key to a trusted CA for signing. The CA returns a client certificate that can be used to authenticate the client. The client can now use the same certificate to authenticate to different servers (i.e. you could use the same certificate for PayPal and MyPonyForum without risking that it can be abused). The way it works is that after the server has sent its certificate it asks the client to provide a certificate too. Then some public key magic happens (if you want to know the details read RFC 5246) and now the client knows it communicates with the right server, the server knows it communicates with the right client and both have some common key material to encrypt and verify the connection.
In two way ssl the client asks for servers digital certificate and server ask for the same from the client. It is more secured as it is both ways, although its bit slow. Generally we dont follow it as the server doesnt care about the identity of the client, but a client needs to make sure about the integrity of server it is connecting to.
I have some simple questions that i can't get a direct answer in any site because the variety of options in this subject.
In Message Level Security, is mandatory for the client to have an installed certificate? I assume this because the server should encrypt the response message with the client Public Key and then the client decrypt it with his own Private Key.
Is any alternative to not have the certificate in the client and have the messages encrypted in both ways(client->server) and (server->client)?
You can have message security without the client authenticating at all. You only need a client cert if the client is authenticating via certificates
The server cert is used for securing the message in the first case. The client encrypts with the public key of the server and the server can then decrypt with its private key
If you are using secure conversation then the server cert is just used to bootstrap a session key which is then used for encryption/decryption
As long as the server cert has a full chain of trust in the client then there is no need to install the server cert on the client either