Can ISPs see the full adress you put into the adress bar?

[nstgc]

I've been wondering this. If I put in, for instance www.site.com\page will they only see "site" or will they also see "page"?

[bork]

what will be seen is your computer doing a DNS request to resolve it to a IP address.  You computer then will send the URL request to the address that the DNS resolved.  It basically blasted out to a lot of systems to get the request to work.  Its best to think that every time you make a browser request, its the same as standing in the middle of the street yelling "I want to see nenpho pictures from the website porn are us"

[Pentium100]

Yes, the ISP can capture packets and see the request you make to an unsecure (http) server and see the returned page.

(click to show/hide)

GET /167185-akb0048-720p-10-bit-evetaku.html HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.6.30 Version/10.63
Host: bakabt.me
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en,lt-LT;q=0.9,lt;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Referer: http://bakabt.me/browse.php?limit=15&page=1
Cookie: last_torrents=a%3A0%3A%7B%7D; last_visit=a%3A3%3A%7Bi%3A0%3Bi%3A1345257332%3Bi%3A1%3Bi%3A1345257368%3Bi%3A2%3Bi%3A1345257362%3B%7D; __utma=258658201.103968967.1345257098.1345257098.1345257098.1; __utmb=258658201.5.10.1345257098; __utmc=258658201; __utmz=258658201.1345257098.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Cookie2: $Version=1
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers

If you do not want your ISP to know what you are sending, you ave to use secure (https) severs. Then the data is encrypted so the ISP (or anyone else on the wire) cannot decrypt it. If you want to make sure that your ISP does not know what server you are sending the data to, you have to use anonymizing networks, like TOR.

[kitamesume]

^ i think proxies under HTTPS works too.

[Pentium100]

^ i think proxies under HTTPS works too.

HTTPS proxy will make it impossible for your ISP to see the data, but the proxy operator will see it (and will know your real IP). TOR makes it so that no node knows who you are, who you are talking to and what you are saying at the same time (the first node will know your real IP, but not the server or data, the last node will know the server and the data, but will not know your real IP, intermediate nodes know neither your IP nor the data).

[CappinHoff]

^ i think proxies under HTTPS works too.

HTTPS proxy will make it impossible for your ISP to see the data, but the proxy operator will see it (and will know your real IP). TOR makes it so that no node knows who you are, who you are talking to and what you are saying at the same time (the first node will know your real IP, but not the server or data, the last node will know the server and the data, but will not know your real IP, intermediate nodes know neither your IP nor the data).

It won't make it impossible, it'll make it almost impossible. If an ISP really wanted to see what you were doing they could.

[Pentium100]

It won't make it impossible, it'll make it almost impossible. If an ISP really wanted to see what you were doing they could.

What? HTTPS or TOR?
With HTTPS, unless the ISP gets a valid certificate for the destination address, it's not going to happen (at least if the user is careful). It is possible to track someone using TOR, but it is very difficult and requires cooperation of multiple ISPs (since the data goes trough multiple intermediate nodes).
Similar with VPN - unless the ISP manages to get the private key of my CA, it is not going to be able to sniff out what I am sending over my VPN connection.

[CappinHoff]

It won't make it impossible, it'll make it almost impossible. If an ISP really wanted to see what you were doing they could.

What? HTTPS or TOR?
With HTTPS, unless the ISP gets a valid certificate for the destination address, it's not going to happen (at least if the user is careful). It is possible to track someone using TOR, but it is very difficult and requires cooperation of multiple ISPs (since the data goes trough multiple intermediate nodes).
Similar with VPN - unless the ISP manages to get the private key of my CA, it is not going to be able to sniff out what I am sending over my VPN connection.

If you say so. I've worked for an ISP and what they can see and do would surprise you.

[kitamesume]

ISPs can see whatever they want even with all those protection layers, i mean all they'd do is mirror the datas flowing and decrypt them without interfering with the lines. the part with the decrypting though would be what they'd have the most trouble with.

[Pentium100]

If you say so. I've worked for an ISP and what they can see and do would surprise you.

So, which part of my post is wrong (being proven wrong gives me an opportunity to learn)?

