The TLS server is configured to send the leaf and intermediate certificates on TLS handshake.
The TLS client will validate the trust-chain of the server leaf certificate with the help of intermediate and root certificates. The root certificate must exist local on the client, the server leaf certificate must be sent from the server. However if the intermediate certificate exists locally on the client and is sent from the server - in this case there are two copies of the intermediate certificate available to the validation process. Which copy of the intermediate certificate will be chosen to be used to validate the chain of trust?
It depends on specific implementation of certificate chaining engine and is outside of TLS scope. Certificate chaining engine constructs as much chains as it can by using all available information. After building all chains, CCE eliminates duplicate ones, then based on internal algorithm, selects the best chain which is used for further operations.
There might be a case when local intermediate certificate is better than the one received from TLS handshake. In this case, intermediate certificate received from TLS is not used.
Related
If I understand right, for TLS handshake, client initiates the connection, server returns it's certificate, client verifies the signature on it and then a session key is generated which is used for further communication.
If above process is happening, does it mean that the initial call that the client made was HTTPS? Or is it possible to do TLS handshake for HTTP?
TLS and HTTP/HTTPS are different things, but in practice they are often deployed together, and so the boundaries between them can become a bit blured.
TLS itself can happily be used without HTTP, and is an integral part of many of the other protocols you'll use on a daily basis, such as your email connection (IMAPS/ESMTP etc). When it is used with HTTP (as HTTPS) though, then there are a few TLS extensions that the client can use when establishing the connection, to let the server know that it is expecting an HTTP response (such as the ALPN extension).
Likewise, HTTP can also happily be used without any thought of TLS. However, there exists a collection of HTTP features that have been introduced over the years to either force (or invite) an HTTP connection to migrate to HTTPS (such as the strict-transport-security or upgrade-insecure-requests headers)
HTTPS is simply HTTP inside TLS (or SSL if you're asking this question from a time when dinosaurs roamed the earth).
I am using a setup wherein a chain certificate(Root CA Cert-> Intermediate CA Cert -> Client Cert) is being sent to the Nginx. I need to configure Nginx in such a way that it forwards the entire certificate chain to the middleware. Right now, it is just sending the leaf certificate i.e. client certificate.
I found the following options from the Nginx's documentation (http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate)
1- $ssl_client_escaped_cert
2- $ssl_client_cert
None of the above returns the full certificate chain.
Is anyone aware if there is such an option available ?
This seems to be impossible by design - see https://serverfault.com/questions/576965/nginx-proxy-pass-with-a-backend-requesting-client-certificates
The usage of $ssl_client_escaped_cert (as explained in https://clairekeum.wordpress.com/2018/12/05/passing-client-cert-through-nginx-to-the-backend/) seems to be your only option.
This may not be a complete answer, but thought I'd post some resources that may give you a couple of ideas.
If you want the client cert details downstream, then one option is to avoid terminating Mutual TLS in nginx by using the stream module. Here is an example:
Mutual TLS Secured API Blog Post .
NGINX Config
In this setup there are 2 Mutual TLS connections being routed via nginx:
To authenticate with an Authorization Server - where Mutual TLS is not handled by nginx
To call an API with a certificate bound access token - where nginx terminates TLS
Note that this uses a LUA plugin and the ssl_client_raw_cert property to do the extra work of calculating a SHA256 thumbprint, which NGINX itself does not support.
Generally though it makes sense to externalise Mutual TLS plumbing from application level components, as in the above example. Eg you can forward ssl_client_eacaped_cert to your middleware, but perhaps nginx should do the more detailed work of checking issuers.
In the TLS handshake process, the Certificate Verify message will follow the Client Key Exchange message after the server requested a client certificate. The Certificate Verify contains a digital signature computed over all previous handshake messages including the type and length fields of the handshake messages. This process allows the client to prove that it owns the private key of the client certificate it sends to the server.
The idea came from a practical problem. There is an mTLS enabled server that conducts different action policies based on the client certificate received, for example, different welcome pages for different client certificates. If a layer-7 reverse proxy service like the load balancer is placed in front of the proxied server which also requires decrypting the TLS traffic. The proxied server can only get the client certificate information from the HTTP header (for example, set proxy_set_header with $ssl_client_cert variable in NGINX) which requires modifying the logic of the server.
A simple but very troublesome solution is the reverse proxy service stores all the client certificates and their private keys. The reverse proxy service will use the same client certificate it received during the mTLS handshake process to establish the mTLS connection with the proxied server.
Since the reverse proxy service can choose whether to trust the client or not with its own implementation, it is possible to forge the Certificate Verify message by asking the client to send a second Certificate Verify signature when the proxied server needs the reverse proxy service to do so (I know it's like a man-in-the-middle attack)?
I could find any quick answer on google. Most probably the answer lies somewhere in RFC docs on http or https however I just couldn't (too time consuming ) get those information.
So here is the question:
Is the content of a webpage served through HTTP signed digitally by the server ? Same question for HTTPS.
If yes, how does it work correctly when using a proxy ? In my opinion the proxy could tamper the data, sign the tampered data with it's own private key, and claim that the corresponding proxy's public key is actually the genuine public key of the original server ? I am assuming that the client can't check the original server's public key, because there is a proxy which could lie.
I am sorry if this is a dump question and easy searchable on the internet, but every answer I found posed some doubts to me.
Thanks for your help :)
Content sent via HTTPS is encrypted, clients verify the authenticity of the host certificates with whom they are communicating. The server uses a TLS/SSL key/certificate which is signed by certificate authorities (CA) The CAs make sure that they only sign the certificates of the rightful owners of a domain. The certificates of the CAs them-self are installed in you browser/OS. By using these pre-installed certificates, the browser can check if the key used by the remote server is signed by a trusted CA.
A man-in-the-middle does not have the original key, nor another key signed by a CA for the domain in question. Therefore, a man-in-the-middle cannot modify the content without breaking HTTPS.
On the other hand, if you want to use a proxy to cache requests, the proxy can terminate the HTTPS connections. This means the proxy has its own connection to the server and verifies the certificates. In order to secure the connection to the client, the proxy acts as a CA and uses a HTTPS connection with self-signed certificates. To avoid that your browser complains about an insecure connection, you need to install the proxies own CA certificate.
HTTP content is not signed and can be tampered with.
Edit 2018-06-15:
I wasn't really precise with the term "signed" here. The server does not actually sign the content it sends. This means if you store the responses from the server, you cannot prove that they came from that server, in other words: standard TLS dose not provide non-repudiation. However, the authenticity of the server is established during the handshake. The client encrypts a master-key with the servers public key. Only servers in possession of the private key can decrypt the master-key and derive session keys from them.
CAs, on the other hand, actually sign the certificates. A CA cannot validly deny that it signed for the authenticity of a server certificate.
There is something I don't understand, When I don't put certificate at all, the SSL connection is established successfully, I wonder how the server decrypt the message without client certificate.
What is client side certificate is for?
Thanks
As I understand it (the 15000 metre view.)
The server has a public key it publishes in its cert. This is used by your browser to encrypt everything it sends. Only the server can decrypt the info as only it (hopefully) has the private key.
If you have a client cert then you give this to the server to ensure that it encrypts stuff to you so only you can decrypt it (again with your private key).
So to me: You can send your credit card info completely freely, knowing that only the server can read it. The client can either then send a proper cert or create a 'temp' one for the session and then the 'public' encryption key to the server secure in the knowledge that no one else will have sent it. Then the comms are encrypted both ways, but separately.
Now from here
A TLS client and server negotiate a
stateful connection by using a
handshaking procedure. During this
handshake, the client and server agree
on various parameters used to
establish the connection's security.
The handshake begins when a client
connects to a TLS-enabled server
requesting a secure connection, and
presents a list of supported
CipherSuites (ciphers and hash
functions).
From this list, the server
picks the strongest cipher and hash
function that it also supports and
notifies the client of the decision.
The server sends back its
identification in the form of a
digital certificate. The certificate
usually contains the server name, the
trusted certificate authority (CA),
and the server's public encryption
key.
The client may contact the server
that issued the certificate (the
trusted CA as above) and confirm that
the certificate is authentic before
proceeding.
In order to generate the
session keys used for the secure
connection, the client encrypts a
random number (RN) with the server's
public key (PbK), and sends the result
to the server. Only the server should
be able to decrypt it (with its
private key (PvK)): this is the one
fact that makes the keys hidden from
third parties, since only the server
and the client have access to this
data. The client knows PbK and RN, and
the server knows PvK and (after
decryption of the client's message)
RN. A third party may only know RN if
PvK has been compromised. From the
random number, both parties generate
key material for encryption and
decryption.
This concludes the
handshake and begins the secured
connection, which is encrypted and
decrypted with the key material until
the connection closes.
This wikipedia article probably gives more info than you'll ever want.
Think about certificate not in terms of encrypting-decrypting, but in terms of authentication. Encryption can be done without certificates at all - just knowing open key is enough. But certificate contains different fields, among them is personality of certificate owner. For web this value is the domain name of the server you wish to connect to. As there are means to check that IP address of the server is always equal to name stated in certificate (forward and backward DNS requests), you can be sure that you're talking to the one you wish to.
In this terms, client certificate issue should be much simpler to understand. Client certificate allows server to authenticate client, so the authentication will be mutual. Server could check, for example, that the client certificate is valid (not expired, not black-listed, etc.).
Using a certificate from either the server or the client will give the endpoints a means of exchanging a shared secret (a symmetric encryption key - or seed).
A secondary purpose for the certificate (and one that's much less well-leveraged these days, relative to "encrypting the channel between endpoints") is to authenticate the endpoint supplying their digital certificate (using the cert and the proof of possession that they also send).
The overwhelming majority of SSL transactions these days are effectively only worried about the "encryption of the channel", not to authenticate the endpoint. (Practically speaking, it's a side benefit on the commercial internet, though the mass of man-in-the-middle attacks out there give us increasing incentive to try to figure out how to really know you're talking to the server - or client - that you think you are.)
In other words, the client certificate would be useful to authenticate (in a more or less "stronger" manner) that the server is interacting with either (a) a "more trusted" client (if all you were doing was ensuring that the cert is among a pool of certs you trust - e.g. mapped to an LDAP/AD directory of users you deem "trusted", or issued from a CA whose issuing practices you "trust") or (b) a specific user that you authenticate (e.g. again, through an LDAP/AD database of user, one - or more uncommonly, or more - of which has been mapped to that certificate through some automated or out-of-band - but either way, hopefully a sufficiently secure - process).