2

I'm trying to perform MITM between a remote server and IoT internet bridge device but even though I set add_upstream_certs_to_client_chain=true, I'm still getting 'The client may not trust the proxy's certificate' error so basically it means proxy does not use upstream certificate against client.

This is how I run mitmproxy:

--mode transparent --ssl-insecure --set add_upstream_certs_to_client_chain=true

what am I doing wrong?

LifeIsBeatiful
  • 31
  • 1
  • 2

1 Answers1

1

what am I doing wrong?

You are having the wrong expectation. This option is only intended to fool insecure implementations of certificate pinning which check only the certificates send by the server instead of sending the certificates which are actually used to authenticate the server - see Testing for CVE-2016-2402 and similar pinning issues for more on this.

A proper certificate validation will not be fooled by this option, otherwise man in the middle attacks would be easy. The client actually needs to explicitly trust the certificates created by mitmproxy for this, i.e. you need to make changes on the client side if you want to do an active man in the middle attack.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • i had to delete my previous comment. now I understood certificate pinning and why i might be getting 'client may not trust' error. so if I order same IoT device again and if I perform MITM again as first thing then I should be able to gain Client's trust as I'll be providing first public key. i'm really trying to understand what is missing. can you please navigate me – LifeIsBeatiful Dec 25 '20 at 19:09
  • @LifeIsBeatiful: *"... if I perform MITM again as first thing then I should be able to gain Client's trust ..."* - this will only work if the device relies on Trust On First Use (TOFU) instead of a builtin trust store. Usually TOFU is not used, browsers don't use it either. – Steffen Ullrich Dec 25 '20 at 22:14
  • i still can not understand why i'm not able to bypass this measure. whether it is certificate pinning or public key pinning i'm able to extract it from the handshake between client and server. why can not I imitate the server in a way client will trust? – LifeIsBeatiful Dec 26 '20 at 18:24
  • @LifeIsBeatiful: If there would be a way to man in the middle a TLS connection __without explicit consent from the client__ (i.e. knowingly trusting the MITM CA) then it would be pretty bad for the security of TLS. – Steffen Ullrich Dec 26 '20 at 18:48
  • that is what i mean. i'm able to get upstream server's certificate which client normally trust. and i'm able to extract pinned public key etc because it comes from server which I can use against actual client. why am I getting this error which 'client may not trust proxy's certificate' if I'm providing Server's certificate to the client? i really dont understand. can you please navigate with some links? it really puzzled me – LifeIsBeatiful Dec 26 '20 at 19:14
  • @LifeIsBeatiful: You just add the original servers certificate to the chain but you don't __authenticate__ as this server - instead you authenticate as the MITM proxy. To authenticate as the server you would not only need the certificate (which is public) but also the matching private key. – Steffen Ullrich Dec 26 '20 at 19:27
  • thank you now i got it. even though i convince i'm the server, when client says 'okay let's handshake i wont be able to decrypt the traffic as I dont know the private key'. but how can I verify that it's the problem not sth else? – LifeIsBeatiful Dec 26 '20 at 20:15
  • @LifeIsBeatiful: The private key of the certificate is not about encryption but about authentication. The behavior you are trying to trigger by including the original server chain will only occur with broken clients, i.e. client having a security issue. If you want to check that this is actually the problem you need to reverse engineer the client. – Steffen Ullrich Dec 26 '20 at 21:01