The only way to intercept data over VPN (AFAIK) is to do a MITM attack, however, certificates were created for the purpose of making MITM attacks extremely difficult, if not impossible. When connecting to my VPN, the computer only trusts the certificates issued by the CA that is in my server, so, unless you manage to hack that server and get the private key of the CA (assuming that server is actually connected to the network), you are not going to be able to impersonate my VPN server. A certificate from Verisign is no good, you need the one from my server.
Well, or the implementation could have some serious bugs allowing anyone to decrypt the captured data, but hopefully that bug can be found and patched.

HTTPS works similarly, but the downside is that there are a lot of CAs that issue certificates, If the ISP manages to persuade Verisign (or someone else) to issue it a certificate that lets it identify as my bank, then there's a problem.

ISPs can see whatever they want even with all those protection layers, i mean all they'd do is mirror the datas flowing and decrypt them without interfering with the lines. the part with the decrypting though would be what they'd have the most trouble with.

Well, if you can't decrypt the data then the protection did its job.

[kitamesume]

with encryptions having a standard table all it would take is time imho =P

[Pentium100]

with encryptions having a standard table all it would take is time imho =P

What standard table? You mean rainbow tables? Those are for hashes (which are different than encryption) and can be easily defeated (by using salt).

And yes, any encryption can be decrypted, given enough time. Though for the better algorithms, the time approaches (and exceeds) the current age of the universe.

[Pagonis]

Yes, the ISP can capture packets and see the request you make to an unsecure (http) server and see the returned page.

(click to show/hide)

GET /167185-akb0048-720p-10-bit-evetaku.html HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 5.1; U; en) Presto/2.6.30 Version/10.63
Host: bakabt.me
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en,lt-LT;q=0.9,lt;q=0.8
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Referer: http://bakabt.me/browse.php?limit=15&page=1
Cookie: last_torrents=a%3A0%3A%7B%7D; last_visit=a%3A3%3A%7Bi%3A0%3Bi%3A1345257332%3Bi%3A1%3Bi%3A1345257368%3Bi%3A2%3Bi%3A1345257362%3B%7D; __utma=258658201.103968967.1345257098.1345257098.1345257098.1; __utmb=258658201.5.10.1345257098; __utmc=258658201; __utmz=258658201.1345257098.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Cookie2: $Version=1
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers

If you do not want your ISP to know what you are sending, you ave to use secure (https) severs. Then the data is encrypted so the ISP (or anyone else on the wire) cannot decrypt it. If you want to make sure that your ISP does not know what server you are sending the data to, you have to use anonymizing networks, like TOR.

Packets? Why so complicated? A lot of ISPs are running Squid or similar software, so checking logs is simpler. Also, https won't help at all, seriously... Use VPN.

[Pentium100]

Packets? Why so complicated? A lot of ISPs are running Squid or similar software, so checking logs is simpler. Also, https won't help at all, seriously... Use VPN.

Transparent proxies can be detected by the end user, also, running a transparent proxy requires more resources than just capturing packets.

By the way, HTTPS helps against transparent proxies - if you try to go to a https site and instead run into a transparent proxy, the browser will throw an error message saying that the certificate does not match (or was not issued by a trusted party). The connection will just not work (or you will have to manually allow the invalid certificate but then you do so knowingly).

[Freedom Kira]

ISPs can see whatever they want even with all those protection layers, i mean all they'd do is mirror the datas flowing and decrypt them without interfering with the lines. the part with the decrypting though would be what they'd have the most trouble with.

with encryptions having a standard table all it would take is time imho =P

It's reeeaalllllyyyy obvious that you don't know what you're talking about.

[kitamesume]

for the most part, yes i don't know what im talking about. what i know is only at the tip of the ice berg, because, well im not into networking.

as for the decryptions, theres already a lot ways to do this.
decrypting ssl
spying on tor

so theoretically its impossible to be fully secure, at the most part you could just mask your line to evade prying eyes.
though now a days putting up a high-level encryption would attract more attention than going bare, what would you think about a regular salaryman renting an armored car and a few tanks just to transport something unknown? suspicious o.o

