Unless you SET THE PREFERENCE, you are insecure, even if you MANUALLY type in https://mail.google.com/ always.
Because unless you SET THE PREFERENCE, google does NOT set the session cookie to be SECURE.
This is what Mike Perry's tool does: it takes any of your OTHER connections, redirects it to http://mail.google.com/ so your browser spits out the session cookie anyway, and then can redirect you back (so you don't know what happened).
Google's SSL mode for gmail, UNLESS YOU SET THE PREFERENCE, offers you NO protection against an active adversary. And since someone snooping your traffic at starbucks can just as easily inject packets, IT OFFERS NO PROTECTION EVEN IF YOU MANUALLY TYPE IN HTTPS ALL THE TIME, UNLESS YOU SET THE PREFERENCE!!!!
Until Google added the option, it never actually set the GX cookie as secure, so you could do an active-hijack of any OTHER connection they make so that it does a redirect to http://mail.google.com/ and spits out the cookie in the clear for the attacker to capture.
Mike Perry did a great public service by making this tool and making it available.
This attack also works against yahoo mail, hotmail, etc. Just Yahoo, hotmail, etc don't even OFFER SSL, so well, if you use them, your FSCKed.
And Google has known about this problem for a LONG time. EG, see my blog post from last february!.
Google waited for a year before even giving users the OPTION to be protected when SSL is used, and notice that it was only after they found out about Mike Perry's talk that the option was even added.
Also, as I argue, they got it wrong. The checkbox is good, but most users don't know about it. But if a user MANUALLY enters https://mail.google.com/ I argue that google should INFER that the user wants to be SSL-only, at least until they explicitly log out.
Having gotten the demo, I had to buy it. The game is absolutly brilliant. It is a work of art, with mindbending, unique puzzles, AND a lot of fun, all at the same time.
If you have an XBOX 360, install the free demo, and if you like it, buy it.
A client cert, stored on the computer, should NOT be considered one factor in a two factor scheme, because the client computer is far too easy to compromise.
OTOH, it makes a good point that a client cert (OR, hell, just caching the server cert and complaining when it changes!) should be used because its too easy to social engineer a valid cert from a CA
You see, they don't just get the cookie, they also get the referrer field, so Google doesn't just get to see that it is "Nicholas Weaver" who's surfing the web, but can see that I am composing a reply to this article, because the referrer field in the doubleclick adds and google analytics on slashdot allow them to know this!
The Defcon network is bad if you are a sheep, but if you jsut treat it like you are going to visit China (with a return trip through US Customs), its not that bad...
New system, everything through an SSH tunnel, only your necessary working set, and temporary login credentials to throwaway accounts, and its all good!
Quoting Emin Gun Sirer:
Incidentally, the client should be wary of trusting glue records
unconditionally, as they are non-authoritative. A well-known cache
poisoning attack works by tricking clients to believe glue records for
all time and for all queries. Glue should be trusted for only the
lookup in question for only the duration of that lookup. We'll assume
that the clients treat glue properly (even though many do not).
Thus it was already known, two years ago, that trusting Glue records is "well-known cache poisoning attack". Just apparently, not well known enough by the authors of Bind, Microsoft's DNS server, Cisco, etc.
Actually, it is often THIS bandwidth that is the SCARCEST.
Its easy to add bandwidth to a trunk: just light a few more wavelengths. Providing more bandwidth to a cable modem, however, is often very expensive if possible at all, short of pulling new wiring.
The problem with putting anything that provides bandwidth to others on the edge is that it is really inefficient from an aggregate cost-of-bandwidth view.
Bandwidth to a colo facility costs an order of magnitude less than bandwidth to an end-user's location. Thus shifting to a P2P or distributed architecture like this for providing content doesn't actually reduce the costs, instead it substantially increases them. It just shifts the cost from the content provider to the end user or the end user's ISP.
The only real savings is cooling: at the user's home, they don't have the thermal load so they don't need the AC to cool the end-point node. But OTOH, the end user's cost of electricity is higher, so that may be a wash as well.
I had always used an assumed price of $.01 myself, but a bunch of UC Davis folks used Mechanical Turk to estimate the cost of CAPTCHA breaking and to guage what can be hard for a human to solve. They paid only $.0025/CAPTCHA using existing infrastructure.
CAPTCHAs are only able to protect things worth $.0025, no matter how good they are. Simply because at about that price, you can pay humans to solve them for you.
Thus for preventing mail spam, it can work. But to prevent, say, bots from harvesting Ticketmaster, they will always fail, no matter how good they are.
There were lots of us who thought he probably did it: the "she ran away" excuse just never floated, and there was too much stupid circumstantial excuses (I don't care HOW much of a geek you are, doing BOTh the seat AND flooding the car AND saying you slept in the wet sopping car is just ridiculous)
Drive a girl to commit suicide, and get prosecuted for loggin in under a fake name...
I don't know whats worse, the ACTUAL crime that isn't criminal, or the prosecution under criminal statutes for something which shouldn't be considered a crime?
As the ETF is probably only $150-200 or so, just get a phone for $200 and when you decide you hate AT&T, just break the contract.
What I worry about is this is the "tax price", so that in CA (and other states), you may pay $200, but you are paying tax on a $600 phone, which would up the cost to the end user an additional $33.
The problem is, what users expect is long-baseline fairness (measured over minutes to hours) evaluated between users.
What the network provides is either nothing (UDP) or short baseline fairness (measured over round-trip-times) evaluated between flows.
Thus everyone benefits if the short flows from the light users are given priority, as they don't have to wait but it has almost a trivial effect on the big heavy users.
I don't like one aspect of his solution, however, is that it focuses on apps first and then users, when it should be the opposite: focus on users first then applications.
I'm quite sure Amazon would have been delighted to host mozilla.com temporarily on the EC2 cloud, or Akamai on their service, just for the bragging rights of supporting the most downloads EVAR!
Victoria's Secret learned a LONG time ago when broadcasting their "Fashion show" online for the first time: If you want to deal with massive hordes of salavating geeks, you need to use a CDN.
Slashdot Mirror
Unless you SET THE PREFERENCE, you are insecure, even if you MANUALLY type in https://mail.google.com/ always.
Because unless you SET THE PREFERENCE, google does NOT set the session cookie to be SECURE.
This is what Mike Perry's tool does: it takes any of your OTHER connections, redirects it to http://mail.google.com/ so your browser spits out the session cookie anyway, and then can redirect you back (so you don't know what happened).
Google's SSL mode for gmail, UNLESS YOU SET THE PREFERENCE, offers you NO protection against an active adversary. And since someone snooping your traffic at starbucks can just as easily inject packets, IT OFFERS NO PROTECTION EVEN IF YOU MANUALLY TYPE IN HTTPS ALL THE TIME, UNLESS YOU SET THE PREFERENCE!!!!
Until Google added the option, it never actually set the GX cookie as secure, so you could do an active-hijack of any OTHER connection they make so that it does a redirect to http://mail.google.com/ and spits out the cookie in the clear for the attacker to capture.
Mike Perry did a great public service by making this tool and making it available.
This attack also works against yahoo mail, hotmail, etc. Just Yahoo, hotmail, etc don't even OFFER SSL, so well, if you use them, your FSCKed.
And Google has known about this problem for a LONG time. EG, see my blog post from last february!.
Google waited for a year before even giving users the OPTION to be protected when SSL is used, and notice that it was only after they found out about Mike Perry's talk that the option was even added.
Also, as I argue, they got it wrong. The checkbox is good, but most users don't know about it. But if a user MANUALLY enters https://mail.google.com/ I argue that google should INFER that the user wants to be SSL-only, at least until they explicitly log out.
Braid is not listed!?!
Having gotten the demo, I had to buy it. The game is absolutly brilliant. It is a work of art, with mindbending, unique puzzles, AND a lot of fun, all at the same time.
If you have an XBOX 360, install the free demo, and if you like it, buy it.
A client cert, stored on the computer, should NOT be considered one factor in a two factor scheme, because the client computer is far too easy to compromise.
OTOH, it makes a good point that a client cert (OR, hell, just caching the server cert and complaining when it changes!) should be used because its too easy to social engineer a valid cert from a CA
You see, they don't just get the cookie, they also get the referrer field, so Google doesn't just get to see that it is "Nicholas Weaver" who's surfing the web, but can see that I am composing a reply to this article, because the referrer field in the doubleclick adds and google analytics on slashdot allow them to know this!
The Defcon network is bad if you are a sheep, but if you jsut treat it like you are going to visit China (with a return trip through US Customs), its not that bad...
New system, everything through an SSH tunnel, only your necessary working set, and temporary login credentials to throwaway accounts, and its all good!
Ctrl-Alt-Del put it very well.
A: European prices usually include a very high VAT (sales) tax, that can be 10-20%.
B: The european prices were set before the dollar went down the toilet.
Read the quotation again...
Emin Gun Sirer: "Glue should be trusted for only the lookup in question[Emphasis added] for only the duration of that lookup.
This says "No Bailiwick checking at all": glue (additional) records should NEVER be cached. Period.
The interesting thing, DNS glue (additional) poisoning WAS known, just not widely. EG, the SECOND hit for "dns glue poison" in Google gets http://lists.oarci.net/pipermail/dns-operations/2006-May/000537.html.
Quoting Emin Gun Sirer:
Incidentally, the client should be wary of trusting glue records unconditionally, as they are non-authoritative. A well-known cache poisoning attack works by tricking clients to believe glue records for all time and for all queries. Glue should be trusted for only the lookup in question for only the duration of that lookup. We'll assume that the clients treat glue properly (even though many do not).
Thus it was already known, two years ago, that trusting Glue records is "well-known cache poisoning attack". Just apparently, not well known enough by the authors of Bind, Microsoft's DNS server, Cisco, etc.
PayPal IS registered: See Paypal Liscencing page.
Actually, it is often THIS bandwidth that is the SCARCEST.
Its easy to add bandwidth to a trunk: just light a few more wavelengths. Providing more bandwidth to a cable modem, however, is often very expensive if possible at all, short of pulling new wiring.
What, no link? Major FTLC (Failure to Look Cool).
Should be Here .
From the IETF P2PI Meeting are here.
The problem with putting anything that provides bandwidth to others on the edge is that it is really inefficient from an aggregate cost-of-bandwidth view.
Bandwidth to a colo facility costs an order of magnitude less than bandwidth to an end-user's location. Thus shifting to a P2P or distributed architecture like this for providing content doesn't actually reduce the costs, instead it substantially increases them. It just shifts the cost from the content provider to the end user or the end user's ISP.
The only real savings is cooling: at the user's home, they don't have the thermal load so they don't need the AC to cool the end-point node. But OTOH, the end user's cost of electricity is higher, so that may be a wash as well.
Hi!
I had always used an assumed price of $.01 myself, but a bunch of UC Davis folks used Mechanical Turk to estimate the cost of CAPTCHA breaking and to guage what can be hard for a human to solve. They paid only $.0025/CAPTCHA using existing infrastructure.
The Chinese Turing Farms are cheap!
CAPTCHAs are only able to protect things worth $.0025, no matter how good they are. Simply because at about that price, you can pay humans to solve them for you.
Thus for preventing mail spam, it can work. But to prevent, say, bots from harvesting Ticketmaster, they will always fail, no matter how good they are.
He duped a minority, methinks.
There were lots of us who thought he probably did it: the "she ran away" excuse just never floated, and there was too much stupid circumstantial excuses (I don't care HOW much of a geek you are, doing BOTh the seat AND flooding the car AND saying you slept in the wet sopping car is just ridiculous)
Drive a girl to commit suicide, and get prosecuted for loggin in under a fake name...
I don't know whats worse, the ACTUAL crime that isn't criminal, or the prosecution under criminal statutes for something which shouldn't be considered a crime?
As the ETF is probably only $150-200 or so, just get a phone for $200 and when you decide you hate AT&T, just break the contract.
What I worry about is this is the "tax price", so that in CA (and other states), you may pay $200, but you are paying tax on a $600 phone, which would up the cost to the end user an additional $33.
The problem is, what users expect is long-baseline fairness (measured over minutes to hours) evaluated between users.
What the network provides is either nothing (UDP) or short baseline fairness (measured over round-trip-times) evaluated between flows.
Thus everyone benefits if the short flows from the light users are given priority, as they don't have to wait but it has almost a trivial effect on the big heavy users.
I don't like one aspect of his solution, however, is that it focuses on apps first and then users, when it should be the opposite: focus on users first then applications.
I'm quite sure Amazon would have been delighted to host mozilla.com temporarily on the EC2 cloud, or Akamai on their service, just for the bragging rights of supporting the most downloads EVAR!
Victoria's Secret learned a LONG time ago when broadcasting their "Fashion show" online for the first time: If you want to deal with massive hordes of salavating geeks, you need to use a CDN.
If you are going to try to get people to download all at once, use a CDN.
Because http://www.mozilla.com/firefox/ is not working right now.
The Witty worm was specifically targeting a US Military instiution's intrusion detection systems. Do you have any comments on this incident?