| < | November 2006 | > | ||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | ||
Everytime I enter my credit card information or important user/pass
information on web I always look for https with a certificate from some trusted
authority, one of the best practices I learned while working with _sekuwity_
people.
But seems like security research has reached such a stage that
software/automated security implementations are not enough to stay secure,
users must be security concious for close to good online security.
Most of the people I came across never really care about those irritating SSL
certificate warnings and just blindly click "OK" to go to their desiring page,
least they know someone might actually be redirecting traffic which is fairly
easy in a packet switched network and considering available tools like
Ettercap, I think its pretty easy..
Now consider this situation, somebody redirecting your traffic to their box
(at L2)
instead of the original gateway by manipulating the ARP cache of your OS (ARP
Poisoning) and ``The Man in the middle`` (between you and the gateway) has
a ruleset on his firewall like:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 31337So? all your https traffic will be redirected to his proxy on port 31337... then? you might establish an SSL session with the ``Man in The Middle`` rather than the real server.. so? possibilities are endless.
My ARP table is static..you cant poison me.. ok.. I will poison the person to whom you are connected :)
Now I have an idea, idea to implement a state based ARP inside the linux kernel. Basically idea is to make linux kernel stateful while processing ARP reponse packets. By default the kernel should be in non-accepting state for ARP response packets.. only when the kernel xmits an ARP packet to satisfy higher level networking requirements, it should go to accepting state for ARP response packet for a given IP-MAC(x) resolution and there should be timeout for switching back the kernel to non-accepting state if no packet arrives.
But again, this is just a very vague thought.. I really need get into the nitty-gritty details of the kernel network stack and the data structures and especially in the kernel land, its very easy to get lost and considering the stuff I am working on professionally these days, I dont think I will be able to do this in very near future..
posted at: 14:55 | path: / | permanent link to this entry
So finally got leave, plane tickets for bangalore..to attend Foss.in
Supposed to land on bangalore on 23rd Nov '06 @ 11:30am or so.. but cant be
that sure since its Air Deccan (the best affordable i could get at this
time).
Going to stay with my old time pal Hirosh in a place called ``Lakkasada`` or
something similar.
Hope to meet lots of people I talk to everyday on IRC (you know who you are)
:)
posted at: 14:30 | path: / | permanent link to this entry