[Pentium100]

for the most part, yes i don't know what im talking about. what i know is only at the tip of the ice berg, because, well im not into networking.

as for the decryptions, theres already a lot ways to do this.
decrypting ssl

Too bad you didn't link to a specific site about this. However, normally, to decrypt SSL, you either need the private key of the server (so you can decrypt the captured data), a valid certificate with the server's name on it (then you can do a MITM* attack) or a clueless user that ignores certificate warnings (then you can do a MiTM attack without a valid certificate).

* a MiTM attack is the attacker inserting himself between the client and the server, pretending to be the client (to the sever) and the server (to the client), so that the connection is not like this:
client <====encrypted====>server
but this:
client <====encrypted====>attacker<====encrypted====>server
with the attacker being able to read the plaintext data.

However, SSL was designed with this in mind, this is why it uses certificated to validate if the "server" is the actual server or someone pretending to be it.

spying on tor

Yes, it is possible to figure out both endpoints and the data being sent on TOR, it requires a lot of work though and (IIRC) requires targeting a specific user ("What Pentium100 is doing?") instead of tracing back ("Who posted this comment insulting our glorious leader?").

so theoretically its impossible to be fully secure, at the most part you could just mask your line to evade prying eyes.
though now a days putting up a high-level encryption would attract more attention than going bare, what would you think about a regular salaryman renting an armored car and a few tanks just to transport something unknown? suspicious o.o

Maybe I like driving an armored car, own one and use it all the time .

SSL is widely used for banking and logging in to websites (even if they later drop back to unsecure HTTP). Also, Google allows you to use HTTPS with Gmail all the time (instead of just when you are sending the password).

As for "suspicious", a lot of things can be suspicious, someone said that not using Facebook (I do not have an account and do not intend to get one) is suspicious.

Also, it is possible to be fully secure - you just need to want it bad enough to implement one time pad encryption. That is unbreakable, even given infinite time, however, the downside is that you need to meet and give the key to the other party.

[datora]

.

As for "suspicious", a lot of things can be suspicious, someone said that not using Facebook (I do not have an account and do not intend to get one) is suspicious.

I had a job interview about six weeks ago in which I was asked what my Facebook account is, and would I Friend the interviewer so she could check my profile.  When I told her I don't have a Facebook account there was this really awkward pause where she got this look in her eyes like she was trapped in a room with someone who was mentally unstable.  I'm not expecting to hear back from that company.

Just what has happened to the world ..??!  I mean, for teh sake of fuck.  She wasn't trapped. 

But, yeah.  Weird how a company like this is looking for a technology expert, then gets surprised (and scared) that said expert knows that the Internet is somewhat more than just Facebook, and has a rational grip on how to travel t3h Toobz with security protocols in place.  They go on to hire some Tumbling Twit with a cool-looking Facebook profile, then can't figure out why they're getting hacked while said Twit is spending all day updating his social media accounts.

[kitamesume]

then wouldn't the ISP be able to easily launch an MiTM attack? since they're practically [client <====encrypted====>ISP<====encrypted====>server]

wouldnt it be more secure to transfer the files physically then? lols, plus its more manageable within laws since its not the internet anymore *chuckles*.

ps: facebook needs to die, its like it has become the world's biggest ID database >,>

[Freedom Kira]

then wouldn't the ISP be able to easily launch an MiTM attack? since they're practically [client <====encrypted====>ISP<====encrypted====>server]

No. The idea behind a MITM attack is that the MITM is impersonating the client and server by spoofing their security (identity) certificates, so that the attacker is having the client encrypt stuff with the attacker's key instead of the real server's key. Same situation on the server-attacker side.

An ISP is a MITM in a technical sense of the term, but does not act as an attacker because it is merely passing data back and forth between the client and server. It does not know either side's private keys and thus cannot decrypt any of the data passing back and forth.

Read a little bit into public key encryption and security certificates. Verisign is a good topic to read about too, since it is the trusted entity on the Internet that holds all registered security certificates and connects them with identities. If you visit a site via HTTPS and its security certificate is either unregistered or does not match the site it is claiming to be, all modern browsers will tell you.