How can we actually implement the usage of TLS Channel ID in our web apps for signing things or even using it in way that server side encrypts something for the client side using public key of OBC (Client) and then client can decrypt it using the private-key?
Related
I am authenticating the client using gRPC's client-side SSL/TLS. How do I find out on the server side which user it is?
Use context->Auth_Context()->FindPropertyValues("x509_pem_cert") in C++ to get the peer's (client's) certificate and the client id (SAN?) in the cert.
I'm trying to create a GRPC service to authenticate users. The back end server will be written in Go and the front end will be in Javascript. The connection between client and server must be secure, so I will use SSL/TLS on the server side.
My question has to do with the GRPC client API. When creating a GRPC client to make the request, I need to specify a credentials object:
var ssl_creds = grpc.credentials.createSsl(root_certs);
var stub = new helloworld.Greeter('myservice.example.com', ssl_creds);
There are a number of different credentials objects I can supply, but they all seem to require having the public key for the server present on the client side. How do I get the public key from the server to the client to create the credentials object? Do I have to do any sort of verification myself to ensure that the cert is trusted?
For libraries used to make REST HTTP requests, this step seemingly happens in the background, as I do not have to specify the key. Often you can supply the key as an optional parameter, which is only necessary when the SSL cert is not verified by some certificate authority. How are these libraries (e.g. jQuery or Python's requests library) fetching the necessary public key and performing verification? Is there similar functionality in the GRPC library which I can use for this purpose?
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 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
I know that certificates that are sent by the server cant be faked (still there is MD5 collisions but costy) but what about faking the client ..
in man in the middle attack:
cant we tell the server that we are the legitimate client and take data from that server manipulate it then encrypt it again with legitimate client public key ? how does the client be sure that the data came really from the server ?
in theory .. can we inject any data into the response sent by the server to the client ?..
How are you authenticating the client? SSL client certificates? Or some application level system (cookies etc)?
Here's what SSL does in a nutshell:
Negotiates a Diffie-Hellman shared session key between the two parties
Has the server sign the session key and send the result to the client. Once the client verifies this, the client knows there is no MITM, and the server is who they say they are.
If client certificates are enabled, has the client sign the session key and send the signature to the server. The server now knows there is no MITM and the client is who they say they are.
Encrypts all data in both directions using the shared session key
Typically when you use SSL you won't use client certificates. Strictly speaking, the server does not know if the connection is MITM'd. However, most clients will disconnect if the server certificate is bad. The server assumes that if the client pushes forward with the connection, there is no MITM. Even if Mallory, doing the MITM, chooses not to propagate the disconnect from the client, he has no new information now; all he's done is connected to the server himself. Without intercepting the client's session cookie or other authentication information (which is only sent by the client after verifying the connection is secure) the MITM is useless.
So in short, as long as one end or the other verifies the certificate of the other end before initiating any high-level communication of sensitive information, SSL is secure in both directions.
You're right -- without secure certificate authentication on the client and server there is an opening for a man in the middle attack.
SSL can be "secure both ways" if you use mutual authentication also called two-way SSL.