Does SSL/TLS (https) hide the urls being accessed

The HTTPS protocol is equivalent to using HTTP over an SSL or TLS connection (over TCP).

Thus, first a TCP connection (on port 443) is opened to the server. This is usually enough to reveal the server's host name (i.e. www.mysite.com in your case) to the attacker. The IP address is directly observed, and:

1. you usually did an unencrypted DNS query before,
2. many HTTPS servers serve only one domain per IP address,
3. The server's certificate is sent in plain, and contains the server name (between multiple ones, maybe),
4. in newer TLS versions, there is the server name indication, by which the client indicates to the server which host name is wished, so the server can present the right certificate, if it has multiple ones. (This is done to be able to go away from 2.)

Then a TLS handshake takes place. This includes negotiation of a cipher suite and then a key exchange. Assuming at least one of your browser and the server didn't include the NONE cipher in the accepted suites, everything following the key exchange is encrypted.

And assuming there is no successful man-in-the-middle attack (i.e. an attacker which does intercept the connection, and presents a forged server certificate which your browser accepts), the key exchange is secure and no eavesdropper can decrypt anything which is then sent between you and the server, and also no attacker can change any part of the content without this being noticed. This includes the URL and any other part of the HTTP request, as well as the response from the server.

Of course, as D.W. mentions, the length of both request (which contains not much more variable data than the URL, maybe some Cookies) and response can be seen from the encrypted data stream. This might subvert the secrecy, specially if there are only a small number of different resources on the server. Also any follow-up resource requests.

Your password in the URL (or any other part of the request) should still be secure, though - at most its length can be known.

You should assume that the URL is not protected, i.e., that a passive eavesdropper may be able to learn what URL you are visiting.

I realize this contradicts what some other folks are claiming, so I'd better explain.

It is true that everything after the domain name is sent encrypted. For instance, if the url is https://www.example.com/foo/bar.html, then www.example.com is visible to the attacker, while the HTTP request (GET /foo/bar.html HTTP/1.0) is encrypted. This does prevent an eavesdropper from directly seeing the path part of the URL. However, the length of the path part of the URL may be visible to the eavesdropper. In addition, other information -- such as the length of the page you visited -- may also be visible to the eavesdropper. This is a foot in the door for the attacker. There has been some research which uses this foot in the door to learn what URLs you are visiting, if the attacker can eavesdrop on your https traffic.

While there is no guarantee that these attacks will succeed, I suggest that it would be prudent to assume the worst: to assume that an eavesdropper may be able to learn what URLs you are visiting. Therefore, you should not assume that SSL/TLS hides from an eavesdropper which pages you are visiting.

Yes, https does provide integrity for the URL you visited.

P.S. One other caution: in practice, sslstrip and other man-in-the-middle attacks may be successful against many or most users, if the web site is not using HSTS. Those attacks can violate both confidentiality and integrity of the URL. Therefore, if users are visiting web sites that are not using HSTS over an insecure network (e.g., open Wifi), you should be wary that an attacker might be able to learn what pages the users are visiting. One partial mitigation against the sslstrip threat is for users to use HTTPS Everywhere and for sites to adopt HSTS.

As @Paŭlo Ebermann and @Jeff Ferland have told you, the GET request is encrypted under SSL and so is safe. However, don't forget that many web servers log GET requests and parameters, and any credentials or other sensitive information you send via GET could be written to a log somewhere. For that reason, you should use POST (which will also be encrypted under SSL) when submitting sensitive data.

This falls into the category of "encryption isn't magic security that solves all your problems."