I navigate to my bank's website, e.g., http://www.company.com.  
The homepage begins to load, and the URL reads: https://www.company.com.

I then enter my username and password into the homepage, to log in to
my account.  The URL then reads as follows:

https://login.company.com/Login/Init?UID=123456789&PIN=98765&Submit=Log+In

Question:  In this case, is my UserID and Password readable in transit
by a third party (i.e., is the URL string itself encrypted -- or is it
sent over the internet as plaintext)?

[Please also provide corroboration in the form of link(s) to
reasonably plain-English explanations on the web.]

Thanks!

---

Request for Question Clarification by tisme-ga on 21 Aug 2006 17:04 PDT

Hello rnd13-ga,

If indeed both your username and password are visible in the URL, then
no, this is not secure. Are you sure this is the case?

tisme-ga

---

Clarification of Question by rnd13-ga on 24 Aug 2006 19:18 PDT

Positive.  The example here is essentially copied & pasted from the
site in question [with minor changes, for anonymity].

There seems to be a difference of opinion here ...?

---

Clarification of Question by rnd13-ga on 24 Aug 2006 19:25 PDT

Hi there, Roshini --

Belated thanks for the information.  It appears -- based on the links
you provided -- that the information in question is purported to be
secure.

However, I suppose that's dependent on proper implementation of the
protocol in the browser?  In other words, even if the extra
information in the URL string is theoretically secure ... is it
possible that in practice, depending on the client software, it may
not be?

Also, could you reconcile your response with tisme's ...?

Many thanks!

Hi, 

HTTPS Establishes an underlying SSL conenction before any HTTP data is
transferred. This ensures that all URL data (with the exception of
hostname, which is used to establish the connection) is carried solely
within this encrypted connection and is protected from
man-in-the-middle attacks in the same way that any HTTPS data is.

All HTTP-level transactions within an HTTPS connection are conducted
within the established SSL session, and no query data is transferred
before the secure connection is established.

From the outside the only data that is visible to the world it the
hostname and port you are connecting to. Everything else is simply a
stream of binary data which is enctypted using a private key shared
only between you and the server.

In the example you provide your browser would do this:
1) Derive hostname (and port if present) from from URL. 
2) Connect with to host.
3) Check certificate (it must be 'signed' by known authority, apply
specifically to correct IP address and port, and be current).
4) The browser and server exchange cryptographic data and the browser
receives a private key.
5) The HTTP request is made, encrypted with established cryptography. 
6) HTTP response is received. Also encrypted. 

HTTP is an 'Application Layer' protocol, it is carried on top of the
secure layer. According the SSL specification, drawn up by Netscape,
dictates that no application layer data may be transmitted until a
secure connection is established - as outlined in the following
paragraph:

"At this point, a change cipher spec message is sent by the client,
and the client copies the pending Cipher Spec into the current Cipher
Spec.  The client then immediately sends the finished message under
the new algorithms, keys, and secrets.  In response, the server will
send its own change cipher spec message, transfer the pending to the
current Cipher Spec, and send its finished message under the new
Cipher Spec.  At this point, the handshake is complete and the client
and server may begin to exchange application layer data."
http://wp.netscape.com/eng/ssl3/draft302.txt

So yes. The data contained in the URL query on an HTTPS connection is
encrypted. However it is very poor practice to include such sensitive
data as a password in the a 'GET' request. While it cannot be
intercepted, the data would be logged in plaintext serverlogs on the
receiving HTTPS server, and quite possibly also in browser history. It
is probably also available to browser plugins and possibly even other
applications on the client computer. At most an HTTPS URL could be
reasonably allowed to include a session ID or similar non-reusable
variable. It should NEVER contain static authentication tokens.

The HTTP connection concept is most clearly explained here:
http://www.ourshop.com/resources/ssl_step1.html

---

Clarification of Answer by sycophant-ga on 27 Aug 2006 05:22 PDT

Hi, 

Sorry, also to address your specific issue of improper implementation
leading to insecure transmission of URL data.

The only way I can understand that this might happen is if a proxy
server were in place and the browser totally ignored HTTPS
sepcifications and made a direct HTTP request through that proxy. I am
not sure that this is even possible - I certainly do not think it
would work. No valid connection would be established.

HTTPS is established first with a 'CONNECT' command, a proxy server,
upon receiving this command opens an immediate pass-through binary
connection between the client and server. From that point onwards all
communication is carried out directly between server and client.

If this were not implemented then the browser would make a direct
connection to the proxy and issue a GET request including the full
query string. However this would not work as the proxy would be unable
to establish an HTTPS connection directly. It would essentially
require that the client software not have implemented HTTPS at all.

In practice I think that would be impossible. Any actual
implementation of HTTPS will ensure that all application layer data is
tranmitted only over a secure connection.

Regards,
Sycophant

Excellent response (& clarification).  I agree that this is poor
practice, and was very unpleasantly surprised to see this on the
website of a major corporation.

Thanks!

Hai I believe this is the information you are looking for...
This question is usually geared toward whether or not the path and
query string is encrypted in an HTTPS "get" request (this is where
form field responses or program variables are tagged on to the end of
the url). These fields are stripped off of the URL when creating the
routing information in the https packaging process by the browser and
are included in the encrypted data block.

The page data (form, text, and query string) are passed in the
encrypted block after the encryption methods are determined and the
handshake completes.

A related issue that frequently comes up is whether or not form data
is transmited with encryption if the blank form is displayed without
https. If the form "action" is set to use https then the ssl handshake
will take place before the data is sent. Whether or not the original
form is displayed using https has little to do with the form
submission unless the form action uses a relative path, in which case
the default will be to use the protocol that was used to display the
form.

This applies to both the re

Links
http://en.wikipedia.org/wiki/Https
http://www.ourshop.com/resources/ssl_step1.html
Hope this solves.

Roshini