Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This is why sites choose to stay vulnerable to Firesheep

google.com

Post reply on HN
Print view View original

81–90 of 143 posts

Re: This is why sites choose to stay vulnerable to Firesheep

#81

Post by erikano »

SpikeGronim wrote: post #77
erikano wrote: post #69

Earlier quoted context omitted.

> Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. I like that, as opposed to requiring users to have to install some plugin before they can even talk to the server.

You may like it but it really reduces the security. A man in the middle can make it look like you don't speak Tcpcrypt by manipulating the first few packets of a connection. It's the same issue as mixing HTTP/HTTPS - the HTTP parts leave you vulnerable. If encryption is not mandatory then it might as well not be there.

I hadn't thought about that. However, at the bottom of tcpcrypt.org, it said "You're not using tcpcrypt =(" to me, so perhaps this could be used to show a (less obtrusive and less intimidating than browsers do when they detect the lack of SSL for some content on the page) warning to users that they are not using Tcpcrypt.

Re: This is why sites choose to stay vulnerable to Firesheep

#82

Post by tommorris »

kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

Is there a lot of GitHub users using IE? ;-)

Re: This is why sites choose to stay vulnerable to Firesheep

#83

Post by dekz »

Udo wrote: post #17
kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

Exactly. Browser makers (including Mozilla/Firefox to a large degree) are responsible for the fact that HTTPS hasn't become the standard protocol as it should have been years ago. It's not only the unproductive mixed content warning but also the insistence of all browsers to only accept expensively bought certificates and throw a very scary and hard to overcome error dialog if a site uses any other kind of cert. Whil…

I don't really understand why these Certificate Authorities exist and need to charge money to sign a digital certificate. Couldn't some sort of user based distributed network be used for authentication? I mean we trust compilers and code patches (which do see many eyes) that we then load onto our PCs. Why can't we trust some similar mechanism of authority that is user based.

Re: This is why sites choose to stay vulnerable to Firesheep

#84

Post by dekz »

drivebyacct2 wrote: post #80
drivingmenuts wrote: post #18

Honestly, how many sites are aware that they are vulnerable? It seems like you assume that because the security-oriented 0.5% of the web knows about it, the rest of the web should, too. For most people, just making sure that their site runs at all is quite enough for them to handle, and keeping current on the latest vulnerabilities is way down on the list. Additionally, fixing a site takes time. How long has Fireshee…

How many sites (that any of us are legitimately worried about) employ webmaster, developers, system admins or other that DON'T know why SSL/HTTPS is important? You can't honestly be giving facebook, twitter, etc a pass on understanding very basic concepts... (sniffing, http (cookies))? Firesheep has been around for 2+ weeks now, but come on, we've all known this has been possible for forever. I'm 20, and I knew how t…

I can understand a possible flaw in a websites attempt to provide secure transfer of data, but just disregarding encrypted communication makes me question their title of web developer.

Re: This is why sites choose to stay vulnerable to Firesheep

#85

Post by notphilatall »

kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

How about: Give every user a monotonically incrementing value that's initialized at the start of the session using HTTPS. For every request, the client will provide the next value in the expected sequence. Listeners won't have the secret key that was exchanged during the HTTPS authentication, and can't issue requests on the legitimate client's behalf.

Forcing the requests to be serial sucks, but if you only do it for privileged actions (as opposed to public page GETs) it should be manageable.

Re: This is why sites choose to stay vulnerable to Firesheep

#86

Post by zbanks »

notphilatall wrote: post #85
kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

How about: Give every user a monotonically incrementing value that's initialized at the start of the session using HTTPS. For every request, the client will provide the next value in the expected sequence. Listeners won't have the secret key that was exchanged during the HTTPS authentication, and can't issue requests on the legitimate client's behalf. Forcing the requests to be serial sucks, but if you only do it for…

Still vernerable to MITM attacks, since an attacker could intercept a legitimate respo se for safe.js, but then send the user a completely different file. You need to sign the entire file. Now you're incredibly close to having SSL.

Re: This is why sites choose to stay vulnerable to Firesheep

#87

Post by nikcub »

eru wrote: post #60
nikcub wrote: post #52

Earlier quoted context omitted.

Wifi connections should probably all use WPA2, even at coffee shops if you just write the password on the wall, it defeats the purpose - everyone who logs in is on the same network again, just like a public network

Everyone being on the same network isn't too much of a problem. They still can't read each others traffic. See http://en.wikipedia.org/wiki/IEEE_802.11i-2004 or http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#WPA2 Every device negotiates its own keys with the access point.

ye I should clarify and add that it means you can see the traffic. even if it is switched

Re: This is why sites choose to stay vulnerable to Firesheep

#88

Post by aschobel »

kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

We had to disable support for Google Maps on Catch.com because the costs was too prohibitive to use their "enterprise" SSL enabled version.

It's a damn shame because it was a really cool integration.

Re: This is why sites choose to stay vulnerable to Firesheep

#89

Post by mambodog »

thwarted wrote: post #75
kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

During the last Velocity conference, one of the last sessions on the last day was a talk from Google guys about how to make SSL faster, because they had recently turned SSL on for all gmail accounts. I asked how they deal with the unlocked icon and warning dialogs for mixed protocol content on the page and the response was that people are so used to the popups and the lock being unlocked, that they (Google) don't con…

Maybe they feel like its not a problem for them because average users trust them without a second thought.

Re: This is why sites choose to stay vulnerable to Firesheep

#90

Post by thwarted »

mambodog wrote: post #89
thwarted wrote: post #75

Earlier quoted context omitted.

During the last Velocity conference, one of the last sessions on the last day was a talk from Google guys about how to make SSL faster, because they had recently turned SSL on for all gmail accounts. I asked how they deal with the unlocked icon and warning dialogs for mixed protocol content on the page and the response was that people are so used to the popups and the lock being unlocked, that they (Google) don't con…

Maybe they feel like its not a problem for them because average users trust them without a second thought.

I suppose; unfortunately, the talk was in the context of making the same kinds of changes to your, or any random, site to make it more feasible to use SSL.

Also unfortunately, when there is mixed protocol content, especially with email, you're not asserting trust of the page origin, but of the additional assets loaded. Google has no control over the content referenced in emails. Encouraging people to ignore the warnings doesn't make anyone safer, if people are not informed enough to care or not.

One of the suggestions was to use shorter key lengths to make SSL less expensive to process, this wasn't considered a welcome suggestion by many of the more security conscious and vocal folks in the room.

Post reply on HN