I'm finally online at home, some 29 days in to my two year tour with State in Kathmandu. Town's nice, when the garbage men are running and the fuel tankers aren't. Otherwise it's hazardous to walk and the traffic's a bit a much, especially near the gas stations with their WW2-style rationing.
On a more LUG-relevant note, the new ISP seems to be running some sort of Squid proxy, according to some "that host ain't responding" errors that explicitly stated they were coming from a Squid install. If they are running an HTTPS proxy as well then I am extremely nervous - Would anyone care to share a simple test to determine whether or not they are and, if possible, simple ways to bypass a transparent proxy? Bandwidth is scarce in Nepal, but I'm a touch more concerned about protecting my privacy than limiting my bandwidth consumption.
Thanks, Sean
To clarify one point, these folk also NAT/don't have a nice fat block of IPs from ARPA yet. This is fairly common in the third world, but complicates testing for a transparent proxy.
On Tue, Jul 15, 2008 at 7:27 AM, Sean Crago cragos@gmail.com wrote:
I'm finally online at home, some 29 days in to my two year tour with State in Kathmandu. Town's nice, when the garbage men are running and the fuel tankers aren't. Otherwise it's hazardous to walk and the traffic's a bit a much, especially near the gas stations with their WW2-style rationing.
On a more LUG-relevant note, the new ISP seems to be running some sort of Squid proxy, according to some "that host ain't responding" errors that explicitly stated they were coming from a Squid install. If they are running an HTTPS proxy as well then I am extremely nervous - Would anyone care to share a simple test to determine whether or not they are and, if possible, simple ways to bypass a transparent proxy? Bandwidth is scarce in Nepal, but I'm a touch more concerned about protecting my privacy than limiting my bandwidth consumption.
Thanks, Sean
To clarify
You have service in Klandathu? Count your lucky stars!
http://www.universeguide.com/Planet/Klandathu.php
Klandathu is a rocky planet situated on the other side of the Galaxy to us. It is inhabited by bugs that have started an interstellar war with Earth. All the fighting takes place on this planet.
Thanks,
Ron Geoffrion 913.488.7664
-----Original Message----- From: kclug-bounces@kclug.org [mailto:kclug-bounces@kclug.org] On Behalf Of Sean Crago Sent: Tuesday, July 15, 2008 6:28 AM To: KCLUG Subject: Nepal and proxies
I'm finally online at home, some 29 days in to my two year tour with State in Kathmandu. Town's nice, when the garbage men are running and the fuel tankers aren't. Otherwise it's hazardous to walk and the traffic's a bit a much, especially near the gas stations with their WW2-style rationing.
On a more LUG-relevant note, the new ISP seems to be running some sort of Squid proxy, according to some "that host ain't responding" errors that explicitly stated they were coming from a Squid install. If they are running an HTTPS proxy as well then I am extremely nervous - Would anyone care to share a simple test to determine whether or not they are and, if possible, simple ways to bypass a transparent proxy? Bandwidth is scarce in Nepal, but I'm a touch more concerned about protecting my privacy than limiting my bandwidth consumption.
Thanks, Sean _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Sean Crago wrote: | On a more LUG-relevant note, the new ISP seems to be running some sort | of Squid proxy, according to some "that host ain't responding" errors | that explicitly stated they were coming from a Squid install. If they | are running an HTTPS proxy as well then I am extremely nervous - Would | anyone care to share a simple test to determine whether or not they | are and, if possible, simple ways to bypass a transparent proxy? | Bandwidth is scarce in Nepal, but I'm a touch more concerned about | protecting my privacy than limiting my bandwidth consumption.
You need to look at the certificate of the site you're talking to.
It's possible to proxy/NAT/mangle https traffic w/o listening in on the encrypted communication. It's also possible to do a man-in-the-middle decrypt/re-encrypt of the traffic to sniff the contents.
Baring any serious bugs in your crypto implementation, the way to tell if you're talking securely to the site you intend is to examine the certificate used to encrypt the traffic. If the certificate (and hence the public key) are trusted, it should not be possible for anyone to listen-in on your communication, regardless of whether or not they have access to the traffic (assuming, of course, that you trust public-key encryption).
So...make sure the certificate for the far-end was issued to your bank and not to some local Nepal company. And pay close attention to any pop-ups your browser throws about certificates.
...or contact the folks you want to communicate with ITRW and exchange a few one-time pads. :)
- -- Charles Steinkuehler charles@steinkuehler.net
On Tue, Jul 15, 2008 at 09:25, Charles Steinkuehler charles@steinkuehler.net wrote:
You need to look at the certificate of the site you're talking to.
Don't we always do that?
It's possible to proxy/NAT/mangle https traffic w/o listening in on the encrypted communication. It's also possible to do a man-in-the-middle decrypt/re-encrypt of the traffic to sniff the contents.
You could proxy it and pass it on without modification, getting information from traffic shape and access times to deduce what's going on, but this would be very difficult and not very useful. You can certainly NAT https. That's of little importance. You can not "mangle", or more accurately, you can not read or alter the contents of the https connection without compromising one or both hosts on the connection. An attacker would have to install a false certificate authority in your browser, or have the cooperation with whatever site you were accessing, or the issuer of its certificates. Of course, not possible means not possible within the next several thousand years with all the energy of the known universe, assuming there isn't a backdoor in all PKI, as opposed to not possible ever.
Baring any serious bugs in your crypto implementation, the way to tell if you're talking securely to the site you intend is to examine the certificate used to encrypt the traffic. If the certificate (and hence the public key) are trusted, it should not be possible for anyone to listen-in on your communication, regardless of whether or not they have access to the traffic (assuming, of course, that you trust public-key encryption).
Examining the certificate used to encrypt the traffic does not assure you are talking 'securely'. What is 'securely? Examining the certificate tells you what entity you're connecting to, according to who. The certificate itself is only as trustable as its issuing certificate authority. The issuing certificate authority is usually one of the big vendors. Verisign being my example. There are many others. When you downloaded you browser, it came with a set of certificate authorities. Any root certificate installed after that could be used to certify authenticity of an attacker's forged SSL certificates. The Tor people have identified ISPs that do this in foreign countries. They give their users 'software' to install to 'get internets'. That software installs the ISP's root cert, and the ISP can then play verisign on your secure connections. Unless this has happened, you are as secure as anyone in America, at leas as far as https is concerned.
So...make sure the certificate for the far-end was issued to your bank and not to some local Nepal company. And pay close attention to any pop-ups your browser throws about certificates.
Who issued the certificate according to the certificate is not that relevant, as a malicious certificate authority can easily say their Verisign. When a bad guy installs a rogue root cert on your system, he doesn't have to call his certificate authority Evil Inc. What is important is if he can be confident that his computer has not been tampered with to install a bogus root certificate. dmcrypt/LUKS helps with that.
-
Billy Crook -
Charles Steinkuehler -
Geoffrion, Ron P [IT] -
Sean Crago