Is HTTPS proxying (via CONNECT) allowed?

It does not work through Tor. But if you are able to exploit a vulnerability and run the code on the machine (see #3 in the answer), this is possible. I'll edit the answer.

Please note that the long description in the answer explains how the Tor user IP could be revealed in general. I already said this will not work in Whonix. However if other Tor applications/platforms are used, such as Tor Browser Bundle or Tails, this is possible.

So by querying a non-existent subdomain (for example, your username on a website is qwe123, so I write an exploit which queries qwe123.mydomain.org - for example by embedding an image as <img src=qwe123.mydomain.org/img.jpg>), I can force your browser to resolve this domain and log it on my server. To avoid this, your computer should not resolve the domains yourself, and should use a large public DNS (such as Google 8.8.4.4)

The DNS works as hierarchy. Simplifying this a lot, if your computer does DNS resolving by itself, then to find out the IP address of update.microsoft.com your computer first queries which DNS server serves the microsoft.com domain. Then it sends the request to this DNS server (which runs by Microsoft). Thus if I run a DNS server at mydomain.org, and your computer tries to resolve abc.mydomain.org (for example if you type it in your browser), my DNS server will receive this request, and can log the IP address of a computer which sent it.

@SethMichaelLarson: that's the result of being battle-tested. I really doubt Teleport authors write significantly more secure code than OpenSSH authors.

Neither ICMP nor UDP can be "routed" through Tor network because it doesn't have support for that (only for TCP), so it should be blocked completely. With DNS it is a bit different - if Whonix resolves non-Onion DNS requests by itself, it is possible to find your IP by executing code (via exploits) which attempts to resolve subdomains such as <random>.myserver.com - this request will be handled by the DNS server running at myserver.com, which will record the IP.

You can look at track record, which is unfortunately not good for many manufacturers. Notably, all US carriers make their own firmware of popular phones, and they're all bad both in timely delivering updates, and in supporting old phones. The only devices which are updated fast enough, and have decent track record are Google phones.

There are no known unfixed security bugs in the Android OS source code tree. But there's a long path from the bugfix made in the source tree to the actual firmware change on a non-Google Android device. Many devices never receive those fixes, and thus stay unpatched.

Good point. I was mostly focused on Z30 Android support. The native Android phone is not likely then to be significantly more secure; they can add defenses on top of Android (like KNOX), but the effectiveness of them will always be questionable until someone actually tries to break it. Many hardening solutions sounds good on paper, but don't really change much.