If you are an user of a web site that requires authentication (which means, basically, every site) you usually access it from a network you don’t have control over it, i.e. you don’t know, besides many other things, which DNS server the infrastructure guy has chosen and which version it’s running.This means that you can be exposed to the well known Dan Kaminsky’s DNS hijack attack (you can actually check for this).
Leveraging on this vulnerability (it’s still plenty of DNS that haven’t fixed) it’s possible to implement a man in the middle attack at the application level, stealing your cookies from the authenticated HTTP session: ladies and gentlemen, please welcome CookieMonster. You are exposed even if your login page is protected via HTTPS, as the auth-cookie will be passed in cleartext in every subsequent HTTP interaction.
This worst case scenario requires a flawed DNS implementation (better, a DNS implementation following the original and flawed DNS protocol) so you can be reasonably safe if you always control your DNS or at least can have some trust in the guys that are operating it, but if you are a roaming user you are completely exposed.
So, as you are a competent Linux user, you could fix this in a very simple way: install a DNS caching webserver and use, as your primary DNS, something you could trust.
If you cannot do this, you must ask to your web application provider to fix this issue (some have already done this, as an example you can force all WordPress administration pages to be accessed only via HTTPS, and I’m writing this blog entry via HTTPS so it works).
If you are a system administrator, you must check and eventually fix your DNS implementation, and probably you should take a look at an SSL accelerator, because your connection peers (i.e. users accessing web sites under your control) could be from every possible insecure networks, and my 2 cents are that this man in the middle attack will be only the first of a new kind based on an interaction of different levels on the TCP/IP stack.