I have the following certificate chain
Client -> Intermediate -> root
I don't have any control over the server, I'm required to sent the full chain but HttpClient is only sending the client and intermediate certificates during mtls handshake. Without the full chain, the connection is being refused.
Windows deem it unnecessary to send the root certificate because it should be on the server CA trust Store. Is there any work around?
I can achieve the above functionality with curlthin, currently our codebase is heavily based on HttpClient.
Related
I am developing an app with a server part programmed in Go and a client programmed in C#, the connection between the two is made using TCP socket communication, and to ensure the connection I am using TLS.
My question is whether there would be any security problem in my case when using self-signed certificates for TLS communication.
I understand that for a web server that uses https it is necessary to use certificates signed by a certificate authority (CA) but in my case, when connecting my own client application I don't see why I should use one of these.
If anyone knows anything about it, it would be a great help.
Certificates are used for authenticating the end points, and usually the cert is signed by a certificate authority which your client (such as a web browser) already trusts. Using a self-signed cert in that scenario can lead to problems, as the browser won't trust it, and so will pop a warning box. However, the real issue is that for the typical user, a warning from your server is as good as indistinguishable from an attacker using another self-signed certificate. They'll click-away and KABOOM!
If this is a closed environment, and you control both the server and client, then the self-signed certificate is irrelevant. In fact, you don't even need one at all, and may be better off with one of the alternatives, like TLS-PSK, or TLS-SRP.
I am trying to split up my Network traffic into two streams using Mitmproxy.
I therefore have one incoming proxy that accepts traffic from my IPhone and I am using two secondary Proxies to which the Traffic is forwarded. I start the three instances like this:
mitmproxy --mode upstream 127.0.0.1:8083 -s mitmRoot.py --ssl-insecure
mitmproxy --listen-port 8083 --ssl-insecure
mitmproxy --listen-port 8082 --ssl-insecure
I am using the following, very simple Python script to route the traffic:
class mitmRoot:
def request(self, flow: mitmproxy.http.HTTPFlow):
if "github.com" in str(flow.request.url):
flow.live.change_upstream_proxy_server(("localhost", 8082))
addons = [
mitmRoot()
]
Now everything works perfectly fine if I am using only one proxy without any upstream Proxy. I have installed the certificate on the Phone and I can open any website in the browser
However if I add the two upstream proxies I see start seeing certification errors,
mostly for IPhone related stuff:
clientdisconnect
clientconnect
Certificate verification error for gateway.icloud.com: self signed certificate in certificate chain (errno: 19, depth: 1)
Ignoring server verification error, continuing with connection
Client Handshake failed. The client may not trust the proxy's certificate for gateway.icloud.com.
Interestingly I can still establish connections to websites except the ones where I am switching the upstream server. So in this example I am not able to open github.com.
The input proxy now throws cert errors for github.com as well, while the upstream proxy that should be getting the traffic (the one on port 8082) does not see any traffic at all I also see some clientconnect/ clientdisconnect messages in the stream:
https://github.com/
clientconnect
clientconnect
Certificate verification error for github.com: self signed certificate in certificate chain (errno: 19, depth: 1)
Ignoring server verification error, continuing with connection
Certificate verification error for keyvalueservice.icloud.com: self signed certificate in certificate chain (errno: 19, depth: 1)
Ignoring server verification error, continuing with connection
Client Handshake failed. The client may not trust the proxy's certificate for keyvalueservice.icloud.com
I have tried different configuration options, for "--set add_upstream_certs_to_client=true" but so far I am not able to set this up right.
It seems like there is some kind of configuration issue but I don't yet see why it is happening.
Thank You for your help!
From my browser I want to communicate to localhost application using ssl. Here browser(which acts as client) will submit the certificate instead of localhost application(which acts as server). Can Ssl be established in this scenario? So finally it boils down to problem statement can a ssl communication be established by server validating the client certificate and client not validating the server certificate.
The SSL/TLS implementation inside the browser do not support this scenario. A server certificate is always required by the browser with SSL/TLS in order to be sure that the browser is communicating with the expected server (as specified in the URL) and not some man in the middle. Apart from that it is not clear what you want to achieve with such a setup in the first place - maybe there is a better design for your unknown use case.
I have to develop a web application that is both secured over https and uses client authentication certificates. The clients are connecting via invitation, thus it is not intended for users stumbling upon this application by googling around.
The ideal would be to get an intermediate CA certificate form a public root authority and sign both the ssl certificate and use it to issue client authentication certificates. I think that won't work, as simply put I will never qualify for such an intermediate CA (as far as I know, but maybe I am wrong with that).
Second guess: create own Root CA, an intermediate CA and use them. Because of what I wrote about the users, I can embed the necessary certificate chain in the issued certificates. This technically works.
What I would prefer is to get an ssl certificate from public authority and to use my own chain to issue authentication certificates and verify the users. According to this it is possible. But I haven't found anything about how to configure IIS for example (or Kestrel) to request client certificates issued by a specific CA, even less some standard specification where this flow is described.
When I login to my bank account using https, it's only a server side SSL authentication before I enter my login info. My browser does the server authentication based on the certificate info from the server during SSL session. I did not have to do any manual import of server certificate as a trusted cert into my browser. It just happens at runtime during SSL exchange.
On the other hand, I have also seen applications where one has to manually import the certificate (using keytool for e.g.) when you look into their install guide.
Question is: If the certificate info is exchanged in the beginning of SSL session, each side has enough info to authenticate the other side. Why would some apps require manual import of certs from each other between client and server. Be it either or both side authentication.
ADDITIONAL INFO based on the responses below:
I was referring the scenario where I was installing a commercial software based on client-server model with client side SSL authentication turned ON. I installed the server on machine A and 2 clients on different machines all in my private network. During install, server generates a self-signed certificate locally. So do the 2 clients. Once installation is complete, I was asked to copy the clients' certs to server machine and manually import them as trusted certs. Also, copy the server cert to client machines and do the import into their trusted store. They provided a wrapper tool on top of java keytool to perform the cert import. Why is this manual import necessary here? The client and server will anyway exchange certificate info during SSL handshake and perform the authentication. Again, these are self-signed certs and CA involved here.
Note that a certificate is signed by a certificate authority so it depends on which certificate authorities your browser trusts. If the Web server sends a certificate signed by a certificate authority that’s trusted by the browser/application and the certificate is valid, you shouldn’t get any warnings whatsoever.
On the other hand, if the browser receives a certificate from the Web server and it doesn’t trust the certificate authority that signed that certificate, the browser will take some action — at the very least, it should warn you about this. When you import a certificate from a Web site, you’re essentially telling your browser that you have decided to trust that certificate independently of who signed it.
Edit: The same reasoning applies: The keystore keeps a list of trusted certificate authorities and their corresponding certificates. The whole concept of PKI is to have a hierarchy of trusted CAs that emit signed certificates for other parties. If a certificate is self-signed, there’s no valid trust chain — how will Java know that the certificate hasn’t been forged by an attacker?
You’re assuming that a connection between a client and a Web server is implicitly trusted just because certificates are exchanged during the SSL handshake. What if a man in the middle poses as the Web server and, instead of sending the server certificate, sends his own certificate instead? How would clients know that the certificate received by the man in the middle is not to be trusted? If the certificate is signed by a trusted CA, or if the certificate has been manually added to the keystore as a trusted certificate, the client can check whether it should trust the certificate or not.
An SSL server's certificate has to be "vouched for" by a certificate authority (CA). Your browser (or other program) contains a list of CAs it trusts. If you're using a site that is not certified by one of the standard CAs, then you'd have to import its CA in order for the verification to succeed.
No legitimate site (especially for online banking) should require you to use an "alternative" CA. Only do this for sites where you're not sending super-sensitive data.