Ssl

JohnK

Hi all, just got a quick question about SSL encryption. When you browse to a secure URL, what can your network admin, ISP or any other machine along the way see exactly? Obviously they need to know the destination of the data but can they see a full URL for example? So lets say I logged into my bank account with BOI will they just know that I’m doing something on the domain https://www.365online.com or would they be able to see that I’m looking at the page https://www.365online.com/Services/ApplyForALoan.htm? Or would they even see that much as in would they only know the connection is to IP 123.123.123.123 and not what website you're on?

WizZard

Do you go through a work proxy/filter? If so the URL every page you request can be seen (in general)

JohnK

Thanks for the response WizZard. I'm really talking about a more general situation than just a work environment though.

My rudimentary understanding was that the encrypted communication was from the browser on my desktop to the server at the far end and that nothing in-between could read any data that was sent between the two. I’d imagine that’s fine for form posted data but what about the likes of query strings? They form part of the URL so would they be readable and if so doesn’t that defeat the purpose of encrypting the data?

There are also sites that use virtual documents so each URL would look different but its always being handled by the same page. For example you might have some URLs that look like:

• https://www.example.com/1111.aspx
• https://www.example.com/2222.aspx
• https://www.example.com/3333.aspx

but in reality they are really the same as

• https://www.example.com/product.aspx?prodID=1111
• https://www.example.com/product.aspx?prodID=2222
• https://www.example.com/product.aspx?prodID=3333

In this case the query string is really part of the root URL but if its readable by anyone in-between then its not really as secure as you might think.

I suppose I'm really just trying to figure out exactly what can and cant be read by a 3rd party when you're using an encrypted connection regardless if that 3rd party is your network or ISP admin or just someone snooping on your wireless network (assuming the wireless has no encryption of its own).

thanks.

WizZard

Hmm, well you could easily find out by setting up a network tap or sniffing the traffic (check out WireShark )
AFAIK the URL is sent in plaintext (else the server cannot understand it, and just the page data is encrypted.

ecksor

The entire network conversation should be encrypted, which would include the querystring, since that breaks down to connecting to the host and delivering a http get for the required resource over that connection. So no, the query string shouldn't be visible.

WizZard

Wouldn't https://www.example.com/1111.aspx be visible in the above case, which redirects to https://www.example.com/product.aspx?prodID=1111 (of which only the https://www.example.com/product.aspx would be visible)

This has piqued my interest now (must check it out later in the week)

ecksor

Assuming you mean visible to a packet sniffer, then I don't see why it would be. You're splitting up the path of the script and the variables, but that doesn't get done on the network level, that's done at the server. I think you may be getting this idea from reading proxy or webserver logs and seeing what they log but that's not really what's being asked in the first post.

crashedmind

After the initial DNS lookup for www.example.com when you connect everything else should be encrypted i.e. browsing to https://www.example.com/1111.aspx will just show an ssl connection to the associated IP. Ditto with https://www.example.com/product.aspx?prodID=1111.

There are of course ways to hide the initial DNS lookup depending on what you want and what resources you have available.

Referring to the original example, note that when you click on the loans tab on https://www.365online.com you're back to non-ssl browsing i.e. directed to http://www.bankofireland.ie/html/gws/personal/get_loan/ without warning.
The problem here is that you are relying on the server side to determine what pages are encrypted with ssl and what ones aren't...

JohnK

Thanks for the replies everyone
SSL is an area I've completely neglected in the past, I’ve always just assumed it worked and never looked into exactly what it is that it does so its good to finally find out a bit about it.