over the weekend, i almost became a victim of a man-in-the-middle attack. while staying in castro urdiales, i changed into a different hotel on friday. the hotel had free (password protected) wireless internet, as many hotels do have. what was different to other hotels was what happened when i wanted to check my emails via imaps, i.e. imap over ssl, which means that my communication with my email servers are encrypted. my email program informed me that the cerficiates changed and asked me whether i want to store the new certificate. this happened for both imap servers i’m using, namely my own and the one of my institute. i was somewhat surprised – sometimes the institute’s server gets a new certificate, but my own server? without me, the admin, doing anything? i checked the certificates, to find out that essentially nothing changed, except the (rsa) public key, and that the signer changed to “FortiGate CA”. fortigate is the flagship product of an american company called fortinet; this is apparently (related to) secure wireless (wlan) equipment.
part of their software/hardware seems to be something which tries to scan email. scanning unencrypted email communication (via smtp, pop3, imap, …) is easy – as there is no encryption. but they also try to check encrypted communications with email servers. for that, they have to break or circumvent encryption. the easiest way to do that is a man-in-the-middle attack: send traffic through a proxy, and in case someone wants to connect to a imaps server (identified by access to port number 993, i assume), act as if you are the imaps server, send a faked certificate including your own public key, so that the user is transmitting its data to you. then connect to the “real” imaps server and forward the data to it. works pretty well. except that suddenly, you, the client, gets presented with a different public key. if you (more precisely: your email software) stored the certificate (which includes the public key) and compares the certificate it obtains from the proxy (thinking it is the email server) with the stored one, it will note that something changed. and it will hopefully complain to you, the user, and ask you what to do. ask you whether the new certificate is acceptable or not.
if you accept the new certificate, or the software you’re using does it for you (guess that’s “user friendly”, so you don’t have to care about stuff like certificates), the proxy server will read all your communication with the imaps server. some combinations of servers and clients will even ensure that your password is send plaintext (assuming the ssl encryption between client and server), which means that in this case, the proxy server knows your email password. in case the proxy server is used in a malicious way, someone can steal or abuse your data. (especially as passwords are often used for different accounts). more importantly, once the connection is open and you authenticated to the email server, the proxy server can use the open connection to do anything it likes with your email account – it can access all emails stored on your account on that server.
i assume (hope?) that the fortigate software/hardware is not doing this. but anyway, such behavior is very, very bad. (and it opens the question what else is analyzed by the proxy. maybe all your http connections? https seems to be unaffected, as the certificates there were still fine, at least in my case.) luckily, i was able to circumvent this by using the vpn of my university. but not everyone has access to a vpn, or knows how to use that. (and another thing which made me worry is that i don’t have a certificate for my vpn server. so in theory the proxy could also try a man-in-the-middle attack here, and circumvent my use of the vpn. but apparently they don’t, or at least not so easily: when i used the vpn, the email servers returned their “correct” certificates.
well. so what’s the morale of this story? certificates are important! be vigilant when using unknown networks, such as hotel wlans, and use vpn in case you don’t trust it. and use software which correctly checks certificates! and in case you get a warning that a certificate changed, be alert! don’t just click on “accept new certificate” to make your life easier!

i was staying in hannover this weekend, with some friends. we were staying in a kind of hostel there. as probably no one would be there to hand us the keys, we were instructed to check out safe number 3 in the entrance, having the code 3456. sounds really complicated, does it? well, everything worked good, we got our keys. later, someone was trying to open it again, but accidently shifted the code and typed in 2345 instead of 3456. it made “click” again but, surprisingly, door number 3 didn’t opened. after trying all the possibilities, we noticed that door 2 opened. well, we then tried combination 1234 to see that it opens door 1, and 4567 to see that it opens door 4. well, and now guess the combination for door 5 and 6 and 7 and …
do i have to comment on this any further?

leaving traces is easy. just think on how many fingerprints you leave outside your home every day.
and this does not only apply to your real life, but also to your online life. every little thing you do in the internet leaves traces at many different places. for example, think of typing in a url like spielwiese.fontein.de in your browser and pressing enter. first, your browser will put that address in its history (for the pedants out there: i’m fully aware that there are situations in which this does not happen. as i don’t want to blow up this article with technicalities, i’ll simply ignore that.), so days later you can still see that you visited that page. you’ll also find copies of the page in your browser cache. back to the incident itself. in order to access the site, your browser has to establish a connection with my web server and send a request for that site. this request is relayed though different places, every one able to see that you (identifyable by your ip number, which can be traced back to you by your internet provider) requested this specific site (except in case you’re accessing pages using https, in that case, the intermediate relays just know your ip address and the ip address of the destination server).
finally, in any case, my web server will receive your request to deliver the page / from my domain to you. and, as most web servers do, it will note that down into it’s logfile, so i can see that you accessed my site. in fact, i see a lot more. usually, in the request, your browser sends a lot of additional information: for example, a string identifying the user agent. for example, this could be

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4

it usually also includes information on your operating system (in this case, linux) and the exact version of your browser. usually, the browser will also send on which site you were before (the so called referer). this information will be sent for any web page you click on, and for every image or other object contained in that page. hence, i am, without any tricks, able to track you on your way through my web page, and i can see where you’re coming from.
being a bit more clever, i can find out a lot more. for example, i could modify the urls of outgoing links on my page to go though some kind of `gate’, like the forward.php which you might have noticed. then, if you click any link on my site which leaves it, your browser will first contact my webserver to retrieve the forward.php output (which will tell your browser `go to that other site’) and, surprise!, it will leave an entry in the web server’s log that you clicked that link. so i also know where you’re going from my site. next, there’s a lot more information on you which one can find out using javascript, like your screen’s resolution. i’m including a little script on my site which tells the browser to include a little picture, simply consisting of one complete transparent pixel, on every page of my site. to the images url, it adds the screen resolution. so by looking into my server’s log, i can see your screen resolution—at least if you haven’t turned javascript off, but most people have it turned on anyway.
so, now i have a big log file containing a lot of information: which user came from where, looked at which sites, left where, used which browser, which operating system and which screen resolution, at which time. if i feed this log file into an analysis tool, it will gather the information and present them to me in a useable way—whatever that might mean.
are you surprised? some of you won’t be, i know. anyone interested in this subject can find out about this on lots of places on the web (for example, look here). and, in fact, one can do much better than me. first, by using cookies, i could identify you uniquely and connect your different sessions to see how your surfing behaviour varies over a larger time scale. then, i could combine the data from several servers. if i would have data from enough servers, i could throw together a very detailed survey on what you are doing on the web. in that case, i’m your big brother, watching (almost) every step you do online. luckily, for you, i’m not doing that. but other people do. for example, the big web advertisement companies, which have their advertisements on a huge amount of web servers, can see you everytime you view such a web page (if you’re not using an ad blocker). or assume that your web page is using the service of another server which tracks statistics for you. many people are using such services (may it be in the form of a simple counter), so the provider of the service knows when you are looking at which site. and now assume that some of these data collectors cooperate. sharing their huge amount of data. a creepy thought, isn’t it?