HTTPS encrypts the password in transit, but the remote server (verifier) still gets the plaintext of the password. You need a PAKE to use a password without transmitting it to the verifier.
To fair though, there are very few situations where the network is completely trustworthy, like your home network with no one else on it or a VPN direct to an HTTP server.
My understanding was that if you have a valid https session, you are good.
A really really untrustworthy network could MITM your SSL connections and impose itself in front of all of them (Cisco IronPort?) but I think even then your browser will complain unless you've installed a proxy that allows it or a custom root certificate.
If there is no one else on the network between you and the server (like on your wired home LAN with no one else on it), you’re good, regardless of HTTPs.
It’s not enough for the network to be untrustworthy for MITM attacks, they have to use a certificate signed a by root certificate that your computer already trusts.
Organizations with those IronPort gateways use device management and Active Directory policies to pre-install a root certificate into your OS. The IronPort decrypts the original server then re-encrypts it with its own certificate to your computer.
If you used a non-organization managed device on those networks, it would show big scary warnings before letting you visit any HTTPS site that the certificate issuer is not trusted by your computer.
