Hopefully I can make this clear enough.
Goal:
Client Certificate-Authenticated Azure Function
Scenario:
Azure Function App with:
HTTPS Only: set to Yes
Client certificate mode: set to Require
HTTP-triggered Azure Function (Python) which:
Loads client certificate from X-ARR-ClientCert header
Pulls a pre-shared client cert from a database and compares:
Issuer
CommonName
Not Valid Before/After
Hits the listed OCSP endpoint to see if cert is revoked
If properties from each cert match and the certificate has not been revoked, the Function will generate a SAS token for the requestor and send it in the response.
Question:
How is the cryptographic part of client cert auth handled in this scenario?
According to this (great) blog post, there is a CertificateVerify step where...
"The client is authenticated by using its private key to sign a
hash of all the messages up to this point. The recipient verifies
the signature using the public key of the signer, thus ensuring it
was signed with the client’s private key."
I don't see a way to access ...all the messages up to this point. to validate this has occured using the Function (Python) code.
Is this something Microsoft handles automagically (similar to how they forward client certs via the X-ARR-ClientCert header)? Or is this not possible?
From what I implemented in a similar case:
Your app received the certificate via the header and must:
load the certificate (using the library cryptography in python for example)
verify the signature of the certificate with you certificate authority
verify the date of validity
verify that it has not been revoked
Using web app (but the same would apply to functions), the Azure frontend seems to just launch authentication protocol to verify that the client that send the certificate has the private key associated (and launch the mutual auth protocol as described in the blog post). But it does not verify the validity or signature of the certificate.
The CertificateVerify step you're mentionning seems to be handled by the Azure Frontend, I don't think your need to worry about this process.
Hopes this helps !
Related
Currently I want to expose a gRPC Method as Public API and protected by Auth0 (JWT Token), with Istio(Envoy Proxy) will help validating the token on server side. Since the JWT Token is not encrypted by the standard (it is only used to end-user authentication and authorization layer), I want to encrypt the communication using TLS. Also, my public server already have valid certificate.
The problem is on the gRPC Client side. Every example I look, the gRPC Client have to initialize the TLS Connection with server cert pem file. Is it really necessary? Because it adds operational burden and complexity, where we have to distribute our server pem file everytime we renew the certificate AND/OR the client side has to restart the application.
Thanks,
Agung
If you are using a self signed certificate, then yes you must explicitly trust it in your client. If you use a publicly signed certificate on your Server, gRPC will use the Operating System's certificate authorities to verify the cert. (In the case of Java, it uses the JVMs cert authorities.)
If you are using a self-signed certificate you need to specify the server's root certificates in the pem_root_certs member of the SslCredentialsOptions struct passed in when creating a channel, as Carl says.
However if you are using a CA issued certificate, leaving the pem_root_certs member empty will cause gRPC to default to its own master list (reviewable online), not any OS-specific list.
Why a service certificate is required when non-windows client credential specified ?
(i found some specifications on the book said that, a service certificate can be used to negotiate a symmetric key for messaging encryption and signing when negotiation is enabled, but if negotiation is disabled, the client must reference the certificate in the store or including the BASE64 encoded public key, it comes out another question as below)
when the negotiation is disabled, definitely the service certificate will be used for encrypting message, because the client knows the public key, but which one will be used for message signing ?
when the transport security is enabled, and the service certificate is also specified, it said that the certificate will be used for negotiate a SSL session key for message signing and encryption, it applied to all the bindings ,such as HTTP, TCP, etc.
when we are using the windows client credentials, which one will be used for message encryption and signing?
thanks.
IF you choose to authentucate the client you can choose between windows credentials, username, certificate or SAML token. If windows auth is not available you need some other mechanism.
As for the other questions please be more specific. In general client will generate a temporary key (session key) which will be used to encrypt the message. Server certificate will encrypt the session key.
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.
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.)
So I have a WCF service where I have various parts of the service contract with a ProtectionLevel of Sign. I set the credentials on the client side by choosing a certificate from the certificate store. This is fine.
However ....
Does this client certificate need to be in the 3rd party certificate store on the server for this to work?
If this is the case how can I configure a service which accepts any client certificate?
And finally how do I access the signing certificate within the implementation of the operations which require signed messages? Just the signing certificate subject name would do fine!
Thanks
Ah the joy of self answering.
So
"It depends". If you have
ChainOrPeer validation then both the
chain or the presence of the
certificate in the trusted people
store results in success. Only
validating on chain obviously checks
the chain, setting Peer validation
uses the store, and None lets
everything through.
Set the validation mode to none
The SecurityContext for the request
contains an X509CertificateClaimSet
which in turn exposes the
certificate itself.