0

I have in my home a proprietary device, which I took an interest to see what it does over the network.

I first determined his Ip on my network, and the port used to pass http/s requests, then arp spoofed him to my mitmproxy server.

After this setup I'm able to see unencrypted traffic coming through.

My question is, what are my options to force the device to accept my ssl certificate, in order to see the encrypted traffic as well. Is that even possible? The device software won't help, as this is black box type of device (you plug it in and it automatically work), so I'm left with physically modify the device hardware, or working locally on the same network as I did until now..

I need to note that all the work is done solely for learning purposes.

Thanks.

Nadav96
  • 193
  • 6

2 Answers2

2

For the HTTPS proxying to work, the client must know (and trust!) the mitmproxy CA, i.e. the CA key file must be added to the trust store of the client. What type of device is it? How can you access it?

cyzczy
  • 1,518
  • 5
  • 21
  • 34
  • The problem is I don't have access to the device trusted certificates, it does have a UI, but doesn't offer much network functionality, or none to be exact (it doesn't have wifi, only support LAN), it has one custom open port that used to pass http traffic. I would have used proxy instead of arp spoof if it were easily configurable on the device haha.. – Nadav96 Dec 25 '16 at 22:40
  • Simply put, HTTPS is designed to prevent what you're intending to do. The client only connects to sites it considers trustworthy. You either must be able to tell your client to trust your proxy or you must get your proxy to pretend to actually "be" the targeted site, which in turn is only a theoretical option. – Thomas Dec 30 '16 at 22:29
1

In other-words even if you're MITMProxy can present a certificate, it's certificate's details don't match the intended end server and so will present a certificate error.

So while your solution may allow you to decrypt the encrypted traffic (because the sending machine is using your public certificate, rather than the end points), and though you can re-encrypt the traffic (using the end points public certificate) you're not getting around the problem of non-repudiation (or digital signature).

The end point would normally use its private key to prove it was truly the end point. Anyone would be able to use the endpoints public certificate to verify that were true. However, your MITMProxy doesn't have access to the endpoint's private key so can't convince anyone that it is an acceptable termination point for the SSL traffic.

user34445
  • 503
  • 2
  • 12