Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
Sorry, that was not correct. The "1" was actually an upper-case, sans-serif
"I." Please try again by typing the following letters and numbers, this
time using your nondominant hand and with one eye closed:
-- The New York Times has some fun with CAPTCHA
[...] Sorry, the second "X" was also lowercase. It looked larger because it was closer to the screen than the first. Please try again by retyping the words you see in this box:
As shown in the movie, the tool has a database that contains city profiles
including Paris, Berlin, Amsterdam, Brussels, and Geneva. The tool runs on
the right and on the left is the browser accessing Google Maps over SSL. In
the first attempt, I load the city of Paris and zoom in a couple of
times. On the second attempt I navigate to Berlin and zoom in a few
times. On both occasions the tool manages to correctly guess the locations
that the browser is accessing.
-- Vincent
Berg
Please note that it is a shoddy proof of concept, but it shows the concept of SSL traffic analysis pretty well. It also might be easier to understand for less technically inclined people, as in "An attacker can still figure out what you're looking at on Google Maps" (with the addendum that it's never going to be a 100% perfect and that my shoddy proof of concept has lots of room for improvement).
The publication, citing a former 19-year Nortel employee who oversaw the
investigation into the hack, said Nortel did nothing to keep out the
hackers except to change seven compromised passwords that belonged to the
CEO and other executives. The company "made no effort to determine if its
products were also compromised by hackers," the WSJ [Wall Street Journal] said. Nortel, which sold off parts of its business as part of a 2009 bankruptcy filing, spent about six months investigating the breach and didn't disclose it to prospective buyers.
-- ars
technica reports on a 2000 infiltration of Nortel(Log in to post comments)
Security quotes of the week Posted Feb 16, 2012 9:36 UTC (Thu) by epa (subscriber, #39769) [Link]
To defeat traffic analysis, Google would need to recompress all image tiles to the same size. Those which have more detail could be compressed with a stronger JPEG lossy factor. That might be a good idea anyway to make the speed of the user experience more consistent.
Security quotes of the week Posted Feb 16, 2012 10:08 UTC (Thu) by Fowl (subscriber, #65667) [Link]
They use PNGs for the street maps, so it would be a little harder, playing around with the encoder parameters, and it could strictly only make the experience worse.
They/Browsers could randomize the image load order somewhat though. SPDY probably helps too.
Security quotes of the week Posted Feb 16, 2012 12:43 UTC (Thu) by epa (subscriber, #39769) [Link]
I did some experiments to see if lossy PNG compression were possible (by messing around with the LZ compression window to accept fuzzy matches) but it only really worked acceptably for photographs. There is certainly scope to compress street tiles a bit tighter using some format other than PNG.
Security quotes of the week Posted Feb 16, 2012 18:24 UTC (Thu) by bracher (subscriber, #4039) [Link]
would it work to choose a common size, based on the largest-detail tiles, and pad a comment field in the exif header of the rest of them to reach that size?
Security quotes of the week Posted Feb 16, 2012 18:54 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
no, just add some random garbage in EXIF fields, it doesn't need to be much, just enough to break the exact matches.
You can either go completely random per host (which unfortunantly breaks caching), or you can pad the files to some standard sizes
In any case, unless you already have some idea where the person is looking, trying to find the right set of tiles in a map of the entire world seems like an expensive thing to do (and will require you to frequently find all tile sizes for the entire world, something that I'm sure will trigger google's monitoring system)
Security quotes of the week Posted Feb 17, 2012 11:46 UTC (Fri) by robbe (guest, #16131) [Link]
> [...] unless you already have some idea where the person is looking, [...]
Berg is well aware of that. An attacker with enough resources might be able to scan the whole GM database in reasonable time, though. That includes botnet herders of course.
I also think that Google Maps is not a very juicy target. Maybe my use of these services is untypically low, but I fail to get aggravated by this particular attack. (I use openstreetmap, which is strictly unencrypted.) That said, Berg was only using it as a well-known example of an SSL-encrypted service.
I wonder why padding is not used more often. Is the (small) performance price really too much to pay? Is it hard to get right so that it really protects against these kind of attacks?
Security quotes of the week Posted Feb 17, 2012 13:24 UTC (Fri) by epa (subscriber, #39769) [Link]
Padding should happen at the TLS or even TCP level, not by adding junk data to the HTTP response (which messes up caching, and may not be possible for data types such as plain text which lack a suitable comment field to pad). If done in lower layers of the stack it could be responsive to congestion - so you can be more generous with padding when the link is unloaded, dropping it to just a couple of bytes in harder conditions. While that doesn't give quite the same protection as padding everything by a huge random number of bytes all the time, it can be left on by default.
Security quotes of the week Posted Feb 17, 2012 13:25 UTC (Fri) by epa (subscriber, #39769) [Link]
Thinking about it, padding the HTTP response may be the right solution, just don't alter the message body. Stuff some junk into a header field when serving the PNGs.
|
|||||||||||||