[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 28/10/10 11:31, Gordon Henderson wrote: > > ssl/https is an answer, but in-general, web hosts are loathe to do this > as it does require additional CPU power to do the encryption/decryption > - and going that for every transaction, large graphics, etc. will soon > soak up resources. That and that https/ssl doesn't lend itself that well > to being proxyd by the front-end load balancers/accelerators that most > busy sites use these days more or less rules it out - for now. I think these are less of an issue to running SSL more widely than one might initially expect. Static content is often served via CDNs for performance, and/or from other domains to subvert per server concurrency limits in browsers. So often implementing this bit is easy. Front end load balancing with SSL is easy, you just deploy the SSL in the load balancer leave the back end part in the clear. It does of course require larger load balancers. The problem is that HTTPS will break caching further down the line. If Google can run Google mail entirely in SSL, I believe Paypal is also entirely SSL they days, even the CPU requirements can't be that painful resource wise. However SSL does create other issues. It is harder to troubleshoot, and makes caching behaviour in clients less effective, and inevitably you hit issues with SSL technologies themselves. I think getting to there from the typical web application is harder, since you can't mix content types this means many web applications that mix content from different sources can't go their unless the other content is also available via SSL. We aim to keep one of our own applications SSL clean, so people can opt for SSL everywhere but every so often it breaks (currently broken). I think I will suggest we opt to make it SSL all the time (or by default), which will stop it being broken inadvertently. > So - on an open Wi-Fi access point (e.g. BT fon/openzone, Shoreline > cafe, etc.) what you need to do is establish a VPN tunnel to somewhere > secure and do the web browsing by proxy WPA-TKIP is potentially susceptible to ARP poisoning, so using WPA without checking which algorithm doesn't evade the problem (just means the attacker needs another bit of software and slightly more clue). But ARP poisoning has been a well known attack for many years, you could download toolkits to make it easy many years ago. Also ADSL is as I understand it unencrypted, so anyone with access to your phone line anywhere between your router/wireless access point and the exchange can also perform a similar attack in principal. Plus your ISP, anyone the ISP trusts routing announcement from, and various other folk can perform the same attack. If they have access to the physical LAN the attack is pretty easy and doesn't require hardware beyond a laptop and LAN cable. An example of the "hard way" of doing this attack. http://www.securitytube.net/Session-Sidejacking-Demo-video.aspx -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq