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!
Related
CocoaMQTT client is running on iOS15 with the SSL enabled as shown in this example. The cert_key.p12 file was merged from the client.crt and client.key files signed by the same (self-created) CA that was used for the MQTT server/broker certificate generation. The MQTT broker is configured to require client's certificate and use its CN as the username. The handshake does not go well - the log complains about the unknown certificate:
New connection from 192.168.1.87 on port 8883.
OpenSSL Error[0]: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
Based on the above error research, the broker does not like the client's certificate, right? In fact, looking at the wireshark's log, it seems like the client does not send the certificate to the server. Is that something I need to enable in the App configuration? Does the Swift CocoaMQTT package even support this feature (provide the cert to the broker)?
EDIT:
I tried running a client with the same cert/key with paho mqtt implemented in python, which also allows to provide the client with the CA certificate, and everything runs ok:
Trying using the same client's cert/key in CocoaMQTT implemented in iOS15 shows the MQTT broker log error message as above and the fatal alert shows up the the wireshark log:
Initially, I thought that the sever did not like (or did not receive) the client's certificate, but that fatal alert package destination is port 8883. So now I tend to believe that it's the client, who does not like the server's certificate. This is expected if the client uses the pool of official CAs to verify the certificate instead of recognizing that its own certificate was issued by the same CA as the server's one. This is further confirmed by setting the allowUntrustCACertificate = true and seems like the handshake is suspended and no more communication occurs:
There's also a debug message on the client's side:
Call the SSL/TLS manually validating function
So it looks like the client will not continue the communication until this validation process occurs. As #Brits mentioned in his comment, there's a callback to validate the cert manually but it is implemented as a part of the delegate. I do see that there's a method mqtt.didReceiveTrust which I assume should be used for cert validation, and I wish to use the closures approach as stated on the README page as giving an example for the didReceiveMessage methond:
Now you can use closures instead of CocoaMQTTDelegate:
mqtt.didReceiveMessage = { mqtt, message, id in
print("Message received in topic \(message.topic) with payload \(message.string!)")
}
With a weak understanding of Swift Closures, I am not able to figure out how to make that function all, so the question now becomes: how to convert that function from the delegate definition into the closure?
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 want to configure Haproxy so that it only requires client certificate when specific URL accessed? Ex:
www.test.com - it proceeds normally.
www.test.com/secure - haproxy requires the client certificate.
To understand why this isn't directly possible requires an understanding of how TLS (SSL) works. TLS encrypts the connection before the HTTP request is sent (over the now-encrypted connection). By the time the URL is known by HAProxy, the time for requiring a client certificate has already passed.
For practical reasons, an endpoint (HAProxy frontend or listen) needs to either require a certificate for connections, or not... however, using verify optional it might be possible to achieve what you want. Using verify optional means that the proxy will ask for a client cert upon connection, and if either the client offers no cert or if the cert is valid according to the ca-file, the client will be allowed to connect. Invalid certs will result in disconnection.
Then, the ssl_c_used fetch could be used to deny requests for that path for clients who didn't present the "optional" certificate, earlier.
http-request deny if { path_beg /secure } ! { ssl_c_used }
The viability of this solution depends on how gracefully browsers behave when asked for a certificate that they would not have -- and all connecting browsers will be asked for a certificate.
But there is no way of doing exactly what you are asking, either in HAProxy or on any other platform since, by design, the path is unknown until after TLS negotiation is already complete.
We procured standard ssl certificate to mydomain.net from godadday.
We shutdown live server mydomain.com, configured new server mydomain.net with ssl, everything works fine.
We have added redirect records in DNS for mydomain.com to mydomain.net
www.mydomain.com redirecting properly to www.mydomain.net
We are experiencing a issue, when any request to https //www.mydomain.com
redirection happening but with untrusted certificate error message.
www.mydomain.com uses an invalid certificate.
The certificate is valid for the following names:
www.mydomain.net , mydomain.net
(Error code: ssl_error_bad_cert_domain)
Godaddy india support not able to resolve the issue, escalated to US support no update from US support.
Please suggest me how to resolve this issue?
Thanks,
ItsR
Redirection inside a HTTPS connection from domain A to domain B needs a proper certificate for domain A too, which does not seem to be in your case. This is because the redirection happens inside the TLS connection, i.e. the TLS connection needs to be established first which needs the proper certificate.
Getting below error
Http Action - Request to host 'sipoc.cloudapp.net' failed: TrustFailure The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
while invoking below WCF RestService on https from Azure scheduler service GET job.
below is the webservice URL
https://sipoc.cloudapp.net/Service1.svc/GetPlayersXMl
Service URL is working fine.
Any help would be appreciated.
If I browse to the URL provided it indicates that the SSL certificate is not trusted.
"The security certificate presented by this website was not issued by a trusted certificate authority.
The security certificate presented by this website has expired or is not yet valid. "
Scheduler jobs will fail as it can't trust the endpoint. You can either use a trusted certificate or just use HTTP (instead of HTTPS).
Although I would never recommend this in production unless you know the cert is valid (i.e. self signed), you can override the default behavior and confirm that the cert is good.
Below is a sample on how to do it in C#. There are a couple of ways to write it. The advantage here is that it remains SSL encrypted (versus falling back to HTTP).
ServicePointManager.ServerCertificateValidationCallback = (sender, certificate, chain, errors) => true;