From a security perspective, if I give a person a know https url and a password, it is indistinguishable from a know https url with the password appended in the

From a security perspective, if I give a person a know https url and a password, it is indistinguishable from a know https url with the password appended in the path. There is even a standard where you can write https://username:password@example.com/ https://username:password@example.com/ Any distinguishable security property will have to come from elsewhere, such as the web server detecting a brute force scan and blocking the request. Tor can't do this so it has to rely on the address length alone, which now can be 56 characters of A-Z and numbers 2-7. I do not know how plausible it would be to scan the whole key space, but I suspect the tor project considered this when they increase the key size with version 3. In comparison scanning the whole IPv4 network takes around 45m for the zmap project. Let's Encrypt developers have stated interest in .onion, see: https://community.letsencrypt.org/t/if-when-will-le-support-onion-addresses/341/81 https://community.letsencrypt.org/t/if-when-will-le-support-... The additional considerations in regard to tor is that all traffic is already end-to-end encrypted with identity being served through the address. In regard to https there isn't much left, beyond enabling standards like http2 which explicitly require https and browser security features which are only enabled when visiting a https website.