I think you have some confusion between expectations upon the client and the server. This very site (and almost every other) sends your password in plaintext over form data when you sign in.
Hashing (and/or salting) a password client-side before sending it would offer next to no protection, as if the server is expecting this value and the attacker intercepts it, they could just replay the hashed value themselves. Why would they need to know the original password?
The salt for the password should also have been randomly generated when it was first created, and stored alongside the password in the database. The only way for the client to know this value would be to retrieve it based on username alone, when the request is first made. This would reduce the security of the system and allow a dedicated attacker much more leverage to try and crack that single password, if they knew only the username of the user.
The comment you're replying to is correct, encryption is the job of HTTPS.
I don't think this is what the GP meant, but he's accidentally correct in that there is indeed no good reason for a password to reach the server.
The client could do a challenge-response PAKE with the server, proving the client held the password while not transmitting it. The session cookie could be sent from the server as part of that exchange, encrypted so only the holder of the user's password could decrypt it.
That's not how the web works, but it's strictly superior to the accepted standard of the client sending the raw password to the server, and it would be secure even over an active MITM unencrypted link.
... as opposed to using salted hashing like in every tutorial since 1990s.
I think you have some confusion between expectations upon the client and the server. This very site (and almost every other) sends your password in plaintext over form data when you sign in.
Hashing (and/or salting) a password client-side before sending it would offer next to no protection, as if the server is expecting this value and the attacker intercepts it, they could just replay the hashed value themselves. Why would they need to know the original password?
The salt for the password should also have been randomly generated when it was first created, and stored alongside the password in the database. The only way for the client to know this value would be to retrieve it based on username alone, when the request is first made. This would reduce the security of the system and allow a dedicated attacker much more leverage to try and crack that single password, if they knew only the username of the user.
The comment you're replying to is correct, encryption is the job of HTTPS.
I don't think this is what the GP meant, but he's accidentally correct in that there is indeed no good reason for a password to reach the server.
The client could do a challenge-response PAKE with the server, proving the client held the password while not transmitting it. The session cookie could be sent from the server as part of that exchange, encrypted so only the holder of the user's password could decrypt it.
That's not how the web works, but it's strictly superior to the accepted standard of the client sending the raw password to the server, and it would be secure even over an active MITM unencrypted link.