The way I'd build this, if I had to, is to a) terminate TLS at the proxy, b) use some an interior protocol (possibly TLS) between the client and the sensor, with the client telling the sensor a digest of (or perhaps the whole) EE certificate presented by the proxy.
This might look like a CONNECT if the proxy will permit it, though using HTTPS to talk to the proxy, not HTTP, naturally. Or it might look like a full-duplex POST to the sensor through the proxy, with TLS being spoken over that POST. If neither CONNECT nor full-duplex POST are options, I might try Websockets, and as a last resort, I'd split up the protocol into multiple POSTs, one for each round trip.
EDIT: At any rate, this sounds exactly like what CONNECT is for, and this covers your needs:
- The client trusts the proxy if it can authenticate it.
The proxy is an explicit client-side proxy, though
it's actually on the server-side, which might seem strange.
- The client trusts the device if it can authenticate it.
The proxy cares only to decide whether to route the
request.
- The proxy may need the client to authenticate to the
proxy -- there exist headers for this, and the client
could also use a user certificate in the TLS
connection to the proxy.
- The client may need to authenticate to the device,
which it can do in the TLS connection to the device
that runs over the outer CONNECT, with all existing
choices for authentication available.
The only strange thing is that historically client-side proxies are accessed w/o TLS, but you really need to use TLS here because the "client-side proxy" is actually far away, across the big bad Internet. That client-side proxies are usually talked to w/o TLS is really a bug.
EDIT: If you find that getting your client to use TLS to talk to the proxy is difficult, just think how much more difficult it is to implement a new protocol from scratch.